MVPs at full speed with a little team: OK. But once the project scales, how do you address the inevitable slowdown due to exponential complexity? Kaizen is Toyota's scalable solution and our results are impressive.

1. How to Scale Quality
With Kaizen

2. 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

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

4. A dev team produced 220 perfect user stories in a row...
...and tripled the velocity!

5. A dev team scaled from 4 to 12 devs over the year...
… while continuously decreasing the build time

6. A dev team trying to integrate 3 new developers efficiently...
was so efficient that the average velocity increased by 2x!

7. It all started with two things
1. Benoît went to Japan with Michael Ballé

8. 2. Theodo UK forced us to rethink our added value

9. ...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

10. 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...

12. 改善

13. My definition of Kaizen:
The cultural effort of trying to improve continuously, as a
team, on an identified problem.
What is 改善?

15. 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

16. 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

17. #1: “0 bugs Kaizen” on a large project in production
What?
● 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

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

19. … is not the right way to do kaizen!

20. #2: “0 defects Kaizen” on a long redevelopment
Why?
● 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

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

22. #3: “Divide build by 2 Kaizen” on a 3 teams project
Why?
● 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

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

24. #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

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

26. The
Future

27. ● 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

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

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

30. 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?

31. Are we creating an army of 100x developers?

32. Thank you.
fabriceb@theodo.co.uk
@theodo

33. Rendez-vous in 2025