Theory of Constraints, Lean, and Agile Software Development

[article]
Summary:

Delivering More Business Value Where Needed

Within the software development community, one of the biggest movements over the past decade has been Agile Development whereby teams adopt practices and attitudes consistent with the now famous Agile Manifesto. Additionally, there has been much discussion over the past four to five years about applying principles from the Theory of Constraints (ToC) and Lean Product Development (Lean) to software development. This has had a tendency to muddy the surrounding waters as teams question whether they  should apply Agile, ToC, or Lean concepts. Are these three approaches mutually exclusive? Is there some hidden magic that can be unlocked by careful application of all three? Isn't it hard enough just trying to be Agile, without also trying to be Lean and ToC-ish? In this article we give an overview of Lean and ToC and show how they can be used in conjunction with Agile practices to focus on an organization's business value. By using elements of Lean, ToC, and Agile together more business value can be delivered with less effort.

Introduction
What is important to your organization? The answer to that question is as varied as the number of organizations that exist. Software that we build should always address/advance one or more of the organization's goals. With advent of Agile development we have become much more effective at meeting those goals. We have also become adept at recognizing and responding to changes and making course adjustments appropriately. So is that enough? Are we there yet?

There is more that can be done. By borrowing some good ideas from the business world, namely ToC and Lean, we can target our customers' needs and goals even better. In this article we briefly outline how to do so and give references for further reading.
The diagram in Figure 1 shows a very simple process that will be used for illustration of Lean and ToC below. Each step has a speed indicated in parentheses below the step name. Inventory builds up between two steps when they are of mismatched speed - therefore because step A is faster than step B, an excess product of A waits to be processed by B.

ae0307-1
Figure 1: Simple Sequential Process (SSP)

Lean
Much has been written about Lean Manufacturing and its application to software development. Lean is all about defining value as the sole service/product delivered to the customer. Everything else that does not either directly or indirectly provide value to the customer is seen as waste and is to be eliminated. Broadly, the steps in Lean, as defined by Womack and Jones [2] are:

  1. Define value for your customer. Everything else is waste. Learn to see that waste.
  2. Eliminate all waste. Any step that does not provide value for the customer should be a candidate for modification or removal from the process.
  3. Make steps in your process flow. Each step in a process should directly feed into the next one without delay. Inventory is one form of waste because it does not deliver value to the customer.
  4. Pull work. That is, a step in the process should not create anything until it is needed by the step after it. This brings inventory levels down to zero and only processes work ls "pulled" by the customer at the end of the process chain.
  5. Work towards perfection. That is, go back to step one and make things better - remove more waste.

With respect to the SSP process in Figure 1, value would be defined with respect to our customers–anything they are willing to pay for {sidebar id=1}(not intermediate results). We would next see everything that does not deliver value as a "waste" and work diligently to remove that waste until the steps flow from one to the other without waiting or inventory. We would then only create product when the customer (at the end of the process) requests–or pulls–it.

By continuously eliminating waste the entire system delivers more and faster with less effort. Mary and Tom Poppendieck [7, 8] have given us a guide describing how this relates to software development directly. They help us see different forms of waste in software development such as stale requirements, gold plated code, and functions that are rarely (if ever) used. They also give us some strategies to help eliminate them.
So all is well and good. We're done! Well... Lean doesn't address where to start eliminating waste. It turns out that where you start eliminating waste is an important factor. You can continue to eliminate waste for a long time until you get to "flow" and a "pull" system.

Theory of Constraints
The Theory of Constraints, created by Eliyahu Goldratt

Pages

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!