In the first article in the “3 years of Kanban at Sandvik IT” series, I described why Sandvik IT decided to use the Kanban method, how it was packaged, introduced and supported. In this second article, I want to focus on the lessons that the System Development Office (SDO) learned when sustaining the Kanban method during this 4 years journey.
In an Enterprise context where organization changes are frequent - if not regular - the improvements generated by a virtual kanban system (or by any other way for that matter) are often short term. If we accept that nowadays an enterprise needs to be in a constant transformation, the problem becomes: How to engineer kanban systems to be sustainable and resilient despite these changes?
This article presents four qualities that we have identified as key when setting-up relevant, and long-term, kanban systems in the enterprise: Stickiness, Clarity, Curiosity and Influence.
Observed Improvements Patterns
The SDO at Sandvik IT - a small support group of 3 persons - has helped more than 60 teams in using the Kanban method over a 4 years period. During this period the SDO has had the opportunity to observe how the teams improved over time.
These are the behaviors that we have observed:
- At first, all teams start improving after setting up their virtual kanban system and hold this improvement rhythm for a few weeks to several months. The improvements are usually straight-forward and - in retrospect - rather “obvious”: limiting work-in-process, helping each-others to finish high-priority work, addressing plain visible bottlenecks, improving work selection policy, etc. The visualization practice in the Kanban method makes these improvement opportunities very accessible: they are graphically obvious and almost too painful to look at everyday to ignore. One can say that, at this stage, visualization is the engine driving the improvement work.
- Eventually, all teams reach a tipping point where visualization alone is not sufficient for motivating improvements. The teams can then go three ways:
- Collapse! The team simply stops improving and quickly abandons its kanban system (about 10% of the teams, none of them self-organizing agile teams). Looking at the root causes, it appears that there is always some internal conflicts and/or a lack of sense of purpose, combined with a detached or distant team manager (direct team manager is not present or it is unclear who actually manages the team, e.g. during a re-organization).
- The team reaches a “good enough” state. It maintains its kanban system but does not strive to improve its way of working (the vast majority of the teams, including self-organizing agile teams). These teams usually have a team manager that is not regularly engaging with them (e.g. not regularly coming to daily huddles, not actively helping the team to resolve issues).
- The team improves continuously (about 20% of the teams). These teams usually have a very active manager, engaging daily with the team.
Observed patterns a team improvements at Sandvik IT
(60+ teams from november 2010 to mars 2014).
Based on these observations, the key to succeeding with a kanban system in the long run (months from the initial kick-start) seem to be the manager’s engagement. Actually, this is no big surprise: leaders have always had a critical role in change initiatives.
One solution would be to fill all manager positions with natural-born great leaders, though that may not be practical nor feasible at an Enterprise scale. The question now becomes: using the managers that are at hand, is there something we can do to maximize the chances for our teams to take the continuous improvement path, rather than the “good-enough” path, let alone the “collapse” one? Basically, as a coach how can I help to engineer a kanban system that is sustainable and resilient?
Having tried to answer that very question for the past 4 years in Sandvik IT’s context, we found out that a coach should try to maximize stickiness, clarity, curiosity and influence,.
Quality #1: Stickiness
Sandvik IT has gone through two major reorganizations during the 4 years that the SDO has been helping teams with the Kanban method. Some of these teams disappeared overnight, while other were moved around the organization or saw their manager being replaced. Interestingly, despite the sometime quite dramatic changes, most of the team did continue to use their kanban system. This was possible because these kanban systems were sticky, they were resilient to outside changes.
Here is what we did to cultivate and reinforce the stickiness of these kanban systems:
Grow, do not Summon
A kanban system is sticky if it is intimately adapted to its context. Therefore a kanban system should be grown in context and not summoned from another context. This - of course - requires time and effort, both from the team creating the kanban system and the coach supporting them.
The key here not to use pre-cooked solutions (e.g. use a standard visualization board and standard policies). These canned solutions will probably help in the (very) short term - the team starts with “something” - but it will very quickly fail the team by not mapping to the team’s reality and challenges. The biggest problem with pre-cooked solutions is that they let the team members believe that they do not need to think, as someone else (in an totally different context) has already done the thinking for them. At best, a pre-cooked solution can act as an example when discussing what the team needs.
So, in our experience, a pre-cooked solution will not help a team reaching a continuous improvement path, but most likely quickly parking the team in the “good enough” or even “collapse” path (if the manager isn’t present). The Kanban Kick-start Field Guide is one way to grow a kanban system in context.
Sustainable by the Team
A kanban system should match the maturity of its team. This is crucial for the coach: do not rush! Pushing for all Kanban bells & whistles at once will confuse more than it will help. A way to sustainably grow a kanban system would be to let the team pull concepts when it is ready for it (or just right before that) rather that the coach doing the pushing. The Kanban kick-start as described in “The Kanban Kick-start Field Guide” is built to introduce all concepts progressively.
Let the team lead! A kanban system designed by an expert will probably be correct but it will not be sticky, simply because it does not comes from the team. In an Enterprise environment you want a kanban system to be resilient more that perfect. In other words: “In an Enterprise context, perfect is not nearly as good as sticky”. Again, the Kanban kick-start concept was developed specifically for this need.
Resilient to lack of leadership
If a kanban system is sticky (i.e. it sustains organization changes), it can help bridging the inevitable periods of uncertainty - and sometimes right-out chaos - that ensue from the constant transformation of the Enterprise. This requires the teams to have well functioning set of policies allowing them to function in ‘automatic mode’: all decisions are naturally aligned with the teams’ purpose, not requiring any involvement from a manager or coordinator (how to select work, how to classify work into different classes of service, when is a work ‘done’, etc.).
This means that, in the Enterprise, the “make policies explicit” practice of the Kanban method is especially important and should be a focus for the coach: the team will need these policies more than ever sooner or later.
Quality #2: Clarity
Nothing matters more than a team’s alignment to it’s purpose. It does not matter if there is an engaged manager with influence that helps building a sticky kanban system; if the team doesn’t have a clear purpose it - at best - just does the wrong thing right. To avoid this the coach must, as early as possible, help the team to be clear on its purpose and to make sure that the team’s kanban system is aligned with it.
The kanban system is aligned with the team’s purpose
It first requires that the purpose of the team is known and that the team members share it. In practice we found out that few teams ever discuss their purpose: what business they are in, or what services they deliver? The coach is crucial here to help the team formulate a valid purpose, acting like a management consultant at a team level, discussing value delivered, success criteria and slogan. The Kanban Kick-start Field Guide provide some guidance on how to facilitate this discussion.
Note that the purpose formulated by the team does not need to match that of the managers or the stakeholders. Actually, it is very interesting if it doesn’t: you have just uncovered a golden opportunity for improvement!
Once there is a valid and shared purpose, the team must design, or re-design, its kanban system to clearly reflect that purpose. This means that the policies describing how the team works must reflect the purpose: work types, classes-of-service, demand shaping, etc.
For example, a team may use a ‘red’ work type for all work that is not directly aligned with its purpose to see and understand how much of its effort that goes to the wrong things. These red work types represent non value-adding activity according to the team’s purpose. Another team, sharing its time between application management (budgeted at 25%) and project work (budgeted at 75%), divides its work-in-process limit of 12 between the two according to the budgets and visualizes the two types of demand using different swimlanes.
Once the policies reflect the purpose of the team it becomes very easy to measure how much the team is aligned with its purpose. In the examples above, the team could measure the number of red stickies or if the application management lane really only have a maximum of 4 of work items at any moment.
The kanban system is built to gather the right facts
A well designed kanban system should provide a team with plenty of improvement opportunities. It should surface the facts that are needed to push improvement further. It should provide clarity not only of purpose, but clarity of opportunities. A well designed kanban system should expose plenty of “smart moves” for the team to act on to change their current condition towards an ideal.
See queues
Queues are leading indicators, a unique opportunity to predict the future: you know in advance that something will probably be delayed if it is in a queue. Therefore queues should be very visible. Always ask yourself: where is the bottleneck right now? If it isn’t obvious, how can the visualization board be refactored to make it clear?
Have the right metadata to allow meaningful analysis.
Understanding and solving problems may require to temporarily measure one or several aspects of a kanban system, and that the kanban system is built to be able to gather the right facts. A kanban system should be continuously adapted to make the right information available to improve in the right direction.
For example, a team finally understand why it has unsatisfied customers when it realize that work items that have less than a man-day worth of work take as long as 4 man-weeks work items. To re-establish trust, the team decides to prioritize small items over large ones. This requires to estimate the size of work items as they come in. Then, having set a goal to complete small items within a week, the team creates a new temporary Key Performance Indicator measuring how well the small items are complying to that goal. The team then uses the KPI to evaluate the impact of its improvements to reach the goal it has set to itself.
Quality #3: Curiosity
We found out that there is one quality that seems to set aside engaged team managers from the others: they are curious, and they take the time to be curious. They go and see the team, ask the team members about their current issues, share their observations and concerns. While many other qualities are needed in a manager to create a trust relationship with the team (e.g. sincerity, openness, reliability), we found out that curiosity in itself inspires team members to reflect about what they do and look for improvement opportunities. It comes down to the team members experiencing that someone really cares for what they do and act when needed.
Creating Curiosity
Ok, so let’s make all team managers more curious! But, how?
We want managers to have the behavior to go and see teams and ask questions. “How are we doing?” is a good start. Soon, we would like to have more specific questions related to the team’s current concerns like “How good are we at holding our promises?”, “Are our stakeholder satisfied?”. Eventually, we would like very specific questions like “What is our due-date completion rate?”.
One possible way to create this culture of curiosity is to establish regular peer-to-peer coaching sessions similar to Mike Rother’s coaching kata1. The SDO is experimenting with such a tool where a manager, or coach, (the mentor) is having a regular dialog with another manager (the mentee) based on current concerns. Their discussion focuses on facts and requires the mentee to become curious with his/her team to get the facts right.
An example of a mentor-mentee discussion.
This is the very first discussion when the mentee must first get data from his team.
(template by Johan Nordin)
Quality #4: Influence
For the teams that see the need to improve (either due to internal motivation or a curious and supportive manager), we observed that they always end-up identifying major improvement opportunities that are perceived to be, rightfully or not, outside of the team’s sphere of influence. The danger leaving these opportunities unaddressed is that it undermines the team’s motivation, eventually making the whole improvement exercise irrelevant. Interestingly, regardless of how motivated a team and/or its manager is, it will always end-up in this situation: the team hits a ceiling, gets stuck, loses motivation and parks itself in a “good-enough” path (or in a “collapse” path if management is disconnected and the kanban system isn’t sticky). In other words - and that is somehow quite depressing - there is always a ceiling to any continuous improvements work.
There is always a ceiling to any continuous improvements work.
Should we just all go home and do something else? Quite not yet, here is what we tried to do to push this ceiling as high as possible:
Get a sponsor
Addressing improvement opportunities that cannot be not be resolved from within the team requires influence over other groups. For instance: making another team comply to a clear interface (e.g. “Definition of Ready”), or to solve a dependency to another group that regularly result in blocked urgent work.
These problems can usually be solved by escalation when the different groups are from the same unit. If it is not the case, a sponsor is a good way to solve these situations by compensating for a team manager’s lack of influence. In an Enterprise, someone - probably higher up in the hierarchy, but not necessarily - usually has the means to make things happen over there.
So, one important and often overlooked function of a coach is to help teams get sponsors, either by putting teams in direct contact with one or - even more important - by building the necessary skills for the teams to do it themselves (e.g. communication skills, business case building, elevator speeches based on facts collected by a kanban system, etc.).
Stretch your value stream
Improvement opportunities can also be limited by having a too narrow and local view of the workflow. Stretching a kanban system upstream and/or downstream is a way to extend the team’s influence and control. Actually, a kanban system really pays off when applied to an end-to-end workflow, from customer demand all the way to delivery2. Therefore, a coach should strive to help teams stretching their kanban systems over whole value streams.
For example, the Integration department at Sandvik IT started with many small kanban systems for each technical platform but is now integrating them in one bigger kanban system stretching from an integration solution demand (at a sufficiently high level to not yet have specific technical platform requirements) to a delivered integration in production. This new approach brings direct value to the customers by providing solutions that better fit their needs (i.e. by not locking the technology directly but letting it come from the real needs).
Dis-continuous Improvements
The organization itself may be the problem when teams needs to spend way too much effort and influence to support or stretch their kanban system. The organization may not be ‘configured’ to allow what the teams are trying to do. The last option is then to change the house by moving the ceiling up: changing the way the organization is built! For instance, the way the different functions are organized may require many specialized groups to cooperate to have a true end-2-end perspective. A change in the organization (e.g. form component teams to cross-functional service teams) may be needed to create the possibility to improve the services.
Dis-continuous improvement (redesign the organization) as a way to break through the ceiling.
This type of change can be a tough sell as it requires a sponsor really high-up in the organization (CIO and even above) that often demand a solid business case. Here it may help for the coach to bring onboard external help, like lean and/or agile consultants - with the right mindset - that can demonstrate past successes.
Conclusion
Teams using the Kanban method can quickly improve their way-of-working. In an Enterprise context, improvements tend to stop when the organization’s continuous transformations bring chaos and change the rules, or when the teams must go out of their comfort zone to improve further. In this context, a coach can help the teams to stay relevant and on a long-term continuous improvement path by building-in 4 qualities:
- Stickiness: Make the kanban system sticky, by letting the teams grow their kanban system and by matching the coaching given with the teams’ maturity.
- Clarity: Help the teams have a clear and shared purpose that is reflected in their kanban systems.
- Curiosity: Keep the managers curious so that they care about their teams and support them in their improvement effort.
- Influence: Give the teams the capability to have influence over their environment either by the way of a sponsor, by stretching the control they have over their workflow or by re-engineering the organization to better fit their needs.
The Kanban method is a modern way to manage and improve services that fits very well in the Enterprise. With some care you can make it fit for the long term.
1 Mike Rother “Toyota Kata”
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.