This is a guest posting by Johanna Rothman.
When managers believe testing is a service—or worse, a shared service—the product suffers. That’s because software development, especially agile software development, is about how the team learns as a team. Instead of thinking of testers as providing a service, learn how the testers can help managers think about product development instead of a project.
Get TestRail FREE for 30 days!
Solving Problems by Creating Experiments
Cindy, the QA Director, knocked on the door of Dave, her CIO. She was ready and she was pretty sure he wasn’t going to like this meeting. Dave waved her in and joined her at his visitor table.
“Dave, we need to talk about this idea of “shared services” for testers,” Cindy said.
“Okay. What’s wrong?”
Cindy gave Dave a copy of her project portfolio with two lists of projects. “I don’t have enough testers to fully staff all the projects. The ten projects on the left is the list I can staff. The list on the right, the other six projects, I can’t staff. We don’t have enough testers to staff those projects.”
Dave’s eyebrows came together as he scanned the page. He frowned. “This isn’t good.”
“It’s not. You can see I’ve staffed the most important projects.”
He nodded.
“I’m not staffing the less important projects.”
He sighed. “You’re right in your assessment.” He paused. “What about sharing testers, as a shared service?” He leaned back.
Cindy leaned forward. “You’re probably not going to like what I’m going to say,” she started. “About ten years ago, I attempted to share testers between two projects. Just two, not more.”
Dave nodded.
“Neither project got the benefit of having testers,” she said. “The testers missed meetings, which meant they didn’t know about requirements changes. Or, they didn’t understand the impact of changes. Or, the testers didn’t understand the details of the architecture, or even how features were supposed to work.” She paused. “Sharing testers means they don’t learn enough to be effective. I learned my lesson. No more.”
Dave nodded. “Well, that would explain what I’ve seen in projects before. What do you think we should do?”
“We’re using agile now, so let’s try an agile approach to this problem,” Cindy said. “We can make slightly larger teams, so we only have as many teams as we have testers. And, we make smaller stories. That way, the teams might have faster throughput. And, if we have ‘extra’ developers, they can help with test automation, at all levels.”
Dave nodded slowly.
“I don’t mean that this is the only answer,” Cindy said. “We could do that for a week or two—not more—and then do retrospectives at the team level and as managers. We might find more possibilities.
Dave agreed and arranged for an all-management meeting first. Then, he talked to the other managers and the department. They created several experiments:
- To optimize for teams instead of individuals.
- To try larger teams to flow work through enough people.
- To manage the department’s WIP (work in progress), its project portfolio.
Optimize for the Team’s Ability to Create Products
Are you optimizing for the team or individuals? Too many organizations still optimize for each unique person, wanting to see that each person is “utilized.” That idea of utilization can create lopsided teams, or even insufficient teams to create a real product. Until Cindy showed him her lists, Dave didn’t realize his department had lopsided teams with too many developers.
Instead of resource utilization, agile approaches encourage us to optimize for the team’s throughput as in finished features. Optimizing for a team means:
- The team has all the necessary skills or capabilities. If your team doesn’t have those skills or capabilities, the team agrees on who will do what, and when. People take other roles so the team can proceed with its work—possibly more slowly. However, the team can still make progress.
- The team reviews its WIP and asks, “How can we, as a team, move this work to done?”
- The team learns together: in planning, in workshopping new stories, in spikes, and especially in demos and retrospectives.
When your team optimizes for the team’s work, you might realize you have lopsided teams. You might need to combine teams.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Consider Larger Teams
Once Dave asked the teams to work as teams, several teams realized they needed to fulfill the testing skills themselves. The smaller teams without testers didn’t have enough people to make progress. Of the six teams without a tester, three of them combined into a larger team of twelve people, two of them combined into a nine-person team. The remaining four-person team joined one of the other teams that already had a tester.
In the department, the average team size grew from five people to eleven people. And, because many of the teams had “extra” developers, their first inclination was to have every developer work on his or her own story.
The teams learned to optimize for the team’s work, instead of a given developer’s work. Some developers paired with other developers. Some teams decided to work in triads of two developers and one tester. One team decided to put its “extra” developers to work on the test automation they’d postponed for the past year.
They weren’t done experimenting and reflecting.
Manage the Projects in Progress
One of the product managers banged on Dave’s door and asked why no one was working on his products. Dave explained that they mistakenly committed to too much work all at the same time. They were now managing their project portfolio, and he was sure they could get to that product in another month.
The product manager wasn’t happy. However, he could see the progress the teams made on the other products. He could see that the date of “next month” was realistic.
In fact, because the teams had “extra” people, and they weren’t creating more not-quite-done work, one of the larger teams finished early. They were able to start on that product in just two weeks.
Testing is an Integral Part of Product Development
As a department, they learned three important facts about their work:
- Sharing anyone meant they couldn’t create real agile teams.
- They needed to optimize for the team’s throughput, not any single role’s throughput.
- With slightly larger teams, the teams had more capability to automate more of all of the testing
Instead of the idea of shared services, think about your projects as product development. What do you need to do to create great products? Create real teams with all the skills and capabilities that team needs. If you don’t have enough people, consider creating larger teams to learn as a team. Optimize for a team’s work, not an individual. And, if your department manages its project portfolio, you might not ever need to share people among projects.
This article was written by Johanna Rothman. Johanna, known as the “Pragmatic Manager,” provides frank advice for your tough problems. Her most recent book is “Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.”
Test Automation – Anywhere, Anytime
