4.0 1

Kanban at Scale – A Siemens Success Story

originally written by

Our summary and key takeaways

Why turn to Kanban?

In this fascinating use case, Bennet Vallet of Siemens Health Services looks six years back at the history of the company's move from Scrum and XP toward Kanban.
The company provides healthcare IT solutions and services. The part of the business that the author is taking a specific look at is Product Lifecycle Management (PLM), made out of around 50 teams in the US, Europe, and India. The Kanban experiment was conducted for the Soarian Financials ® product.

The reason for PLM's undertaking of the journey towards an Agile mode of working was to afford higher software delivery speeds and quality, keeping their products competitive.

Two man sitting at their computer desks with a Scrum board on the wall behind them

Having started their Agile adoption in 2005, by 2011, it was beginning to be clear that the used methods were not a complete success. The teams were not meeting their due dates, and there was always a noticeable crunch with much overtime just before the planned sprint's end.

Since the teams had the freedom to work on as many stories as they wanted within each sprint, there was no easy way to assess how much was already done, what was left to do, who was blocked, etc. There was a tendency for all the work items to reach completion at the very end of the sprint. As a result, the PLM division lacked the predictability levels required in the intensely regulated and demanding market.

How to adopt the change?

That started to change in late 2011. After a reevaluation of how the teams work, the company decided to move towards Lean Thinking established for manufacturing purposes: to identify value in the process and consider large batches' and queues' impact, rather than on the previous optimization of specific activity types. One of the core problems the teams had was not keeping tabs on the number of started items at one time and a lack of insight into the current state of things. That led them to Kanban with its process and state visualization and transparency, WIP limits, measurable cycle time, and throughput values.

Drawing from previous experience, the PLM managers knew that for the new method's implementation to be successful, they needed to:

  • involve as little outside help as possible,
  • include members of all of the affected teams in the transformation process,
  • and go all in, affecting all teams across the process at once and equally.
    • A revolution over an evolution

      That meant that the way they enacted the adoption was somewhat different than usual - a revolution, not an evolution. And while this approach took more effort, it did pay off, assisting in the desired paradigm change. Together with achieving the much-needed process transparency, a clear benefit in moving to the use of kanban boards was the ability to increase work quality through specific completion definitions for each work type and process stage. It caused a significant drop in defect rates.

      However, despite running a Kanban revolution, there was no real turmoil for the teams already familiar with Agile management. Yes, the practices related to time-set iterations were removed, but the general aspects of Agile software development known and believed in by the team remained intact. To enforce the understanding of Kanban, Siemens turned to train provided by a consultant with experience at Corbis, the first company to use Kanban for software development. As one of the quickest indicators of the implementation's success, the author also mentions higher team engagement thanks to the boards' collaborative nature.

      Two workers discussing work items shown on a visual Kanban board

      Finding new performance metrics

      For their new performance measurements, Vallet's teams have adopted Cumulative Flow diagrams, scatter plots, and histograms - analysis tools delivering actionable information about the process state. Thanks to the Kanban training consultant, the team had also realized the crucial connection between the amount of Work in Progress and Throughput values and its impact on cycle times. It's the relation described by Little's Law. Understanding the relationship between these three values allowed the team to control their progress speed and state.

      The results

      After just one year of using Kanban and the new metrics, Siemens HS' management recognized it as a success, approving the introduction of Kanban to all remaining product lines' development.

      Bennet Vallet concludes the use case by underlining how a Lean, systemic take on software development, with process visualization and WIP limits, can work to a large-scale corporation's advantage without ripping out the core of Agile software development. Vallet emphasizes how much the appreciation of Little's Law changed for his team and the crucial value of tailoring WIP limits to the team's capabilities. The author also underscores the significance of the teams' having already been familiar and using stories, TDD, CI, and self-organization of teams, pointing out that without these previously acquired skills, the implementation of Kanban alone would probably not have been that big a success.