Essentialism is agile

I’m reading Greg McKeown’s book Essentialism: The Disciplined Pursuit of Less and many of the lessons within it echo the tenth principle from the Manifesto for Agile Software Development which is “Simplicity–the art of maximizing the amount of work not done–is essential“.

In the past, I’ve mostly considered this principle as it relates to how we deliver value to our customers. It provides a constant reminder that practices, ceremonies, tools and artifacts are just a means to an end, and shouldn’t be elevated as an end unto themselves. Minimal sufficiency should be our goal when expending effort on anything which doesn’t create business value for our stakeholders.

But we can also apply this principle to our products.

While Greg’s book provides a lot of insights, there’s one line which really resonates with me: “If it isn’t a clear yes, then it’s a clear no.”

Greg provides an example of the company Vitsoe which applies this filter when hiring new staff, but the same principle could be applied when deciding what to include in product backlogs. Let’s consider the example of the mice provided with the first Apple Macintosh computers. The design team at Apple could have added multiple buttons and scroll wheels the way future generations of PC mice were designed, but a single button sufficed to allow a user to effectively use the Macintosh graphical user interface.

This principle is key when defining Minimum Viable Products (MVP). A good MVP should generate empirical evidence to support or refute a hypothesis and adding features which won’t directly support that learning is waste.

But minimal sufficiency could be applied beyond MVPs to general releases. By doing so we can reap some of the following benefits:

• Reducing learning curve. One of the attributes of well designed products is that they can be used with minimal instruction.
• Reducing ongoing maintenance costs. To quote Scotty from Star Trek III: The Search for Spock – “The more they overthink the plumbing, the easier it is to stop up the drain“
• Reducing ongoing regression testing efforts. As system complexity grows, the points of interdependence between seemingly unrelated components makes it almost impossible to avoid regression defects.
• Focusing development teams on core capabilities.

To quote Greg, the next time you are considering whether or not to add a feature, ask yourself the question “Is this exactly what I am looking for?”