Simplicity–the art of maximizing the amount of work not done–is essential. — Agile Principle #10

A simple development process is a lean, efficient process with no unnecessary work.

This principle is the most direct connection between the Agile Manifesto and lean thinking, which calls for the elimination of all “unnecessary waste” from processes, and the minimization of “necessary waste” that a process needs to run, but that does not directly add value. In software development, value is in the form of working software, and everything else is waste.

A Simple Process Has Less Waste

From a lean perspective, all documentation — including requirements, User Stories, system architecture and database models — is waste. All tests — including unit tests, regression tests and even acceptance tests — are waste. All project management and stakeholder management activities are waste. Some of this is necessary waste.

The authors of the Agile manifesto pushed boundaries by eliminating documentation that seemed necessary — until they proved that it wasn’t. They removed large chunks of waste, in the form of lengthy requirements and specifications documents, by replacing these deliverables with the smaller “necessary waste” of User Stories. They eliminated detailed project plans, replacing them with backlogs. They eliminated all the waste associated with late integration by integrating at the end of every sprint — or even more often.

Over the years since the Agile Manifesto was published, the field of DevOps has tackled other types of waste with automated regression testing, daily builds and other tools to keep software flowing through development and out to the customer.

A Simple Process Keeps Value Flowing

We tend to think of “simple” as basic and perhaps inadequate to the needs of a complex product. But that’s not the type of simplicity that this principle describes. This is the simplicity that comes from elegant design, with nothing extra, that leads to a process that fulfills its purpose in a way that is easy to understand, easy to execute and easy to manage.

We layer in only the complexity we need to perform the work to be done. A medical device will necessarily have a more complex development and testing process than a desk lamp, but “complex” doesn’t have to mean “complicated.” We should still strive to have a development process that is easy to follow, and easy to use, focused on maximizing the flow of value.

This is hard to do, because development processes tend to grow more complicated over time, no matter how simple our product may be.

Where Do Processes Begin to Become Complicated?

Here are three sources for complexity in development processes:

• The desire to follow industry standards that have worked elsewhere. Sometimes, people add things to the product development process because they represent the organization’s understanding of “best practices” or “industry standards” that may or may not actually apply to the organization. Instead, we want to understand what problems a “best practice” is trying to solve. We may not have a problem that the practice will solve, or we may have a different way of accomplishing the same thing.

For example, many groups produce a “Marketing Requirements Document” (MRD) to transfer knowledge about requirements from the marketing group to the engineering group — but is this the best way to manage this knowledge? Requirements management tools do a better job of managing the many decisions that such a document bundles together, some of which are Key Decisions that need special attention.

• The desire to maintain control in a dynamic situation. Meetings proliferate for a different reason: managers feel nervous that a program team isn’t doing the right things or seems to be struggling, so they ask for more meetings to try to maintain control. In crisis situations, the meetings could be daily. But every meeting takes time that could be spent fixing the problem, and takes decision making away from the people who are closest to the problem and best suited to make decisions about it.

Micromanagement is clearly unnecessary waste. The Agile Manifesto authors sought to eliminate every meeting except a short daily standup for the team, and a Sprint Event at the end of an iterative development cycle. How many of the meetings on your calendars are really needed? How many reviews and approvals do you need, and how often do you find something via these reviews that needs to be fixed?

• The desire to prevent the problems we’ve had in the past. Every painful late-found defect leads to the desire to try to prevent it earlier, in a design review or in an earlier test. This can lead to lengthy checklists that become unwieldy, or to approval steps that add delays.

This is problematic for two reasons. First, every item on a checklist is something that will take time, even if it’s just a few minutes to see if an item has been checked off. Over time, this creates a lot of process overhead. Second, it doesn’t fix the problem. The root cause of a late-found defect is a decision made earlier in development, and the real danger doesn’t come from repeating past mistakes — it comes from making new ones.

Simple Processes Prevent Mistakes with Focus

A simple process is one that prevents these problems from being made in the first place, with a minimal amount of overhead and only the documentation needed to fulfill the purpose. This allows the team to focus on the work that adds the most value by building the most knowledge.

In physical product development, we necessarily need Bills of Material, CAD models and drawings, sourcing decisions captured in purchase orders and vendor contracts, test plans and assembly instructions. We should look for tools to manage those items that have only the complexity we need, without being complicated.

This principle appears in all forms of Operational Excellence because it is universal. The only thing I would add to it is its purpose:

“Simplicity–the art of maximizing the amount of work not done–is essential to maximize the flow of value.”