How to Scale Quality

With Kaizen

From building MVPs to addressing scale● Theodo

○ agile tech-team-for-hire, Paris & London, 200 people ○ x10 growth from 2012 to 2016

● Our strength: build & deploy MVPs in less than 10 weeks○ Small teams of excellent engineers + super strong agile discipline

● Until 2016, when the project scaled...

○ ↘ velocity and enthusiasm

○ ↗testing time, complexity and cost of integrating new devs

Today, I will share with you 3 counter-examples from 2017

A dev team produced 220 perfect user stories in a row...

...and tripled the velocity!

A dev team scaled from 4 to 12 devs over the year...

… while continuously decreasing the build time

A dev team trying to integrate 3 new developers efficiently...

was so efficient that the average velocity increased by 2x!

It all started with two things

1. Benoît went to Japan with Michael Ballé

2. Theodo UK forced us to rethink our added value

...to go fast?

Why would you need excellent engineers?

For that we have quick&dirty off-shoring

...to make a good product?

For that we have excellent design agencies

...

French CTO

UK CEO

Brits are pragmatic, they buy business results

What is the business impact of excellent engineers?=> Products that scale

So:● we had to focus on becoming expert at code that scales● and for that we looked at Toyota...

改善

My definition of Kaizen:

The cultural effort of trying to improve continuously, as a team, on an identified problem.

What is 改善?

Our current recipe (continuously improving)

● A clear target addressing a problem “0 bugs deployed by 31/10/2017”

● A team, a team leader, a coach and a sponsor

● A whiteboard

● Make sure time is spent on Kaizen

A clear indicator, updated every day / every week

A schema of the situation

The last identified defects to analyse

them

Ideas for experiment, expected results and

checks

#1: “0 bugs Kaizen” on a large project in productionWhat?● Look at every bug in production to find team improvements

Improvement examples:● Create a standard way of coding an API call cache● Make sure everyone is using a well-configured IDE with a debugger

BUT● Bugs not clearly defined: some UX issues were not considered important● Analysis was very hard: not reproducible or too old to understand● Temptation to solve and move on was too strong

Kaizen topic chosen by CTO without proper go&see...

… is not the right way to do kaizen!

#2: “0 defects Kaizen” on a long redevelopmentWhy?● Client voice: “I wish I could validate all user stories at first try”

What?● Look at every issue during the development flow to find improvements

Improvement examples● Agree to define validation steps beforehand● Improve the definition of a “perfect” user story ready for development● Refactor emails to not have duplicate code for text and html versions

Results:● 220 User Stories in a row validated at first try by the Product Owner!● x3.5 velocity over 15 weeks

#3: “Divide build by 2 Kaizen” on a 3 teams projectWhy?● Devs were fed up of wasting so much time on failed and/or long builds

What?● Inspect build failure rate & build time and experiment ideas every week

Improvement examples● Refactor tests, update testing libraries, migrate to ES6● Pre-hook to run tests locally before build, stop tests at first fail● Switch to Circle-CI 2.0● Only run tests linked to modified code

Results:● Build failure rate divided by 3● Build time divided by 2 and maintained low

#4: “Succeed 100% of sprints” (while integrating 3 new devs)

Why?● There were many late sprints already and the team was concerned of how

worse it would become with the dev team growing from 3 to 6

What?● For every ticket, plan the “how” before coding (steps of 2 to 20 minutes),

get it challenged and ask for help as soon as the plan goes wrong

Improvement examples● Script ticket start to reduce that step from 10 to 3 minutes ● Change DB creation step to reduce testing from 18 to 7 minutes ● Competency matrix of every dev to know whom to train on what

Results:● Less than 5% User Story longer than planned!● 7/7 sprint success!● Average velocity x2!

The

Future

● Not only is kaizen helping us scale quality● It is also empowering every developer to act as a tech leader...● … growing Theodoers at much faster speed than ever before

“J’ai autant appris cet après-midi qu’en deux ans chez Theodo”

Nicolas

Seeing the spectacular progress made me think of the 10x developer myth

At current speed of progress, 10x is just a few years away…… and unlike the car industry, software is not limited by the law of mechanics. What is the limit of progression?

Are we creating an army of 100x developers?

Thank you.

fabriceb@theodo.co.uk@theodo

Rendez-vous in 2025