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

Unit 8 - Getting Stuff Done

Jez Humble
November 04, 2019

Unit 8 - Getting Stuff Done

Jez Humble

November 04, 2019
Tweet

More Decks by Jez Humble

Other Decks in Technology

Transcript

  1. i290 lean/agile product management
    unit 8: how to get better
    This work © 2015-20 Jez Humble
    Licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
    @jezhumble
    https://leanagile.pm/
    [email protected]

    View Slide

  2. understand how to take a scientific approach to
    process improvement
    be able to explain principles of organizational change
    understand activity accounting and waste
    how to get stuff done in big orgs
    consider the limitations of methodologies
    learning outcomes

    View Slide

  3. change

    View Slide

  4. achieve large-scale change iteratively & incrementally
    improvement work is never done
    leaders & teams agree outcomes, teams decide how
    create community structures
    build a culture of experimentation
    organizational change

    View Slide

  5. change
    “a majority of employees, perhaps 75 percent of management
    overall and virtually all of the top executives, need to believe
    that considerable change is absolutely essential”
    John Kotter, Leading Change

    View Slide

  6. the key to the TPS
    Mike Rother | http://www-personal.umich.edu/~mrother/Homepage.html

    View Slide

  7. HP LaserJet Firmware division
    2008
    ~5% - innovation capacity
    15% - manual testing
    25% - product support
    25% - porting code
    20% - detailed planning
    10% - code integration
    Costs
    Full manual regression: 6 wks
    Builds / day: 1-2
    Commit to trunk: 1 week
    Cycle times

    View Slide

  8. implement continuous integration
    reduce hardware variation
    create a single package
    create a simulator
    implement comprehensive test automation
    FutureSmart re-architecture

    View Slide

  9. Change in Costs
    ~5% - innovation
    15% - manual testing
    25% - current product support
    25% - porting code
    20% - detailed planning
    10% - code integration
    2008
    ~40% - innovation
    5% - most testing automated
    10% - current product support
    15% - one main branch
    5% - agile planning
    2% - continuous integration
    2011
    The remaining 23% on RHS is spent on managing automated tests.

    View Slide

  10. The Economics
    2008 to 2011
    • overall development costs reduced by ~40%
    • programs under development increased by ~140%
    • development costs per program down 78%
    • resources now driving innovation increased by 8X
    A Practical Approach to Large-Scale Agile Development
    (Addison-Wesley) Gruver, Young, Fulghum

    View Slide

  11. View Slide

  12. target conditions
    Gruver & Mouser, Leading the Transformation

    View Slide

  13. key insights
    1. You can use the same meta-process for:
    • product development
    • organizational change
    • architectural change
    2. Leaders set targets, teams design and run experiments
    Kiichiro Toyoda, quoted in Toyota Kata, p40 (Rother)

    View Slide

  14. methodologies
    Kiichiro Toyoda, quoted in Toyota Kata, p40 (Rother)
    Certainly the thieves may be able to follow the design plans
    and produce a loom. But we are modifying and improving our
    looms every day. So by the time the thieves have produced a
    loom from the plans they stole, we will have already advanced
    well beyond that point.
    And because they do not have the expertise gained from the
    failures it took to produce the original, they will waste a great
    deal more time than us as they move to improve their loom.
    We need not be concerned about what happened. We need
    only continue as always, making our improvements.

    View Slide

  15. OKRs
    • “objectives and key results”
    • objectives are clear statement of goals / intent
    • key results are measurable outcomes
    • gathered from key stakeholders (including teams)
    • prioritized

    View Slide

  16. View Slide

  17. focus
    The 4 Discplines of Execution by Chris McChesney
    Number of
    Challenges
    11-20 4-10 1-3
    Challenges
    Achieved
    0 1-2 1-3

    View Slide

  18. View Slide

  19. What obstacles are preventing you from reaching
    it? Which one are you addressing now?
    What is the target condition? (The challenge)
    What is the actual condition now?
    When can we go and see what we learned from
    taking that step?
    What is your next step? (Start of PDCA cycle)
    Improvement Kata

    View Slide

  20. Deming cycle
    by Johannes Vietze | https://commons.wikimedia.org/wiki/File:PDCA_Process.png

    View Slide

  21. community structures
    2019 State of DevOps Report | cloud.google.com/devops
    Elite teams favor strategies that create community structures:
    • Communities of practice
    • Grassroots
    • Proof of concept (POC) as a template
    • POC as a seed

    View Slide

  22. communities of practice
    https://martinfowler.com/articles/testing-culture.html#google
    “The Testing Grouplet was a team of Google developers who worked
    together in their 20% time (time provided by Google to allow
    developers to work on Google-related projects of their choosing aside
    from their main projects) to address the challenges in promoting unit
    testing adoption throughout Google. An all-volunteer group with little
    funding and no direct authority, it relied on persuasion and innovation
    to convince Google developers of the value of unit testing, and
    provided them with the tools and knowledge needed to do it well.”
    — Mike Bland

    View Slide

  23. “If it's a good idea, go
    ahead and do it. It is
    much easier to
    apologize than it is to
    get permission.”
    —Rear Admiral Grace Hopper,
    USN, 1906-1992

    View Slide