Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Q&A on Kanban Change Leadership

Q&A on Kanban Change Leadership

In the book Kanban Change Leadership Klaus Leopold and Sigi Kaltenecker explore how kanban can be deployed to get change done in organizations and to build a culture of continuous improvement.

InfoQ readers receive a discount of 25% if they order Kanban Change Leadership on Wiley using the discount code VBJ24. This code is valid in 2015 only.

InfoQ interviewed Leopold and Kaltenecker about doing change in small steps, solving problems, advantages from using WIP limits, priorities and classes of service in kanban, using the Theory of Constraints with kanban, and getting results from using a kanban change approach.

InfoQ: Why did you write this book and for which audience?

Kaltenecker: We wanted to provide a holistic approach by combining technical knowledge about kanban (practices and tools) with psychological insights on change dynamics (principles of evolutionary change management) and a systemic concept of leadership. At the same time, we tried to make it as much of a cookbook as possible. That's why we offer a lot of tools accompanied with case studies to illustrate how their implementation can look like in your daily business.

Hence, our target audience are kanban beginners as well as practitioners who look for further improvement. Besides, the book offers some fresh impulses for those who are busy with organizational change in general.

InfoQ: Kanban suggests to do change in small steps and focus to make these change steps successful. Can you explain why?

Leopold: I think the size of change steps is totally subjective to the situation of organizations. Only the first practice of Kanban “visualize work” could be a huge step for one organization and for another organization it’s like almost nothing. Not to talk about limiting work in progress, flow and feedback loops. And I think that’s exactly the point when it comes to change: not all organizations are alike. Kanban respects the current state of an organization and you can decide on your own, how big your change steps should be. That’s the art of change - find the right dose. I myself prefer not to overstrain organizations by introducing too much change and I think Sigi has a similar take on this.

Kaltenecker: Basically, doing small steps rather than big ones is less stressful and has more potential for success — which is a good trade-off. It's an experimental approach of trying out small things in order to learn as quick as possible. If real data show that our experiment pays off we do more of the same. If not, we try something new. A welcome side-effect of this lean approach is the opportunity to integrate new information which is arriving constantly. We definitely don't want to build our change efforts on big design upfront and plan-driven implementation anymore as we did for quite a long time.

InfoQ: How can you assure that these small steps will get you where you want to be in the future?

Kaltenecker: By relying on a system of fast feedback loops. Certainly, continuous improvement depends on regular inspect and adapt cycles based on real data and open conversations. Who knows what our current situation will look like in two or three months time? Moreover, living in a turbulent world, how can we be sure what our future state will look like? Better to head for shorter change circles with smaller steps and finish them before we start new ones.

InfoQ: In the book you suggested to "work on your problems first before going on to new work". Which sounds logical, but I have seen that people can find it difficult to do. Do you see the same?

Kaltenecker: Yes. I see a lot of pressure these days to accomplish certain stuff - often at all costs without even recognizing how much time, money and motivation we waste by favoring workarounds and symptom cures over countermeasures based on a proper root cause analysis. For sure, we talk about cultural issues too, because the DNA of many organizations is still pretty much driven by the push-principles.

Leopold: Agreed. It's a hard thing to establish. However, I have some good experience to quantify the impact of these problems. If people see the economic impact of problems you're often getting attention. There's a powerful technique to do so: Blocker clustering. Troy Magennis and I wrote an InfoQ article on this: Using Blocker Clustering, Defect Clustering, and Prioritization for Process Improvement.

InfoQ: Do you have any suggestions on how to make it a habit to solve problems?

Kaltenecker: In my experience, regular training is the only way to achieve this. As sportsmen would do: in order to become great athletes they practice the same habits over and over again. and they do this under the observation of an experienced coach who provides accurate feedback in terms of data as well as improvement ideas. With the help of this feedback the athlete finally builds the right routines. I think we should do the same in knowledge work — as I advocate with the slogan of “leadership as a team sport” in my new book on Leading Self-Organising Teams.

Leopold: Let me quote Sigi: “The difference between sports men and managers is that sports man practice a lot for only a few competitions and mangers are always in competition and never practice."

InfoQ: Can you elaborate on the advantages that teams can get from using WIP limits?

Leopold: Oh wow, that's a big one. Let's make a short economic consideration: If you have 10 projects that are all finished by 10% you didn't generate any value for your customer. If there's one project 100% finished, you generated value. I think the slogan "stop starting, start finishing" is a good summarization. Sigi, you're good in quick summaries.

Kaltenecker: Why WIP-limits? Here is my list of best of in 10 seconds: less stress by limiting task switching, better focus on things to be done, faster work accomplishment, better work flow and collaboration, better product and/or service quality and more work satisfaction. Not too bad, I think, what you can get out of some queuing discipline.

Leopold: And there're two more important fact about limiting WIP: (1) limit work items that generate value for your customers and (2) always try to limit the bigger items. Ad 1: Kanban is not a task board with WIP limits. You want to chase value through your systems and not tasks. Ad 2: What's the point in limiting epics if there are unlimited projects in your system? What's the point in limiting user stories if there are unlimited epics in your system? And so on... Limit the bigger one! I know it's more difficult but it also makes a lot more sense.

InfoQ: Can you elaborate on the differences between priorities and classes of service?

Leopold: As described in the book, the idea of classes of service is to make a statement about the urgency and impact of work items. The idea is that stakeholders of the Kanban system find a common understanding about the business impact and when the impact kicks-in. Having this common understanding it’s much easier to decide on which work items to work on. That's one of the topics that's only covered in a very brief overview in this book as the focus is more on the "getting things started" aspect. However, the good news is that I'm currently working on my next book where I devote much more attention to the risk aspects of working systems.

InfoQ: Do you have an example of using the Theory of Constraints with kanban?

Leopold: I like to use TOC as a thinking model. I think it’s a great “tool” to understand bottlenecks and to get the message across that full utilization might not be the wisest way for managing knowledge work. Each and every system does have a bottleneck and it does not make any sense to start more work than the bottleneck can actually process. We probably made our first contact with a bottleneck as a six year old, when we tried to pour sand into a funnel. “Ohhhhhh… It’s spilling over,” was probably the amazed reaction. Yes, it is spilling over! As we all know, the throughput of a system is determined by its bottleneck. That’s true everywhere on this planet - we only doubt about it when it comes to our working systems. It’s also true for working systems! It’s no use to...

  • analyze more stuff than you can develop;
  • develop more stuff than you can test;
  • test more stuff than you can deliver;
  • etc.

I find TOC useful to get these messages across. So, it’s not about applying TOC to knowledge work - it’s more about understanding the underlying principles. In knowledge work we e.g. have to deal with moving bottlenecks or bottlenecks because of specialization. I’m not sure if TOC is the best tool to get rid of bottlenecks in these situations. However, it still helps to understand the underlying principles because a bottleneck is a bottleneck, no matter whether it’s constant or moving, no matter whether it’s caused by capacity constraints, non instant availability, or specialization. The actions of how to deal with bottlenecks may vary.

InfoQ: In the book you explain that when starting a kanban initiative a deeper understanding of the current problems is needed and you have to design the kanban system for your organization. You also mentioned that kanban is about evolutionary improvement in small valuable steps. How do you balance this, and assure that you start getting results with kanban soon enough for people to stay involved in the initiative?

Kaltenecker: Once you understand that introducing kanban means starting a change initiative rather than some technical adaption, you can use all the good practices and patterns that are available in the 21st century. For instance, building a change team as kind of a guiding coalition, discovering what your stakeholder map would look like, engaging with the most important stakeholders, running some short retrospective interviews with them and providing feedback on what you learned about it. As our experience with various customers shows, this can be done in a couple of weeks You don't need months for preparation — all the input you need for a tailor-made system can be gained quite quickly.,

Best thing, however, you create value step by step since every single conversation is a means to improve your stakeholder relationships. You can build more trust, share knowledge, ensure a better understanding and the like. Besides, the value of transparency guarantees that everybody involved is pretty much aware of what is going on.

InfoQ: Let's suppose that an organization wants to become able to deliver software solutions faster. Can you give some examples showing how kanban can help them?

Leopold: I think there’s no general answer to this question as Kanban is not a revolutionary approach with a nice poster which tells you how to do it right. The Kanban approach is to make the current situation explicit and to encourage you to think on your own with lean guidance. Kanban is the cure and not the medicine.

However, there is of course a pattern that one can observe when it comes to delivering software solutions faster. One of the first topics on the table is making waiting times visible. What one will see is that the majority of lead time of a work item (e.g. feature, user story, etc.) is waiting time. This means most of the time, nobody is working on work items but they are lying around in your systems waiting for better times. So when it comes to deliver software faster it’s usually not about working faster - that’s only a very small lever. It’s about killing waiting time of work items!

If we assume that we started our Kanban journey somewhere in the software development departments in a company, it’s very likely that the next step is to scale to the upstream as usually there’s again a lot of waiting time involved and thus, a huge potential to deliver software solutions faster. Regarding scaling kanban I’d like to refer to another InfoQ article: Can you Scale Kanban?

About the Interviewees

Klaus Leopold is computer scientist with many years of experience in helping organizations from different industries along their improvement journey with lean and kanban. He is co-author of Kanban Change Leadership (published by Wiley in 2015). Klaus was one of the first lean kanban trainers and coaches worldwide. He was awarded the Brickell Key Award for outstanding achievement and leadership within the kanban community in 2014. Klaus is also a founding member of the management network Stoos. His main interest is agility beyond team level, especially in large projects and programs from 30 to 500 people. He publishes his current thoughts on his blog and you can follow him on Twitter at @klausleopold.

Sigi Kaltenecker is the joint managing director of Loop Consultancy in Vienna, helping individuals, groups and organisations to successfully master their professional challenges. He is a Certified Scrum Master, Kanban Coaching Professional and co-editor of PAM. Sigi authored the book “Leading Self-Organising Teams” which was published in English in 2015. Reach him at @sigikaltenecker.

Rate this Article