The Role of the Test Manager in an Agile Organization

What do test managers do? In traditional organizations, they assign people to projects, oversee the testers' progress, provide feedback, and maybe offer some coaching to people who want it. They are the go-to people when you don't know how to do something—not because they know, but because they should know who does know. Test managers build trusting relationships with their staff and build the capacity of the testing group.

Building capacity in the testing organization has two components: hiring more people when appropriate and providing a forum for education and training. Sometimes that training is cross-training in the group, and sometimes it is a form of expert-led training.

How does that change with a transition to agile? Do we still need test managers? Or development managers? Or any kind of functional manager?

Yes. The problem is that we need test managers and any other functional manager to do different work. We still need them to build trusting relationships with people and to build capacity in the organization, but which people and what kind of capacity?

How Agile Changes the Organization
As organizations move to agile approaches, the project team members learn from each other and take a more generalist approach to product development. Developers learn more testing approaches, testers learn about nifty developer tricks they can try to exploit, and business analysts learn what that user story really means from an architectural perspective, not just a user perspective.

In agile, managers don't shuffle people among projects; they assign people to a team for a long duration. Managers don't check in on a given person's progress; the team commits to each other and tracks progress themselves.

And, the project team members still need a manager with whom they can build a trusting relationship. That trusting relationship is key to retaining people [1], [2]. In addition, managers need to be on the lookout to build capacity in the organization. Is it time to hire more people? Do the current project team members need some form of training?

The functional manager now has these responsibilities: build a trusting relationship with everyone in the group, remove organizational obstacles, provide coaching, do career development, and help build the capacity of the organization. It looks as if it's less work, doesn't it? It's not. Mangers can't hide under the "I have too much project work to do my management work" excuse anymore. Managers now have to manage.

Agile Managers Are Generalists, Too
Let me propose a radical departure from the traditional matrix manager. Just as the capabilities between developers and testers blur, so do the capabilities of the managers. It's time for functional managers to become generalists, much like we have asked the team members to become.

This means an agile manager, who is the champion for the entire agile team, builds trusting relationships with the team members, regardless of their functional skills. The manager also removes organizational obstacles and provides coaching and feedback. And, the manager is ideally placed to see how to build capacity strategically—to see when more people are needed and what skills people need to develop as the products change.

Sure, the manager would have to understand the issues of development, testing, business analysis, user interface design, database administration—any function represented on the team. But, remember that the manager doesn't have to have all the answers—she needs to know who to ask.

I cannot think of a time when a good functional manager didn't need to understand those functions to manage capably in a single-function group. I haven't met your group, so maybe you have an exception to my rule. But, when I've seen and worked with functional managers who understood the issues across the organization, the teams worked better and the product was better for that understanding.Separate the People Management from the Project Manager
A team champion separates the management from the project management. I'm all for separating the person who represents the organization's management from the person who protects the forward progress of the project. Those are two different jobs. Unless you have a small organization—as in, three to five people—it's not possible to do both jobs well. There is too much management work to do the project management. Or, if you do the project management, you shortchange the management role. Certainly, once you have more than one project team, you need a manager to do the management work.

Why Separate the People Management from the Project Management?
In a new agile environment, the project manager/ScrumMaster/process leader—whatever the person who protects the team's agile process is called-has a ton of work to do: remove obstacles, maintain velocity charts, remove obstacles, make sure the standups remain standups, make sure someone facilitates the retrospectives, work with the customer or product owner on the product backlog, remove obstacles, help the team define what done means, help people recognize when they need help, and remove obstacles.

You've noticed I've mentioned removing obstacles numerous times. In new-to-agile teams, noticing the obstacles is the first challenge. And, as more organizations attempt to move to agile, they are noticing that removing the obstacles often entails influence and negotiation at varying levels of the organization-not an easy task.

It's a big job, and many managers of these project manager people also expect them to contribute technically to the project. Once you have technical work and are a technical peer, it's not possible to act as a manager for people on the team.

Who Will Review the People?
When I coach managers in organizations transitioning to agile, they all want to know: How will we make sure people have a fair review?

Well, forget the fair business about reviews. No review is completely objective and fair. If you really want to make it fair, ask the project team members to review their colleagues.

What people really want is time every week or every other week to discuss their progress with a trusted colleague. That's what a manager does.

If you want to make sure the raise is fair, that's a different problem. You need a published career ladder with a number of rungs and objective criteria attached to each rung. You need relatively thin salary ranges at each level. You need to make sure someone reviews those levels at least once a year and increases them to match the going rate in your area.

Reviews are a red herring [1], [2]. There are tons of ways to review people. Separate the feedback providing from the money exchange.

Agile Changes the Game for Managers
When an organization transitions to agile, managers have to work across the organization—not just for managing the project portfolio instead of shuffling people around, but also to help team members with the inevitable stresses that come from working closely with others in a knowledge worker organization.

If you're a functional manager, are you ready?Acknowledgements
I thank Esther Derby, Don Gray, and George Dinwiddie for their review.

References
[1] Buckingham, Marcus and Curt Coffman. First, Break All the Rules: What the World's Greatest Managers Do Differently. Simon & Schuster, New York, 1999.
[2] Rothman, Johanna and Esther Derby. Behind Closed Doors: Secrets of Great Management. Pragmatic Bookshelf, Dallas and Raleigh, 2005.

Further Reading

• Pfeffer, Jeffrey. The Human Equation: Building Profits by Putting People First. Harvard Business School Press, Boston, MA. 1998
• Kohn, Alfie. Punished by Rewards. Houghton-Mifflin, New York, 1993.
• Pfeffer, Jeffrey. What Were They Thinking? Unconventional Wisdom About Management. Harvard Business School Press, Boston, MA, 2007.
• Hope, Jeremy and Robin Fraser. Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap. Harvard Business Press, 2003.
• Pfeffer, Jeffrey and Robert I. Sutton. Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management. Harvard Business Press, 2006.