Pro Yearly is on sale from $80 to $50! »

Unit 8 - Getting Stuff Done

D8004857fc10614cfa4dec1bae20f874?s=47 Jez Humble
November 04, 2019

Unit 8 - Getting Stuff Done

D8004857fc10614cfa4dec1bae20f874?s=128

Jez Humble

November 04, 2019
Tweet

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
  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
  3. change

  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
  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
  6. the key to the TPS Mike Rother | http://www-personal.umich.edu/~mrother/Homepage.html

  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
  8. implement continuous integration reduce hardware variation create a single package

    create a simulator implement comprehensive test automation FutureSmart re-architecture
  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.
  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
  11. None
  12. target conditions Gruver & Mouser, Leading the Transformation

  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)
  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.
  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
  16. None
  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
  18. None
  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
  20. Deming cycle by Johannes Vietze | https://commons.wikimedia.org/wiki/File:PDCA_Process.png

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