Bas, and the world are not ready...

My good friend Bas Vodde just published a review of the panflet Scrumban.

I see that his review is yet another manifestation of what I titled "the world is not ready".

I don't think that his ideas are wrong, on the contrary, just that his ideas show that a lot of ground is still to be covered in software until we understand the nature of software and why certain techniques (like Scrumban) work, despite their counter-intuitive properties.

One example is when Bas states:

Another interesting thought that made me uncomfortable is the idea that there is such a thing as "in-control production" and special/common causes within that. To me, it feels like a manufacturing assumption within product development. Though Corey does cover these assumptions and makes great points about how to control variability, I'm not sure if it is a good thing to do.

Not believing that a team/organization can produce software at a regular pace in terms of number of stories is a common thing. The most common among people that believe strongly that you need to spend a lot of time in estimation of stories.

That is not my experience, I've been working in many projects (in many roles) and one thing that is common to all of the agile projects I've been is that the team's throughput (the number of stories they get DONE in a sprint) is very stable, "in control". This, to me, suggests that the throughput of a team can, indeed be "in control" (actually statistical process control (SPC) is the term).

I recently wrote a post where I detail how you can use the knowledge from SPC in order to help a team improve. The point I make in that post is that you can look at a team's velocity and based on it analyze whether the variation is a special cause (the velocity is all over the place) or if it is a common cause (the variation is predictable i.e. it goes down or up in a predictable fashion).

This distinction is very important. Special causes need to be eliminated one-by-one by instituting error-proofing, for example. Common causes are much harder to eliminate because as Wikipedia states:

Common-cause variation is characterised by:

• Phenomena constantly active within the system;
  
• Variation predictable probabilistically;
  
• Irregular variation within an historical experience base; and
  
• Lack of significance in individual high or low values.
  

In practice this means that a team where special causes are the reason for their velocity variation needs help in doing deep retrospectives with PDCA cycles tackle the root causes of their velocity variation.

However, a team who's velocity varies due to "common causes" will need support from management because they most likely need to change their process or the process of the neighboring teams in order to get any improvement to their throughput.

My experience is that teams of software developers can handle the special causes most of the time on their own, but need support and coaching to be able to overcome the common causes for their lack of constant improvement.

Not recognizing this lesson from manufacturing and applying it to software development is, in my opinion, lose sight of the goal: not falling in love with Agile, but falling in love with the improvement of our industry.