This Agile transformation is going through three distinct phases. First is to Understand and stabilize the teams, then improve design, implementation and delivery to be "fir-for-purpose" and finally the continuous and never ending phase of making the organization entirely "fit-for-purpose" from a business perspective. We will present the results from the first phase including their Discovery/Upstream Kanban implementation, their downstream Kanban and how they Support the Agile transformation via enabling cross-team knowledge sharing and alignment on Agile practices between teams

1. Kanban
@
Bosch Software Innovations
Bulgaria
2019

2. Dimitar Bakardzhiev is an expert in managing
successful and cost-effective software
development. With his blend of technical,
managerial and operational expertise, he
effectively combines the theory and practice of
Agile and the Kanban Method to deliver business
results.
As an Kanban trainer, coach and avid, expert
Kanban practitioner and Brickell Key Award 2015
Finalist, Dimitar puts lean principles to work every
day when managing complex software projects.
@dimiterbak

3. IT IS NOT NECESSARY TO CHANGE. SURVIVAL IS NOT MANDATORY.
W. Edwards Deming

4. IMPROVEMENT ALWAYS MEANS CHANGE

5. THE KANBAN MATURITY MODEL MAPS TYPICAL KANBAN PRACTICES
AS WELL AS CULTURAL VALUES AGAINST 7 ORGANIZATIONAL
MATURITY LEVELS.

11. Some facts
• The organization has a headcount of 190+ in Sofia.
• I worked with EGs and MPRM - two of the product
development units with headcount of 70+ people comprising
the product engineering teams responsible for the
development of several components for the Bosch IoT Platform
including edge software and cloud services
• Most of the results presented here come from the EGS unit.

12. Agile Transformation Roadmap
Stage 1: Stable Stage 3: Learning and AdaptingStage 2: Fit-for-purpose
Understand and stabilize the
teams
Improve design, implementation and
delivery to be ”fit-for-purpose” from
a customer perspective
Make the organization entirely “fit-
for-purpose” from a business
perspective.
Acceptance Criteria: Acceptance Criteria: Acceptance Criteria:
• There is an agreed and understood
basic definition of processes,
policies and decision frameworks
• These are followed consistently
• Desired outcomes are not yet
achieved consistently
• Optimizing for efficiency and improved
economic outcomes
• A strong culture of continuous
improvement has emerged
• Quantitatively managed
• Robustness against unforeseen events
and exceptional circumstances
• Teams performance is predictable
• Customer expectations are being met
• A strong sense of unity and purpose
along the value stream
• Desired outcomes are achieved
consistently

13. Enterprise Agile Transformation Roadmap
Stage 1: Stable Stage 3: Learning and AdaptingStage 2: Fit-for-purpose
Understand and stabilize the
teams
Improve design, implementation and
delivery to be ”fit-for-purpose” from
a customer perspective
Make the organization entirely “fit-
for-purpose” from a business
perspective.
Acceptance Criteria: Acceptance Criteria: Acceptance Criteria:
• There is an agreed and understood
basic definition of processes,
policies and decision frameworks
• These are followed consistently
• Desired outcomes are not yet
achieved consistently
• Optimizing for efficiency and improved
economic outcomes
• A strong culture of continuous
improvement has emerged
• Quantitatively managed
• Robustness against unforeseen events
and exceptional circumstances
• Teams performance is predictable
• Customer expectations are being met
• A strong sense of unity and purpose
along the value stream
• Desired outcomes are achieved
consistently
ML 3ML 2 ML 4

14. TRAININGS

15. Start Sep 19th 2018

16. Trainings (tailored)
Name
Leading Agile Change (managers) 1 day
Introduction to Agile (everybody) 1 day
Kanban Team Kickstart workshop 2 days
Scaling Kanban (managers) 1 day
Upstream Kanban (managers) 3 hours

17. TEAM KANBAN BOARDS
Observed practices

18. Kanban gives teams the freedom to...
• Think for themselves
• Be different from the team across the floor, on the next floor,
in the next building and at another firm
• Deviate from the textbook – as long as they are adhering to the
principles Kanban.

19. A KANBAN BOARD SERVING THE NEEDS OF THE
TEAM [VZ 1.2]
VZ LW XP

20. A kanban board
serving the needs of
the team [VZ 1.2]

21. A kanban board
serving the needs of
the team [VZ 1.2]

22. A kanban board
serving the needs of
the team [VZ 1.2]

23. A kanban board
serving the needs of
the team [VZ 1.2]

24. A kanban board
serving the needs of
the team [VZ 1.2]

25. VISUALIZE SEQUENTIAL ACTIVITIES [VZ 2.9]
VZ LW XP

26. Visualize sequential
activities [VZ 2.9]

27. Visualize sequential
activities [VZ 2.9]

28. Visualize sequential
activities [VZ 2.9]

29. Visualize sequential
activities [VZ 2.9]

30. Visualize sequential
activities [VZ 2.9]

31. THE BOARD IS TWO-TIERED [VZ 3.4}
VZ LW XP

32. The board is two-
tiered [VZ 3.4}

33. The board is two-
tiered [VZ 3.4}

34. The board is two-
tiered [VZ 3.4}

35. VISUALIZE WORK TYPES BY MEANS OF CARD
COLORS OR BOARD ROWS[VZ 2.2]
VZ LW XP

36. Visualize work types
by means of card
colors or board
rows[VZ 2.2].

37. Visualize work types
by means of card
colors or board
rows[VZ 2.2].

38. Visualize work types
by means of board
rows[VZ 2.2].

39. Visualize work types
by means of board
rows[VZ 2.2].

40. Pink color to visualise
“unplanned” work [VZ
2.2]

41. VISUALIZE CLASS OF SERVICE USING TICKET
COLORS [VZ 3.17]
VZ LW XP

42. visualize class of
service using ticket
colors [VZ 3.17]

43. visualize class of
service using ticket
colors [VZ 3.17]

44. Visualize class of
service using ticket
colors [VZ 3.17]

45. Fixed Date
Classes of Service

46. visualize class of
service using ticket
colors [VZ 3.17]

47. USE A SEPARATE FLAG FOR VISUALISING THE
BLOCKED ITEMS [VZ 2.3]
VZ LW XP

48. Use a separate flag
for visualizing the
blocked items [VZ
2.3]

49. Visualize blocked
items using separate
small sticky [VZ 2.3]

50. Blockers

51. Visualize blocked
items using separate
small sticky [VZ 2.3]

52. Visualize blocked
items using separate
small sticky [VZ 2.3]

54. Blockers clustering

55. Visualize blocked
items using separate
small sticky [VZ 2.3]

56. VISUALIZE WORK ITEM AGING [VZ 3.13]
VZ LW XP

57. Ageing work items are
visualised [VZ 3.13]

58. Ageing work items are
visualised [VZ 3.13]

61. Ageing work items are
visualised [VZ 3.13]

62. Parked
Waiting for review

63. DEFECTS EXPLICITLY VISUALIZED. [VZ 2.10, XP
2.4]
VZ LW XP

64. Defects explicitly
visualized. [VZ 2.10,
XP 2.4].

65. Defects explicitly
visualized. [VZ 2.10,
XP 2.4].

66. Defects explicitly
visualized. [VZ 2.10,
XP 2.4].

67. VISUALIZE BASIC POLICIES [VZ 2.6]
VZ LW XP

68. Visualize basic policies
[VZ 2.6]

69. Visualize basic
policies [VZ 2.6]

70. Visualize basic policies
[VZ 2.6]

71. PULL SIGNALS ARE VISUALISED USING VIRTUAL
KANBANS [VZ 3.10]
VZ LW XP

72. Pull signals are
visualised using
virtual kanbans [VZ
3.10]

73. Pull signals are
visualised using
virtual kanbans [VZ
3.10]

74. Pull signals are
visualised using
virtual kanbans [VZ
3.10]

75. Pull signals are
visualised using
virtual kanbans [VZ
3.10]

76. THE WIP LIMITS REPRESENTED IN A VISUAL WAY BY A
NUMBER AT THE TOP OF THE COLUMNS. [VZ 2.6, LW
1.2, LW 2.1, XP0.1, XP 1.1]
VZ LW XP

77. The WIP limits
represented in a
visual way by a
number at the top of
the columns. [VZ
2.6, LW 1.2, LW 2.1,
XP0.1, XP 1.1]

78. The WIP limits
represented in a
visual way by a
number at the top of
the columns. [VZ
2.6, LW 1.2, LW 2.1,
XP0.1, XP 1.1]

79. CONWIP WITH AN EMERGENT WORKFLOW DELIVERY
KANBAN BOARD [VZ 2.11]
VZ LW XP

80. CONWIP with an
emergent workflow
delivery kanban
board [VZ 2.11]

81. CONWIP with an
emergent workflow
delivery kanban
board [VZ 2.11].

82. CONWIP with an
emergent workflow
delivery kanban
board [VZ 2.11].

83. VISUALIZE ABORTED WORK [VZ 3.16]
VZ LW XP

84. Aborted work

85. DAILY KANBAN MEETINGS IN FRONT OF THE
KANBAN BOARD [FL 1.2]
MF FL

86. Kanban Meeting Agenda
1. Ask if anybody is blocked but just forgot to show it on the board?
2. Walk the board right to left and discuss all blocked work. What the team
could do to unblock it?
3. Walk the board right to left and identify all work that is older than say 5 days
and ask why it is aging? Can we do something about that?
4. Ask are there any risks that might affect the flow of work? Risks could be: a
customer goes on vacation for two weeks and the work will be blocked; the
technology we use is unstable and we feel it will cause us problems...etc.
5. Ask what will be pulled next into Ready to Start from Backlog. Deciding what
to be done next should be based on the priorities the customers have but also
on what the team thinks is good for the overall flow of work.

87. Retrospectives and Service review
Are the
customers
happy?
Is the team
happy?
Service reviewRetrospective

88. 3.3 CONDUCT SERVICE CAPABILITY REVIEW
MF FL

92. CONDUCT TEAM RETROSPECTIVE [FL 2.2]
MF FL

96. PRODUCT (PORTFOLIO) BOARD

97. Problem
• EGS had four development teams all working on the same
product. Of course there are dependencies between the
teams.
• The organization needed to manage the interactions between
their four teams – make sure that the right team works on the
right things at the right time.
• The opposite is to optimize the parts of the system i.e. the
teams but not optimize the system itself i.e. the organization .

98. Why there are so many dependencies?
• Multiple teams working on features for the same product
• Product components not completely independent
• Shared services (architects and technical writers.)

99. Solution
• Managing interactions between teams i.e. things not visualized
on the team boards – integration, acceptance, release…
• End-to-end management of the value chain from customer
perspective
• Manage dependencies by making them visible, get the right
people in front of the board and set up feedback loops so that
people talk about these dependencies.
• Limit WIP where we want to achieve the benefits!

100. How to manage inter-product dependencies?
• Establish operational portfolio management
• Common view on all projects
• Dependencies between projects are handled as INTERNAL
dependencies
• External dependencies are only OUTSIDE of product
development
• WIP limits on epics, features

101. The product board
• Visualize the work at the product level.
• Allow for measuring lead time for the initiatives and features.
• Limit WIP at the point where they wanted to achieve benefits i.e. at
the features level
• Show the difference between local and global optimization when
compared with the team boards.
• First evolutionary step to the end-to-end management of the value
creation chain. The upstream, integration and release details were
to be added later when the org matures for that.

102. An organization-wide level Kanban
Team 1 board
Team 2 board Team 3 board Team 4 board
Release team
board
Product board

103. A kanban board
serving the needs of
the team [VZ 1.2]

104. Visualize class of
service using ticket
colors [VZ 3.17]

105. Visualize work types
by means of
different colors [VZ
2.2].

106. Visualize blocked
items using separate
small sticky [VZ 2.3]

107. Visualize Feature percentage complete on
a portfolio kanban board [VZ 2.13 ]

108. Releases as swimlanes

109. Risks description, action
due date, owner. Use
ticket decorators to
indicate risks [VZ 4.2 ]

110. Risk register

111. Visualize basic policies
[VZ 2.6]

112. Daily Kanban meeting of the management team in
front of the portfolio board

113. THE MOST INFLUENTIAL TRAINING FOR THE MANAGEMENT TEAM?
UPSTREAM KANBAN!

114. О
C
A
C A О
Client
context
Capability context
Obvious
Analysis
Complex
AnalysisComplex
Analysis
Complex
Complex
Complex
Complexity profile (CP)
O –очевидно
А – анализ
С - синтез

115. O
C
A
C A O
Obvious
Analysis
Complex
All possible moves

116. Options funnelO
C
A
C
A
O
Obvious
Analysis
ComplexSynthesis Analysis

117. End-to-end flow
Analysis
MQ
Milestone
backlog Development
J
K
Testing
P
Commitment point
Synthesis
Product
Options
Discarded
options
X Y T
UAT
?
To be
analyzed
when
developed
Analyzed
before commit
O I
R N
Complex
never to be
committed!
>10>20 ∞∞
?
?
?
?
C
E
A
F
B
D
C A O
Obvious
>2 & <5
C
A
O
G
<30 <3 <3
B
L
HU
V W
S

118. A kanban board
serving the needs of
the team [VZ 1.2]

119. The WIP limits
represented in a
visual way by a
number at the top of
the columns. [VZ
2.6, LW 1.2, LW 2.1,
XP0.1, XP 1.1]

120. Pull signals are
visualised using
virtual kanbans [VZ
3.10]

121. Visualize blocked
items using separate
small sticky [VZ 2.3]

124. Visualize discarded options using a
bin on an upstream/ discovery
kanban board [VZ 3.8 ]

125. FEEDBACK LOOPS (FL)
Observed practices

126. Strategy
Review
Risk
Review
Monthly
Service
Delivery
Review
Bi-WeeklyQuarterly
Kanban
Meeting
Daily
Operations
Review
Monthly
Replenishment &
Commitment
Meeting
Weekly
Delivery
Planning
Meeting
Per delivery cadence
change change
change
change
change
change
change change
change
info
info
info
info
info
info
info
info
info
change info
Kanban Cadences

127. Strategy
Review
Risk
Review
Monthly
Service
Delivery
Review
Bi-WeeklyQuarterly
Kanban
Meeting
Daily
Operations
Review
Monthly
Replenishment &
Commitment
Meeting
Weekly
Delivery
Planning
Meeting
Per delivery cadence
change change
change
change
change
change
change change
change
info
info
info
info
info
info
info
info
info
change info
Kanban Cadences

128. DAILY KANBAN MEETINGS IN FRONT OF THE
KANBAN BOARD [FL 1.2]
Cadences

129. Strategy team Kanban Meeting Agenda
1. Is anyone blocked but just forgot to show it on the board?
2. What can we do to unblock the flagged epics?
3. Are there any risks that might affect the flow of work? What
can we do about them?
4. What can we pull next for Analysis or Development?
5. Are WIP limits met? If not, why and what can we do about it?
6. Are there epics that are aging? Why are these epics aging?
What can we do about it?

130. 3.3 CONDUCT SERVICE CAPABILITY REVIEW
MF FL

131. Retrospectives and Service review
Are the
customers
happy?
Is the team
happy?
Service reviewRetrospective

132. SERVICE DELIVERY REVIEW [FL 3.5]
MF FL

133. RELEASE MANAGEMENT

134. A kanban board
serving the needs of
the team [VZ 1.2]

135. Visualize sequential
activities [VZ 2.9]

136. Each team’s work has
a color [VZ 2.2].

137. Visualize basic
policies [VZ 2.6]

138. Visualize pull criteria
[VZ 3.1]

139. Mintain a Risk
register [VZ 4.2 ]

140. Ageing work items are
visualised [VZ 3.13]
Use ticket decorators to
indicate risks [VZ 4.2]

141. Visualize aborted
work [VZ 3.16]

142. Important dates

143. Parking lot

144. DAILY KANBAN MEETINGS IN FRONT OF THE
KANBAN BOARD [FL 1.2]
Cadences

145. Release team Kanban Meeting Agenda
1. Is anybody blocked but just forgot to show it on the board?
2. What can we do to unblock the blocked work?
3. Is there delays from the release schedule? Why the work is
delaying? Can we do something about that?
4. Are there any risks that might affect the release schedule?
Can we do something to avoid them?

146. Change Management Principles
1. Start with what you do now
1. Understanding current processes, as actually practiced
2. Respecting existing roles, responsibilities & job titles
2. Gain agreement to pursue improvement through
evolutionary change
3. Encourage acts of leadership at all levels

147. Evolution of the functional organization
• Five months after the start of the Agile Transformation based
on the trainings and their improved understanding of how the
organization works the management team refined the
functional organization.

148. Bosch Software Innovations GmbH | INST/MKC | 17/08/2018
Functional organization

149. Bosch Software Innovations GmbH | INST/MKC | 17/08/2018
Functional organization – leading principles
Working groups and virtual teams
• Alignment between teams
• Knowledge sharing between teams
• Building expertise across teams
Empowered cross-functional teams with clear
purpose and responsibilities
• Built-in expertise to make trust-worthy
commitments and deliver end-to-end
• Using decision making framework
• Enabling leadership
• Enabling org-wide collaboration
• Process ownership

150. Bosch Software Innovations GmbH | INST/MKC | 17/08/2018
Functional organization – Continuous Discovery
Purpose:
Drive the strategic development of the product
Staffing: Team leads of each team
Responsibilities:
• Continuous synthesis and analysis of strategically
important product features and enablers
• Continuous collaboration with stakeholders and ensure
customer satisfaction
• Visibility over strategy and priorities
• Product roadmap and release schedule
• Planning and commitment policies

151. Bosch Software Innovations GmbH | INST/MKC | 17/08/2018
Functional organization – Continuous Delivery 1/2
Purpose:
Deliver committed features, improvements and
maintenance end-to-end, on time and with required
quality. Contribute to the continuous discovery.
Responsibilities:
• Planning, design, implementation, test and
documentation of product features, improvements and
maintenance following the established planning and
commitment policies
• Generation of ideas, participation in synthesis and
analysis via research and PoC
• Cross-team collaboration and support
• Visibility over team commitments
• Development policies

152. Bosch Software Innovations GmbH | INST/MKC | 17/08/2018
Functional organization – Continuous Delivery 2/2
Purpose:
Facilitate and coordinate the planning and
execution of product releases and continuously
improve release policies and guidelines enabling
faster delivery with better quality.
Responsibilities:
• Release planning facilitation
• Development infrastructure configuration –
testing environments, infrastructure etc.
• Release execution coordination ensuring
release process and policies are followed
• Collaboration with development teams and
infrastructure working group
• Release policies

153. Bosch Software Innovations GmbH | INST/MKC | 17/08/2018
Functional organization – Continuous Improvement 1/2
Purpose: Support the Agile transformation
via enabling cross-team knowledge sharing
and alignment on Agile practices
Staffing: Participants from each of the
development teams.
Purpose: Maintain and continuously
improve the development infrastructure
via building expertise and enabling cross-
team knowledge sharing.
Staffing: Participants from each of the
development teams.

154. Bosch Software Innovations GmbH | INST/MKC | 17/08/2018
Functional organization – Continuous Improvement 2/2
Purpose: Ensure synchronization, knowledge
sharing and alignment on documentation
policies, guidelines and tools, ensure
consistency with marketing materials.
Staffing: Tech. writers from each of the
development teams.
Purpose: Ensure synchronization,
knowledge sharing and alignment on
software quality assurance practices,
guidelines and tools.
Staffing: QAs from each of the
development teams.
Purpose: Ensure coherent product
architecture via enabling cross-team
synchronization, knowledge sharing and
alignment on architecture policies,
guidelines and tools.
Staffing: Architects from each of the
development teams.

155. Training & Coaching Costs

156. RESULTS: ALL IS GOOD! NO?!?!

157. Enterprise Agile Transformation Roadmap
Stage 1: Stable Stage 3: Learning and AdaptingStage 2: Fit-for-purpose
Understand and stabilize the
teams
Improve design, implementation and
delivery to be ”fit-for-purpose” from
a customer perspective
Make the organization entirely “fit-
for-purpose” from a business
perspective.
Acceptance Criteria: Acceptance Criteria: Acceptance Criteria:
• There is an agreed and understood
basic definition of processes,
policies and decision frameworks
• These are followed consistently
• Desired outcomes are not yet
achieved consistently
• Optimizing for efficiency and improved
economic outcomes
• A strong culture of continuous
improvement has emerged
• Quantitatively managed
• Robustness against unforeseen events
and exceptional circumstances
• Teams performance is predictable
• Customer expectations are being met
• A strong sense of unity and purpose
along the value stream
• Desired outcomes are achieved
consistently
ML 3ML 2 ML 4
At present the Agile Transformation is somewhere here

158. Service delivery principles
Your organization is a network of interdependent services with
policies that determine its behavior.
Therefore:
1. Focus on the customer. Understand and focus on your customers'
needs and expectations.
2. Manage the work;
let workers self-organize around it.
3. Evolve policies to improve customer and business outcomes.

160. THE ORG ACHIEVED ML02.

161. THE ORG IS STILL INWARD FOCUSED.

162. “WHY WE DO WHAT WE DO?” IS MISSING!

163. Objective obstacles
• The acquisition by Bosch in 2015 & reorg in 2016
• The context – middleware product
• The effort needed – the transformation by itself is quite an
effort on top of the software development work

164. WITHOUT THE CUSTOMER FOCUS THEY IS NO ENOUGH
STRESS TO MOVE THE ORGANIZATION FORWARD.

165. THANK YOU!