Unit 8 - Getting Stuff Done

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/
   humble@berkeley.edu
   

   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