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

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

change

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

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

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

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

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

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.

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

No content

target conditions Gruver & Mouser, Leading the Transformation

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)

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.

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

No content

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

No content

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

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

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

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

“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