At the Lean Kanban Netherlands 2012 conference I gave a talk entitled Enhanced Risk Management in Kanban via the Theory of Constraints, proposing how one can combine Kanban with the Theory of Constraints. In this post I will describe how I do this.

If you are not familiar with the Theory of Constraints, you can read about the essential concepts in my earlier posts, which I published in preparation for the conference talk. You can find those posts here:

• Critical Chain Project Management in the Theory of Constraints
• Buffer Management and Risk Management in the Theory of Constraints
• Root Cause Analysis and People Factors in the Theory of Constraints

Similarly, if you have a background in the Theory of Constraints and need some notions about Kanban, you can read these two posts:

• Risk Management in Kanban
• Virtues of Minimum Marketable Releases

The Kanban Method was Influenced by the Theory of Constraint

The Kanban Method was deeply influenced by the Theory of Constraints, as David Anderson says [ANDERSON-2012]:

This is the fifth and last post in preparation for my presentation at the Lean Kanban Netherlands 2012 conference, about Enhanced Risk Management in Kanban via the Theory of Constraints.

You can read the earlier posts here:

• Critical Chain Project Management in the Theory of Constraints
• Buffer Management and Risk Management in the Theory of Constraints
• Root Cause Analysis and People Factors in the Theory of Constraints
• Risk Management in Kanban

The first three described how the Theory of Constraints deals with Schedule Management, Buffer Management, Risk Management, Root Cause Analysis and Continuous Improvement. The forth described how risk is handled in the Kanban Method. The purpose of these posts is to gain some foundational knowledge in order to combine Kanban with the Theory of Constraints.

Before we can see how we can combine the Kanban Method with the Theory of Constraint, there is one further aspect that needs attention. The use of Minimum Marketable Releases in Kanban; and that is the topic of this post.

This is the fourth post in preparation for my presentation at the Lean Kanban Netherlands 2012 conference, about Enhanced Risk Management in Kanban via the Theory of Constraints. In the earlier posts…

• Critical Chain Project Management in the Theory of Constraints
• Buffer Management and Risk Management in the Theory of Constraints
• Root Cause Analysis and People Factors in the Theory of Constraints

…we learned about the Theory of Constraints, and in particular how TOC deals with:

• Schedule Management
• Buffer Management
• Risk Management
• Root Cause Analysis
• People Factors
• Continuous Improvement

The purpose was to learn how we can use the Theory of Constraint to manage risks, and to improve our software engineering processes. We learned to react to emergency situations (special cause variation), or handle the most pressing recurring problems (common cause variation) by improving the underlying process, and eliminate the root causes. We came across a variety of tools for doing so.

(Also, a general introduction to the Theory of Constraints was given in the earlier post: Theory of Constraints in Software Engineering.)

In this post, we will focus on what has become a very popular approach as of lately: the Kanban Method (or just “Kanban” for short). Specifically we will look at how Kanban is equipped to deal with risk.

We will find that Kanban is already excellently equipped to handle risks, and thus ensure final delivery of software development projects. After learning in more detail about how Kanban handles risk management, in later posts we will look at how we can use what we have learned thus far from the Theory of Constraints to introduce significant innovations over a standard Kanban process.

The end result will give you both the flexibility of Kanban, and the systematic approach of the Theory of Constraints for managing risk and improving the underlying processes.

This is the third post in preparation for my presentation about Enhanced Risk Management in Kanban via the Theory of Constraints at the forthcoming Lean Kanban Netherlands 2012 conference, on October 25-26, 2012. The purpose of this series is to help understanding how the ideas of the Theory of Constraints can be applied in contemporary software processes, and in particular to the Kanban Method. This series will provide some foundational knowledge in the areas of:

• Schedule Management
• Buffer Management
• Risk Management
• Root Cause Analysis
• People Factors
• Continuous Improvement

Recap

The two earlier posts…

• Critical Chain Project Management in the Theory of Constraints
• Buffer Management and Risk Management in the Theory of Constraints

…presented Schedule Management, Buffer Management and Risk Management. In this post we will look more deeply into Root Cause Analysis and People Factors.

Earlier we’ve covered how Critical Chain Project Management places a Single Project Buffer at the end of the project activity network, and how the project buffer needs to be appropriately sized. We learned how to monitor the Buffer Consumption during project execution. We divided the project into three zones (green, yellow, and red), and we learned how to interpret the thresholds and signals with Buffer Fever Charts and Control Charts. We realized that even processes that are not under statistical control can be handled via Trend Analysis. We discovered that we can identify Common Cause Variation and Special Cause Variation by classifying Reason Codes for buffer penetration events, and then performing Frequency Analysis to examine the frequencies with which they occur. When a common cause is found, we have identified a potential Constraint in the Process (rather than a constraint in the project work flow), and we can take actions to promote a Process of Ongoing Improvement driven by the Five Focusing Steps, and focusing only on the most common or expensive problems (the constraints of our process).

To make our interventions as effective as possible, though, we need to find the root causes of such problems, and then propose and implement solutions that are accepted by all people involved. That is the topic of the present post.

This is the second post in a series in preparation for my presentation at the Lean Kanban Netherlands 2012 conference, about Enhanced Risk Management in Kanban via the Theory of Constraints, that I will deliver on October 26 in Utrecht. As described in the previous post, Critical Chain Project Management in the Theory of Constraints, the purpose of this series is propaedeutic to understanding how the ideas of the Theory of Constraints can be applied in contemporary software processes, and in particular to Kanban for Software. This series will provide some foundational knowledge in the areas of:

• Schedule Management
• Buffer Management
• Risk Management
• Root Cause Analysis
• People Factors
• Continuous Improvement

The previous post introduced Schedule Management; in this post we will learn more about Buffer Management and Risk Management.

Finding Herbie

The principal idea of the Theory of Constraints is the simple concept that there is always one constraint that limits the throughput of any system (the “weakest link of the chain”). It is not a surprise that all risk management practices revolve around finding and managing the constraint too.

“Herbie” was a character in “The Goal” [GOLDRATT-1992] — the business novel where the Theory of Constraints was first described. Herbie was a little boy, albeit overweight; and he was the cause of a line of young scouts moving slowly on a hike. Herbie’s rise to fame is that he represented the first constraint that the main character of the novel, Alex Rogo, managed to identify.

Since then, “Finding Herbie” is a colloquial way of saying: “Let’s find the constraint.”

Quite obviously, finding the constraint is very important in the TOC; but it is not always obvious how you can find your Herbie! Using a Kanban board can help identify constraints in your work flow, but it is of limited value in finding constraints in your overall process. We will discover how to do the latter.

On October 26, 2012, I will deliver a presentation at the Lean Kanban Netherlands 2012 conference, about Enhanced Risk Management in Kanban via the Theory of Constraints. The presentation will show how cross-pollination by two different schools of thought — Kanban and Theory of Constraint — can give rise to innovative ways to manage projects, to enhance risk management, and to continuously improve your software processes.

Kanban is relatively new on the software methodology scenario, but it has enjoyed rapid success, and most software practitioners have heard about it. The same is not true with regards to the Theory of Constraint, which is often disregarded, ignored or misunderstood by software practitioners.

In the recent post, Theory of Constraints and Software Engineering, I introduced the Theory of Constraints (TOC), and I described how Throughput Accounting (TA) can be used to make management and investment decisions about software projects. In this post I will continue exploring TOC, in order to describe some foundational knowledge that is necessary to understand my approach to combining Kanban and TOC.

This foundational knowledge is about how TOC deals with:

• Schedule Management
• Buffer Management
• Risk Management
• Root Cause Analysis
• People Factors
• Continuous Improvement

In this post I will cover schedule management. The other components will be covered in future posts. An overview of these components of TOC is illustrated in the following mind map, which will guide our exploration of these concepts. We will refer back to this illustration several times.

In this post we will introduce the Theory of Constraints (TOC) and start looking at how it can be applied to software engineering management. TOC is most well known for its so called “Five Focusing Steps”, and often that process is referred to when trying to identify and deal with bottlenecks in Kanban for Software. However TOC has many other tools one can resort to in order to improve software engineering management. In particular, we will examine how Throughput Accounting (TA) can be used to take important management decisions.

The field of software development is relatively young, but it has progressed very quickly. In just a few decades it has undergone maturing processes that have taken much longer in other fields. During the last decade Agile methodologies have gained wide spread acceptance, and are becoming mainstream. Transitioning to Agile is undertaken both by well established “traditional” software development organizations, as well as by more rudimentary “cowboy-style” development shops. In this post I examine the reasons why this transitioning is taking place, and what consequences come out of it.

In the earlier post Function Points Are Fantasy Points I showed how Function Points have a number of problems, especially when trying to estimate, or when trying to apply Function Point Analysis to a contemporary web project. Francisco Lopez Lira Hinojo correctly observed that we did not mention “how much was the effort and how long the project took to finish.” We will address Francisco’s observation in this post, and look at some further detail.

In the LinkedIn discussion Project Estimation using “Function Point Analysis” helps in Project Success or a Nightmare? which originally prompted us to write the previous post (Function Points Are Fantasy Points), we find Simon Harris comparing Function Points and Story Points, and offering this point of view:

Story Points are all ‘Function Points’ in philosophy if not detail.

When, we critique Function Points and happen to mention Story Points in the same context, it is frequent to receive the objection that Story Points are like Function Points. The similarity is only superficial. In this post we examine the differences.