Our six month journey from Scrum to Kanban. Hugh O Donoghue - October 2017

Transcription

1 Our six month journey from Scrum to Kanban Hugh O Donoghue - October 2017

2 About Ding Ding is the world s largest international mobile top-up network Founded in 2007 Employees in 7 locations worldwide Development, QA, Product Management and Ops Dublin 7 teams Bucharest 1 team

3 The Scrum Focused on keeping everyone busy (100%+) Delivery of work to production was unpredictable We struggled with maintaining quality Priorities weren t clear Teams were told not empowered Sprints where crammed (everyone guilty of this) QA under huge pressure Lack of common purpose between tech, product and business. Making progress but generally pretty frustrated What to do?

4 Initial Assessment 2 consultants on the ground for 2 days to identify pain points 1:1 interviews with key staff members Business agility questionnaire Company-wide survey Small workshop groups

5 Problems observed Delivery is unreliable and hard to predict Work is poorly understood and not visualized Delivery bottlenecks and friction are caused by functional silos Business can not make informed product development decisions because it has no metrics Customer focus is hard because of lots of noise & competing priorities from business areas Daily Scrum Hell 1 Scrum Master for several teams We need a Plan

6 The Plan Train and coach 8 teams in 3 x 12 week waves 3 Consultants on site for > 200 days combined over 6 months Bootstrap teams and then ad hoc coaching Kick-off with 3 days of training (Business Agility, TKP, Agendashift) Supplement with additional training for key staff (KMP1, KMP2, Collaboration Frameworks, Accelerated Learning & Instructional Design) Business Agility Team (DingBATs) set up. Senior and middle management as key advocates Funding from Enterprise Ireland Create a sustainable, learning organization via Kanban

7 One Team s Journey

8 Start with what you do now Short workshop to design board and tickets The teams first board is proto-kanban Basic ticket design / visualization Workflow is the same Still has a sense of 2 weekly iterations Duration (2 weeks)

9 Limit WIP and Manage flow WIP limits emerge Evolution of process and improved flow Removed sprints Team pulling coaching support as they need it Twice weekly Kanban Retros Where have all the bugs gone? Still Very little movement of people between lanes Old habits emerged when under pressure Duration (4 weeks)

10 Make Policies explicit Electronic board Explicit Pull Policy Optimise flow (people moving to where work is) Flow has evolved to included Analysis phase Entry commitment point moved New Classes of Service (Automation) Duration (4 weeks)

11 Improve collaboratively Gathering metrics through online board Using metrics to drive change (focus on quality) Moved back to fortnightly retros Kanban Cadences (risk review, service delivery review, ops review) Improvement experiments Duration (2 weeks)

12 Hoards of Boards

13 Supporting Activities and Tools

14 Supporting Activities getkanban Game Team Health Check Lightning Talks Kanban Rough Guide Executive Sessions Lunch and Learn Featureban Lean Coffee Business Agility Cinema Meetups These activities were key in spreading Kanban understanding outside ProdTech

15 Rough Guide

16 Some Outcomes

17 Useful Metrics we now have some Throughput Flow Efficient System WIPs Average Cycle time Time lost to Blocking Story to Bug ratio Cycle Time distribution Tech Task, Story and Bug mix

18 Productivity Throughput Quality Increased frequency of releases Less rollbacks Flow efficiency has increased by 20% YoY 25% decrease in Bugs found 25%-50% decrease in regression time More time for QA automation, 85%+ coverage for main products

19 Product End to End Board An overall view of Product requests Optimise delivery across the company Improved collaboration between teams Helps a lot in managing the funnel of work coming through to technology Learned that most of the wait time to market is outside development Expectation setting for rest of business

20 Lessons Learned Set expectations that the learning process is unique and individual, it is exploratory Not all teams learn at the same speed, so set that expectation People need to feel safe to learn and experiment Pay greater attention to remote teams for longer Highly motivated individuals really make a difference C-level and middle management support works wonders

21 If you re interested in knowing more