We decided to meet at a nearby restaurant on our way to work. By the time I arrived, Joe was waiting there for me. We wanted to make this a short meeting not exceeding 30 minute.
We started our conversation and placed our orders. Joe started it slowly after a quick icebreaker on some of the trending news items.
“This is about the recent Sprint. Even after passing all acceptance tests, we came across a defect in the system. It blew up the whole thing. The VP of engineering, our customer is furious. ”
“Joe. Could you please be more elaborate and tell me what happened?”
“Well, we delivered the right thing. It is the legacy code that had hidden a bug. This legacy code was developed years ago. May be five years or seven years ago by some developers at customer site. We are held responsible for something that fails in the legacy code.”
“Why so? Do you think the acceptance test could have been improved to cover such scenarios?”
“I don’t know. We wrote the acceptance tests. We considered the Definition of Done and the tech lead at our customer site reviewed all test cases and passed them. When we did our Sprint review, all of us agreed that the stories were done and delivered. But this bug came up at a later stage.”
“Tell me. Has this happened before? How can you solve this problem?”
“It has happened couple of times before but it was not a big concern. This time it became a red alert. This is not our problem. This is because of the legacy code. It is not modular. It is messy. Every time we write a piece of code we are worried because the code we write has to work with legacy code. Our customer does not understand this reality. What can we do now?”
This is when I decided to nudge him a bit.
“Joe, I understand what you are talking about. This problem is affecting you and your team. You need a solution this problem. Take ownership. Why not?”
Joe understood the way I nudged him. He repeated what I said and continued. “Take Ownership! Why not? Could you please tell me what you mean by this? I can take ownership of a problem I caused. Why should I go and fix a messy code?”
I paused for a while and explained him the importance of taking ownership. He was listening to me. I continued.
“Joe. A similar escalation happened in my project years ago. I convened a meeting with my team. We analyzed the legacy code and listed out all issues. We shortlisted and wrote a 2-page document to list the top-10 issues. We added our recommendation on resolving those ten issues and listed the benefits. We presented this to our customer. We had to go through a tough negotiation. Finally, our customer gave us a go ahead. Our team got the necessary budget and schedule to resolve those ten issues.”
“Interesting. Does it help you make the legacy code clean and prevent all issues?”
“Yes. To some extent. It helped us in two ways. First, we cleaned up the source code by fixing the top ten issues. Those were broad issues related to design and coding standards. Second, we understood the legacy code very well by improving the code base. This helped us prevent several issues. How about considering a similar approach in your project? How will that work? Isn’t it an opportunity for you? Take ownership!”
“Yes. It is! I can’t think about a better idea. I must do something like this.”
“Joe, that’s good. Take this as an opportunity to turnaround and win customer confidence. I am sure you will.”
“Sure I will. Thanks for your time! It is time to go to work! I will catch up with you later!”
“Good luck Joe! Keep me posted!”
Our short meeting over breakfast came to an end. Later that day I couldn’t stop thinking about numerous incidents related to taking ownership. It happens at work! Isn’t it?