Theory of Constraints applied to Agile Delivery

We have all heard of how agile is supposed to help us improve software delivery, making it faster, cheaper, better, blah blah blah.  But does it always?  What do we need to know to actually get the benefits we seek?

Part of the reason that agile software delivery methods are an improvement over the phase gated (waterfall) life cycle can be explained by the theory of constraints.  Students of management practices and process optimization are probably already familiar with the concept, but many software delivery practitioners and project managers are not.  The theory speaks in terms of three measures: throughput, operational expense, and inventory.  In a manufacturing environment these things are fairly obvious but in software delivery, they have analogs that we have to work through:

• Throughput in manufacturing is the rate at which the system generates money through sales.  In software delivery, it is the rate that valuable features are made available to be adopted.
• Operational Expense in manufacturing is the money that is spent turning inventory in to throughput.  In software delivery that equates to the cost of the team(s) that deliver the software features.
• Inventory in manufacturing is the money invested in things that are intended to sell (raw materials, and unfinished work in process). In software delivery that equates to money spent on developing requirements, and on software features that are incomplete, or not ready to be adopted.

So if you are at all familiar with with agile and phase gated delivery life cycles, it seems clear that agile methods should have a much smaller inventory level than a phase gated approach.  This is because agile has a much shorter cycle time for getting one feature ready to be adopted.  However, even agile teams may have lots of inventory (a long, over-elaborated backlog) that represents a substantial investment that isn’t being converted to throughput. One can also say that agile, because less time is invested in Big Design Up Front (BDUF) the inventory is smaller, because the cost of that design is broken down and divided into each feature that needs to be designed.  So the operational expense is increased, but the inventory is decreased.  Initially, many agile teams also impose a “tax” that increases operational expense in the form of test automation.  However, over time this tax allows the testing component of operational expense to remain “flat” whereas in projects that don’t implement test automation, the testing component of operational expense grows in proportion to the complexity of the code base.

In agile teams, think of the designers, coders and testers as the “delivery team” and the product owner and business analysts or story authors as the “inventory team”. Also think of the activities your delivery team does as being stations on an assembly line.  If the stations are Design, Development, and Testing, then understand that Design creates inventory in front of Development, and Development creates inventory in front of Testing. So you want the inter-station inventory to be as small as possible at all times.  If your team designs as a team, and develops in pairs, and tests as individuals, then the design activity has to produce enough inventory to keep all the pairs busy until the next design session.  If design is done by an “architect”, then she will have to “transfer” that inventory to each pair at a cost of time for all three resources.  Perhaps there is a code review station before testing, sometimes pairs don’t need it, but individuals do.  How you organize the interactions between team members “as” stations on your assembly line are important to your cycle time, and your inventory.

So from this basic introduction to TOC as it applies to agile software delivery, what can we take away?  How can we apply this to make/keep agile teams running even smoother? Most of these are directed at the product owner and the technical manager. Here is my list:

1. Any investment in tooling that reduces operational expense over time will increase your throughput.  (technical managers)
   1. This includes build automation, test automation, CI/CD/DevOps, developer tools, advanced frameworks (like spring or grails), or even additional test environments.
2. Keep your backlog, or road map fairly high level, with just enough information (elaborated content) to allow good sequencing decisions, to keep inventory costs reasonable. (product owners)
3. Make sure you have a “cycle” or two of “fully elaborated” features or stories ready for the delivery team work on. (product owners)
   1. If your inventory runs low, you will idle the delivery team and spend money but get no adoptable features.
4. Try to keep “constant” funding for the team.  Disruptions in funding equate to massive inventory. (business sponsors)
5. Try to balance the pace of inventory creation, with the pace of delivery. (product owners and technical managers)
   1. You pay for the inventory even when they aren’t busy, or they create massive inventory if the delivery team can’t keep pace.
   2. You pay for the delivery team even while the inventory team is playing catch up on elaboration.
6. Make sure that you account for turnover in both the inventory team and the delivery team.  You can estimate a six week resource cost for every addition or replacement. (product owners and technical managers)
7. You may need to adjust the relative size of the inventory and delivery teams to keep throughput high. (business sponsors, product owners and technical managers)
   1. This is much harder for small teams.
   2. It may also mean that you get done faster than you originally planned, or spend at a slightly lower rate.

If this is interesting to you, learn more about Theory of Constraints by reading “The Goal” or “Critical Chain” by Eliyahu Goldratt.  Both books are written as novels, and are actually fun to read, rather than some dry theoretical treatise or boring business book.