KEA20 - Dimitar Bakardzhiev - Kanban@Bosch

KEA20 - Dimitar Bakardzhiev - Kanban@Bosch
Kanban @ Bosch Software Innovations Bulgaria 2019
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
IT IS NOT NECESSARY TO CHANGE. SURVIVAL IS NOT MANDATORY. W. Edwards Deming
IMPROVEMENT ALWAYS MEANS CHANGE
THE KANBAN MATURITY MODEL MAPS TYPICAL KANBAN PRACTICES AS WELL AS CULTURAL VALUES AGAINST 7 ORGANIZATIONAL MATURITY LEVELS.
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.
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
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
TRAININGS
Start Sep 19th 2018
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
TEAM KANBAN BOARDS Observed practices
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.
A KANBAN BOARD SERVING THE NEEDS OF THE TEAM [VZ 1.2] VZ LW XP
A kanban board serving the needs of the team [VZ 1.2]
VISUALIZE SEQUENTIAL ACTIVITIES [VZ 2.9] VZ LW XP
Visualize sequential activities [VZ 2.9]
THE BOARD IS TWO-TIERED [VZ 3.4} VZ LW XP
The board is two- tiered [VZ 3.4}
VISUALIZE WORK TYPES BY MEANS OF CARD COLORS OR BOARD ROWS[VZ 2.2] VZ LW XP
Visualize work types by means of card colors or board rows[VZ 2.2].
Visualize work types by means of card colors or board rows[VZ 2.2].
Visualize work types by means of board rows[VZ 2.2].
Visualize work types by means of board rows[VZ 2.2].
Pink color to visualise “unplanned” work [VZ 2.2]
VISUALIZE CLASS OF SERVICE USING TICKET COLORS [VZ 3.17] VZ LW XP
visualize class of service using ticket colors [VZ 3.17]
Visualize class of service using ticket colors [VZ 3.17]
Fixed Date Classes of Service
USE A SEPARATE FLAG FOR VISUALISING THE BLOCKED ITEMS [VZ 2.3] VZ LW XP
Use a separate flag for visualizing the blocked items [VZ 2.3]
Visualize blocked items using separate small sticky [VZ 2.3]
Blockers
Blockers clustering
VISUALIZE WORK ITEM AGING [VZ 3.13] VZ LW XP
Ageing work items are visualised [VZ 3.13]
Parked Waiting for review
DEFECTS EXPLICITLY VISUALIZED. [VZ 2.10, XP 2.4] VZ LW XP
Defects explicitly visualized. [VZ 2.10, XP 2.4].
VISUALIZE BASIC POLICIES [VZ 2.6] VZ LW XP
Visualize basic policies [VZ 2.6]
PULL SIGNALS ARE VISUALISED USING VIRTUAL KANBANS [VZ 3.10] VZ LW XP
Pull signals are visualised using virtual kanbans [VZ 3.10]
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
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]
CONWIP WITH AN EMERGENT WORKFLOW DELIVERY KANBAN BOARD [VZ 2.11] VZ LW XP
CONWIP with an emergent workflow delivery kanban board [VZ 2.11]
CONWIP with an emergent workflow delivery kanban board [VZ 2.11].
CONWIP with an emergent workflow delivery kanban board [VZ 2.11].
VISUALIZE ABORTED WORK [VZ 3.16] VZ LW XP
Aborted work
DAILY KANBAN MEETINGS IN FRONT OF THE KANBAN BOARD [FL 1.2] MF FL
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.
Retrospectives and Service review Are the customers happy? Is the team happy? Service reviewRetrospective
3.3 CONDUCT SERVICE CAPABILITY REVIEW MF FL
CONDUCT TEAM RETROSPECTIVE [FL 2.2] MF FL
PRODUCT (PORTFOLIO) BOARD
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 .
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.)
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!
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
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.
An organization-wide level Kanban Team 1 board Team 2 board Team 3 board Team 4 board Release team board Product board
Visualize class of service using ticket colors [VZ 3.17]
Visualize work types by means of different colors [VZ 2.2].
Visualize Feature percentage complete on a portfolio kanban board [VZ 2.13 ]
Releases as swimlanes
Risks description, action due date, owner. Use ticket decorators to indicate risks [VZ 4.2 ]
Risk register
Daily Kanban meeting of the management team in front of the portfolio board
THE MOST INFLUENTIAL TRAINING FOR THE MANAGEMENT TEAM? UPSTREAM KANBAN!
О C A C A О Client context Capability context Obvious Analysis Complex AnalysisComplex Analysis Complex Complex Complex Complexity profile (CP) O –очевидно А – анализ С - синтез
O C A C A O Obvious Analysis Complex All possible moves
Options funnelO C A C A O Obvious Analysis ComplexSynthesis Analysis
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
Visualize discarded options using a bin on an upstream/ discovery kanban board [VZ 3.8 ]
FEEDBACK LOOPS (FL) Observed practices
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
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
DAILY KANBAN MEETINGS IN FRONT OF THE KANBAN BOARD [FL 1.2] Cadences
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?
3.3 CONDUCT SERVICE CAPABILITY REVIEW MF FL
Retrospectives and Service review Are the customers happy? Is the team happy? Service reviewRetrospective
SERVICE DELIVERY REVIEW [FL 3.5] MF FL
RELEASE MANAGEMENT
Each team’s work has a color [VZ 2.2].
Visualize pull criteria [VZ 3.1]
Mintain a Risk register [VZ 4.2 ]
Ageing work items are visualised [VZ 3.13] Use ticket decorators to indicate risks [VZ 4.2]
Visualize aborted work [VZ 3.16]
Important dates
Parking lot
DAILY KANBAN MEETINGS IN FRONT OF THE KANBAN BOARD [FL 1.2] Cadences
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?
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
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.
Bosch Software Innovations GmbH | INST/MKC | 17/08/2018 Functional organization
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
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
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
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
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.
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.
Training & Coaching Costs
RESULTS: ALL IS GOOD! NO?!?!
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
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.
THE ORG ACHIEVED ML02.
THE ORG IS STILL INWARD FOCUSED.
“WHY WE DO WHAT WE DO?” IS MISSING!
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
WITHOUT THE CUSTOMER FOCUS THEY IS NO ENOUGH STRESS TO MOVE THE ORGANIZATION FORWARD.
THANK YOU!

KEA20 - Dimitar Bakardzhiev - Kanban@Bosch

Check these out next

KEA20 - Dimitar Bakardzhiev - Kanban@Bosch

Recommended

More Related Content

Similar to KEA20 - Dimitar Bakardzhiev - Kanban@Bosch(20)

More from RealResult(16)

Recently uploaded(20)

KEA20 - Dimitar Bakardzhiev - Kanban@Bosch