The Software Development Lifecycle is really a set of dependent events. Someone has to come up with an idea for a feature, Product Management has to write the requirement or User Story, Development has to analyze and code it, QA has to test it, etc. Each event or process depends on the previous one completing, in essence making each of them covariant on the next. If I want to explain how we can use Throughput Accounting and the Theory of Constraints to manage our software projects, we need to understand Dependent Events with Variance. Dr. Eliyahu M. Goldratt describes the "match game" in his book titled The Goal which illustrates this very well. The game is played as follows:

1. 6 buckets are laid out on a table.
2. A person mans each bucket in which matches are placed. The matches and buckets are to represent some type of production process. Think SDLC in this case.
3. Each person is given matches from the person to his right and places them in his bucket.
4. The flow of matches is controlled by the roll of a die.
5. The right-most person rolls the die and gives that amount of matches to the person on his left who in turn places them in his bucket.
6. The die is handed left and rolled. That person takes the amount of matches less than or equal to the roll and hands them left. The amount is constrained by the amount of matches in the bucket.
7. Goto #5.

We can measure three things in this game very easily.

1. The amount of matches consumed by the right-most person. (Raw materials)
2. The amount of matches in the system. (Inventory)
3. The amount of matches passed out of the system by the left-most person. (Throughput)

To illustrate this, I wrote a simple SilverLight application that demonstrates the game. Pay close attention to what happens to Inventory.

I will talk about Constraints, optimizations, etc. in future articles.

Brought forth by Dr. Eliyahu M. Goldratt in his 1984 book titled The Goal: A Process of Ongoing Improvement, the Theory of Constraints is an idea and process that seeks to optimize a system by identifying and eliminating its bottlenecks.  The process is comprised of five, fairly straightforward, steps:

1. Indentify the constraint.  This means you will need to be able to measure a systems performance in order to identify its constraints.  I will talk more about that in later articles but for those of you who can’t wait, take a look at David Anderson’s book Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Coad Series)
2. Exploit the constraint.  This means that you should do everything within your power to make sure that the constraint (equipment, people, policy) is never idle.  Again, I will talk more about this item in future articles.
3. Subordinate all other processes to the constraint.  In Lean and Six Sigma this is known as “balancing” and is simply the act of keeping other phases in a process in-line with the constraint. This step introduces the concept of Drum-Buffer-Rope (DBR) as a mental model that can be used to explain subordination.  The Drum is the physical constraint (rate) of the team, the Buffer protects the Drum so it always has work flowing to it and the Rope is the flow of inventory into final product by way of the implemented process.  David Anderson has a good explanation here.
4. Elevate the constraint.  This is the improvement step.  Consider ways to improve the throughput such as removing inefficient or time-wasting process, hiring more people, buying more equipment or tools.  In my opinion this is where the meat of TOC is and I will spend significant time on this topic in future articles.
5. If the steps taken in #4 have caused the constraint to move, go to #1.

In future articles I will discuss how TOC can be used to improve the efficiency of your Agile teams primarily during the Planning, Executing and Monitoring phases of your Agile project.