Inspired by Michael Dubakov's article Flow. Discover Problems and Waste in Kanban, I thought I’d spend some time looking at Value Stream Analysis.

We talk a lot these days about delivering value to our clients, but many of us don’t understand the details of how that is accomplished.  Sure we understand that raw ones and zeros couldn’t be sold for the same amount as the aggregated application, but let’s take a more concise look at a couple questions?  1) How do we define value.  and 2) How do we analyze the process by which we deliver value? (Value Stream)

The first question we seek to better understand is the definition of value.  Without diving head first into an economics discussion, we can simply look at value as our client’s perceived worth of the product or service we provide.  This has a dollar figure attached to it.  While one can argue that value is also inclusive of the qualitative aspects of our product or service, it is not easily measured, so for purposes of this discussion can be ignored.  I defined a method of assigning a dollar value to SaaS features in one of my previous posts.  This method can also be used to determine the dollar value of a release, iteration, feature or task on either products or services.  With a dollar value in hand we can begin to look at answering question #2.

As we begin to examine our Value Stream, I would be remiss without mentioning the work of all the people that have contributed work in this area, Eliyahu M. Goldratt, Taiichi Ohno, James Womak, Kent Beck, Mary Poppendieck and Tom Poppendieck, to name just a few.  In Tom and Mary’s book Lean Software Development, they present Tool #2 - Value Stream Mapping which gives us a good way to visually represent our Value Stream:

If we look at the figure above, we see the typical steps that an Agile team may follow transforming an idea into reality.  There is active work that is done on the idea/feature (above the line, value add) and time when the idea/feature sits dormant. (below the line, waste)  Examining the timing of the above hypothetical flow, we can see that the overall process took 18 weeks with 11 weeks (61%) delivering value and 7 weeks (39%) of waste.  This example is a bit far fetched but is meant to provide a simple means of showing how the map works.  You may find it more useful to use days as a unit-of measure or even hours.  The point here being that you may be able to reduce your feature time to market to only 11 weeks if you could only avoid wait time.  If we assume that the feature we are developing will provide $5000 of value in the market, (to our clients) then at 18 weeks we are only delivering $278 of value a week, whereas we hit $455 a week when we do it in 11 weeks.

This can be a very useful tool for improving the productivity of your development organization but we need one more piece to make it effective.  Since we are not developing one feature at a time we need to understand the effects of multiple features flowing through our value stream.  If we only seek to optimize the flow of one feature’s flow we may do that at the expense of others.  We must look at the system as a whole and try to optimize elements that will reduce our wait time for all ideas/features currently in progress.  This is not an easy task.  You should look at the steps that are costly first and try to identify the pain points in those steps.  For instance, if there are days lost because team members are unaware of a status change, seek to implement a tool that sends automated emails on status change.

In summary, here are the steps to analyze your value stream:

1. Create a map of the steps that an idea takes from concept to delivery.
2. Measure the value-add and wait time of a number of ideas as they flow through this map.
3. Assign a dollar value to your ideas and measure your current weekly value and share this with the team.
4. If changes were already made to try to increase the flow of value, did they work? By how much?
5. As a team, come up with changes that will increase the flow of ALL ideas through the system.
6. Implement these new changes and go back to #2.

A great interview with Dr. Goldratt. Many of his comments remind me of the MIT Sloan beer distribution game. What I continue to get from reading Dr. Goldratt is that people solve problems, not processes. While the Theory of Constraints, Six Sigma, Lean, are all good tools, they are implemented by people. Just think about how Bill Smith started using Six Sigma at Motorola or how Taiichi Ohno brought the Toyota Production System together. These were people using the scientific method to solve problems and ultimately improve their companies.

Before I talk about schedule development, I want to touch on estimates a bit more since I've received some questions on this. For those of you that are new to Agile estimation, I strongly suggest reading Mike Cohn's book Agile Estimating and Planning. It covers many of techniques I discuss in this series.

The primary question I received was "How can you be sure your estimates are right?" The first thing we need is an Expert Opinion. According to Cohn, If you want to know how long something will take, ask an expert. In the PMBOK, this is called Expert Judgment. (6.4.2.1 in the Third Edition) While this is a good start, I've found that some experts (read developers) are talented estimators while others are horrible, most are somewhere in between. Due to this fact, we need a few tools to help assess our expert's ability to estimate.

The first tool we need some historical data, in lieu of historical data estimating becomes an educated guess. If you don't have historical data, start collecting it today. For reference, you will need to collect the initial estimate and the actual time taken to complete. Once you have some historical data you can produce the deviations I discussed in my previous article and the histograms shown below.

The second tool we can use is an estimate histogram. For features (vs. bugs) you can compile histograms for each expert on tasks they have estimated to be 1,2,4,8,12 and 16 hour efforts. Remember that any task over 16 hours should be broken down into smaller chunks. What you are looking for is each expert's ability to accurately estimate.

Figure 1 – 4 Hour Estimation Histogram

As we can see from Figure 1, Joe (our hypothetical expert) tends to overestimate the amount of time it takes to complete a 4 hour task. While 32 of Joe's tasks that he estimated to be 4 hours in duration actually took 4 hours, 72 of them only took 2.5 hours. In this case, we can leave the estimate as-is since the median of 2.5 is only 1.5 hours off of our expert's estimate. This is in-effect gives us a 1.5 hour buffer which, as you will see, is what we want. If we produce histograms for all other effort sizes we may find that Joe tends to underestimate larger efforts, this would look something like Figure 2.

Figure 2 - 16 Hour Estimation Histogram

Knowing that Joe has a tendency to underestimate larger tasks, it may be in our best interest to try to get Joe to break larger tasks down further. Alternatively, as Mike Cohn suggests, we can provide feature buffers to reduce the risk of poor estimates. Both these methods are valid and have a basis in the Theory of Constraints. We are assuming that Joe's issue with underestimating longer tasks is going to create a constraint during the iteration. My experience has shown me that this is typically true and the use of buffers can help protect the constraint. This is also referred to as Critical Chain Buffers on which there is ample work available online.

To calculate buffer times, you can use the simple "just add 25%" method which may work. In the case shown in Figure 2, adding 25% to a 16 hour estimate would only give us 20 hours, still under the 32 hours seen the most. However, there is only about a 40% chance that Joe will finish a 16 hour task in 32 hours. This is because 60% of the area of the 16 hour histogram occurs from 4-31 hours. A better approach to calculate a buffer is to use two standard deviations which, in this case is about 12 hours. This would give us a buffered task time of about 28 hours. Mike Cohn discusses this in more detail in Chapter 17 of Agile Estimating and Planning. Eliyahu M. Goldratt suggests in his book, Critical Chain, to simply use the median value for a given task, which in this case is about 30 hours, so we can use a buffer of 14 hours.

Whatever method you find works for you, create the buffer as a separate task that is dependent on the primary task. You will want to be able to continue to track estimates independently of the buffer. The goal of this process would be to center the curve over the estimated time.

Now on to Schedule Development...

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.