In March 2015, Michigan Publishing was awarded a grant from the Andrew W. Mellon Foundation for a project entitled “Building a Hosted Platform for Managing Monographic Source Materials.” In a nutshell, Fulcrum, as the platform is now called, is about building an online platform using the Hydra / Fedora framework to publish media-rich scholarship.
The core team consists of a project lead, project manager, data librarian, UI/UX specialist and three developers.
Below is one of our stories, boldly told through the lens of the project manager. No developers were seriously harmed in the writing of this post.
“We can do that. We’re Agile!”
One can count on this statement to be made at least once during any number of project meetings. True, at the start, it was tinged heavily with sarcasm, and, admittedly, it was me saying it. However, these days, nineteen months into a three year project, while this statement still regularly attends meetings, the skepticism that surrounded it has faded and it’s become a declaration of empowerment.
To be fair, the Agile philosophy was relatively new to the team and while we kept hearing from upper management about how we needed to transition to it, there did not seem to be a clear path to do so. In fact, it wasn’t even really clear what was meant when talking about it. For many, it just seemed like a lot of unnecessary rules and meetings that would slow down development and take control away from developers.
For my part, as the project manager, I wrestled with the terminology for an embarrassingly long time. For some reason, I kept referring to it as a methodology and expected there to be clear steps on how to implement it. Digging in deeper, I hit another wall when finding a plethora of other terms like Scrum, Kanban, Extreme Programming (XP), Lean and a bunch more. Finally, I came to surmise that many of these were the methodologies or tools that help make a team Agile. Overly simplistic? Absolutely, but I took it as a sign of progress, anyway. I was still stymied, however, by which to use. Options are great, but having so many can leave you in a state of paralysis, especially when you’re thinking you can only choose one and the clock is ticking on your project.
Enter DCE
Data Curation Experts (DCE) is a software development and consulting company that specializes in the Hydra open source framework. We decided to hire them back in February 2016 for a couple of reasons: (1) we were having trouble filling the two full-time grant-funded developer positions, and (2) our knowledge of Hydra/Fedora was limited and we needed help getting set up.
Our engagement with DCE was fruitful in a number of ways, but, for me, I’d argue that the most important was showing us how to become Agile. I’m not prone to looking for shortcuts, but DCE really did provide a path for us to follow, and one that we continue to use today, with small tweaks here and there.
Their approach was mostly the Scrum method. By using Scrum, they showed us how to approach development in regular cycles, or sprints, and how to successfully run standups (or daily scrums), sprint planning meetings, and sprint demos (or reviews). They laid the groundwork for understanding and accepting the concept of iterative and incremental development, which forced us to identify and prioritize the most important features and functionality of the platform, without being too precious about them. Which is to say, embracing the idea that work done may need to be redone as the project progresses and we learn more. For a bunch of perfectionists, who always want to do things right the first time, this was not an insignificant or easy feat.
The Board
My favorite aspect of Scrum is the Task Board, probably because I have an unhealthy affinity for sticky notes and Sharpies. The Scrum board helps us visualize the work in the current sprint cycle and track it in columns like Backlog, Ready, In Progress, and Done. As we’re working in GitHub, DCE spun up a Waffle board, which shows us all of our tasks (or user stories) virtually and allows us to move them around based on priority and where they are in the workflow.
This board has really been an essential part of our success. For a while, it was uncomfortable to create tasks. For myself, this came from thinking that the issue was either too small or ill-defined to be created. Others were used to writing down issues in their own personal space, or, felt slowed down by having to officially record the task when they’d much rather be working on it.
After several sprints, however, it became clear that we all had to drop the excuses we were using for not populating the board if we wanted to produce a good product on time. While I wouldn’t claim our practices are perfect, I would say that the board serves as the project’s source of truth and the entire team works hard to keep it so.
Iterating
I’ll be the first to admit that we still have a lot more work to do to improve our understanding of what it means to be Agile and incorporating more tools and methods in order to make us so.
Sure, we should be consistently adding acceptance criteria to tasks. And, yes, our standups do not purely hold to a “what I did yesterday, what I’ll do today, and what blockers I have” format and can meander into longer conversations. Sprint retrospectives don’t routinely hit our calendars, so there isn’t a dedicated time to talk about ways to improve future sprints. And, while the developers are starting to experiment with estimating effort, we haven’t formalized an actual point system, like the Fibonacci sequence, so it’s still a bit of a guess as to how long any one user story might actually take to complete.
For us, when we’re saying we’re Agile, we mean that we’re allowing ourselves to move forward using the information we currently have, while recognizing that it may need to change as the project progresses, and being perfectly ok with that.
Our approach may look scrappy compared to more well-established Agile teams, but I believe that we are on the right road and that we’ll continue to improve.
“We can do that. We’re Agile!” And I say that snark-free.