Visual management, flow and leadership on all levels resonates with managers, because they address real problems that they are facing, says Arne Roock (Lean and Kanban coach and trainer). They can use these Lean and Kanban concepts with evolutionary change to continuously improve their systems.
The 2013 international conference in Central Europe about Lean and Kanban (LKCE13) included presentations about change management, systems thinking, leadership, learning, and teamwork, and case studies from larger organizations that have applied Lean and Kanban. Presentations given at the conference can be downloaded from the conference program.
Arne Roock was involved in the organization of this conference, InfoQ interviewed him about deployment of Lean and Kanban in agile software development.
InfoQ: For those not familiar with Kanban, can you briefly state its main principles?
Arne: Kanban is a Method for catalyzing evolutionary change in organizations. Evolutionary means that there is no pre-defined target state we could define upfront before we start our change initiative. Instead, we set a direction (i.e. vision) and then continuously improve our system in that direction. So the outcomes are fixed, but the way we are going to achieve these outcomes need yet to be explored - and they might also change all the time.
The Kanban practices for this kind of evolutionary change are
1) Making invisible work visible
2) Limiting work in progress
3) Making implicit process policies explicit
4) Implementing feedback loops
5) Managing the flow of work
6) Using models and conducting experimentsThis might sound a little bit abstract, but it is highly practical and useful in many different contexts.
I will give you a small example: One of my clients was struggling in different areas. During a workshop I asked the management team what their most important goal was. They agreed upon better quality. We then defined what quality means for them and how they would know that it had improved. We then trained the staff in Kanban and designed their Kanban system with almost the whole company involved. We set up a Card Wall in the office where now everyone can see what kind of tasks (and how many) they have on the plate, in what state these tasks are and what problems they are facing (i.e. wait times because of external dependencies). Then we implemented feedback loops on a daily basis (standup meetings) and on a bi-weekly basis (kind of retrospectives). It pretty soon became obvious that the biggest blocker on the road to better quality was a lack of collaboration between project managers, developers and testers. This was something that many had somehow "felt" before. But now it was visible for everyone, they had their regular feedback loops to discuss it, and the work-in-progress limits created a sense of urgency to change things. The interesting thing is: They started changing their system over and over again and improved their quality step by step. And nobody would have been able to design this system upfront - they simply had to build hypotheses, try things, evaluate them and change things over and over again.
InfoQ: I see enterprises that are adopting agile software development. Most of them implement Scrum. Should they also think about implementing Kanban and/or Lean?
Arne: If they want to improve their way of working and if they suffer from unevenness of flow and overburdening (= demand exceeds capability) then it’s a good idea to have a closer look at Kanban. And it‘s not either Scrum/Agile or Kanban. As I mentioned earlier: Kanban is a change method. We are aiming for improving our organizations learning capability. It’s not a project management tool nor a team process in the first place. Kanban is a method you add to something existing. And this can be Scrum as well as any other method. I’ve seen Scrum implementations that have been improved by using Kanban. And I’ve seen random processes that evolved in something very similar to Scum through the use of Kanban.
InfoQ: Are there new developments in the area of Lean software development that you consider to be of interest for enterprise software development?
Arne: Surprisingly, most of the ideas that become more and more popular these days are rather old. Think of Systems Thinking for example. The writings of Deming, Drucker and Ackoff are decades old, but they are still incredibly insightful and useful. The hard part is to transfer these ideas into new contexts like software development and to synthesize them with other ideas. We have made a lot of progress here during the last couple of years. For me a lot of these old ideas became a lot more tangible and applicable, because now they are framed in Kanban.
If we talk about enterprises (compared to medium sized businesses) my experience is that Lean and Kanban are quite accessible to managers. Concepts like visual management, flow and leadership on all levels resonate with them, because they address real problems they are facing.
Also the evolutionary approach is something that fits the culture of many large organizations, because they don’t like revolutionary change so much, and it creates a lot of resistance within the workforce. The Kanban principles "start where you are now" and "initially respect current roles, responsibilities and job titles" are very useful when we want to change things in such environments.
InfoQ: There were several talks at Lean Kanban Central Europe conference about scaling Lean and Kanban. Can you tell something about the experiences that have been presented?
Arne: For me the main takeaway is: There is not the one correct solution for the problem of scaling. And that should be no surprise. Can we really assume that Lean and Kanban at Ericsson would be the same as at Spotify or SAP? Of course not! Their businesses are completely different; they have different technologies, different customers, different histories and different values. Imagine Ericsson, an enterprise that is proud of its long history and its value "perseverance" and compare it to a young, fast growing startup like Spotify. To think we could have a blueprint that works for both of them and apply it "by the book" would be madness!
I’ll give you an example: If you are providing a web service like Spotify does and you are using newest state-of-the-art technologies, continuous live deployment is almost a no brainer. But can we really expect the same thing from a company like Ericsson where a big deal of hardware is involved? For new major releases they are simulating whole cities, and their test environment is extremely expensive. And now compare these two companies to SAP, where thousands of engineers are working on the same ERP product suite. Again, a completely different environment. Ericsson, SAP, Spotify, Siemens Health Services and Jimdo presented case studies at Lean Kanban Central Europe 2013. All these companies are working on scaling mechanisms that work in their environments. And as far as I can tell there is no silver bullet. Every organization has to find out what works for them. I wish there would be a working scaling solution that comes in a box and works like a charm. But there simply isn’t!