DURING A PROJECT WHEN I WAS THE PROJECT MANAGER, I HAD THIS CONVERSATION WITH A SENIOR manager at a company:
Big Cheese: "Stop those code reviews. They're slowing down the project."
Johanna: "But then we won't know where the bugs are. We need the code reviews."
Big Cheese: "Stop them or I'll fire you."
Johanna: "You'll fire me for doing the right thing?"
Big Cheese: "In this case, the right thing is to finish the project as fast as possible. Stop those code reviews."
Pretty strange conversation, eh?
I wish I could say this was an isolated incident. But even though this particular conversation occurred almost 20 years ago, it still happens every day someplace. This is the story of a team that refused to buckle under management pressure to do it fast. The team knew that they if they did a great job, they could do it fast, by doing it right.
If we turn on the Way-Back machine to the beginning of the project, Big Cheese brought the project team together and said, "I have great news. I sold a new version of ProcessControlApp. But it has to do these three things faster, and have these five new features. And, we need it in six months."
The project team of six developers got together and discussed the problem. They'd worked as a team for several years. The newest team member had 18 months of experience working on the product with the team, and the most senior developer had initiated the product four years before. They knew each other and how to work together.
ProcessControlApp had no GUI because it was integrated into a manufacturing line. All of the access into and out of the application was through the command line or through an API. ProcessControlApp did a visual inspection of the material on the line, made some decisions about the material, and commanded the line based on its decision. So, although there was no GUI, ProcessControlApp was a highly complex application, where performance (how fast could the software make the decision?), reliability (how much uptime did the software have?), and accuracy (how many false positives or negative decisions did the software make?) all counted.
For the previous two releases of ProcessControlApp, they'd all worked together, along with two testers and a writer. They knew how to work together as a team. They told the VP of software engineering they needed that same writer and two testers.
I was the SQA manager, so it was my job to assign testers to different projects. When I met with the engineering VP, Nancy, I explained I had no testers available. "But you have to give them two testers. They can't get the project done without them."
"I have no testers. Look, here's where everyone is allocated." We discussed the other projects and their relative priorities [1]. Nancy agreed that I had no testers to provide. I asked about hiring more people, and Nancy told me I had no budget to hire more people.
I thought for a minute and suggested, "Hmm, I can't do the testing, and I can't give them testers. But here's what I can do for the team. I can be their project manager, help them see options, and remove obstacles so that they can get work done. Since this is a process control application with no GUI, this is possible. Difficult, but possible. Is that OK with you?"
"Talk to the team and see if it's OK with them."