I was thinking about the twelve principles behind the Agile Manifesto, one of which is “Simplicity—the art of maximizing the amount of work not done—is essential.” Why is this principle called an art, while the others aren’t? And why should we maximize the amount of work not done?

When the organization I was working for started its agile transformation, I was very keen and excited to see how things would unfold during the adoption journey. Some of the key aspects I spotted during this transition phase were prioritizing features, picking up only enough items that are doable in an iteration, and focusing on doing just the essential design that suffices for functionality. In trying to meet the iteration goal, we strived hard for simplicity by looking out for things that didn’t add value and maximizing them to get rid of all these activities.

As I continued my journey as a ScrumMaster and an agile coach, I correlated this principle to many things we do every day. I’ve come to appreciate that practicing this principle is an “art” that one needs to truly master.

For example, Microsoft Word and Excel have hundreds of features available, of which most of us probably use barely 20 percent. The other 80 percent do not add real value to the product. The product owner who decides what features should be built into the product needs to constantly analyze and prioritize whether said features are “must-have” or just “nice to have.” Once we arrive at a list of must-have features, we can safely put all the nice-to-have features into the “work not done” bucket.

The more you maximize the “work not done” bucket, the closer you get to nailing down the few truly valuable features that deliver the highest business value. It’s like revealing the inner beauty of an artifact each time you polish its surface to remove the dirt. In this way the practice really is an art, and it’s one product owners and product managers need to master.

This principle reinforces Jeff Patton’s advice to minimize output and maximize outcome and impact. What it really means is that we need to concentrate on the features that would help the customer appreciate the “outcome,” which ultimately may have no correlation with the number of features producing the “output.”

I started my career as a software engineer, and when I think of my good old days as a developer, whenever I had to develop a new feature, I often used to check if there was a similar feature already. If I found it, I could use it to save time. However, there were often many lines of unnecessary code that had been embedded into the files due to copying the existing code base as-is.

I would also often come across comments that were as big as the actual code. Instead, we should try to give importance to the coding standards and coding style. For example, the naming conventions could be written in a way that speaks as to what your code really intends to do. Add longer comments only when appropriate, and try to keep the comments simple and let the code speak for itself.

This drives me back to a basic principle of development: Think about every single line of code you write. Is it really required? Writing clean, simple code takes intent and talent. Once again, it appears that maximizing the “work not done” is an art.

As Kent Beck said, “If simplicity is good, we’ll always leave the system with the simplest design that supports its current functionality.” Concentrate on the design and the architecture of any application you’re developing. Identifying the essential, bare-minimum elements, minimizing the dependencies, and letting go of the extra things makes for a better product.

I feel this principle could lead us to question each and every artifact we capture! Think of all the documentation you produce, and ask whether the product can live without it. Think of every manual step and how much effort and time goes into them. Find ways to automate code, build scripts, testing, and installation to aid in doing things faster and saving time and effort. These are more ways you can maximize the amount of work not done.

There are a few day-to-day practices that can help enforce this principle. Meticulous backlog refinement helps in maximizing the features that don’t add value and eliminating them. Emergent design promotes building only the required architecture in par with the features and encourages to keep the design simple. Progressive elaboration of requirements during small and frequent planning sessions helps in doing away with heavy upfront planning. Engineering practices such as test-driven development enable the developers to write just enough code to make the test pass, and not a line more. It also helps prevent gold-plating and feature creep by encouraging the use of existing standards and proven solutions instead of reinventing the wheel.

This agile principle lends itself to one of the key elements of lean, eliminating waste. By maximizing the work not done, a continuous flow of value can be achieved by optimizing the value delivery chain.

The best way of instigating this principle in your daily work is to ask a question every time you make a decision: “Am I adding value by doing this?” The goal is to deliver the highest value with the fewest number of items, and I perceive this to be a real art that comes from experience.