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.
3 thoughts on “Bas, and the world are not ready…”
Maybe I misunderstood something and because of that I feel that you claim that new product development can be predictable. I my experience it is very rear occasions when I come across a team that delivers on constant pace.
When I think it more I actually have not ever seen a team that could do this. Maybe teams I have seen can not estimate constantly but I doubt it.
@Ran I guess you are missing one of the points I made in an earlier post https://www.blogger.com/comment.g?blogID=18900903&postID=5619664288592663481
Velocity is indeed “stable”, not exactly the same over time, but it will vary within a range. If it does not, then that means that something drastic has changed in the team/technology/environment and should be the object of a retrospective.
If you accept that velocity is stable within a range (I have data from 5 different sized teams that corroborates this) then you can start looking at the development process as a “real” process and apply to it some of the knowledge we have from process measurement/control. The real benefit is that this gives you a tool to know when management or the team can actually have an impact on velocity (special cause: team does a retrospective, common cause: team likely to need support from management as cause is elsewhere in the development system).
Comments are closed.