Mary Poppendieck: Competing On The Basis Of Speed

I watched Mary Poppendieck's talk at Google: Competing On The Basis Of Speed. It is a good talk, but it does not compare well to Mary and Tom's most excellent Lean Software Development: An Agile Toolkit (amazon.com amazon.co.uk safari).



I took some messy notes, way too powerpointish :-(. My advice: go for the book.

Intro

• Fast companies (e.g. Dell, Toyota, Google)
• competitive advantage
  
• lower costs
  
• large barrier to entry for competition
  
• Speed's enemy: complexity
• 3 faces of complexity [1]:
• waste: anything that depletes resources without adding customer value
  keep it simple
  
• inconsistency: anything uneven, unbalanced, irregular
  make it flawless
  
• overload: excessive burden
  let it flow
  

Keep it simple (video 5m45s)

• Common infrastructure:
• Architecture
• Conventions: naming, coding, security, logging, ui, configuration management...
• Tools
• Refactoring to keep simplifying
• Sustainable simplicity: change tolerance (video 7m52s)
• 60%-80% of code is written after the first release
• the development process has to anticipate change
• decide as late as possible, when you have more info
  
• make decissions reversible whenever possible
• make irreversible decissions at the last responsible moment
• set-based development: explore the whole solution space at once (Toyota worked on 10 motors at once for the Prius). Keep multiple options, and one has to work at the last responsible moment.
• paradox: these redundant solutions are not waste

Make it flawless (video 18m28s)

• 2 kinds of inspection
• to find defects -> waste
• to prevent defects -> essential
• Mistake-proof every step: detect defects the moment they ocurr
• don't track defects on a list: find them and fix them
• test first, automated test suites
• Role of testing (video 21m55s)
• manufacturing:
  
• a quality process brings quality into the products (unlike in software development traditional view)
  
• finding process in verifcation -> you have a defective process
• focus on preventing defects. Cannot be at the end of development, adding waste in the form of test-fix churn. It has to be integrated into the development process.
• 4 kinds of testing
• unit testing: developer intend. Automate them.
  
• acceptance/regression testing: business intend. Automate them.
• exploratory + usability testing. Manual by definition.
• property (response, security, scaling....) testing. Take advanteg of tools.
• Technical debt (video 26m55s)
• anything that makes code difficult to change
• the longer you acquire debt the worse it gets
• cost ofcomplexty is exponential
• regression deficit: more features, longer testing, until it dominates the release cycle
• unsync code branches: the longer apart, the longer it will take to merge
• Build Quality in (video 33m17s)
• configuration management, one click build, automated testing, continuous integration, frequent depoyment
• nested synchronization: test as early and often as possible
  
• every check in - unit tests
• evrery day - regression test harness
• every week - operations test harness
• every iteration - deployment ready code

Let it flow (video 43m40s)

• cycle time : customer problem to customer solution.
• software development cycle time: requests to deployment
• process capability: wether you have or not a reliable and repetible cycle time for a given set of problems
  
• delays: hint of opportunities for cost/waste reduction
• queuing theory
• total cycle time = number of things in process / average completion rate
• shorter cycle time: ability to add new features
• small tasks and slack decrease the total cycle time
  
• utilization paradox (48m23s) - not having slack increases the cycle time. This is one of the ideas behind 3M's 15% of free time rule (Google's 20% precedent). Organizations targeting 100% utilization are meassuring the wrong thing.
  
• Keep a honest queue/to-do list: short and in the realm of the things that can be reasonably expected to be done; no useful purpose for long queues
• Stablish a regular cadence, limit work to capacity, minimize the size of things in the process.
  

System meassurements

• cycle time (lean classic) - process capability
• business case (are you making money) - business return
• customer satisfaction — sustainability
• net promoter score [2]

[1] From Matthew May's The Elegant Solution: Toyota's Formula for Mastering Innovation (amazon.com amazon.co.uk)
[2] Frederick F. Reichheld's The Ultimate Question (amazon.com amazon.co.uk)