Hours, Velocity, Silo'd Teams, & Gantts

I've been having some email conversations with some project and program managers turned Scrum Masters. 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 Scrum Master 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 2- and 3-person teams here and maybe a 4-person teams there.

These Scrum Master/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 5-7 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 2 people are too small. And much of the time, teams of 3 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 Scrum Master, 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 2-person team to complete something that takes a 6-person team 1 week is crazy. Of course, I think a story that takes a 6-person team 1 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. (Yes, you can buy my book on Amazon. But you can only buy the electronic version on the Prag site, because that way you can get the updates for free.)

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

9 Replies to “Hours, Velocity, Silo'd Teams, & Gantts”

  1. simple and efficient suggestions for common problems.
    thank you Johanna.
    i recommand the newest book of scott ambler: disciplined agile delivery, a good synthesis of agile practices, particularly focused on delivery.

  2. Great advice as always JR! I think this relates very closely to a fairly recent article over on Bob Galen’s blog called Going Agile…the Price of Admission. I followed that up with a post of my own sharing some of my own thoughts.

  3. One of the things about agile that is never covered is docuementation, user facing docuemntation. the help the manuals all need to be completed with features but no agile trainer ever mentions it you recognise the need for testers in teams but not writers. The number of companies I see that are unable to integrate the technical writers into there scrum process leads me to believe that this is something that should be looked at. Currently we are moving our documenation team to a single team within the We are currently in the process of attempting to solve this within our company, but i would be keen to see how others have solved the issue. (I know the obvious have a writer per team however in most cases this is not going to happen)

    1. Brian, good agile trainers always say, “Make sure the team covers all of the necessary roles.” On your teams, if you need writers, because you ship documentation, then you’d better have a writer. Or, the rest of the people had better include writing documentation as part of the user story.

      It’s not obvious to me that you don’t have a writer as part of each feature team. If you don’t, the team is under-staffed. Why would you do that? You wouldn’t have a team with no developers, right? You wouldn’t have a team with no testers? Why would you have a team with no writers? It makes no sense. (I know, you’re not the manager.) If you have no writers, then you have these choices:

      1. The rest of the team members, the developers and testers write the documentation, and report the impediment.
      2. You don’t create this feature team, because it’s not a real team. It doesn’t cover the roles.
      3. You take only stories that don’t require user documentation.

      That’s just three options. Maybe you can think of more.

      Doing agile with an understaffed team is asking for trouble. Agile provides you the transparency to do things right or report why not. Do so.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.