Lean software development principle – Decide as late as possible

This is the fourth post in a series of posts on Lean Software Development. It was hardest one to write because I struggled with the differences between the Lean Startup principle of failing fast versus this principle of Delaying decisions.

The idea with this principle, is to wait until as late as possible before making a decision. This allows you to gather information during the process, by getting feedback, to make the most informed decision. The Poppendiecks state that delaying decisions is valuable because better decisions are made based on fact and not speculation, and a key strategy for delaying decisions is to build the capacity for change into the system1.

Clearly this definition eliminates the waterfall development methodology as a means to run software development projects. With waterfall big design is done up front, with all technology and functional decisions being locked into the scope of the project at the start. Compare this to Scrum as a development methodology, where the product owner and team are making decisions for short periods of time. With the shorter iterations the team is getting feedback regularly,  allowing the team to change direction often over the course of a project based in these inputs.

In Scrum, because the iterations are short, there is not as much effort been spent in a large documentation process at the beginning of the project, enabling the project team to rather provide functional and technical options to the clients. So how do I gather information and learnings to decide as late as possible?

If we take a Lean Startup approach these options could be created in the form of a Minimum Viable Product (MVP),  they could then be deployed into production to gather feedback using split testing or some form of feature toggling. We have just recently introduced feature toggling into our application and have expanded this to be more than a simple on/off switch. We now have the ability to launch features just to staff and gather feedback on the feature before launching to clients. We have as yet not used our staff toggle but the idea is that if there are any untoward consequences then we can fix and test again.

Teams should be encouraged to generate MVP’s in this way to gather feedback allowing for the informed decision making. But to do this your application must be flexible enough to allow for this.

One of the Lean Startup principles, describe by Eric Ries in his book The Lean Startup,  is the principle of “Eliminating uncertainty”. I see similarities between the Lean Startup principle of Eliminating Uncertainty and and this Lean Software Development principle of “Deciding as late as possible” and another principles of “Amplify learning“. So why do I see these principles being similar? Firstly options are being provided and decisions are being made as late as possible based on learnings, therefore eliminating uncertainty.

Deciding as late as possible is also very prudent when making infrastructure decisions. When creating a new system the first things we lock ourselves into are typically the OS, database, web servers, containers etc. As developers we should think carefully which of these infrastructural decisions we indeed have to make early.

In his talk on Clean Architecture and Design3, Bob Martin says that a good architecture is one that allows major decisions to be deferred and secondly that a good architecture maximises the number of decisions not made 4. This highlights the importance of architecting and factoring your solution properly, to be able to defer implementation decisions to when they are absolutely required. The approach that he took when creating FitNesse is a good example of using these principles.

This extract from the Complete IT Professional really sums up this principle nicely:

This principle means that there should be enough flexibility in the system and in the process to be able to make decisions later in the project. We shouldn’t need to make decisions early on that are defined by the needs of the project.

This doesn’t mean that we don’t make decisions at all. It means that using an iterative development cycle and the “amplify learning” concept, we should be able to gather requirements and facts quickly, and then make a decision, rather than deciding early without all the information we need.2

In closing, if your are cynical, you could see this principle as procrastination. However looking deeper, it is really about not locking your product or application into decisions that are costly to undo later and critically asking the question whether you truly need to make the decision now.

References

  1. Lean development introduction – available at http://www.poppendieck.com/pdfs/Introduction.pdf.
  2. Lean Software Development Principles – available at http://www.completeitprofessional.com/agile/lean-software-development-principles/
  3. Robert C Martin(Uncle Bob) -Clean Architecture and Design-2012 – available at http://www.youtube.com/watch?v=asLUTiJJqdE
  4. Robert C Martin(Uncle Bob) -Clean Architecture and Design – available at https://dl.dropboxusercontent.com/u/4730299/Architecture%20the%20lost%20years.pdf
Advertisements

About craigew

I am a technologist at heart and enjoy working with like minded people who show a passion for what they do. Craftsmanship is important to me and each day I am honing my skills as a software developer on a journey to one day becoming a master software craftsman.
This entry was posted in Lean, Software development and tagged , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s