Having the Right Answer is Not Enough

I’ve often been involved in conversations exploring the right way to build software in large organizations. Very commonly, clients are exploring Agile versus Waterfall. Recently, at a significant conference in our industry various people were representing different “best ways” to build software. Different people held options like Scrum, XP, SAFe, LeSS, and Disciplined Agile Delivery as the right answer. On the LinkedIn groups I follow Prince 2 Agile and Critical Chain Agile are being passionately discussed. Everyone is trying to promote their view as the right answer. Almost without fail, these discussions fall into unintelligible jargon or devolve into unresolvable religious debates.

They are having the wrong discussion.

What I find interesting is that they all have a right answer – they all have an answer that solves some problem in some set of conditions. And all will fail in some set of conditions – the different solutions are appropriate for a different set of circumstances. Each solution requires different conditions to exist to be successful.

The discussion has to start with, “what problem does that solution solve for” and “what conditions must exist for that solution to work“.

Be explicit about what problem you are solving for.

• We have a pretty clear outcome that customers expect at a certain date in the future and we must hit that date.
• We are developing new customers for the product and respond almost weekly to what we learn.
• We are working on a large-scale project across multiple platforms and we are having challenges with testing everything across the platforms.
• We need to improve the rate we can deliver software because our customers are expecting new things faster.

Clearly understand the set of conditions that have to exist for the solution you are implementing to work.

• What underlying organizational structures have to exist?
• Are teams autonomous and can advance independently? Do you need planning and coordination across multiple teams?
• How tightly coupled is the architecture you are working with? Are the teams aligned with the architecture?
• Do you have existing technical practices that support incremental development and rapid deployment?
• Can you frequently integrate and validate the product?
• Does your governance model align with the level of ambiguity you are facing?
• What does the governance model require you to support?
• Do management, HR and accounting understand and support what needs to happen?

Having the right answer is not enough.

Without understanding the problem the solution solves for and the conditions that must exist for that solution to work you can’t even begin the discussion. In most cases, the right place to start is to understand the end state you need to solve your problem before you identify the solution you need. Then get really clear on what conditions have to exist for that solution to work.

From there you can determine if those conditions exist in your organization, figure out what is in the way of getting the conditions in place, and plan the specific actions required to get the conditions in place.