It happens all the time. Skilled testers move up the ranks to software test management. But when they get there, they don't know what to do. So, absent formal training, they turn to a set of vague and outdated test management rules, which includes things like the following:
- Strive for "100% utilization"
- Use experts for each facet of the project
- Plan for overtime to meet release dates
But according to SearchSoftwareQuality contributor Johanna Rothman, author of the forthcoming book Management Traps: Myths, Rules and Illusions, these rules originated in another time and are no longer relevant to software testing. Adhering to them can spell disaster.
I recently chatted with Rothman about her forthcoming book and about why so much conventional advice about software test management is just plain wrong. Rothman, who is expected to deliver an "Exposing Test Management Myths" talk at the Stareast 2014 conference Orlando, Fla., in May, outlined which rules test managers should break and what they should do instead. In this edition of Quality Time, I share the highlights of my conversation with her.
Software test management myths
Rothman said the myth of 100% utilization comes from an earlier mainframe era when computer time cost more than people time. "We had time slices on computers. You would come in at 2 a.m. and bring cookies for the keypunch operators." That led to widespread belief that the most successful managers were those who kept all of their people busy all the time.
When you stop to think about the idea of 100% utilization as a measure of success, its absurdity is obvious. What if you kept all of your people busy all the time, but they were focusing on the wrong things? "When test managers hear me talk about this myth, they say, 'Oh my gosh,' and they look at me with their mouths open," Rothman said.
To ensure success, test managers should focus on getting software projects – and features that are part of those projects -- out the door. The way to accomplish that is to optimize the team's workflow at a steady rate, according to Rothman.
Built-in experts = built-in bottlenecks
Another big myth that lands software test managers in trouble is focusing too heavily on the importance of experts. Rothman noted that software projects do call for specialized expertise. But she also stated that emphasizing the role of experts -- for database, domain knowledge and so forth -- creates an environment where each expert works alone.
Tired software testers make mistakes.
Rothman Consulting Group Inc.
"Built-in experts create built-in silos, which means you have built-in bottlenecks," Rothman said. The right approach recognizes that for the team to be successful, members cannot operate in isolation. When they share knowledge with one another, they collectively focus on the end goal of delivering good software.
Moving away from the importance of experts is a hard sell, because experts often believe their particular brand of expertise gives them "a job for life and that they have golden handcuffs," Rothman said.
Here's what effective software test managers should tell team members to deal with that situation: "It's not that I want to take your expertise away. I don't. I want the team to share knowledge and collectively focus on delivering the product. I am simply asking that you understand a little bit more about each other's work."
Overtime is not the answer
No software test manager wants to force people to work nights and weekends. For one thing, you have to get the boss to sign off on the expense. And yet "we need overtime" has become the de facto test management strategy for dealing with impending release dates.
That's a terrible idea, Rothman said. "Tired software testers make mistakes." To achieve the end goal -- getting features out the door faster – development teams have to be able to work at a sustainable pace. Test managers have to create a situation where a team member doesn't feel guilty about taking a two-week vacation. The only way to do that is to share knowledge within the team, Rothman said.
So here they are, myths and rules worth breaking that include keeping all your people working all the time, relying too heavily on experts and turning to overtime as a deadline strategy.
Those are just a few of Rothman's. What are yours? Let me know and I'll write about them in a future column.
Dig Deeper on Software Project Management Process