3 years of Kanban at Sandvik IT: The Story of an Improvement Journey

Sweden, October 2009: The newly minted System Development Office (SDO) – a small support group of three persons - just got the exciting assignment to increase the delivery capability (throughput, quality, lead-times) of all development teams within Sandvik IT. Four years later, Sandvik IT has implemented the Kanban method in more than 60 teams.

This is the story of this enterprise-wide Kanban implementation. And more than that, it is about how to install a culture of continuous improvements in the enterprise.

We are going to see why Sandvik IT chose the Kanban method; how it was deployed using a kick-start concept; how it was followed-up using a depth-of-kanban assessment; and the effects so far. The reader will find links to very concrete and step-by-step information on how to run these kick-starts and assessments.

The goal of this first article in the series "Kanban at Sandvik IT" is both to inspire you to go on your own improvement journey and to give you some ideas on how to address issues that you may encounter, especially when scaling. A second article will look into the lessons that were learned on how to maximize the effect of Kanban in the long run.

The System Development Office at Sandvik IT

This is a story about Sandvik AB, a Swedish company founded more than 150 years ago. Sandvik is an Enterprise with more than 49,000 employees in 130 countries, a world leader in the supply of mining and construction machines, special alloys, advanced steel products and steel cutting tools.

The System Development Office (SDO) is a support function within Sandvik IT with the purpose to provide methods, processes and tools for the IT deliveries to reach excellence.

Why Kanban?

The SDO got its assignment: to improve Sandvik IT’s delivery capability. The SDO team members were very familiar with Agile and, as such, already had many ideas on how to succeed using agile techniques. At that moment it was very much about continuous integration, continuous delivery and automated tests.

Though, Sandvik IT being process heavy (as all enterprises), management expected the delivery capability to be improved by specifying and deploying a standardized development process. Indeed, this had already been done for the different processes found in the ITIL: incidents, changes, etc. And it worked! Why should it not work for system development?

So, the SDO simply had to specify a common standardized development process - in order to comply with management’s needs - then highlight the parts that really matter like continuous integration/delivery and automated testing, and there you go! What could possible go wrong?

The Problems with Push Approaches to Improvements

Tapping in their agile experience, the SDO team members felt immediately that this approach to improvements based on “pushing” a standardized process would not succeed. The main points against it were:

• The teams and their contexts differ so much that it would be impossible to create a sufficiently detailed and standardized development process that would be useful to all of them. Indeed, each team had a very specific mix of customers, technologies, responsibilities, demands, production update frequency, number and severity of incidents, etc. Even the number of persons in each team, their personality and experience varied greatly.
• When pushing for changes, there was a risk that the SDO would end up managing the delivery capability of each individual team from a central position. This didn’t appear to be sustainable. The great variation of teams would make it so complex that it would not be possible, let alone efficient. A decentralized management felt more appropriate.
• It was also soon apparent that no one really had the time to listen to the SDO: the teams were far too busy delivering stuff, estimating, addressing incidents and responding to the daily demands from the customers. Hell, some team did not even consider themselves to belong to IT at all, so why even listen to some speaking about an “IT” process?

So, what could the SDO do?

The Pains of Knowledge-based Work

First, the SDO tried to understand the current condition of the development teams. What were their pains? They started to gather knowledge by performing value stream mapping workshops with different teams. After 26 workshops, it became clear that - independently of their contexts - all of the teams had the same recurring top-issues. Those were: task-switching, technical debt and plans and deadlines not being met. Moreover, these issues were interconnected in an intricate network of reinforcing negative feedback loops.

(Click on the image to enlarge it)

Figure 1: The Pains of Knowledge-based Work

Flow Control is Key

Based on this understanding, the SDO realized three things:

• All teams had the same problems, and not only development teams. It turned out that even HR, communications and management teams experienced the exact same problems. So, this was valid for all knowledge-based teams and not only for IT development. That meant that finding ways to lift these problems would benefit any team.
• The principal recurring root-cause for all these symptoms seemed to stem from a lack of flow control: too much work-in-process. Consequently, minimizing the amount of work in process should also minimize – or even remove – most of these problems. That was great news!
• Consequently, the one thing that would make the greatest impact on the delivery capability of a team (throughput, lead-times, quality, etc.) would be to gain control of the workflow and limit work in process. It is not to have a common process, or a better way to deal with requirements, or development or testing. These things may be important down the road but they would not be the smartest thing to do right now.

The Kanban Method: Best Return on Investment

For the SDO, realizing these three things meant that they had to abandon their grandiose plan to get everyone started with test automation and continuous delivery. Instead, the one action that would have the greatest return on investment was “simply” to give each team the means (knowledge and authority) to get in control of their own workflow.

At this point, the Kanban method - with its focus on flow control by limiting work-in-process - was an obvious choice. Moreover, its principles and practices were a perfect fit: start where you are, create a shared understanding of the situation and nurture the desire to improve from within the team.

Creating Awareness

Now, the SDO knew what to do: get the teams started with the Kanban method in order to get control over their workflow. But, how? With too much work ongoing, the teams still didn’t have the time to listen to them anyway!

The SDO started to use the ”Pains of Knowledge work” diagram when discussing with team managers. It became the perfect tool to create awareness on the current situation. This awareness quickly led to a desire for change when combined with the improvement expectations from top management. Team managers started to think: “If I do not do something about it now, someone else will certainly force it on me later; and it won’t be pretty…”.

The Kanban Kick-Start

So, the SDO finally got a first manager interested. At this point, their discussion went something like this:

Manager: Ok, I recognize my team’s problems and I totally agree that we need to address these right now for us to succeed. You’ve even convinced me that something can be done about it using this Kanban method. So, let’s do it! How much time do you need?

Johan (SDO coach): Well, there is quite some ground to cover, so what about 2 or 3 days?

Manager: What? I thought it was going to take 2 or 3 hours! There is no way that I can have my guys locked in a workshop for 3 days! We have some actual work to do here… I can give you one day, no more!

Johan: … One day it is then!

And so it was. The SDO had to package the basics of the Kanban method to be delivered in a one day workshop. It became known as “The Kanban Kick-start”.

One day was enough to start, but not sufficient to create a sustainable Kanban system. Therefore something more was required that would allow for adjusting, confirming or introducing concepts that could not be set right from the start. These became the “boosts”, in form of 2 hours sessions.

Looking back, introducing the Kanban method in small steps proved to be excellent in the long run: it made it “sticky” and more resilient, especially to organizational changes. An alternative approach that would overload teams with all concepts at once would certainly have made the system collapse under its own weight before producing any good. I will expand on this point in the second article.

Kick-start Structure

The Kanban kick-start has evolved continuously since 2010. Today it is composed of three parts:

1. Create a shared understanding about the purpose of the team. Real improvements can only occur once all team members share the same team purpose. This part establishes the value delivered by the team, to whom and how. In other words: what service(s) the team provides, what business it is in. This resembles a lot what a management consultant would do, although at a team level. It is quite surprising how few teams have ever discussed this.
2. Create policies (work types, work instructions, checklists, definition of ready/done, work prioritization, definition of work steps/process, how to visualize work, etc.) that are meaningful and aligned with the purpose of the team.
3. How to use policies. Use the visualization board and policies during daily meetings in order to work smart(er).

The kick-start workshop, its preparation and follow-ups in the form of boosts is described in “The Kanban Kick-start Field Guide”. This guide, co-authored by Johan Nordin and myself, is published under a Creative Common license. It came from a need to spread SDO’s knowledge within Sandvik; allowing anyone within the enterprise to perform the kick-start workshop in a similar and consistent fashion.

Scaling the Kanban Implementation

The very first Kanban Kick-Start workshop was done in September 2010, and since then the SDO has kick-started more than 60 teams of all kind within Sandvik IT: application management, project, support/coordination, management, customers, etc.

Interestingly, the SDO managed to perform all these kick-starts and follow-ups with 2, at times 3, coaches. Partly due to the way the kick-start is setup, but mainly due to the introduction of one extra role: the Flow Manager. The flow manager’s role does not actually exist in the Kanban method (there are no prescribed roles whatsoever), but – in Sandvik IT’s context - we found out that there is the need for someone from within the team to take charge for the implementation to stick. The role has some similarities to a Scrum Master role, once removed from the project management aspects it often is loaded with.

The purpose of the flow manager is to make the team reflect and act: follows the policies it has created, create new ones when needed, discuss and act on exceptions (issues and opportunities), experiments to find creative solutions, etc. The flow manager inspires, challenges and coaches. This role really is an extension of the coach and is meant to take over when the coach phases out.

Assessing Kanban

Eventually, the SDO had kick-started many teams, each one having its own flow manager. In effect the teams were free to evolve in any direction that made sense to them, to become what they must to succeed. So, how could the SDO know if a team was actually “doing” Kanban? How could the SDO assess how to best help a team to go further?

Inspired by discussions within the Kanban communityⁱ related to the depth of Kanban and based on David Anderson’s workⁱⁱ, the SDO designed a tool (in the form of a graph with attached questions) to assess the depth - or maturity - of a Kanban system. In short, using a set of questions one can plot how much of a Kanban practice a team is currently “doing”. The more, the “deeper”, the highest on the graph. This tool, and how to use it, is described in more detail in the blog post “Depth of Kanban - A Good Coaching Tool”.

(Click on the image to enlarge it)

Figure 2: Depth of Kanban Assessment – The questions

(Click on the image to enlarge it)

Figure 3: Depth of Kanban Assessment - Example

When using the assessment with a team, the SDO coaches can:

• Understand how “deep” a team has implemented the different Kanban practices.
• Recommend the most obvious - or highest return on investment - next improvement for a team (for example, it may be more costly to go “deeper” in an already advanced visualization scheme rather than starting making policies explicit).
• Inspire a team that has stopped improving (i.e. reached a comfortable and “good enough” depth) to continue improving by giving improvement ideas based on the assessment (“Yeah, that could help us! Let’s try this!”).
• Motivate a team using awards for reaching a certain depth. For instance by marking their Kanban board with a very visible “Excellence Padawan Award” sticker when reaching a sufficient depth, followed by “Excellence Jedi Award” and with the top award “Excellence Grand Jedi Ninja Award” (or something similar).

Having used the assessment on many teams, one thing became very clear: this assessment cannot be used to compare teams! Two Kanban implementations produce two very different Kanban systems that are intimately adapted to each context. Therefore, assessments should be used by and for the team, not by managers to set salary raises.

Effects of Kanban on Teams

By 2011, after having helped 20 teams, the SDO started to get good feedback from the teams, their managers and the customers. The customers were especially pleased by the increased transparency that the method made possible. But, as not all teams were yet measuring their flow, the SDO wanted to better understand the impact Kanban and the kick-start concept had at the teams. What concrete improvements did they experience?

Therefore, the SDO let undergraduates analyze the effect of Kanban on the teams that had been kick-started within Sandvik. The reportⁱⁱⁱ show that, using the Kick-start concept, the teams experienced notable improvements in team spirit, focus, quality and lead-times. Some of the effects occurred directly after the kick-starts, while others could take weeks or even month - depending on the maturity of the team:

• The team acts as a Team. The team members understand what the others are doing, share responsibility over the work in process, assist each other’s (even if it means going outside of their own comfort zone), understand each other’s skills and specialties and create a strategy to share knowledge (when and where relevant).
• The team focuses on the “right thing”. Daily meeting ensure that only relevant work is worked-on (based on work types, classes of service, due-dates). Incoming work is visible and continuously re-prioritized. Team members assist each other’s to finish what is urgent.
• The team works to its capacity and not more. Team members pull work (work is not pushed onto them) and work in process in limited using explicit WIP limits.
• Work is actionable, because it is prepared according to the team’s ’Definition of Ready’ (right size, right information). Blocked work items (due to dependencies to other teams, specialists or customers) are actively managed.
• The team has a common, standardized way of working. This ensures that the reasons for success are known (the standard) and that failures can be avoided in the future by adapting the standard to not recreate the condition for the failure.
• Flow is measured and known. The team now has a more mature discussion with the customer(s) as it is able to tell, amongst other things, when - at the latest - to start a work of a specific type, size and class-of-service for it to be delivered in time.

(Click on the image to enlarge it)

Figure 4: How fast the effects of the Kanban method are experienced by the teams at Sandvik IT using the Kick-start concept to introduce Kanban.

The Journey Goes On

As of today, the SDO has started more than 60 teams using the Kick-start concept. Yet, the SDO is still learning how create a culture of continuous improvement with the Kanban method as cornerstone. What the SDO experienced has been that, within Sandvik’s context and given the top problems experienced, the Kanban method quickly improved the delivery capability of the development teams.

Actually, what Sandvik really achieved with the Kanban method has been to create an environment where necessary changes (e.g. better requirement methods, automated tests, etc.) could stick. Indeed, the Kanban method made it possible for the teams to have the time and capacity to work with the changes while having the focus needed to build these changes in their way-of-working. In contrast, pushing for changes while the teams do not have the mean to sustain them (which was the situation at the start) would have these changes collapse quickly, wasting time and effort both for the team and the one pushing for the change.

Your Turn!

As with all tools, if you are interested in the Kanban method, be clear on why it fits your context and your objectives. This is especially important in the enterprise where many initiatives usually compete for attention. Once you have your pitch, make sure to package it in a form that makes it easily and rapidly deployed^iv, without losing its purpose. Finally, find ways to follow-up and assess^v what you have set in motion for it to be aligned.

In a second article about the improvement journey at Sandvik IT I will go deeper in the lessons that we have learned when deploying Kanban in the enterprise, especially how to maximize its impact. Stay tuned!

ⁱ Blog post by Håkan Forss on the 2012 Kanban leadership retreat

ⁱⁱ Blog post by David Anderson on “Are we doing Kanban or not”

ⁱⁱⁱ ”The effects of Kanban in software development teams - a study of the implementation at Sandvik” R.Ericsson & A.Granlöf 2011

^iv Blog post by C.Achouiantz about “The Kanban Kick-start Fieldguide”

^v Blog post by C.Achouiantz about “Depth of Kanban – a good coaching tool”

About the Author

Christophe Achouiantz is a French lean/agile consultant working for Sogeti in Sweden. He missions for a more efficient and effective knowledge-based work, making it more meaningful and, ultimately, profitable. You can find him  on his blog and on twitter @ChrisAch.