I've been working with several supposedly “agile” teams and their managers. Everyone knows their project is in trouble. And they have no idea what to do about it.
The team members say, “We're on a death march. We have no predictability. Everything takes longer than we think it will.”
The managers say, “We have no idea when the team will finish anything.”
Everyone's frustrated. No one trusts anyone. Worse, no one sees a way out.
It's time for an intervention, starting with some data.
Gather Some Quantitative and Qualitative Data
That's when I ask the team: How long did it take the team to release the most recent three stories? (That's a surrogate for cycle time.)
Next, I ask this question of managers: How little information do you need, and how early do you need it? Often, they tell me they need to know when the team will finish several features. (More on that below.)
Now, we assess the various team-based feedback loops.
See Your Feedback Loops
Without naming this image, I ask the team members if they ever experienced any of these kinds of unplanned feedback loops.
Too often, the team members explain what they did:
“Our management wanted us to decide on an architecture, so we did some requirements gathering and then analysis. We then have a high-level design.”
I ask for clarification: “If you had to guess, how long does it take you to generate your first story or feature, or anything customer-usable? Something you can demo or other people can offer feedback on?”
That's when I hear weeks of prep work, not delivery. Instead of delivering something in Week 1 and building on it, the team spends weeks planning. (That's worse than the old Iteration Zero problem.)
Here are the questions to help the team stop the agile death march:
- What is the first thing you can do to finish something and release it? (This often requires the product leader to choose one feature set and then one story in that feature set.)
- Can the team finish that in two days or less? (I explain about swarming and mobbing, in case the team does not know.)
- If not, what is the very first thing the team can deliver to achieve the product goal?
Now, the team can discuss how to collaboratively work (as opposed to cooperatively). I often recommend an Agile Hudson Bay Start so the team can learn how to collaborate. They start to measure their cycle time, not their velocity.
The managers also have to change.
Planning Does Not Create Delivery
Then I ask managers why they need to plan. They often say their customers are waiting, waiting, waiting for features.
That's true. And it's true because the team has been stuck in long feedback loops because they tried to plan too much up front.
That's when I use these intervention questions for the managers:
- What goal do you have for the product for this release?
- What is the first thing you want the customers to see in that product goal?
- How much are you willing to invest to create that first delivery?
Planning is rarely a problem. However, you can't plan past your headlights, the data you have. Too many managers fall into the trap of how-much thinking instead of how-little. Then, they plan for much longer than they can reasonably foresee. Those plans are fantasies, not based in reality.
Prevent Agile Death Marches at All Levels
The team feels this problem, the too-long feedback loops, as an agile death march. They work and work and work and never feel as if they make progress.
The managers are also in a death march, but it's a planning march.
You can break both of these too-long feedback loop problems by focusing on the product goal. What is the goal for this product (in this project instance) for the customer? Now, what is the first thing the team can do to deliver that?
The team does not need the perfect architecture or design or anything. That's not possible to create without the experience of creation and the necessary customer feedback.
Instead of perfection, use good-enough thinking and creation to get that customer feedback as quickly as possible.
The shorter the feedback loops at all levels, the fewer death marches anyone will experience.
See Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility to diagnose and change your feedback loops.