Imagine this: You're busy at your desk, when you overhear a colleague say, "This legacy code is really messy." Someone else says, "Yeah, it's impossible to work with." Within minutes, the entire team has agreed that they're not going to put up with this shoddy system anymore and that someone should do something about it. Someone says the team should be allowed to rewrite the system from scratch to "get it right this time." The others agree and return to work, the mutiny apparently forgotten. You sigh and say to your colleagues, "I understand where you're coming from, but to really fix this problem let's make sure we have a solution that we can sell to our bosses and they can sell to our customers." Your colleagues' jaws drop at the suggestion that they do something rather than just moan. "I don't like the idea of selling anything to anyone," one says, to which another responds, "And our bosses will just say no anyway." "OK," you say. "Instead of selling our idea, how about if we polish it so we don't have to sell it?" They look around, nodding, and then someone asks, "How do we do that?"
 |
Step One
The first step is to use the "Five Why" technique to ensure you tackle the right problem. When you ask your colleagues why they want to rewrite the core system, they might find it easy to come up with a list of symptoms, such as "It's hard to work with," "It's flaky," or "It's bug ridden." But there's no point tackling the symptoms—you need to identify the root cause of those symptoms. Keep asking "why" until you come up with what everyone agrees is the root cause.
When I'm trying to find a problem's root, a whiteboard and sticky notes are very helpful. They allow me to present the symptoms (on sticky notes) and the answers to the "whys" (on more sticky notes). Each answer is reviewed until we come up with a root cause.
Imagine that our colleagues came up with the root cause being "Over the years we've compromised the system design such that it has become very difficult to work with."
Step Two
What do you do once you've found the root cause? The second step is to develop a sensible way of tackling the root cause. In this case, your team has suggested rewriting the system. I call this the "alpha" solution because it still has a number of bugs that need to be ironed out; otherwise, you probably already would have implemented the solution.
Step Three
The third step is to ask "why" again, but this is a different type of inquiry. Whereas the Five Why technique looks at the causes of the problem (why the symptoms exist), now you want to discover the positive consequences of implementing the alpha solution. After some discussion, your team agrees that rewriting the legacy code will improve productivity and make their jobs more satisfying. But then someone says, "This is so obvious, it's a wonder no one has suggested it before," which brings you nicely to...
Step Four
Now you ask, "Why not?" or "What are the negative consequences of doing this?" You ask, "What would customers think about this idea?" Most say that in the long run they'd approve, but one person says, "We wouldn't be able to deliver any new functionality to customers while doing the rewrite, which would take a long time."
"And I'm not convinced we'd ever be able to successfully rewrite the system and maintain our credibility," you add, feeling awful about playing devil's advocate.
Step Five
You give them a few moments to ponder this new problem and then ask if they want to do a little "And Thinking," also known as integrative thinking. In his book "Opposable Mind," Roger Martin defines integrative thinking as "the ability to constructively face the tensions of opposing models, and instead of choosing one at the expense of the other, generating a creative resolution of the tension in the form of a new model that contains elements of the individual models, but is superior to each."
You explain to your team, "We seem to be at an impasse, but we've actually uncovered new information, so we need to polish our solution." This new information uncovered a new need, which is to improve the productivity of the system. Unfortunately it jeopardizes an old need, which is to keep delivering useful new software to your customers. "We've made progress," you say. "Unfortunately, this solution can't sell itself. Our customers wouldn't stand for no new deliveries for the next six, twelve, or eighteen months. But can we fulfill both needs at the same time? Can we work on the core system AND continue delivering new functionality in the short term? I challenge you to find a way of doing both."
And Thinking allows you to focus on satisfying as many needs as possible, rather than wants. Depending on the problem, you may instantly develop an improved solution—one that keeps both sides happy—or you may need to ponder the challenge for a while.
Step Six
Now you reach step six, where you polish your beta solution even more by asking "Why can't we do this now?" This is where people will generously tell you the undesirable side effects of implementing the beta solution, such as increasing the amount of testing or the obstacles the team might face (like getting approval from the powers that be). Collect as many of these blockers as you can and use them to refine the beta solution and plan how to implement it. Some of the people who raise these issues are also the best to help you to overcome them. You now have a release candidate.
Step Seven
Finally, in step seven, you ask a particularly challenging question: "Our solution solves the original problem, but has it opened up new possibilities for us or our stakeholders?" You'll want to ponder this for a bit.
Let's say that the team's beta solution was to clean up the XYZ module, and they've done that. Then you overhear a conversation between two developer colleagues. "Do you remember those marketing requests we didn't do last August because the estimates were too difficult? Now that we've cleaned up the XYZ module, completing them probably would take only a third of the original estimation time. Do you think we should tell someone?"
