2006/12/28

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)

No hay comentarios: