Hours, Velocity, Siloed Teams, and Gantts

Johanna Rothman shares some tips for project and program managers turned ScrumMasters who are adopting agile. If your management won’t allow you to take training, start reading.

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.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.