It would have been easy to blame the developer, Fred, who had integrated his feature. But that wasn't the team's culture. There was a rousing chorus of "brain-dead code" at our meeting. I suggested we do a quick root-cause analysis at our team meeting, to see what had gone wrong. I was sure we had several issues at work, and it would be worth our while to see what was happening. The team agreed.
The team discovered several things had occurred (see the following figure):
Dan took the lead. "OK, what do you guys want to do?"
Fred replied, "Look, we all know how I can be." Everyone except me nodded, grinning. "I really want someone to review my code each and every time. I'll write unit tests, especially since we don't have testers, do we, JR?"
I replied, "Nope, we don't. Unit tests are a great idea. They aren't the same as system tests, but they should prevent this problem."
Dan said, "But we're not done yet. Just code review and unit tests aren't going to be enough. We're going to have to go to multiple levels of check-in, like we did on the last project."
I replied, "You don't have to do that. You could all just check in all the time, and let the build and unit tests catch the problems."
"No, are you brain-dead?" asked Sam. "That will never work. We need multiple levels of check-ins."
"Well, let me explain how it works," I started.
"Look, you might have used that on a team with testers, but without testers it ain't gonna work," replied Sam.
"Well, if you feel that strongly about it," I replied.
"You bet I do."
"How about everyone else?" Everyone else nodded. "OK. Let's see how the multiple levels of check-in work before we consider an alternative, OK? I'm going to want to build a rolling wave schedule [3] with you so I know what's going on and can track it."
Sam was concerned. "This rolling wave schedule—what is it and how will it help me? Am I going to need to do anything more than my work?"
"Well, you'll all need to spend about 30 minutes getting the schedule ready the first time. Then, we'll update it with your status reports and my one-on-ones with you. If we run into trouble, we'll have to spend another 30 minutes all together, but that's it. Will that work for you?"
"Uh, OK."
"Sam, you know, JR isn't brain-dead, at least not yet." Fred started, and everyone chuckled. "You haven't worked with her before, have you?"
"Nope."
"She pretty much leaves us alone, but she runs interference. If Big Cheese comes to you with a request, you suggest—politely—that he go to JR, and she'll take care of it. Besides, if we don't like what she's doing, we can fire her. Right, JR?"
"You bet!"
Now the team had some safeguards (the multiple levels of check-in) for managing the issues of people working independently and wanting to check in at the same time. They decided to add code review back into their practices. In addition to code review, all developers were now required to write unit-level tests for all their code.
The team decided not to add anything to the system-level test regression suite. They could not imagine they would have enough time to manage the development and that level of testing. But they were quite happy to write unit tests for all their code.