This presentation will describe the approach taken for one of the world’s largest Kanban implementations at Siemens Health Services. It will describe how Kanban augmented existing agile practices there, and it will examine the achieved benefits of “flow” as demonstrated by real project data. Through a careful consideration of successes, challenges, and ongoing opportunities, this case study should be very meaningful to software product/development management organizations of any size whose funding, business operations, and profitability are dependent upon achieving a high degree of operational efficiency, transparency, and predictability.

1. Kanban At Siemens
Health Services
Bennet Vallet
Daniel S. Vacanti
11/04/13
DO NOT REPRODUCE
© Corporate Kanban 2013

2. Is it possible to do Kanban
without doing Kanban?
Does it even matter that
we “do Kanban”?

3. Kanban at Siemens Health
Services
A Philadelphia Story

4. Siemens Health Services
A strategic part of the Siemens
Healthcare portfolio, HS offers a broad
range of clinical and financial IT
applications, as well as outsourcing
and professional services to support
health providers across the continuum
of care.

5. Soarian Revenue Cycle
• Org of about 500
people
• 15 cross-functional
teams
• 3 continents
• Complex software
deployed to
hundreds of
Healthcare facilities
• Highly regulated
• Mission Critical
Mature Scrum Process since
2005
20 day sprints
Stable feature teams
Release Cycles about every
12 months

6. Release
Features
Features
Epics
Epics
User Stories

7. The Problem

8. Predictability
Operational Efficiency
Quality

9. Predictability
Predictability
Predictability

10. Predictability
Completing ―potentially shippable stories‖ in
predictable 20 day time-boxed increments
Accurately estimating story and feature
completion timeframes
Completion of features on a regular cadence
Providing transparent and actionable metrics

11. The business and culture at HS requires a high
degree of certainty, predictability and
transparency.
Internal Decision Checkpoints and quality gates
require firm commitments, low risk tolerance and
very little flexibility in terms of cost, schedule and
scope
Commitments to customers and the market
requires very high levels of predictability in terms
of functionality and delivery timeframes
Cost of delay has a high premium
and predictability trumps everything

12. Product Lifecycle Management (PLM)
Excellence
Goals
Drive Quality
Reduce Cycle Time
Learning
Organization
Balanced
Throughput
People
Tools
Improve Predictability
Work
Units
Continuous
Customer
Validation
Effective
Tools
Process
PLM Excellence Core
Team. Chartered by
senior management to
drive process
improvements
Lean Agile
Practices
Infrastructure
Environments
Systems Thinking
Legend:
Focus
Area

13. The Approach

14. Idealized Design
Focus on transforming the whole system rather than
improving parts of the system

15. Idealized Design
Design the system with which we would replace the
existing system right now as if we were free to replace
the existing system with whatever system we wanted

16. Idealized Design
Requires participation of everyone who will
be affected by it. Ownership of the
resulting plan must be widely spread by
those who had a hand in preparing it

17. Flow Team Strategy
We needed to shift the paradigm and deliver
results quickly
Big bang approach with high degree of workunit and workflow standardization and
cohesion across all teams
Raise the bar on quality

18. Flow Team Strategy
Deploy coaches into all teams
Develop and execute education and
communication strategy
Engage external expert(s) as needed

19. Use electronic board for all feature teams
Support Kolkata team members
Invest heavily in metric capture
Installed large screen TV
monitors in all team rooms in
Philadelphia and Kolkata

20. Teams & Responsibilities
PLM Excellence Core Team
The Flow team is a cross
business unit team, multi- and overseeing PLM-wide improvement projects
• Driving
• Advocating and promoting new approaches to Workflow Management
disciplinary and all technical
and management levels
Operational/Implementation Teams
Process Design Team
SF Operational Flow Team
Flow Team
• Identifying and
improving key Agile
practices
•Defining and rolling out new Kanban
Workflow Mgmt. Process & Tools
• Driving convergence of Version One
usage
•Defining key metrics
•Cross functional
•Includes key SF participants
Education,
Coaching and
Rollout
•
Supporting & enabling new process
implementation
• Actively monitoring workflow and removing
obstacles
SF 3.4.100 Planning Team
• Operationalize new
processes
• Improve execution of
current processes
• Implementing Inception Process
There is significant overlap in membership between the PLM Excellence Core Team, the various Process Definition Teams,
and some of the Operational Core Teams. The process definition teams are responsible for the education, coaching and
rollout to the operational teams. They will also remain in place until D4. The PLM Excellence Core team is responsible for
educating the SF and SC SMTs.

21. But…coaching replaced formal
compliance and governance
21

22. Kanban Coaching Guide
Responsibilities and Knowledge areas:
•
•
•
•
•
•
•
•
•
•
Kanban board
Connecting the process to the tools
Conducting the Stand-up
Role Flexibility / Swarming
Backlog Management & Prioritization
WIP Limits
Cycle Time & Metrics
Policies
Program Reviews and Retrospectives
Release Planning

24. PLM Excellence is our framework for driving long term systemic changes targeted at increasing our
competitive position by improving our execution and throughput. These monthly communications are
intended to keep you apprised of current activities and provide ways for you to access additional
information. Please click here to find a link to our monthly status report.
Initiatives featured in this month’s e-mail communication include Kanban, Inception, Agile Coaching,
Build and BVT improvements, and the Learning Organization/Speaker Series.
Kanban:
Kanban, which we will use to augment our current Agile processes, provides a method for optimizing
the flow of work to improve cycle time, drive quality, and provide the visual transparency and metrics that
we require to achieve the level of predictability we need. Kanban will help us work more effectively in
achieving our vision and delivering the results that our customers expect.
The essential elements of Kanban are:
 Visualizing the flow of work
 Queues
 Using Pull vs Push
 Limiting Work in Progress
 Continuous Improvement
PULL
DON’T PUSH

27. The Results

28. First, some metrics on the
release before the release
that we limited WIP
(at the user story level)

29. Project : SF 3.4 Base
Story Cycle Time Scatter Plot
Team : (All)
Median Cycle
50% of stories Time (All Sprints) ==21
Average Cycle Time (All Sprints) 34
finished in 21 days
or less
200
180
160
140
y = 133
y = 126
120
Days100
80
y = 71
60
40
y = 40
20
y = 21
y =8
Cycle Tim e
Linear (70% @ 40 days or less)
Linear (98% @ 133 days or less)
Sprint Boundary
Linear (85% @ 71 days or less)
Linear (30% @ 8 days or less)
Linear (50% @ 21 days or less)
Linear (97% @ 126 days or less)
27-Apr-12
20-Apr-12
13-Apr-12
6-Apr-12
30-Mar-12
23-Mar-12
16-Mar-12
9-Mar-12
2-Mar-12
24-Feb-12
17-Feb-12
10-Feb-12
3-Feb-12
27-Jan-12
20-Jan-12
13-Jan-12
6-Jan-12
30-Dec-11
23-Dec-11
16-Dec-11
9-Dec-11
2-Dec-11
25-Nov-11
18-Nov-11
11-Nov-11
4-Nov-11
28-Oct-11
21-Oct-11
14-Oct-11
7-Oct-11
30-Sep-11
23-Sep-11
16-Sep-11
0

30. Project : SF 3.4 Base
Story Cycle Time Scatter Plot
Team : (All)
Median Cycle Time (All Sprints) = 21
Average Cycle Time (All Sprints) = 34
85% of stories
finished in 71 days
or less
200
180
160
140
y = 133
y = 126
120
Days100
80
y = 71
60
40
y = 40
20
y = 21
y =8
Cycle Tim e
Linear (70% @ 40 days or less)
Linear (98% @ 133 days or less)
Sprint Boundary
Linear (85% @ 71 days or less)
Linear (30% @ 8 days or less)
Linear (50% @ 21 days or less)
Linear (97% @ 126 days or less)
27-Apr-12
20-Apr-12
13-Apr-12
6-Apr-12
30-Mar-12
23-Mar-12
16-Mar-12
9-Mar-12
2-Mar-12
24-Feb-12
17-Feb-12
10-Feb-12
3-Feb-12
27-Jan-12
20-Jan-12
13-Jan-12
6-Jan-12
30-Dec-11
23-Dec-11
16-Dec-11
9-Dec-11
2-Dec-11
25-Nov-11
18-Nov-11
11-Nov-11
4-Nov-11
28-Oct-11
21-Oct-11
14-Oct-11
7-Oct-11
30-Sep-11
23-Sep-11
16-Sep-11
0

31. Project : SF 3.4 Base
Story Cycle Time Scatter Plot
Team : (All)
Median Cycle Time (All Sprints) = 21
Average Cycle Time (All Sprints) = 34
200
180
160
140
y = 133
y = 126
120
Days100
80
y = 71
60
40
y = 40
20
y = 21
y =8
Cycle Tim e
Linear (70% @ 40 days or less)
Linear (98% @ 133 days or less)
Sprint Boundary
Linear (85% @ 71 days or less)
Linear (30% @ 8 days or less)
Linear (50% @ 21 days or less)
Linear (97% @ 126 days or less)
27-Apr-12
20-Apr-12
13-Apr-12
6-Apr-12
30-Mar-12
23-Mar-12
16-Mar-12
9-Mar-12
2-Mar-12
24-Feb-12
17-Feb-12
10-Feb-12
3-Feb-12
27-Jan-12
20-Jan-12
13-Jan-12
6-Jan-12
30-Dec-11
23-Dec-11
16-Dec-11
9-Dec-11
2-Dec-11
25-Nov-11
18-Nov-11
11-Nov-11
4-Nov-11
28-Oct-11
21-Oct-11
14-Oct-11
7-Oct-11
30-Sep-11
23-Sep-11
16-Sep-11
0

32. For the next release we
didn’t limit WIP right away

34. 201204
6-Apr-12
4-May-12
11-May-12
27-Apr-12
20-Apr-12
13-Apr-12
201205
201206
201207
27-Jul-12
13-Jul-12
20-Jul-12
6-Jul-12
29-Jun-12
22-Jun-12
15-Jun-12
8-Jun-12
1-Jun-12
25-May-12
18-May-12
201208
24-Aug-12
201209
201210
19-Oct-12
12-Oct-12
5-Oct-12
21-Sep-12
28-Sep-12
14-Sep-12
7-Sep-12
31-Aug-12
201211
16-Nov-12
9-Nov-12
2-Nov-12
26-Oct-12
201212
14-Dec-12
201213
18-Jan-13
11-Jan-13
4-Jan-13
28-Dec-12
21-Dec-12
201301
8-Feb-13
15-Feb-13
1-Feb-13
25-Jan-13
201302
8-Mar-13
80
1-Mar-13
22-Feb-13
Program : SF - 3.4.100 Program
30-Nov-12
7-Dec-12
23-Nov-12
200
17-Aug-12
Team : (All)
10-Aug-12
3-Aug-12
Project : (All)
Story Cycle Time Scatter Plot
Story Estimate Type : (All)
Median Cycle Time (All Sprints) = 1
180
Average Cycle Time (All Sprints) = 2
160
140
120
Days 100
y = 90
y = 74
60
40
y = 43
20
y = 30
y = 19
y = 11
0

35. When we limited WIP…

37. 201204
6-Apr-12
4-May-12
11-May-12
27-Apr-12
20-Apr-12
13-Apr-12
201205
201206
201207
27-Jul-12
13-Jul-12
20-Jul-12
6-Jul-12
29-Jun-12
22-Jun-12
15-Jun-12
8-Jun-12
1-Jun-12
25-May-12
18-May-12
201208
3-Aug-12
24-Aug-12
201209
201210
19-Oct-12
12-Oct-12
5-Oct-12
21-Sep-12
28-Sep-12
14-Sep-12
7-Sep-12
31-Aug-12
201211
16-Nov-12
9-Nov-12
2-Nov-12
26-Oct-12
201212
14-Dec-12
201213
18-Jan-13
11-Jan-13
4-Jan-13
28-Dec-12
21-Dec-12
201301
8-Feb-13
15-Feb-13
1-Feb-13
25-Jan-13
201302
8-Mar-13
80
1-Mar-13
22-Feb-13
Program : SF - 3.4.100 Program
30-Nov-12
7-Dec-12
23-Nov-12
200
17-Aug-12
Team : (All)
10-Aug-12
Project : (All)
Story Cycle Time Scatter Plot
Story Estimate Type : (All)
Median Cycle Time (All Sprints) = 1
180
Average Cycle Time (All Sprints) = 2
160
140
120
Days 100
y = 90
y = 74
60
40
y = 43
20
y = 30
y = 19
y = 11
0

38. 201204
6-Apr-12
4-May-12
11-May-12
27-Apr-12
20-Apr-12
13-Apr-12
201205
201206
201207
27-Jul-12
13-Jul-12
20-Jul-12
6-Jul-12
29-Jun-12
22-Jun-12
15-Jun-12
8-Jun-12
1-Jun-12
25-May-12
18-May-12
201208
3-Aug-12
24-Aug-12
17-Aug-12
201209
201210
19-Oct-12
12-Oct-12
5-Oct-12
21-Sep-12
28-Sep-12
14-Sep-12
7-Sep-12
31-Aug-12
201211
16-Nov-12
9-Nov-12
2-Nov-12
26-Oct-12
201212
14-Dec-12
201213
18-Jan-13
11-Jan-13
4-Jan-13
28-Dec-12
21-Dec-12
201301
8-Feb-13
15-Feb-13
1-Feb-13
25-Jan-13
201302
8-Mar-13
80
1-Mar-13
22-Feb-13
Program : SF - 3.4.100 Program
30-Nov-12
7-Dec-12
23-Nov-12
200
10-Aug-12
85% of stories
finished in 43 days
Project : (All)
Story Cycle Time Scatter Plot
or less
Team : (All)
Story Estimate Type : (All)
Median Cycle Time (All Sprints) = 1
180
Average Cycle Time (All Sprints) = 2
160
140
120
Days 100
y = 90
y = 74
60
40
y = 43
20
y = 30
y = 19
y = 11
0

39. And the release after
that?

40. 43 days
41 days

41. 2000
3.4.100 Open
3.4.100 Closed
3.4 Open
3.4 Closed
1800
1600
1400
1200
1000
800
600
400
200
0
D2
RI

42. We have a problem?

43. Lessons Learned (so far)

44. “If you can’t do Scrum why
do you think you can do
Kanban?”
“It’s because we can’t do
Scrum that we have to do
Kanban”

45. Visualization forced
collaboration—stronger standups
with remote teams; testers said
this was the first time they had
really ―participated‖ in a standup
System did not really stabilize
until WIP limited at story level

46. At some point we violated all
the foundational principles of
Kanban
No Classes of Service were
harmed in the making of this
film

47. At Siemens HS, back in
November 2011, no one had
heard of Kanban. First year
results convinced all product lines
to migrate to Kanban:
–1300 people
–About 40 teams
–3 continents

48. Next Steps

49. Forecasting and Simulation
Teams fighting for scarce resources
across complex product lines.
Legislative timelines need careful
risk management. Penalties if late.
Need to promise features to many
major customers

50. Story Flow – Current State
CONDITIONING
Reqt
Candidates
Pre-Incept
FORMAL TEST
DEVELOPING
Incept
Dev
Backlog
Pre-Sprint
Planning
Analysis
Develop
Integrated Test
Test
Pre-Integrated
& Perf test
Performance
Deploy Test
DELIVERY
System
Test
Performance
Deploy Test
DEPLOY
Validation
/Beta
GA
Cycle Time
Feature Flow “Deliver Faster”
CONDITIONING
Continuous Flow
CONTINUOUS
TESTING
DEVELOPING
Reqt
Candidates
Pre-Incept
Bklog
Mgt
Incept
Analysis
Develop
Test
Preintegrated
test
Lead Time
Page 50
IT, Perf,
Deploy
ST, Perf,
Deploy
Delivery
FREQ
DEPLOY
Validation
/beta
GA

51. For more information…
Bennet Vallet, Director of Product
Development
bennet.vallet@siemens.com
Daniel S. Vacanti
daniel@corporatekanban.com

53. Thank-you!
Bennet Vallet
Daniel S. Vacanti
DO NOT REPRODUCE
© Corporate Kanban 2013