Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

June 16, 2022
Tweet

More Decks by Arnaud LEMAIRE

Other Decks in Programming

Transcript

  1. None
  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