« Peace for Pachyderms| Main | Stupid Meeting Tricks »
Leaky Projects
I've been sitting through several iteration close and planning meetings, and I was really amazed at the amount of leaky agile projects we have out there.
What's a leaky project? A leaky project is a project that has items on its backlog that are too small to be there. Somehow they have "leaked" from the daily stand-ups -- where they should have been addressed -- into the backlog, where they become a work item and engender all kinds of useless questions and conversations.
Have to spend a few hours installing tool X in order to get a couple of your stories done in a 4-week cycle? Go do it. Making a backlog item out of that is a travesty. Did you suddenly realize that somebody has to go talk to testing to start getting a testing environment set up? By all means, go do it whether it is on your task list or not.
Daily stand-ups (and their weekly counterpart, the weekly "what's the most important things for us to do this week") exist not only to make commitments to perform, they exist in order to spot problems and obstacles quickly and overcome them. If lots of things leak from those meetings into the backlog, pretty soon you've got a backlog full of dozens of small or very small items.
In this scenario, you spend more money working the stories than you do simply getting the thing done in the first place.
We know this intuitively yet somehow we forget when we apply it to larger projects. If the building is on fire, maybe it's time to pack up your stuff and leave. Probably not a good time to put "investigate warm feeling" on a risk list somewhere.
I recently sat through a retrospective, showcase, and iteration planning meeting for a huge agile team of 35 developers. Their project, which is mostly on-track and doing well, has thousands of stories in the backlog. Hundreds of these stories are at the small or very small level and are stories that are not really optional.
Meeting with the PM this morning, she pointed out that there had been some problems with people not having things to do at the end of the iteration. "Do you know what it is like to sit in a retrospective with the Product Owner and have her hear one developer after another say something like 'I didn't have anything to do the last week of the cycle'?"
Putting 2 and 2 together, this team has a bad leak. Items that are "must-haves" migrate to the backlog while developers sit idle. Now having a team of 35 brings with it an enormous amount of problems. Let's face it -- it's probably not agile in any way we understand it, but this happens to teams of all sizes.
With large teams you can really get a feel for how this hurts. Imagine a story that would take a day to complete. It gets put on the backlog, then called out during planning, then sized, then prioritized, then discussed, then bought, etc.
So we have 60 people in a room, all listening while we work through an item that is 8 man-hours. After 8 minutes or so, we've used more time processing the story than it would take to complete it.
Is your team leaky? Do you have a backlog full of small to-do items that are non-optional? Do you skip the daily and weekly discussions of "hey -- what's the most important stuff we have to do right now, regardless of the schedule or plan?" If so, you're spending a lot of energy on the wrong side of the power curve. You've reached the point that the more you throw at it, the less you get back.
Leave a comment