Maximizing the Amount of Work Not Done

One of the principles of the Agile Manifesto reads: “Simplicity – the art of maximizing the amount of work not done – is essential.”

Okay. What does that mean? Does it mean we should avoid doing our work to the extent possible? Well, not exactly.

Consistency Between Lean and Agile Principles

Without coming at the question from that angle (as far as I know), the authors of the Manifesto arrived at an idea from Lean Thinking – the idea of reducing process waste. Maximizing the amount of work not done means maximizing the amount of unnecessary work not done.

General principles in Lean Thinking are:

• Define value
• Identify the value stream
• Flow
• Pull
• Perfection

Agile thinking is consistent with these principles. The idea of maximizing the amount of (unnecessary) work not done fits in perfectly with Lean principles.

What’s Value?

“Value” in the context of delivering products and services to customers is defined by the customers. It’s whatever they think they’re paying for. Anything other than that is defined as “waste” in Lean terms. If we have to do additional things beyond building the product the customer cares about, that’s on us. It’s overhead. So, we want to minimize all of that.

Regulatory compliance? Absolutely, yes. Customers expect us to be compliant, but that isn’t specifically what they’re paying for. The cost of compliance is on us. We want to minimize that cost.

Basic product safety? Absolutely, yes. Customers expect the product to be safe to use, but that isn’t specifically what they’re paying for. The cost of product safety is on us. We want to minimize that cost.

What’s a Value Stream?

A value stream consists of all the steps necessary to deliver a product or service to a customer, starting from the beginning. For instance, the value stream to deliver a hamburger to a customer in a fast food restaurant includes all the steps from growing the grain for the buns and raising the cattle for the meat to grilling the patty and placing it lovingly between the top and bottom bun halves.

Womack and Jones, in their book, Lean Thinking, speak of aligning value-producing activities with the value stream. In the context of a software development and delivery organization, the value-producing activities include all the usual things we do when we produce software, from deciding what functionality we should write, prioritizing the various bits and pieces of the functionality, deciding how best to implement the functionality, getting the resources we need to do the work, organizing people into groups or teams to get the work done, obtaining funding for the work, keeping track of things so that we stay on target with customer needs, fixing any errors or other problems that come up along the way, adjusting course as we learn more about customer needs and about how best to implement the solution, checking, packaging, deploying, releasing, and monitoring the solution, getting feedback from customers about how to improve the solution, etc.

Exactly how we do these things is up to us. We want to minimize the cost of doing them. If we set things up so that it’s cumbersome to get the work done, our customers won’t pay extra to cover the cost of our inefficiency. It’s our problem, not theirs.

What’s Flow?

In the context of product delivery, we’re interested in continuous flow of product through the value stream. Any time value-add activity is paused to wait for something to happen, flow is interrupted. All that waiting time is waste.

Consider a water pipe. One would expect to pump water through the pipe at a predictable rate, based on the diameter of the pipe. But if the pipe wasn’t laid out in a straight line, there may be twists and turns in it that interfere with the flow of water. And if the people who designed or built the pipe weren’t very good at the work, there may be unnecessary structures inside the pipe that block the water. And if the pipe has been in place a long time, there may be corrosion on the inside that slows down flow. And if the operators of the pipe aren’t knowledgeable about how water flows through pipes, they might create back-pressure by trying to pump too much water through the pipe too fast, resulting in slower flow. If they really crank up the pressure they might split the tube or cause a rupture at some connection point between lengths of tubing.

There are analogues in a software development/delivery organization. One would expect product to flow through the organization at a predictable rate based on the scope of planned work and the demonstrated delivery capacity of the organization. But if the people are organized into functional silos rather than product-aligned, cross-functional teams, there will be twists and turns in the flow of work that impedes smooth delivery. And if the people who designed and established the delivery process weren’t very good at the work, there will be standards, procedures, reviews, approvals, and other unnecessary structures within the delivery pipeline that impede flow. And if the processes have been in place a long time, there will be rusty old rules and procedures and forms and meetings and reports whose original purpose has been forgotten and may no longer be necessary. And if management isn’t knowledgeable about how work flows through organizations, they will create back-pressure by driving their people to work harder, when that isn’t actually the reason work isn’t flowing well, resulting in fatigue, burn-out, low morale, and high turnover, all of which reduce flow. If they really crank up the pressure, the organization will gain a reputation in the workforce as a bad place to work.

Maximizing the amount of work not done means aligning value-producing resources and people with products and services, to promote flow. Accompanying that, it means understanding priorities based on customer-defined value, as well as keeping the “pipe” clean by treating the workers properly. That way, we minimize unnecessary thrashing, which keeps people busy but doesn’t contribute to delivering value to customers.

What’s Pull?

With a pull system, customers draw value out of the system when they need it. Each step in the process of creating the product pulls from the step before it on demand (or according to so-called order points, to refresh supplies of needed resources).

In contrast, in a push system the people running the system stuff work into it without regard for the delivery capacity of the system, the rate at which customers want to buy, or the cost of unfinished goods inventory that piles up at bottlenecks in the system.

In a software development organization, when management doesn’t consider the capacity of delivery teams or the limitations of bottlenecks in the process, they tend to add more and more work to the “to do” list arbitrarily. Well-intentioned workers try their best to meet this demand by working overtime and burning themselves out.

The simple reality is that no system can operate at a rate faster than its constraint (tightest “bottleneck,” for lack of a better word). So, to maintain flow and deliver customer-defined value smoothly, we want to limit the amount of work we introduce into the system to the capacity of its constraint. Once the system has stabilized at that level of production, we can think about ways to increase capacity. Until then, we’re thrashing.

Maximizing the amount of work not done means limiting input to the system to the level at which the constraint in the process can process work. The simplest way to do that is to allow downstream process steps to pull work, rather than pushing work into the system.

What’s perfection?

Perfection is the name of a fictional town in Nevada that serves as the setting for the 1990 cinematic masterwork, Tremors. In Lean Thinking, perfection is the unattainable target of our process improvement efforts. We choose perfection as the target as a way to avoid becoming complacent in our work. We can’t actually achieve perfection; therefore, as long as we keep striving for it, we’ll never stop looking for opportunities to improve.

The LeadingAgile Model and Maximizing Work Not Done

We emphasize three things: Structure, governance, and metrics.

Just as the physical structure of a water pipe determines the rate of flow more than any other factor, organizational structure has a greater effect on flow than any other factor. Our guidelines for Basecamp 1 include forming teams. That means forming cross-functional teams aligned with products and services; it doesn’t mean just any old random team structure. The appropriate organizational structure will do more to maximize the amount of work not done than any other changes we might make. We’re removing the kinks from the pipe and straightening it out.

By governance we don’t only mean procedures to assure regulatory compliance, we mean all the processes and procedures and rules and standards and so forth an organization uses to get work done. We’re removing the unnecessary internal structures from the pipe and cleaning out the corrosion.

Metrics help us understand how well work flows through the pipe. With the appropriate metrics in place, we can make data-driven decisions about how fast to pump the water in order to maximize throughput. We’re measuring capacity and adjusting work-in-process levels to maximize flow.

Once we know how fast to pump the water, and we’ve moved the pump from the front to the end of the pipe so it can pull instead of push, we need to learn how to manage the whole system properly. That includes market analysis, strategic planning, prioritization, backlog creation and refinement, story mapping, coordinating multiple work streams, dealing with cross-team dependencies, and applying robust engineering practices to design, code, testing, packaging, deployment, infrastructure, and production monitoring. With these skills, we can maximize the amount of non-value-add thrashing in the organization, and provide a smooth flow of value to customers.

When we understand our market, we maximize the amount of work not done by avoiding investment in products and services that will not yield customer value.

When we understand our core business, we maximize the amount of work not done by offloading non-core but differentiating activities to partners, core but non-differentiating activities to suppliers, and discarding non-core, non-differentiating activities. Then we can focus our people and our resources on differentiating core business investment.

When we understand how to apply practical management methods and sound technical practices to the work, we maximize the amount of work not done by avoiding delays due to cross-team dependencies, misunderstandings, and errors, and redundant or non-value-add procedures so that we can focus on serving customer needs and maximizing product quality.

All the pieces fit together, across the three dimensions of structure, governance, and metrics, and vertically from strategic leadership to on-the-ground execution.