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

Arnaud LEMAIRE

June 16, 2022
Tweet

More Decks by Arnaud LEMAIRE

Other Decks in Programming

Transcript

  1. Agile software development has its roots
    in the lean manufacturing paradigm
    Toyota Production System

    (Just In Time)

    View full-size slide

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

    View full-size slide

  3. 1. Just In Time


    2. Jidoka


    3. Poka yoke


    4. Kanban


    5. Kaizen


    Agile software development has its roots
    in the lean manufacturing paradigm

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. Software is eating the world

    View full-size slide

  7. Software is eating the world

    View full-size slide

  8. Software is eating the world
    And Space X is the most
    valuable private company with
    a valuation of $125 billions

    View full-size slide

  9. We have gone full circle
    Manufacturing Software Engineering
    Lean
    Agile

    View full-size slide

  10. www.lilobase.me
    Let’s reset Agile
    (at scale)
    @lilobase
    #Lean&AgileDay
    Arnaud LEMAIRE

    View full-size slide

  11. 1. The Two Pizzas Team model
    (skunk works team)
    2. Strong alignement with
    explicit ownership
    3. Tighten your feedback loops

    View full-size slide

  12. A fictive project
    Compliance Operation Development Test Marketing
    Engineering &
    Design
    Functional

    Analysis Program
    Manager

    View full-size slide

  13. A fictive project
    Engineering &
    Design
    Functional

    Analysis
    Development

    View full-size slide

  14. Cross functional team
    dedicated to a project

    View full-size slide

  15. Cross team direct
    communication

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  20. - Not a signi
    fi
    cant
    management overhead


    - Minimize communication
    overhead


    - Minimize inter-locking
    phenomenons


    - Minimize over-
    engineering
    Why smaller teams perform better ?

    View full-size slide

  21. But beware, your team size may be
    bigger than you think
    Team A Team B

    View full-size slide

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

    View full-size slide

  23. Project Manager /

    Product Manager /


    Product Owner
    Don’t try to scale Agile
    Descale your Organization

    View full-size slide

  24. Smalls, autonomous and cross
    functional teams
    First ingredient

    View full-size slide

  25. 1. The Two Pizzas Team model
    (skunk works team)
    2. Strong alignement with
    explicit ownership
    3. Tighten your feedback loops

    View full-size slide

  26. Autonomy is not a given
    This is where a lot of companies react

    by increasing procedures and controls

    View full-size slide

  27. It is all about alignement
    Autonomy
    Alignement
    Most organizations see them as

    both ends of the spectrum

    View full-size slide

  28. Autonomy and Alignement are indivisible
    Micromanagement

    &

    Mindless execution
    Autonomy
    Alignement
    Confusion

    &

    Inaction
    Misdirected

    Actions

    View full-size slide

  29. 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!


    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  33. This is not a justification to avoid difficult
    conversation

    View full-size slide

  34. Autonomy and Alignement are indivisible
    Autonomy
    Alignement
    Clarity

    (Vision & shared
    understanding)
    Competency

    (Mastery)
    Cohesion

    (Trust)
    Don’t forget the third A:
    accountability!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  37. Create alignment to provide
    autonomy with clear ownership
    through explicit boundaries.
    Second ingredient

    View full-size slide

  38. 1. The Two Pizzas Team model
    (skunk works team)
    2. Strong alignement with
    explicit ownership
    3. Tighten your feedback loops

    View full-size slide

  39. 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."

    View full-size slide

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

    View full-size slide

  41. Engineering is about feedback loop
    Empirical De
    fi
    ned
    Chem
    ical
    Electrical
    Civil
    Aviation
    Aerospatial
    Biological
    Pace of innovation
    SpaceX

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  44. An incremental process

    View full-size slide

  45. An incremental process
    Most organizations thinks
    they will save time by
    starting here
    2010 2013 2015 2018 2018 2019
    2009

    View full-size slide

  46. 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”.

    View full-size slide

  47. Introduce some empirical
    discovery in an incremental
    way through fast iterations
    that may fails
    Third ingredient

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  50. www.lilobase.me
    Thanks !
    @lilobase
    [email protected]

    View full-size slide