Lead Your Agile Culture Change

Too often, managers think of testers as a necessary evil. That thinking might lead these managers to think of testing as a support function.

Nothing could be further from the truth. Testing is an integral part of product development, where we have something valuable to release to customers. What testers do, exposing information about the risks of release might not change with an agile approach. How they do it changes with any agile approach.

When we use agile approaches, we change from thinking about testing as “support” to being an integral part of the project so we have a working product as we proceed. Integrating testing as we proceed helps everyone realize what the product is and how well it works.

Here’s how an agile approach changes one organization’s culture.

Jay, the CIO, brought his staff together to assess their agile transformation.

“Hi gang. First, I have some kudos to the product team A. I went to their demo because I wanted to see how the product was progressing. I was really surprised.”

Kim, the development manager, and Stan, the QA Manager looked at each other. They smiled. They looked back at Jay.

“Okay, I can see you two laughing at me. But, I was quite surprised by how much progress the team had made in just the past week.”

At that, Kim snorted and Stan burst out laughing.

Kim started. “You know, we told you months ago—maybe even years ago—that the developers worked better with the testers when they worked together. It’s about time you believed us.”

Stan stopped laughing and said, “Here’s the thing. Testing is actually quite creative. When the testers create their evil tests, especially when they automate those tests, the developers learn how people will use the product in the ‘real world.’” Stan used air quotes for emphasis. “Too often, the developers think the users will think just like the devs do.” He paused. “Users don’t think like devs do.”

Kim grinned. “Thank goodness the users aren’t as nasty as the testers are,” she said. “But it’s not really about the nastiness.”

Jay asked, “No? I thought that was a great benefit.”

Kim nodded and said, “Oh, the test nastiness does help a lot. But the real value is that the testers challenge the dev assumptions about everything. We always think we know what the product is when we have stories. It turns out we have a surface understanding. The real value of the testers is that they help the devs really understand what the feature set and this story is.”

Stan added, “That’s why the team can make such progress when they work together. I don’t even think they mobbed on these stories, did they Kim?”

Kim shook her head. “Nope, they all worked separately.” She paused. “I think they swarmed so they could keep their WIP low. But they didn’t mob on what you saw.”

Jay asked, “Whip? You mean the testers whipped the developers into shape?”

Stan shook his head and grinned again. “Jay, you gotta pay more attention to the terms. No, it’s W-I-P, Work in Progress. When the team works all together on one thing, and swarming lets them do that, every team member keeps the mental model of the design and what the story really means in their head. Then, it’s easy—okay, easier—to finish a coherent story that works the way everyone wants it to work from start to end.”

“But here’s the really cool part,” Kim said. “The developers had been thinking about the design in a specific way. One of the testers asked a question, which totally changed the design. That question helped the entire team simplify the design and the code. And, that change increased performance. You saw that speed test, right?”

Jay nodded. “Yeah, I thought that was impossible for us to do.” He cocked an eyebrow at Kim.

“With our old design, it was impossible,” she said. “We couldn’t have done it unless we changed our thinking, and that’s what the testers did for us.”

“Well,” Jay said, “I have to change my thinking about teams. You convinced me I need to keep teams together and flow work through the teams.” He paused. “You’ve been saying that to me for a while. Now, I get it.”

Kim and Stan high-fived each other.

“Okay, let’s get to the problems we need to solve as a management team.”

Agile Approaches Make the Case for Flow Efficiency

Too many managers think of software as a factory, where people on the team work in their own function, working according to their function. UI people only do UI. Platform people only work on the platform. Testers only test.

Agile team members often discover they have much more flexibility than just working in their own function.

Even if the team members do work in their own function, agile teams learn together to create the product.

The more the team works together, the faster the team learns. Not only does the team learn faster, they can see potential problems faster. This team was able to see how to speed up performance.

Flow Efficiency Changes the Culture

Well-working agile teams care more about their throughput than any one person’s contribution to the team. When managers realize that the team’s throughput matters more than any single person’s contribution, they start to change the organization’s culture.

This culture change doesn’t happen immediately, but it does happen. All because the testers worked with the developers, not for them.

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.”