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
- 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
- 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
- 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.
- 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:
Publicar un comentario