Considering a New Methodology? First, Understand the Question

Solutions are meant to solve problems.

In Douglas Adams’s Hitchhiker’s Guide to the Galaxy series, an advanced civilization builds a supercomputer to calculate “the ultimate answer to life, the universe, and everything.” After millions of years of calculation, the computer finally gives its answer: forty-two. Despite being an advanced civilization, it succumbed to the pitfall of getting an answer without first understanding the question.

We often fall into the same trap. I once worked on a development team that practiced Agile programming. Every now and then the team would debate whether we were really practicing Agile, whether we should do more Agile, whether we should abandon Agile altogether, and whether we should adopt some other methodology. The debates centered on personal preferences and impressions of team productivity. Alternatives were suggested based on what the team had tried before and who had what certifications. Never did our conversations start with understanding what problems the various disciplines were designed to solve. Neither did we begin with the most important question: what problems were we trying to solve? We jumped straight to the answers without first understanding the question. Forty-two.

The concept of Lean started in manufacturing and has spread to entrepreneurship, programming, design, construction, and beyond. Usually when a team decides to adopt Lean, they start by adopting the tools. They begin value stream mapping, erecting kanban boards, laying out key performance indicators, memorizing the 5 S’s, and learning a variety of Japanese words. Rarely do they ask the question Lean is designed to solve: Is there waste in our process? Companies adopting Lean often jump past the question to executing the answers.

Without keeping an eye on the core question, acting on the answers can actually add to the problem. Lean aims to eliminate waste, but training everyone in the new methodology, staying up-to-date on best practices, and evaluating the team’s adherence to the discipline can easily add waste instead of removing it. The same habits on an Agile development team can create bureaucracy that robs the team of the very adaptability Agile is designed to provide. Paying more attention to how well the team is implementing the answers—rather than how well it’s solving the questions—quickly turns a helpful methodology into something harmful.

Lean, Agile, and many other popular methodologies have generalized over time; they solve broad problems like waste, reliability, and changing requirements. But the problems we face day-to-day are specific. Mismatching general solutions to specific problems can cause headaches. You might have tried Extreme Programming and abandoned it because it caused too many problems, but perhaps Extreme Programming wasn’t the wrong solution, only too big of a solution. Test-driven development might have solved the problem, but focusing on 100% pair programming got in the way. When you’ve skipped past understanding the question, you run the risk of emphasizing the wrong parts of the right solution.

It’s easy to sour on formal solutions — jumping from one diet-of-the-month to another. Until we understand the ultimate question we are trying to answer, we’re easily lured astray by procedures and tools that promise to cure all our ills, and in some cases actually might, but only if we have the right problems. Without first identifying the problem we are trying to solve, we are in danger of repeating the mistake of Douglas Adams’s fictional civilization, spending too much time and too much effort only to produce an answer that doesn’t solve the original problem.