Register now and get the early bird special price of $300.

We have a fantastic program lined up and a uniquely collaborative
conference format.

Key note speeches from

Lisa Haneberg,
author of several books including "High Impact Middle Management",
"Focus Like a Laser Beam" and "Two Weeks to a Breakthrough",

and John Yuzdepski,
Chief Marketing Officer at TestQuest, former VP & GM at Openwave and
prior to that VP & GM of Sprintpcs.com

a CIO panel - featuring leaders from firms around Seattle,
participants to be confirmed

Think Tank / Open Space Sessions led by recognized leaders in the
agile field, including...

Luke Hohmann, Collaboration Games
David Anderson & Corey Ladas, Kanban
Brent Barton & Lance Young (of Solutions IQ), Scrum
Mitch Lacey & Julie Chickering, Getting Started with Agile
Bruce Eckfeldt & Jim Benson, Writing Agile Contracts
Mike Griffiths, Agile Program Management
Chris Matts & Olav Maassen, Real Option Theory
Arlen Bankston & Jeff Patton, Agile User Experience

On Day 1 each Think Tank facilitator will lead an open space group to
develop new material, thinking and ideas. Participants are free to
choose a single session or wonder freely from session to session
learning and contributing to each.

On Day 2 each session facilitator will present a 20-30 summary of the
findings from the previous day. The output from all 8 sessions will be
made available to participants.

Please come and join us. Enjoy the beautiful venue. Enjoy the Seattle
summer weather. Enjoy mixing and networking with leaders in the agile
and board members of the APLN.

It's a mini-Agile Conference in the Northwest.

Enjoy the great food at the luxury Edgewater Hotel. Join us for the
cocktail reception in the evening of the 17th. Technorati tag: Agile, APLN, Lean, Seattle, Edgewater+Hotel, Luke+Hohmann, Jeff+Patton, David=Anderson, Lisa+Haneberg

If you'd like to meet me in person and ask me anything about Agile Management, Kanban, MSF CMMI, FDD, or what we're doing with Modus Co-operandi, then come listen to me present on Kanban at the JW Marriott in downtown San Fran on Monday. Sign up now using code 'd400' to get a $400 discount. Technorati tag: David+Anderson, Software+Engineering, Kanban, Lean

Later in a lecture I remember watching Eli tell a story of how he'd scolded a client (or maybe it was a consultant) for confusing a non-instant availability resource with a capacity constrained resource. He argued that non-instant availability resources are not constraints because they are not capacity constrained. The non-instant availability is the side-effect of a policy that controls the process. However, I believe that we can still call these bottlenecks.

Hence, I now teach that there are two types of bottleneck: capacity constrained resources CCRs; and non-instant availability resources [we need a good acronym (TLA) for these ;-) ???]

Only CCRs should be treated with the Five Focusing Steps: identify the constraint; decide how to exploit the constraint; subordinate all else in the system to the decision in 2; elevate the constraint (i.e. add capacity); do not inertia prevent you repeating by identifying the next constraint and starting again at 2.

Non-instant availability resources exhibit bottleneck behavior but we don't try to exploit them as first step to improving the throughput. The reason there is a lack of throughput is lack of availability. We must identify the policies, transaction costs, coordination costs or other physical constraints that cause the non-instant availability.

For example, an ambulance is a non-instant availability resource because it must be dispatched from a central base like a hospital and it must travel to the location. We can improve availability (response time) by locating ambulances closer to where they might be needed. To illustrate this, imagine a seaside town that is a popular retirement destination such as Largs in Scotland (a town where I lived 20 years ago.) Largs with a population of 11,000 is too small to support a hospital let alone an accident and emergency (ER) department. The closest one was around 20 miles distant. To improve response time for ambulances, the ambulance service stationed vehicles in Largs even though there was no depot or hospital. This is an example of improving availability on a resource that impedes flow of value in the system.

The dispatching of the ambulance and its travel time must be seen (economically) as a transaction cost on the delivery of value. In Lean terms all transaction costs are waste. So non-instant availability is waste. Hence, improving availability is a way to reduce waste. It also improves flow and alleviates a bottleneck.

So how can we describe this generically in order to abstract a set or rules or principles for dealing with non-instant availability bottlenecks in process flow?

Figure 1. Doug Burris, build engineer and a kanban board showing the "Build Ready" state

At Corbis, we discovered that our build engineers such as Doug Burris pictured in Figure 1 were a non-instant availability resource.

We had in place a policy which stated that only build engineers could build code and push it from our development code-line in to our test environment. This policy existed in order to maintain the integrity of our test environment. Developers, through prior bad behavior, were not trusted to keep the test environment in working order and the negative effect that this had on the team was sufficient that the policy that only build engineers can touch the test environment had been introduced.

Further, we had a policy that our build engineers were generalists within their own field of configuration management. They each had to work three different types of problem: build code for test; maintain pre-production environments, applying software patches and configurations; and build out new environments. Each of these types of work required different amounts of time and effort: builds approximately 15 minutes to 2 hours; maintenance up to 2 days; and environment builds up to 2 months. In order to cope with the different time scales across the three different types of work, the team members multi-tasked by (effectively) time-slicing their effort across the three types. Hence, build was a non-instant availability resource, as the build could only be undertaken when the build engineer was in "build" mode and not in "maintenance" mode or "environment build" mode.

What is important about all of this is to understand that all of this is controlled by policies, and that management has it within its power to change those policies.

So for example, do we want to have instant availability build engineering? do we really need the policy that developers are considered untrustworthy and are not permitted to build code on their own?

In the end, we settled for a multi-faceted approach to attack this problem: invest in automation - a long term strategy; increase the time slice for build from some of the engineers; relax the no developer can build policy under some circumstances.

I'm still distilling out the abstract set of rules for improving throughput through non-instant availability bottlenecks. I'll publish more as develop it.

For now, it is enough to question: is this bottleneck truly a CCR? or is it a non-instant availability problem? If it is a CCR apply the Five Focusing Steps. If its a non-instant availability problem, examine the policies, transaction costs, coordination costs or physical obstacles that cause it to be non-instant availability and consider what you can change to improve availability. Technorati tag: David+Anderson, Software+Engineering, Kanban, Lean

Figure 1. Cumulative Flow Diagram showing "design" step as a bottleneck

However, in a kanban system the WIP is limited and the CFD (Figure 2) does not typically exhibit a bulge like the one in figure 1.

Figure 2. Kanban system CFD with no noticable bottleneck indicator

So how do you detect bottlenecks in a kanban system?

Bottlenecks are not indicated by inventory build up. They are indicated by ragged flow of WIP through states in the process. When things are not moving smoothly a bottleneck is indicated. There are two ways to see this. One is dynamic, by looking at the kanban board every day at the standup meeting and observing that things are not moving. The second is to observe vacant space on the kanban board - WIP dropping to zero at a given state or set of states in the process, as seen in Figure 3.

Figure 3. Kanban board showing a section of zero inventory indicating a bottleneck in front of this area

As work continues to be pulled through to the end of the board - the software release - a bottleneck will be indicated by an opening gap in WIP. Things cannot be pulled through the system despite downstream capacity because of the bottleneck.

Hence, in a kanban system the CFD behavior is inverted. A band of zero inventory on a CFD would indicate a bottleneck directly before it. (Unfortunately, I don't have a good report graphic to demonstrate this. I'll need to make one.) Technorati tag: David+Anderson, Software+Engineering, Kanban, Lean

It occurred to me that many newer reader may not be aware of my earlier video interviews. The first interview is with Robert Scoble in my office in Building 25 and we mostly talk about FDD, Theory of Constraints and MSF for CMMI Process Improvement. The second interview was done on my last week with Microsoft at my new office in Building 5 when I'd moved in to the Patterns and Practices group. In the second interview, I talk about the future of the MSF process and the TFS process framework under Alan Wills leadership, metrics and objective management in MSF, as well as my new approach to agile change transition and the kaizen culture that I intended to (and later did) create at Corbis.

Channel 9
David Anderson - Writing Agile Software
David Anderson - Thoughts on Visual Studio Team System Technorati tag: Agile, David+Anderson, Microsoft, VSTS, MSF, Channel9

Pete is right!

In fact, in the realization of the Recipe for Success, I advise people that they mature down through the list. First focus on quality which is primarily a waste elimination function. Then reduce (or limit) WIP which is both a waste reducing function (as quality improves with smaller batch sizes) and a flow function (as flow improves with smaller batch transfers). Then balance demand against throughput which is primarily a flow function. And finally, when quality is high and flow is smooth, focus on prioritization. It is prioritization that is value focused in the Recipe for Success.

And hence, it appears that while, from a decision standpoint, you read the Recipe for Success from bottom to top, from an implementation standpoint, you read it (and implement it) from top to bottom. The reasons for this are relatively easy to understand and self-evident in practice.

When there isn't a reliable system producing working software, prioritization is problematic because delivery is unreliable - either from a timing or quality perspective. With bad timing or poor quality the true value delivered is different from the intended value. In a true pull system, prioritization is deferred until the last responsible moment, keeping real options open, and allowing the most accurate definition of true value to be determined. With a reliable system of delivery, accurate prioritization decision can be made. Without a reliable system, either due to timing or quality, prioritization decisions will suffer.

One of the biggest impediments to smooth flow, is the stop go effect from rework due to poor quality. A second related problem comes from batch transfers from poor quality - in software, issues with builds and systems integration when batches of code are promoted through a set of environments. Poor quality impedes flow and prevents it from smoothing out. Hence, it makes sense to focus on quality first, before attempting to smooth the flow in the system. The working reality is that both measures start to take effect together, however, management attention and focus should go quality issues first. Not because quality is waste and it should be eliminated but because quality impedes flow.

Hence, organizations mature in to value optimization. It doesn't happen overnight!

Related articles: Recipe for Success, Providing Value with Lean Technorati tag: Agile, David+Anderson, Software+Engineering, Management, Lean, Kanban, Pete+Abilla

I'm very pleased with both of these papers. The co-authoring experience in both cases was very enjoyable and rewarding. The outcomes were superior to anything I might have written on my own.

There are many lessons in the Lean paper, but perhaps the most important is this message...

Value first, then flow, then waste reduction/elimination

Too often I see Lean being taught as "the elimination of waste" when in fact waste reduction is a tertiary concern. While waste elimination is important, waste should not be reduced in detriment to flow, and smooth flow can be sacrificed to improve value delivery.

So for example, a queue in a kanban system can be considered as waste (probably necessary waste). As queues are a type of waste, it makes sense to reduce or eliminate queues. I see this advice coming from others who talk about Lean in software development.

However, it is important to understand why the queue is there. It is there to absorb variation in size and complexity of work items or in the availability of someone to process those work items. If you reduce the size of the queue or eliminate it altogether, it may impeded the smooth flow of the system, causing a stop-go effect, lowering the overall throughput of the process.

For example, (and I talk about this when I present kanban at conferences) at Corbis we had a non-instant availability bottleneck in build engineering, due to the time-slicing (multi-tasking) required of the build engineers. As a result, we increased the size of the queue in front of build engineering in order to smooth the flow through the whole system. In this example, the variability comes from the availability (or lack thereof) of the resource, not from the sizing of the work items. So we increased the amount of "waste" in the system to smooth flow and increase throughput.

It is also known that expediting is bad. Expediting impedes flow and causes WIP to increase and lead times to lengthen. We have demonstrated this empirically with the kanban implementations we've done so far. If we are to focus on smooth flow we would never expedite.

However, this general rule would be wrong. Occasionally there will be times where an expedite request carries a very high monetary value. The impact on flow and WIP and lead times to other items in progress is outweighed by the monetary benefit of accepting the expedite request. Hence, it makes sense to pursue the value in the expedite request despite its impact on flow and its introduction of waste in the system.

Hence, value trumps flow and flow trumps waste elimination in all process operation and process improvement decisions. Technorati tag: Agile, David+Anderson, Software+Engineering, Management, Lean, Kanban, David+Raffo, Merwan+Mehta