There has been a lot of talk recently about whether Kanban Systems for Software Development include the need to respect people, and allow self organisation and continuous improvement. It is true that the community has primarily focussed on the mechanics of Kanban Systems. I believe that this is because it is the mechanics that are the differentiating factors, and thus generally the most interesting to discuss. However, we should not forget the human factors, as they are inherently part of the Lean Thinking from which Kanban directly descends. This post is an attempt to try and redress the balance by showing how the five primary practices should enable the right behaviours.
A Kanban System should respect people by allowing them to take ownership of process decisions. Mapping the value stream sets up a team where everyone who is involved in creating value is recognised and respected equally for their role. Visualising the value stream enables a team to decide for themselves how best they want to manage the work. Setting work in progress limits gives the team a mechanism to manage their work/life balance effectively and avoid having more work pushed onto them than they have capacity to deliver. Establishing a cadence gives the team a way to create a rhythm which is natural and works well for them. Reducing the kanban tokens guides the team in creating their own process in order to allow the work flow. All these practices are about the people on the team having discussions and making decisions which work for them. They are not about the team having decisions made for them by managers.
By allowing the team to take ownership of all the process decisions described above, a Kanban System automatically empowers them to self organise and continuously improve all the elements of the process. The primary mechanism for enabling this self organisation and continuous improvement is making the work visible. The whole value stream is visualised so that the whole team can see where the problems are and where the improvements are needed. Limiting work in progress makes the bottlenecks or constraints even more visible, and will ultimately shut down the system so that the team has to self-organise fix the problems. The team’s cadence provides a regular rhythm to reflect on the whole system, alongside the spontaneous quality circles and kaizen events triggered by the visualisation and limits. Self organisation and continuous improvement are therefore crucial if the team are to successfully refine the process such that they can reduce the number of kanban tokens and allow the work to flow more freely.
A Kanban System is more than just a basic tool to be used to manage the work. It is a way of working which frees people to think for themselves in the pursuit of achieving success through improved productivity and quality.
I think that some of the representations of “self-organizing” here hold as long as we presuppose that managers are not teachers and competent and talented technologists.
I think we’re continuing to fail to recognize our inculcated beliefs about leadership on lean software teams. Maybe this is because we’re focused on process mechanics, but I think that it’s a fish-in-water issue; where the fish doesn’t know that it’s in water and that there are other ecosystem paradigms to potentially evolve to.
If ‘respect’ inevitably means ‘does not accept direction’ then we’re deeply screwed.
If we use the Chief Engineer model of leadership, then management is on the team, and self-organization inevitably includes management direction, and ‘respect’ inevitably goes back to being that two-way street that we so often try to blockade on agile teams with the ‘self-organization’ meme.
The differentiator is the quality of leadership and the quality of organizational and cultural mechanics in-place to create and support a learning culture.
Whether the Toyota literature applies to software development or not isn’t up to me to say, but I’ll take one snippet from Toyota’s story: Toyota leaders observed that western companies’ failures to duplicate its successes were tied to seeing lean as process improvement exercise, whereas Toyota sees lean as a means to create a learning organization where managers are teacher/practitioners and self-organization does not preclude the giving and receiving of either respect or direction.
Karl,
Great post.
I would suggest that a manager should exercise discipline in ensuring that current pace is sustainable. Having identified a bottleneck a short term improvement could be achieved by asking that person to work harder and longer.
I believe that kanban can expose valuable information. Since this could be misused it is important that the whole team and management agree in advance on basic values / principle such as sustainable pace and how bottlenecks will be dealt with.
Cheers
Dave.
Hi Karl,
What you state here is what most people would recognise as Agile values and principles.
Hi Scott,
Great point. Agile and the “TPS” share a common philosophy of learning and continuous improvement, but some of the principles and many of the practices are somewhat different.
Is either right or wrong? I think this is the wrong question, since each arised from a different context in response to different problems. The management culture at Toyota sounds very different to what we are use to in the West, and “Leadership” is an excellent term to describe their approach.
I’ve come across lots of companies where the concept of “leadership” isn’t well established in the corporate culture. In such a context “self-organisation” is a great approach, allowing true leaders to emerge from the team itself, with the mutual respect of their peers and the true ability to lead effectively.
So back to “Lean”. I think the whole branding of “Good thinking” as “Lean thinking” is a mistake. We should just think for ourselves and solve our own problems. Infact the whole “Lean” branding leaves me cold.
Back to a primary source like Taiichi Ohno. I’m sure that he would disapprove of the branding of “good thinking”. If you take a close look at the TPS, it was created by simply asking the question why?(five times) and through independent thought Ohno went against the mass production orthodoxy of his time and came up with an approach that worked in his context (ie Japan).
I think we need to do the same. Think for ourselves and solve our problems.
Paul.
[…] Does Kanban Respect People, Self Organisation and Continuous Improvement and Kanban Is My First Language (Karl Scotland) […]
@scott bellware
I believe you touch a very important point that we constantly miss in software (and I bet will continue to miss): Lean works bwcause it is a system, not a bag of tools.
This has vey deep implications, Kanban for example was a tool devised in Toyota to solve a specific set of problems, but was followed by other tools once the impact of Kanban was recognized. TPS is a system (not a tool or set of tools) that evolved over many years. In software we don’t seem to be patient enough to rip the benefits of Lean and are rushing into tools forgetting they cannot work alone.
If we accept that there are good development teams, and not-so-good development teams, no matter what tools they use or what name they give their process then I start to wonder what the “Kanban system” you describe here offers that Scrum does not already include.
In other words what’s the difference? I just don’t see any. And if there is none, why the need for new names at all? It would probably be more constructive to drop all names and just call this way of working “software development”. Simple.
Hi Scott,
Good points, and I must say I agree with everything you say. The teacher student relationship is key. It starts with the idea that you need good teachers and those teachers need to be respected.
Ideally the teachers should be the people in management positions. I don’t know why, but in my experience this is seldom the case. The motive for people going into management seems more to do with Ego and attaining a pay grade, then empowering and teaching others. Perhaps its not East versus West, but it is definitely cultural issue in a lot of organisations.
Ultimately what you describe as “Lean” is where we want to be. I suppose you’re right “Agile” in this regard is a watered down “tactical” alternative.
Given the reality of the organisational cultures I’ve had to work in though, Agile has proven a practical alternative, that provides space for true leaders to emerge. It is a bit hap hazard granted, but with some coaching and a team of people who have established mutual trust and respect then good leaders can emerge. Often this is in contrast to almost certain “poor leadership by management”.
Thanks for your reminding me. Just to back up what you say Mary Poppendieck has an excellent presentation on Leadership:
http://www.infoq.com/presentations/poppendieck-agile-leadership
If the Lean proponents in software at the moment focused more on this aspect and less on “process”, then I agree, “Lean” in Software would be serving its true objective.
Paul.
[…] With all due respect… However, we should not forget the human factors, as they are inherently part of the Lean Thinking fr… […]
[…] Does Kanban Respect People, Self Organisation and Continuous Improvement by Karl Scotland – “A Kanban System is more than just a basic tool to be used to manage the work. It is a way of working which frees people to think for themselves in the pursuit of achieving success through improved productivity and quality.” […]
I’ve given this some more thought, and I have had an epiphany
mostly based on this article by Alan Shalloway:
http://tinyurl.com/pysl4f
Having experienced Lean principles first hand I have always had a strong gut feeling that in many ways Agile and Lean are very different. Alan spells out the differences in beliefs very well in his article.
A difference that is related to the idea of “self organisation” is the concept of a “defined process”, which is more commonly referred to as “Standard Work” in Lean parlance.
Now Alan believes in a “defined process” for software and using PDCA as a process improvement technique. Having being trained and experienced in both over many years and experience them work in manufacturing and fail in software, I don’t. I mean that “defined processes” aren’t a universal good and are appropriate for a given context.
Self organisation in Agile also means having the freedom to change the process on the fly. In fact it goes further. It means spontaneous process creation, guided by values and principles, resulting in innovative and creative solutions to problems on the spot. Kind of like improvisation in the theatre. Lean does not allow for this, If it did, statistical process control would be impossible, because there would be no “defined” basis on which to base the maths.
Agile does. Is either wrong or right? Again it depends on context and the nature of the work. Is the work ndustrial or is it? Most work has both qualities but a dominant component. The types of software project I have worked on have been mostly artful (what Jim Highsmith would describe as high exploration). Some software projects (like maintenance and bug fixing) could be considered mostly industrial in nature (low exploration).
I could expand further, but this is long enough as it is. The main point is tat theory that can sound very rational may not work in practice depending on your context.
Paul.