The instant message app chimed on my desktop. “How confident are you that we won’t find any more defects in testing?”, the department head asked. I glanced over at the task board, at the lone sticky note sitting in the “In Progress” section: “Architecture Review”, it read. I popped open the chat window, and responded, “100% sure. We are done with testing.” I watched the window for a moment as the message app informed me they were typing their reply. “Okay. Because I’m about to go report that to the senior managers.” “No problem,” I typed back. “See you at the demo, tomorrow.”
It was an awesome moment. The end of the first agile project had arrived. The last task was all but complete, just waiting for the architect to complete his review of the last set of code changes. Confidence was pretty high. A short time later, the department head sent a quick note of congratulations to the team. The senior managers were thrilled with the news that we had completed the project, the first attempt to create a web page using Responsive Design techniques, while proving that we could employ agile in this environment to achieve more rapid deliveries.
I passed along the congratulations to the team, and we began discussing plans for how we were going to stage the demo on the next day. I heard another chime from the messenger app, and popped open the chat window. The message was from the architect. “I have completed my review. I have to reject the changes. They violate our coding standards. Sorry.”
—
As news of the rejection worked its way around the team room, the developers started to look panicked. They got the architect on the line. He was going over the mistake with the team. “It’s a one-line change!” he said, trying to calm them down. “Yeah, but it’s still a change. We don’t have code-freeze.”
“What do we do?” They asked. “How do we hide this?”
—
It was one of those moments that agile coaches live for.
“We don’t hide it. We call it out.” I replied.
They didn’t look too happy with that.
“Before you freak out. Let me ask you some questions. First, how often do you get findings from an architectural review?”
The developers looked at each other. “Not very often.”
“Why is that?”
“I guess because we’ve all been working on the project for so long, we all know the architectural constraints.”
I nodded. “Good. What is different this time?”
They looked confused.
“How did you make a mistake this time? What’s different?”
One of them looked up from her laptop and said, “This is the first responsive application we’ve written.”
A smile spread on my face. “Was the problem in the responsive section?”
She nodded.
The other developer spoke up. “It doesn’t matter. It’s still a finding.”
“No one is disputing that.” I said. “The question is, ‘how did that code get into the product. You guys know what you’re doing. I can’t believe you intentionally introduced a violation like this. So where did it come from?”
I got a few blank stares. I guess they needed a hint.
“What did you base the responsive code on? You never wrote a responsive application before, and you just attended a training class on responsive design. Where did you get your starter code?”
A light dawned. “The sample code!”
“Exactly. I’ll bet nobody vetted the training materials to see if they met your coding standards.”
I turned to the phone and addressed the architect. “Can you confirm the problem came from the training sample code?”
“Yes”
“Then would you be willing to do one more thing? How long would it take you to go through the rest of the training materials and make sure there aren’t any more landmines lurking in there?”
“A few hours. I could finish it by tomorrow.”
“Perfect!” I said. “Now here is what we’re going to say…”
And then I began to explain the plan. We would report the finding. We would report that we have already corrected the error. Further, we have already identified the training materials as the source of the defect, and have reviewed the materials to see if there are other violations hidden within. We would even take it one step further, and take advantage of the fact that one of our developers would be helping teach the training class the next time it was given — ensuring that nobody else would make the same mistake again.
Mistakes happen.
You don’t have to hide from them. You need to embrace them. Examine them. Learn from them.
When we reported the problem, the resolution, and the mitigation strategy, we were not met with a negative response. The team was commended for taking the initiative to fix the problem and be good corporate citizens to help others avoid the same trap.
