Let's reset Agile at Scale — Lean&Agile day Michelin 2022

Transcript

2. Agile software development has its roots in the lean manufacturing paradigm Toyota Production System 
 (Just In Time)
3. Defects ➡ Bugs Overproduction ➡ Extra features Transportation ➡ Task Switching Waiting ➡ Delays Inventory ➡ Partially done Work Motion ➡ Handoffs (Over) Processing ➡ Unneeded processes Agile software development has its roots in the lean manufacturing paradigm The seven wastes in Lean Software Development
4. 1. Just In Time 2. Jidoka 3. Poka yoke 4. Kanban 5. Kaizen Agile software development has its roots in the lean manufacturing paradigm
5. Agile software development has its roots in the lean manufacturing paradigm While lean manufacturing is primarily focused around optimization Modern Agile practices will add a systematic innovation process
6. Software is eating the world More and more major businesses and industries are being run on software — from movies to agriculture to national defense. Over the next 10 years, I expect many more industries to be disrupted by software, with new world-beating Silicon Valley companies doing the disruption in more cases than not.
7. Software is eating the world
8. Software is eating the world
9. Software is eating the world And Space X is the most valuable private company with a valuation of $125 billions
10. We have gone full circle Manufacturing Software Engineering Lean Agile
11. www.lilobase.me Let’s reset Agile (at scale) @lilobase #Lean&AgileDay Arnaud LEMAIRE
12. 1. The Two Pizzas Team model (skunk works team) 2. Strong alignement with explicit ownership 3. Tighten your feedback loops
13. A fictive project Compliance Operation Development Test Marketing Engineering & Design Functional 
 Analysis Program Manager
14. A fictive project Engineering & Design Functional 
 Analysis Development
15. Cross functional team dedicated to a project
16. Cross team direct communication
17. Introducing the Skunk Work team model The term originated in the 40s for the Lockheed’s Advanced Development Projects Division. Skunk Works was run using « Kelly's 14 Rules ».
18. Kelly’s 14 rules (extract) The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to normal). A very simple drawing and drawing release system with great fl exibility for making changes must be provided. There must be a minimum number of reports required, but important work must be recorded thoroughly. The inspection system, meets the intent of existing military requirements and push for more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection. Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects. There must be mutual trust between the project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.
19. Popularized by Amazon through their Two pizzas team « Two-Pizza Teams work like semi-independent entrepreneurial hothouses. Insulated from the greater organisation’s bureaucracy » - John Rossmann
20. Diseconomy of scale in knowledge works Comstock 2011 « We conclude that a 3-7 person team has the best performance » Putman 1997 « Best in Class projects used smaller teams (over 4 times smaller, on average) than the worst performers. » Armell 2006
21. - Not a signi fi cant management overhead - Minimize communication overhead - Minimize inter-locking phenomenons - Minimize over- engineering Why smaller teams perform better ?
22. But beware, your team size may be bigger than you think Team A Team B
23. But beware, your team size may be bigger than you think your true (but hidden) team size The size of your team is the number of people who need to synchronize their work.
24. Project Manager / 
 Product Manager / Product Owner Don’t try to scale Agile Descale your Organization
25. Smalls, autonomous and cross functional teams First ingredient
26. 1. The Two Pizzas Team model (skunk works team) 2. Strong alignement with explicit ownership 3. Tighten your feedback loops
27. Autonomy is not a given This is where a lot of companies react 
 by increasing procedures and controls
28. It is all about alignement Autonomy Alignement Most organizations see them as 
 both ends of the spectrum
29. Autonomy and Alignement are indivisible Micromanagement 
 & 
 Mindless execution Autonomy Alignement Confusion 
 & 
 Inaction Misdirected 
 Actions
30. Alignement require clarity Then you add clarity: - A common understanding of goals and objectives - People can make rapid decisions without seeking approval - Standards and agreements - Where the autonomy starts and ends is essential to rapid, high-quality decision-making. It start with a (long term & inspiring) mission Explain the why, give goals, not procedures!
31. Explicit boundaries allow for 
 better collaboration When boundaries are unclear most people will not explore, but rather keep their head down and play it safe. Stepping over invisible boundaries invites punishment.
32. Autonomy require competency (mastery) As an of fi cer, David wanted to give more autonomy to the crew. But it was a disaster. Unused to their new-found freedom, the crew members made mistake after mistake. They did not have the competence for that level of autonomy. To perform well, teams need to be competent. They need to know how to deliver the optimal solution using the most appropriate technical practices. In other words, team members need to be skilled at their craft.
33. The secret sauce: cohesion (trust) Aristotle project: « What makes a team effective at Google? » The researchers found that what really mattered was less about who is on the team, and more about how the team worked together, and the fi rst factor was « psychological safety » within the team.
34. This is not a justification to avoid difficult conversation
35. Autonomy and Alignement are indivisible Autonomy Alignement Clarity 
 (Vision & shared understanding) Competency 
 (Mastery) Cohesion 
 (Trust) Don’t forget the third A: accountability!
36. Its is aligned with personal drivers Autonomy: the desire to have control over what we do Mastery: the satisfaction that comes from becoming better at what we do Purpose: the feeling that we are doing something that matters
37. Turning followers into leaders From Command & Control – Submerge the ship! – Aye aye, sir! To Shared Understanding – Captain, I intend to submerge the ship. Water depth has been checked and is four hundred feet, all men are below, and the ship is rigged for dive. – Go ahead.
38. Create alignment to provide autonomy with clear ownership through explicit boundaries. Second ingredient
39. 1. The Two Pizzas Team model (skunk works team) 2. Strong alignement with explicit ownership 3. Tighten your feedback loops
40. Longer feedback loop leads to bigger defects « The wiring wasn't following the expected routing through the fuselage, so when we got to the end they weren't long enough » said one German mechanic. He asked not to be identi fi ed out of fear that he might lose his job. "The calculations were wrong," he said. "Everything had to be ripped out and replaced from scratch."
41. Engineering is about feedback loop Empirical De fi ned Chem ical Electrical Civil Aviation Aerospatial Biological Formals methods were developed to save money when prototyping is too costly. BigTech Continuous Integration
42. Engineering is about feedback loop Empirical De fi ned Chem ical Electrical Civil Aviation Aerospatial Biological Pace of innovation SpaceX
43. An iterative process Design Test Simulation 3D modeling Parallel exploration 3D printing Automated tests Fast full scale prototyping It helps the design to converge faster Shortest possible cycle time
44. An iterative process A Model X gets 27 hardware and software changes a day, 540 per month, or 5,400 each year. A legacy automaker delivers a model refresh or update earliest after 2 and often after 5-7 years. Legacy automakers avoid making because they believe it’s costly and their organization is not designed for it in short they believe it’s impossible. Because the hardware and software of Tesla vehicles change so frequently, a dedicated person from the local government works at Tesla every day to review each car and sign off on its homologation to ensure it is ready to be delivered to a customer.
45. An incremental process
46. An incremental process Most organizations thinks they will save time by starting here 2010 2013 2015 2018 2018 2019 2009
47. Risk is rewarded, failure expected “Our goal is to make it to orbit without blowing up. If the booster even does its job and something goes wrong [right after launch] with the ship, I’ll still count that as good progress. Actually, to be totally frank, if it takes off without blowing up the stand, — ‘stage zero’ [the tower, tanks, etc.] — , which is much harder to replace than the booster, that would be a victory. That’s my number-one concern”.
48. Introduce some empirical discovery in an incremental way through fast iterations that may fails Third ingredient
49. Obliquity « Strange as it may seem, overcoming geographic obstacles, winning decisive battles or meeting global business targets are the type of goals often best achieved when pursued indirectly. This is the idea of Obliquity. Oblique approaches are most effective in dif fi cult terrain, or where outcomes depend on interactions with other people. » – John Kay
50. Don’t try to « Scale » Agile, instead: - Create smalls, autonomous and cross functional teams - Provide alignment to give autonomy with clear ownership through explicit boundaries -Introduce some empirical discovery in an incremental way through fast iterations that may fails
51. www.lilobase.me Thanks ! @lilobase alemaire@quantis.fr