A client asked me to do an assessment. He wasn’t sure agile was working for their teams. The standup meetings felt like micromanagement. People were on several projects, so they didn’t meet their commitments. The project manager had to translate the project’s progress and status to Gantt charts. Worst of all, people went through the motions of agile, but they were not happy about it.
I asked him several questions about how they had transitioned to agile:
- How long are your iterations?
- Does each item in your backlog get to “done” at the end of the iteration, or do you have work that is not complete at the end?
- Does the team have a retrospective at the end of each iteration?
- How much work is in progress at any given time?
- What does your velocity chart look like?
How Long Are Your Iterations?|
Some people like short iterations, such as one or two weeks. Some teams think they can’t possibly accomplish anything in a two-week iteration. Or, they see the iteration planning as overhead.
I have found that I can ask two questions to determine a good guideline for iteration duration:
- When do you need feedback?
- How much can you afford to throw away?
Teams transitioning from waterfall are accustomed to thinking about large feature sets, not small features. You can help the team by refocusing their attention. Instead of thinking about everything they have to do, when you ask these questions the team members think about smaller chunks.
You might discover that they want feedback each week. You can suggest one-week iterations and ask, “How can we get feedback each week?”
If you ask the throwaway question, people realize agile is about the ability to change. Sometimes, even when the team delivers a great user story, the product owner realizes that’s not the story he or she needs. Uh oh. Team members realize they don’t want to work for many weeks and have to throw their work away.
Does Each Item Achieve “Done”?
Some teams have the notion of “done”, “done-done” and “done-done-done”. Frankly, I don’t understand all those dones. To me, the product is either “releaseable” or it’s not.
When you ask this question, you might discover impediments to releaseable. You might discover that the testers aren’t integrated into the iteration. You might discover there is another team who releases the features. Is that team agile? If not, your team members may have interruptions later, when they are already on to other work. That’s multitasking, and it kills your project’s momentum.
Does the Team Reflect?
Agile is built around the idea that teams inspect and adapt everything so the team can change: their work process, their assumptions and their product. The team doesn’t have to change. However, the teams that don’t build in retrospectives tend to repeat behavior that doesn’t work for them.
In this case, the team hadn’t done a retrospective in six months. Instead, they complained about how their standups weren’t working for them when they ate lunch together.
The project manager facilitated a retrospective at the end of the next iteration. That’s when the team members discovered managers were handing them extra work that wasn’t counted in the iteration–but was necessary for them to complete to get good performance evaluations.
The team members were working hard, and their boards didn’t show it. Neither did the project progress.
How Much WIP Does the Team Have?
One of the problems this team faced was that everyone was an expert in a different area. That led the team members to think they had to take separate stories–whatever each of them specialized in.
Each person taking his or her own stories had many side effects: many stories and tasks in progress at the same time, and those stories and tasks too a long time to complete. Because each person worked on their “own” work, the team reinforced the expert roles instead of helping other people learn those areas.
The project manager took pictures of the board each day of the iteration. When the team reviewed the board in their retrospectives, they realized how much work in progress they had.
Work in progress is not an asset. WIP prevents the team from being able to change what they do. Only completed stories/features are assets. When the team realized what was happening, members asked themselves if they wanted to continue working like that. Experts became bottlenecks, and stories lined up in the experts’ queues. They decided they wanted to finish more features, regardless of who the expert was.
They decided to never let an expert work alone. They also thought about pairing and swarming on stories. Those changes were not trivial. The pairing and swarming did help reduce the expert and WIP problems.
What Does Your Velocity Chart Look Like?
Before the team made the changes to pair and swarm, they also looked at their velocity charts for a few iterations. They saw a hockey stick for each of several iterations. The team didn’t finish anything the first week of the iteration. They finished all the stories in the second week.
At first, pairing and swarming seemed to help. But, they still had a difficult time finishing more than one story in the first week. They had to do a little digging to discover why. The product owner was not so good at right-sizing stories. Many of their stories took four or five days to complete, even if the entire team worked on one story.
The product owner ranked those large stories at the top of the backlog. As a result, the team found the standups frustrating–no one could say they had completed anything. Since the team had so much WIP, the managers felt free to ask a team member to “just do one more thing.”
Because the team wasn’t finishing stories in a cadence, the project manager had to create Gantt charts to show progress. The Gantt was always wrong. Your velocity chart might show a hockey stick and your root cause might be different. But, that’s what this team discovered.
The team decided to give feedback to the product owner and ask for smaller stories. That allowed them to be always on the verge of finishing something. That finishing allowed the team members to push back on managers asking for non-project work.
Eventually, the managers asked to put that work in the backlog for an iteration. That wasn’t great because people had to multitask off the project, but it made the work transparent.
What Questions Would You Ask?
You might not find all of these questions helpful. I start here and see what else makes sense to ask. If you think agile isn’t working for you, try assessing what’s going on. Once you see your reality, you can decide what to do next.