Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scale quality with kaizen - Tech.Rocks conference


Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Scale quality with kaizen - Tech.Rocks conference

  1. 1. How to Scale Quality With Kaizen
  2. 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. 3. Today, I will share with you 3 counter-examples from 2017
  4. 4. A dev team produced 220 perfect user stories in a row... ...and tripled the velocity!
  5. 5. A dev team scaled from 4 to 12 devs over the year... … while continuously decreasing the build time
  6. 6. A dev team trying to integrate 3 new developers efficiently... was so efficient that the average velocity increased by 2x!
  7. 7. It all started with two things 1. Benoît went to Japan with Michael Ballé
  8. 8. 2. Theodo UK forced us to rethink our added value
  9. 9. go fast? Why would you need excellent engineers? For that we have quick&dirty off-shoring make a good product? For that we have excellent design agencies ... French CTO UK CEO
  10. 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...
  11. 11. 改善
  12. 12. My definition of Kaizen: The cultural effort of trying to improve continuously, as a team, on an identified problem. What is 改善?
  13. 13. 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
  14. 14. 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
  15. 15. #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
  16. 16. Kaizen topic chosen by CTO without proper go&see...
  17. 17. … is not the right way to do kaizen!
  18. 18. #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
  19. 19. Results: ● 220 User Stories in a row validated at first try by the Product Owner! ● x3.5 velocity over 15 weeks
  20. 20. #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
  21. 21. Results: ● Build failure rate divided by 3 ● Build time divided by 2 and maintained low
  22. 22. #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
  23. 23. Results: ● Less than 5% User Story longer than planned! ● 7/7 sprint success! ● Average velocity x2!
  24. 24. The Future
  25. 25. ● 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
  26. 26. “J’ai autant appris cet après-midi qu’en deux ans chez Theodo” Nicolas
  27. 27. Seeing the spectacular progress made me think of the 10x developer myth
  28. 28. 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?
  29. 29. Are we creating an army of 100x developers?
  30. 30. Thank you. @theodo
  31. 31. Rendez-vous in 2025