Ken, a Test Manager, at the Acme company was concerned. He and his fellow managers had collaborated to create cross-functional feature and product teams. They were pretty successful at the team level. It hadn’t been easy.
It was time to change the rest of the organization. Especially since they had a new Director, Bruce, who wanted to know everyone’s allocation and utilization. Even worse, Bruce wanted to split the testers out of Engineering into a shared services organization. Bruce thought Acme would need fewer testers because they could “share” the testers across several projects.
Ken knew that fighting with Bruce was a Career Limiting Move. Instead, he decided to try a two-pronged approach: explain why flow efficiency works, and to show specific data from before and now. He hoped that was enough.
Get TestRail FREE for 30 days!
Explain Resource Efficiency and Flow Efficiency
Ken thought explaining resource and flow efficiency might mean he didn’t need to do anything else. He started there.
Niklas Modig and Pär Åhlström wrote a book called This is Lean: Resolving the Efficiency Paradox. That’s where they defined the terms resource efficiency and flow efficiency.
Here’s what resource efficiency looks like:
In resource efficiency, each expert takes the work assignment in turn. Acme had used people like this before they moved to agile approaches. A product manager wrote the requirements, and then assigned the work into the UI team. The manager assigned a UI designer, who completed all of the UI work before handing off the requirement to the platform team.
The platform manager assigned a person, who did all the platform work. Then the work went to a middleware person and finally an application layer person. After all that, the work went to the tester.
Yes, resource efficiency is a waterfall approach. If you don’t need to learn while you make whatever you’re making, it works quite well.
However, Acme had many of the same problems other places that used waterfall had. Too often:
- The testers discovered unanticipated problems all the way at the end of the development.
- The “team” didn’t implement what the product manager wanted.
- The product manager realized she had different requirements once she saw the work.
Here’s a picture of flow efficiency:
The entire team together works on the work. The team doesn’t have handoffs. The team doesn’t literally have to pair or swarm or mob, but it’s a good idea to do so, to increase flow efficiency.
If you measure effort, resource efficiency looks good. The problem is this: customers don’t buy your effort. They buy finished features, especially if you can finish them relatively quickly.
If you measure feature cycle time or count the number of features a team can release during a certain time, flow efficiency looks great. You can better predict when a team might finish a feature.
Flow efficiency produces finished results. Resource efficiency produces busyness.
That’s why the Acme first-line managers and their teams collaborated to use agile approaches. Now, they had to explain to their management that the testers and writers weren’t a service organization. The testers and writers were an integral part of the product development teams.
Ken met with Bruce and broached the topic. “I know you’re a fan of resource utilization,” he said.
“I am,” Bruce said. “I want to show my management we’re getting the most out of our people.”
“What if I showed you there’s a better way to get the most out of our people?” Ken asked. Then, Ken showed Bruce the pictures and explained how flow efficiency had helped them finish more work and improve the quality.
“Finish faster, with higher quality?” Bruce asked. “Sounds like a pipe dream. Do you have any data to back that up?”
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.
Measure Cycle Time and Defect Escapes
Ken had already measured cycle time and escaped defects for several projects. He showed Bruce the data:
Before they went to cross-functional teams using agile approaches:
| Project | Time to first deliverable | Escaped Defects (Defects found after release) | Number of Developers | Number of testers |
|---|---|---|---|---|
| Project 1 | 6 Months | 88 | 7 | 2 |
| Project 2 | 3 months | 5 | 6 | 2 |
| Project 3 | 18 months (12 months desired) | 156 (and counting) | 7 | 3 |
Ken said, “These projects aren’t the same. We had two smallish projects and one very large project. Project 3 was a disaster. Management wanted it in 12 months. But, with everything they wanted, we knew it would take 18 months. It did. And, because we took so many shortcuts, we’re still getting reported problems in that release.”
Bruce said, “Well, Project 2 looks pretty good.”
Ken sighed. “Yeah, it looks that way. But our best customer found those problems and he wasn’t happy with the way we implemented the functionality. I had to visit him several times.”
Bruce nodded. “Sometimes, that happens.”
Ken said, “Here’s the data from our most recent three projects. Because we release once a week, it’s hard to compare apples and oranges. I’ll walk you through it.”
| Project | Time to first deliverable | Total number of project weeks | Escaped Defects (Defects found after release) | Number of Developers | Number of testers |
|---|---|---|---|---|---|
| Project A | 2 weeks | 8 | 5 | 7 | 2 |
| Project B | 1 week | 16 | 3 | 6 | 2 |
| Project C | 1 week | 12 | 7 | 7 | 2 |
Bruce said, “Hey, all of these projects took less time. Fewer problems, too.”
Ken said, “Yeah, we’re really happy with these projects. When the product people gave us their roadmaps, we thought each of the projects was about a nine-month project. But, the longest was four months. That’s because we were able to stop earlier than we anticipated.”
Bruce asked, “Why did you stop?”
Ken grinned and said, “The product manager didn’t want any more features on that project. The product guys wanted us to go to another project. How good is that?”
Bruce said, “Quite good.”
Ken said, “We can do this, the release once a week because we have testers who understand the product working with the developers on the same teams for months at a time. They get to learn how to work together and how to solve problems together. We’re not perfect, but we’re getting there.”
Product Development Requires Learning and Dedicated People
Ken and Bruce had several more conversations. Bruce started to understand the value of dedicated people to long-standing teams. And, he gave up the idea of shared services.
If you also need to change your management’s mindset or the culture to a more agile culture, consider helping people understand the idea of flow efficiency. And, consider which measurements you might want to show so that they understand how agile approaches can help the organization.
When people start to change their questions and measurements, they often change their culture. See how you can help.
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
