Hours, Velocity, Siloed Teams, and Gantts

I’ve been having some email conversations with some project and program managers turned ScrumMasters. In general here’s how things have proceeded:

• Their organizations decided agile was a great idea
• Their organizations decided Scrum was a great idea to implement agile (because they don’t know the difference between Scrum and agile)
• The teams started working in two-week iterations, sort-of getting close to done at the end of the iteration

But, if you peel back the covers, what you see is not really Scrum. The person with the ScrumMaster title is doing funky things, such as:

• preparing Gantt charts for the iteration, so you can see who will do what when
• predicting velocity based on hours (!!)
• predicting the number of story points per person per day
• telling the team what they can commit to for stories
• and all kinds of other strangeness I don’t associate with agile

And, the teams are still silo’d teams. That is, there are developer teams, tester teams, architects leading component teams. There are two- and three-person teams here and maybe a four-person teams there.

These ScrumMaster/project manager/program manager people have their hearts in the right places. But they have not had training, and they don’t know what agile can do for them. So while their iterations are helping them and their projects, they look around and say, “Why is agile not helping me?”

If you are one of those people, you have options. Here is my list of recommendations:

1. Stop trying to predict anything for the teams. Make the teams work as teams, and that brings us to #2.
2. Move to cross-functional teams. Make them a reasonable size, such as five-to-seven people. Make sure you have at least one tester on each team. If you don’t have enough testers to go around, that’s an impediment, and your team is going to have to develop tests for your code. But teams of two people are too small. And much of the time, teams of three people are too small. Tester-teams are wrong, just plain wrong. Testers go with developers. You need a cross-functional team to deliver features.
3. Integrate all your architects into the feature teams. If you have more architects than you have teams, you have too many architects. (Yes, one of my correspondents has that problem.)

Now, you have teams that might be able to work together. You, as the agile project manager/erstwhile ScrumMaster, you, stay out of the middle!

1. Now, when you have an iteration planning meeting, here is what you do. You ask the product owner to present the stories, and ask the team if the team can commit to the story for this iteration. That’s it. You don’t commit, the team commits. The team can estimate, but the team commits. If you start predicting velocity and you start predicting which stories a team can commit to, you are not doing agile. You are doing command-and-control in iterations.
2. Oh, and if anyone starts to tell people, “Jim, that’s your story, Sue, that’s your story,” gag that person. Okay, maybe that’s a little extreme. But only a little. Remember, the idea is that the team commits to stories, not a person. What you can say is this, “Is it in our best interests as a team to commit to stories as a person? Remember, we want to make sure all of our stories are done at the end of the iteration. That means the testing has to be done. And, all of the user experience has to be done. (And any of the other special for-your-product stuff has to be done.) If someone who is an expert commits, what happens to the all the other pieces? Does that help us get all the stories done?” Then you hush. You can always facilitate the retrospective and help people learn from what happened.
3. During an iteration, if anyone wants to know what a given team member is doing, you can say, “Look at the board.” If that person wants to know more by seeing a Gantt, you can say, “No, we don’t have Gantts in agile.” If that person signs your paycheck, you can remind that person that you have a demo every two weeks. If that person is insistent, you can ask what the real issue is. Because if that person looks at the people working, can’t that person see that everyone on the team is heads-down working? Look for the information that person wants and find another way to deliver it.
4. If you have trouble seeing what’s really happening, consider adding kanban to your iterations, so you see if you have bottlenecks. Many organizations are understaffed in some area or other, and until you add a kanban board, you can’t see it. Kanban allows you to visualize the flow.
5. Make sure you do a retrospective at the end of each iteration. Every single time. The retros can help you more than you know. Choose one thing to work on after each retro (okay, maybe up to three things), and see how fast you improve.

What’s key is for the teams to turn into self-directed teams, not manager-led teams. The teams have to take responsibility for their own work, and fast. They have to recognize their own impediments.

For many of these teams, one of the major impediments is that the stories are too large. They don’t realize it, so they try to take on too many stories at the start of the iteration. They can’t finish them all, so they don’t get credit, and they are left with unfinished work at the end of the iteration. Well, that frustrates everyone. Who is a “bad” estimator?

Maybe no one. If the stories were smaller, or if a sufficiently large team swarmed around the stories, maybe the teams could complete the stories in the iteration. But asking a two-person team to complete something that takes a six-person team one week is crazy. Of course, I think a story that takes a six-person team one week is too big.

So, if you are on one of these not-quite-agile teams, take heart. First, you are not alone. There are people all over the world, just like you. If your management won’t allow you to take training, start reading. I’m sure there will be comments about what else to read.

Here are my suggestions for reading:

Join the scrumdevelopment group which is a yahoo group. There is plenty of free advice there. Much of it is good. Listen to everything Ron Jeffries says.

Manage It! Your Guide to Modern, Pragmatic Project Management. I offer you tons of ideas about facilitative project management.

Exploring Scrum: The Fundamentals. Rawsthorne and Shimp take you through the nuts and bolts of Scrum.