Your team says they use Scrum in two-week iterations. And, in order to “finish” everything inside the timebox, you don’t do any of these things:
- Refactor to simplify the code or the tests.
- Create automated tests.
- Use formal acceptance criteria on a story or for the iteration or the project. That means you have work that’s in progress—not done.
You always “finish” at the end of the iteration. And the work that’s not done? You create another backlog of “technical debt” to address later.
What does this look like to you? To me, it looks like a death march project.
What can you do? Consider these ideas that might help:
- Stop estimating anything and calculate cycle time.
- Experiment with collaboration to reduce WIP. You can do this even if each of you is an expert on various areas or different products when you use flow efficiency.
- Start collaborating to stop starting and start finishing.
I’ll take each of these in turn.
Stop Estimating and Use Cycle Time
Clare was convinced her team didn’t estimate well. They dutifully estimated in story points each iteration. And, halfway through the first week of each iteration, they realized they needed to “hurry up” to finish the work.
Here’s how Clare’s team worked:
- Every person started their own story. (See Who’s Playing Agile Schedule Games?)
- Because every person started their own story, they had to wait for each other for code review. That increased their WIP.
- They rarely achieved their acceptance criteria. That meant the work wasn’t done by the end of the iteration. They called this undone work “technical debt.”
Clare decided to use the value stream map in Measure Cycle Time, Not Velocity. She measured their work time. The developers were pretty accurate for their work time. They missed their wait times.
Because they worked alone, they didn’t realize how often and how long they waited for each other to become available. Their wait times dwarfed their work times.
(When I’ve done this with clients, they often wait 15-20 hours for every hour of work time. I didn’t believe it was that bad until I saw it for myself.)
Clare realized they already created stories of reasonable size. She decided they didn’t need to estimate any longer. They did need to work together. They decided to experiment with collaboration to see if they could reduce their wait times.
Experiment with Collaboration
Everyone on the team agreed this would be tricky. Each person had their own expertise. And, each person’s bonus depended on “their” work.
Clare asked management to create more of a team approach to bonuses to reduce the individual rewards. And, she introduced the team to these collaboration approaches: pairing, swarming, and mobbing.
The team chose to swarm first. They used this experiment:
- Choose a one-hour timebox.
- Discuss the work for 5 minutes. Make sure everyone knows what they need to do.
- Everyone goes off to their respective areas and works for 15 minutes.
- At the 20-minute mark, check in with each other. When someone is done with “their” work, ask, “Who can I work with?”
- Repeat #3 and 4 until the hour is over or the team finishes the work. (Sometimes, the team finishes early.)
Debrief using either an ORID debrief or What, So What, Now What to see what to do next. This team used What, So What, Now What.
The team then used a 60-minute mobbing experiment. They used the same debrief. Which experiment did they want to continue? Mobbing, much to my surprise.
Start Collaborating
Based on their experiment, the team didn’t like mobbing for the first 30 minutes—until they realized what they accomplished and learned in 30 minutes. That’s why they finished that first hour and then chose to mob.
In that hour, they fixed 5 of the biggest problems that plagued them for the past year. The team decided to attack the build and deploy systems and see what they could automate.
They were so fast because they didn’t have to wait to ask anyone questions. They reduced their wait time to zero.
They spent another five hours of mobbing on those systems. They reduced build times from 10 hours to 30 minutes. They automated several smoke tests which allowed them to know that deployment would work. That meant they could automate much of deployment.
Much of their mobbing was refactoring.
No More Agile Death Marches
Clare’s team doesn’t mob all the time. However, they often pair to integrate learning and code review. They swarm on fewer items. They’re able to release more finished features because they’re not postponing the work they owe the product.
Every iteration, they choose two or three items from their “technical debt” backlog and work to resolve it. The team often mobs to resolve that work.
Even better, since they’re finishing—really finishing work—they have fewer production support issues.
Clare tells me she thinks it took the team about two months to get the hang of collaboration.
Agile approaches are all about collaboration. When you see the wait times and the queues of work with value stream maps or a kanban board, you can decide what to do. When you decide how to collaborate, you can reduce the WIP. And, collaboration means you never have to leave that “technical debt” in the system.
If you see an agile death march in your organization or in your team, let me know if you’ve tried these ideas and what happened.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Three Ways to Stop Agile Death Marches Opinions expressed by Java Code Geeks contributors are their own. |
