You interviewed with a team a month ago, and you were a little concerned. It didn’t seem as if they were keeping to their iterations. Their product owner wasn’t grooming the backlog often enough to keep the backlog filled for the release meeting. They seemed to have an awful lot of defects piling up at the end of the iteration. And, it sure looked as if they finished only two or three stories every four-week iteration.
But you really like the product domain—it’s where you want to go with your career. And you think you can learn a lot from your VP, so you decided to take the job. Now, it’s your second day on the job, and you realize that your original concerns have understated the problem. Not only does your project have all of those problems, but everyone is working on several other projects simultaneously, including the testers.
The iterations are too long. The stories are humungous. Everyone is multitasking. The product owner is not available enough. This is a rich problem-solving environment—the project has a ton of problems. You know you can help the team fix these problems. You just have one problem. Where do you start?
Gather Current Data
When I spoke with my colleague, Mike, in this position, I suggested he start with a retrospective to help people see the current reality. “But Johanna, it’s not the end of the iteration. How can we do a retrospective?”
You can call it something else, such as an “intraspective,” so that people realize you are looking at data between the beginning and the end of an iteration. Especially because you are new to the project, you can ask the team to use an intraspective to help you see the current reality. Timebox the intraspective to a couple of hours, gather the data, make sure no one on the team, including you, plays the blame game. Your only objective is for everyone to see the current reality.
As part of the intraspective, gather a cumulative flow diagram and start an iteration contents chart. An iteration contents chart allows you to see what the team is actually completing in the iteration: how many stories, how many defects, how many changes. See the example in Figure 1.
When you start gathering data, you may not have lots of iterations of data. You will definitely have data from the iteration you are in. And, although I’ve shown this chart using a spreadsheet, I suggest you start gathering the data informally on the wall. The less formal you make the data, the less intimidating you appear as a project manager. This is critical at the beginning of your relationship with the people on the project. You want the people on the team to think you will help them, not feel as if you are there to crack the whip.
You may discover you can work with the team to split stories. You might decide to float the idea of shortening the iteration. Maybe you introduce the idea of tracking technical practices. You might see that the team members need help with their ability to provide feedback and coaching to each other. The possibilities are endless. And, given that everyone is multitasking, you already know there is something you can do for them, and that’s to advocate on behalf of the team with management.
Start Defensive Project Portfolio Management
After Mike had been on the job for a week, he called me again. “JR, it’s even worse than I thought. People are working on not just two projects, but six or seven other projects. My project is not going to get done at all.”
“How important is your project?”
“I think it really is the project to save the company.”
“Tell me why. But, before you start, take out your pad and pen, and take notes as you talk to me.”
When I work with project managers, I tell them to act as if their projects are the most important projects in the company. In this case, Mike will need to make the case to his management to help them see that the context switching is killing the project. He can’t just use cumulative flow diagrams; he needs to have at least one conversation with his manager—and maybe more managers—and use influence and persuasion. That means he needs to articulate the reasons for the project.
As Mike spoke, he explained the strategic reasons for project’s importance. He wrote down the reasons as he spoke. If he’d been a person who liked to think about issues first instead of talking them through, I would have suggested he think and note his reasons before we spoke. Then he could have practiced the conversation he planned to have with his manager with me first.
Use an Agile Approach for Your Work
You can’t do everything at once. Once you’ve seen the current reality, and started the conversation with management about stopping the multitasking, make a ranked backlog of what you think will help the team most.
You might decide to work in iterations or in continuous flow (Doug, can we ref Timebox or Kanban: A False Dichotomy?, depending on what works best for you. If everyone is multitasking, chances are high you will be asked to multitask also. You might decide to use kanban then, just to make sure you finish work.
For example, if the team does a great job getting to done, and their stories are huge, helping them learn to split stories might be the first item on the backlog. But, if their stories are huge and they don’t get to done, you might help them learn how to get to done first, because they might be trying to get to done by having large stories. It depends what problem they are trying to solve by having large stories.
Most people try to do a great job. They don’t wake up in the morning, go to work, and say, “I’m going to do a lousy job today.” But they may make assumptions about causes and effects, such as one team who thought that the reason they couldn’t get to done was because they didn’t have large enough stories. They were incorrect, and once they made their stories much smaller, they were able to test them easier, which allowed them to achieve done. Sometimes, people have a difficult time seeing cause and effect.
Use your facilitation skills to help them separate cause and effect.
Help the Team See Their Progress
As you aid the team in fixing the team’s problems, help the team see how they have fixed their problems. You might post a chart with a “Team Problem identified date” column, and a “Team Problem solved date” column, so people can see how many and how fast the team was at finding and fixing problems.
You could post your backlog of items of work, so that the team sees your work. Transparency in an agile context is often a great idea. And, it’s not for everyone in every organization.
Consider posting velocity over time, so people can see how their velocity has changed, especially if the team decides to decrease their iteration duration.
I would measure cumulative flow, to keep the pressure on management and to encourage the team members to let me know if anyone wants them to work on other projects.
And, if you are in a position like my friend Mike, good luck. Let me know how you have made progress.
© 2011 Johanna Rothman. This article was originally posted on Gantthead.com.
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.