Our six month journey from Scrum to KanbanHugh O’Donoghue - October 2017

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

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?

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

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

WeneedaPlan

• 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

The Plan

One Team’s Journey

• 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)

Start with what you do now

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)

• 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)

Make Policies explicit

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)

HoardsofBoards

Supporting Activities and Tools

• 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

Supporting Activities

Rough Guide

Some Outcomes

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

Productivity

• Increasedfrequencyofreleases• Lessrollbacks• Flowefficiencyhasincreasedby20%

Throughput Quality

• YoY25%decreaseinBugsfound• 25%-50%decreaseinregressiontime• MoretimeforQAautomation,85%+

coverageformainproducts

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

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

If you’re interested in knowing more email

kanban@ding.com