This is a guest post by Johanna Rothman
In an agile organization, where managers facilitate teams, is there really a role for the test manager? Or the dev manager? Maybe not. I’ll offer three ideas for what you can do in a real agile organization.
Sandra sat back in her office chair and grinned. She’d never thought this would be her future as a test manager. She thought back to the start of their agile transformation, almost four years ago…
Challenge One: Stop the Multitasking
Sandra thought back to her first day as a test manager here. She was excited. She liked the product. She’d met the test group and was impressed by how capable they seemed to be. She’d met her peers during the interviewing. They seemed sharp, too.
The first morning she arrived, she’d tried to deal with no less than seventeen crises. They had 34 projects, spread among the 80 people in the department. She learned that each of the nine testers was attempting to test each of those projects.
Everyone was multitasking. Every person was on at least three projects, and more often six projects. She learned that five testers had quit a month ago and no one had tried to replace them. The previous test manager had quit in disgust.
She had plenty of urgent work as a manager, too. She knew there was important work, too—that’s why she’d taken the job. She had no time to even think about any of the possible improvements that week.
Everyone was busy. Nothing seemed to get through their system of work.
Now, the management team wanted the “teams”—she thought that might be an optimistic use of the term—to use agile approaches. Management had decided on one specific approach. That approach assumed that the team was collocated, worked on just one product at a time, and had all the capabilities and skills the team needed. Well, they were collocated. But, they didn’t work on just one product at a time.
Sandra thought the risk was low, so she challenged Peter, her director, on the agile approach and how the organization managed the project portfolio. She explained that resource efficiency made everything take longer. Flow efficiency helped finish faster.
It took them, as a department, a couple of months to reconstitute real project and feature teams. They felt tremendous pressure because everything was still late. And, Peter decided that as long as the teams delivered something every week and were somehow able to finish projects, he didn’t care how the teams worked. They could choose their own agile approach.
That’s when Sandra and her peers had a long talk with Peter, the director. The five of them, as a management team, presented a strawman portfolio. They walked Peter through how long each of the projects might take, and when they could change projects.
Peter agreed with their assessment. He took their ideas to his peer directors. The director-level management team made a couple of small changes and announced the portfolio. That allowed the teams to stop working on some of the projects. Those decisions provided more slack for the teams to finish their current work.
They weren’t out of the woods yet.
Challenge Two: Focus on Technical Excellence
Once the crises eased, Sandra’s job transitioned from fire-fighting the urgent to address the important work. Aside from hiring new people, much of the important work was in these areas:
- Build times were very slow.
- The various products had insufficient end-to-end test automation.
- The unit test automation was inconsistent.
All the previous decisions made because everything was urgent had come back to roost. They’d taken shortcuts in their previous work without thinking of the ramifications. And, they had technical debt where they had not considered the long-term effects. That meant all the work took “longer” to do than anyone expected. Their agile approaches weren’t helping enough, yet.
Sandra knew about measuring cycle time and how to create columns in a team board to see where the work was stuck. She asked one team if they were willing to experiment. They agreed.
Sandra worked with them to map their value stream. The team learned where they got stuck. They were pretty fast at developing new functionality. When they did, the developers created sufficient unit tests. And, the testers created great end-to-end automated tests. Sometimes, the testers and developers collaborated on automating other tests, such as performance tests.
However, if the team had to touch already-existing functionality, they slowed way down. They had loud and contentious discussions about whether they should add more testing or fix the builds.
Sandra said, “As the test manager, I’m going to take the heat for you. From now on, I want you to add any tests you think you need as you add or change functionality. I want you to spend time on the build and speed it up.”
One of the developers said, “You’re not the product owner.”
Sandra grinned. “You are correct. Let me go to bat for you. Carry on for now, and I’ll let you know what I can do.”
Sandra met with Don, the team’s Product Owner. She explained what she wanted to do. She explained that while this work seemed like “infrastructure,” it wasn’t. She showed Don the cycle time and explained that the duration was why he was still under pressure to deliver more in less time.
Don was worried that he wouldn’t get the functionality he needed in the next couple of weeks. They discussed what he needed and when. Sandra understood his pressures. She asked him to return to the team with her, so they could present a united front. He agreed.
They returned to the team room. Don said, “I understand you want to improve your working conditions. I agree that’s important. And, it’s not quite as urgent as these two stories.”
Sandra said, “As you address those two stories, please add whatever tests you need at whatever level. If you can automate those tests, even better. And, once you’re done with those stories, let’s create a strategy for fixing the existing problems and not creating more problems.”
The team agreed. Any time they had to touch a place in the code and tests, they worked as a team to automate what was manual and add what was missing. They also started to report on the build time every time they completed a story. If the build time increased, they fixed whatever caused that. Because the fixes were small, the team could change their environment as needed.
Sandra met with her colleagues. Gradually, all the managers worked with the other teams, one team at a time. Each team learned how they could gradually fix the debt and shortcuts in their code and tests.
The teams improved their cycle time. Because they were able to work faster, the management realized they could create more and different products. Other organizations might hire more people. Sandra’s company wanted to hire very carefully. And, to resist hiring more managers now that teams managed most of their work themselves.
That meant Sandra had to learn how to coach cross-functional teams. Not just the testing team, but to serve and lead entire teams.
Challenge Three: From Function Coach to Team Coach
Sandra had gone into testing because she liked the challenges of seeing how the products would work under different circumstances. She’d gone into management because she liked the challenge of coaching testers and working with managers to create great products.
Now, as their agile transformation took hold, she realized she needed to learn how to coach and serve an entire team. So did her development manager peers.
As a management team, they learned how to teach the team members to offer each other feedback and coaching. The management team created the space for communities of practice. And, the management team encouraged smaller and more frequent approaches to improving the teams, the process, the team environment, everything.
Management Changes in an Agile Organization
From the perspective of four years into an agile transformation, Sandra decided that her management role and her management actions changed dramatically. Her peers also changed their roles. And, her senior managers changed their roles.
She’d started her management career more as a test leader. Her development manager colleagues had been developing leaders. Now, they served the teams and led the organization. In some ways, her job was less technical because she wasn’t leading the testing. However, she was much more product-focused.
That was now her role as a manager. To serve the people who created and used the product. She couldn’t wait for the next challenge.
