© 2003 Esther Derby, www.estherderby.com
Cedric moved through his office packing up his personal belongings. His boss, Sheila, stood in the doorway, looking uncomfortable. As he started the last box, Cedric sat down in his chair. “How did it come to this, Sheila? I thought I was doing the right thing putting quality processes in place.”
Sheila sighed and leaned against the doorframe.
“We’ve been over this before. The processes you put in place are good practices, Cedric. Just not the right ones for us, at least not yet.”
Cedric had been hired nine months earlier to address quality problems that ShipFast, a small, fast-growing software company, was experiencing. Cedric had been eager to take on the challenge of finding defects and putting quality processes in place.
So Cedric set about establishing a test group from the ground up. He hired testers, built a development environment, purchased defect tracking tools and various other test tools, and established entry criteria, test standards, and procedures. He trained his new testers in classifying defects and writing good defect reports.
Then, Sheila made it clear that Cedric’s group would test the next release for all projects.
Not surprisingly, there were some grumblings and protestations that testing would delay delivering software to customers. But Sheila stood firm and laid out the case for testing, and eventually, the development managers agreed.
Cedric’s group tested three projects in the first four months after they were up and running. Sure, there were glitches, but for the most part, Cedric’s attention to structure and process produced results. The testers found various defects and wrongly implemented requirements, and they duly wrote bug reports, logged the bugs, and ranked their severity.
Cedric produced metrics and reports and showed them to Sheila. He thought things were going well.
And then the grumbling started again.
“I don’t see what value Cedric’s group is adding,” fumed Marisa, one of the development managers. “The system crashes as much as it always has.”
“Sure, he’s finding defects,” chimed in Jason. “But half of them are known defects with workarounds. The other half are minor. If Cedric would ever talk to the helpdesk or us, he’d know that those bugs never happen in production. Those aren’t the bugs that are crashing the system—the reason the system crashes is that all the different applications are stepping all over each other on the desktop and bringing the network down.”
“In the long run, I’d love to fix all these minor defects,” Marisa said. “But right now, I just want to keep the software from crashing.”
When the development managers tried to talk to Cedric, he dismissed them. “You don’t understand quality and process,” he sniffed. “You just want to hack.”
By the end of six months, the software was still crashing—and so were Cedric’s working relationships.
Where Did Cedric Go Wrong?
Cedric’s approach to establishing a test group isn’t an unreasonable one, and he’d been successful with this approach in the past. But the practices and processes that Cedric implemented weren’t addressing ShipFast’s most important problems.
Cedric’s first mistake was implementing his test group without understanding the context of the current environment. He came in believing that he knew exactly what the test group should be doing, and how they should do it. Cedric didn’t talk to the development managers or business people to understand what problems they were experiencing, and how he could help solve those problems.
Understand What’s Working and What’s Not
In almost every organization, some things are working well or the company wouldn’t still be in business. Investigate what’s working, as well as what’s not working. Part of any change is deciding what to keep.
If Cedric had investigated, he might have realized that functional testing was not their number one concern. The development managers were aware of many of the defects, but to them, and to the customers, system stability was more critical than the bugs they knew how to avoid.
Build Alliances
People are usually not receptive to a newcomer waltzing in and telling them they’ve been doing their jobs wrong. Understand what’s giving people a pain in the tush, and then help them see how your goals will help solve their problems or create the situation they want. People who see you as helpful are likely to reciprocate in the future. People who feel badgered and looked down on, as Cedric’s colleagues did, are generally less cooperative.
Work within the Current Situation
Cedric came in believing that there was one right way to do testing and one path to get there. When the development managers at ShipFast didn’t see things the same way, he dismissed them. Cedric may have established a test group in record time, but in the end, he failed in the goal of improving the quality of the ShipFast product.
Practices that fit at one company may not fit well in another organization, may not fit right now, or may not fit at all. Even “best practices” need to be adjusted to suit the current situation. The right practice is one that helps the company meet its goals.
Whether you are establishing a new test group, implementing requirements modeling, or bringing discipline to project management, successful change starts where people currently are. Understand the context, adjust practices to fit that context, and build relationships and alliances. The road may be less direct, but some of those detours—helping others to solve problems before putting out your own agenda—will help you reach your destination faster in the end.
