In working with teams trying to adopt agile, I find many people getting stuck on “things” and not what really matters. Often, people get stuck on a tool, probably because it’s something concrete and something they can feel.
Recently, in a planning session for a new project kickoff, where everyone was only vaguely familiar with agile concepts, the project leader attempted to run a constrained story brainstorming session using an online XP management tool. Things bogged down quickly as the session became more about the tool, which did everything it needed to do but didn’t always quickly support how we were working. The project lead attempted to keep up with our ideas, and it was evident that she was quickly becoming frustrated while the rest of us were getting bored. I figure the meeting would have lasted at least another 90 painful minutes had we continued down this path.
I convinced the project manager to switch to a more flexible technique. We first used the whiteboard to brainstorm stories. This involved a lot of erasing because we were still trying to figure out what we were building. Once we felt like we were on the right track, we scribbled the stories onto index cards. We then applied estimates to all the stories. The estimation exercise was a matter of sorting index cards on the table to be ordered by relative sizes, and then deriving a point scale. The project manager later transferred the stories to the tool to satisfy her needs.
We were able to wrap up our session in about 20 minutes, instead of the 90 minutes I had earlier projected. The project manager was very satisfied and the team members were happy to have had the meeting run expeditiously. When the iteration completes, we’ll revisit the estimation point scale, and I’ll introduce the team to planning poker techniques.
I sometimes think that many people view agile as The Tool. The Tool accommodates tracking agile, therefore agile == The Tool. Even though the Agile Manifesto explicitly says you should emphasize “individuals and interactions over processes and tools,” sometimes you have to remind people of why. The modified planning session became a team working together to brainstorm stories, not a bunch of people trying to use a tool.
My second thought is that many people view the iteration as the core of agile, including many experienced agile practitioners. I don’t think this is wrong, but I do think there are better perspectives.
Iterations are great things. They are potential “ship” points, when you can ship quality completed software to your customers. They are learning opportunities, to help you figure out what’s going wrong before it’s too late. They are data points, letting you know how fast your team is capable of building software. They are correction points: Via retrospectives, you can introduce experiments in subsequent iterations, and see what we can improve. They are negotiation points, allowing customers to change their minds about what’s going to happen next. They are blocks of sanity time for developers, allowing them to put their heads down and concentrate for a couple of weeks without someone interrupting them to change their priorities. They are touchpoints, nice boundaries where you can synch up with other teams.
For all those great things iterations are, iterations aren’t “The Thing.” Agile is primarily about delivering a continual stream of quality business value. That means that stories are The Thing. Ultimately, little else matters.
Why do I think this is important? Because I’ve seen too many teams focus on iterations and not so much on stories. They tackle too few stories, guaranteeing higher levels of risk across an iteration. But, the bigger problem is that teams will open up all or almost all stories at the outset of the iteration, and not complete any of them until the end of the iteration. The iteration becomes a miniature waterfall. Too often, a large number of stories remains not quite done by iteration end.
My suggestion: Focus on implementing and completing stories, not iterations. If your iteration is 10 days, and you have 10 stories of 1 point each, you should have delivered one story by the end of the first day, and two stories by the end of the second day, and so on. Teams focusing on iterations can end up with 80-100% of their iteration at risk for not getting completed—at iteration end, the developers need just “a little more time” on many of the stories. Teams focusing on stories deliver the majority of their stories by iteration end, putting at most 10-20% of their iteration at risk.
About the Author
Jeff Langr is a veteran software developer celebrating his 25th year of professional software development. He’s authored two books and dozens of published articles on software development, including Agile Java: Crafting Code With Test-Driven Development (Prentice Hall) in 2005. You can find out more about Jeff at his site, http://langrsoft.com, or you can contact him via email at jeff at langrsoft dot com.