Keep Your Commitments Few and Manageable
We're talking over the next few posts about the changes in mindset and procedures that become necessary when your development team grows beyond one or two developers. If you missed them, you can go back and read Part One and Part Two
Before we discuss how to organize your dev board, I want to clearly state a few key ideas on which this process relies.
First and foremost, always remember that the work done on an item has no value until a feature is delivered to the product. So, the dev board is optimized for the delivery of compact, clearly-defined features. To that end:
- Work must be clearly and unambiguously defined in both its requirements and administrative steps to deliver. There should never be a question of "What do I do next?" or "Whose responsibility is that?"
- Requirements must not change once a work item has been committed to. The time for feature planning and definition of requirements is before an item is brought onto the dev board.
- Always work on the item that will deliver the most business value to the product. This means your dev board needs input from someone empowered to identify business priorities.
So, now that your vague feature ideas and developer to-dos in The Studio have been defined with clear, unambiguous acceptance criteria, it's time to bring them over to The Factory. You can do this at any interval that makes sense to your organization, but I am a fan of doing this each morning with a few cards. The key is to make sure that you keep a reasonable runway of work items that are ready for work by developers, without planning so far in advance that a change in business priorities could suddenly make all of your planning obsolete.
Your Studio board will have a column for items that are ready to be moved to the Factory. Identify the item in that column with the highest business priority, and bring it over to the Factory. Since it has clear requirements and is compact in scope, your developers can evaluate the complexity of the item with reasonable accuracy. The most important thing that happens here is not the estimation of the work item, but the discussion amongst the developers about what will be required technically to complete the card. The goal is not to hammer out every single edge case, but to determine the major considerations involved. Having several developers discuss the item will unearth hidden complexities that a single developer would likely overlook. Also, this activity builds team-wide understanding of the codebase and prevents knowledge siloing, where individual developers own one part of the project and know nothing about other parts.
The process of estimating is a subject for its own post, so we'll leave the details for another day. (in fact, I don't like the word estimating)
Having arrived at The Factory (aka the Dev Board), we place the item into a column called Ready for Work (also commonly known as the Sprint Backlog). At this point, you have committed to the work item and its requirements should not change. Repeat the process, pulling more work items over from the Studio to the Factory until you feel you have enough items in your Ready for Work column that your developers will definitely not run out of work before the next items are pulled in.
At a minimum, your Factory board should contain four columns. Ready for Work, In Progress, Review, and Done. In practice, your workflow will require more complexity than that, but we're going to focus on those four for right now.
Ready for Work
We've already discussed Ready for Work. It's a priority list. The top-most item in the list is the highest business priority, as defined by whomever in your company is empowered and available to make that call. It should be a consistent person who is prioritizing these items such as a Product Manager or CEO, depending on the size of your company. When a developer is ready to start a new work item she takes the top-most element from that list, self-assigns it, and moves it to the In Progress column
The In Progress column should never contain more than one work item per developer. There are at least two reasons for this: First and foremost, remember that we are optimizing for the delivery of features. Without the constraint of one card per developer, a developer could--in theory--work indefinitely and never actually deliver anything of value. Second, context-switching is costly. If a developer has multiple items in progress at one time, the cost of mentally switching between them means that she is not working as effectively as she could be.
So, now that you have all of your Developer's focus on a single work item, and with the boundaries of that work item clearly defined, the developer can tackle the problem efficiently. It's easy for her to say if something is in or out of scope of this card by consulting the list of Acceptance Criteria. She's already discussed implementation strategies with the rest of the team and has a reasonable plan for how to complete the work.
When the developer finishes the work item and believes that all acceptance criteria have been met, she moves the card to Review. In practice, this may actually be multiple columns depending on how many phases of review you have before shipping code. For instance, you may have a column for Code Review, a column for QA, and a column for User Acceptance Testing. For simplicity right now, we'll just discuss a single, generic Review column.
Whatever type of review is happening, you must ensure that it is clearly understood who must do the review and when. The last thing you want is for a work item to be functionally complete, but languishing in the review column because no one feels like reviewing it.
If the item doesn't pass review, it goes back to Ready for Work, at the top of the queue. Remember that until this item is delivered to the end-user, the work that has been done has no value. We are optimizing our system for delivery of features, and this is still the highest-priority item in the queue, so it goes at the top. It is closer than any other item to actually delivering value, so we want to make sure that it doesn't get neglected in its last mile, but instead redouble our efforts to get it over the finish line.
If the original developer that worked on this item has not started another item in the interim, she should immediately address the feedback that she received from the review. If she has begun another item, then this should be the next item that she takes once she is done with the one currently in progress. When she has addressed whatever kept the card from being accepted, she puts it back in Review. Assuming the item passes review this time, the reviewer then moves the card to Done. Specific steps related to merging code and releasing will vary by organization, but they should be clear and unambiguous, just like the rest of the steps up to this point.
Once you've worked with this system for a little while, you'll find that you hit a steady groove, and the delivery of features to your product becomes much steadier and more predictable.
However, some developers may start to feel that this process robs them of the creativity in their job. The key is to recognize that the creativity has not been removed from the process, but simply moved to a different area. The blue-sky feature dreaming and high-level architectural planning is now happening before a card gets to the Dev board, and it's important to make sure that developers understand that if they want to be involved in that process, they need to be involved in the roadmap discussions. More on that in a later post.
How is this process similar or different to what you're currently practicing in your organization?
Does this sound familiar? Lots of the things in this article will sound familiar to you if you are even somewhat familiar with any of the various Agile Methodologies. That's intentional. I've seen many teams try to adopt Agile all at once, only to get swamped with the details and rituals and abandon the process. Consider this a sugar-coated, bite-sized delivery of some of what Agile has to offer. I'm not an Agile purist (or a purist of any sort) but I do find a lot of value in much of what the various Agile methods have to offer, so I use them liberally. Agile is all about incremental delivery of value to the product, and I'm all about incremental delivery of value to your development team.