Scale quality with kaizen - Tech.Rocks conference
Download as PPTX, PDF1 like986 views
Theodo emphasizes scaling quality through Kaizen, achieving significant improvements in development processes by continuously addressing specific team challenges. Examples include reducing build times, increasing user story validation rates, and integrating new developers successfully, resulting in enhanced project velocity and efficiency. The approach not only improves product quality but also empowers developers, suggesting a potential future of exponentially increased productivity.
Scale quality with kaizen - Tech.Rocks conference
- 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?