I received some fascinating responses to Do You Want More Productivity?
One correspondent told me that managers need to move people—especially testers—from one project where they are not busy to another project where they could help.
His experience matches mine—many projects do not have enough testers. However, we do not share the same conclusion.
If the developers have large stories, or the organization works in a more waterfall approach, the testers might not have much to do between spurts of development. Managers might think, “What's the harm in moving people between projects? We can get more done.”
There are several project problems when you move testers in and out of teams:
- The team incurs a cost of delay when you add or subtract people because the team needs to go through forming, storming, norming and performing every time you change the team members.
- The testers don't learn either product enough–the one they came off or the one they move onto. They become second class testers.
- When you change the people on the team, no one can create a reasonable estimate. That's because you don't know if you will have the needed people when you need them. (See Predicting the Unpredictable for more explanation.)
Also, there's a project portfolio problem: managers expect that partially staffing a project is the same as a full commitment to a project. I've heard these people say, “But we have some people on the project. Can't they make any progress?” All too often, the answer is, “No,” because the projects are missing key people.
If you think I'm nuts when it comes to flow efficiency vs. resource efficiency, try an experiment:
0. For a two-week timebox, ask each team to measure the number of features they produce, the number of defects, and the ratio of rejected fixes to total fixes. You have some baseline data now.
1. Determine the projects you can staff with full cross-functional teams.
2. Assign each project full cross-functional teams. Stop when you have no more teams left. (I realize you may have more projects you “need” to finish. Don't try to partially staff projects for this period.)
3. If you have people remaining, not assigned to projects, you have more options. You might ask them to work on defects or technical debt for this timebox. If the other teams are quite small, you might ask if the other teams need these people. Let the teams decide.
Do not start another project if you don't have a fully cross-functional team.
For two weeks, measure the number of features these full cross-functional teams produce, the number of defects, and the ratio of rejected fixes to total fixes. (Yes, same measurements as before.)
My experience is you will see that the full cross-functional teams, where you focus on flow efficiency rather than resource efficiency, create more features and fewer defects in the same period. It will be interesting to see what you measure.
Think about how you create an environment in which people are productive, not just busy.
Next year, I'm leading the Influential Agile Leader workshop again with Gil Broza. We are taking registrations now. Early bird registration ends December 31, 2015.
Dec 15, Scaling Agile Projects to Programs: Networks of Autonomy, Collaboration and Exploration, Boston SPIN, Burlington, MA
See my calendar page for all my workshops and speaking dates.
Are you new to the Pragmatic Manager newsletter? See previous issues.
Do you need a friendly ear and some sound advice? See my coaching page for my packaged and customizable coaching services.
See my workshops page for my workshops.
© 2015 Johanna Rothman
Tags: cost of delay, experiment, flow efficiency, leadership, management, project management, project portfolio management, resource efficiency, servant leadership, teams