While as one commenter put it, nothing new, it was interesting to me to see it strung together and the one-year transformation.
Basically starting with a team that followed many Agile practices he described changes using Lean that transformed or even eliminated the need for some of the Agile practices.
Initial agile practices: Collocated teams with daily stand ups. Pair Programming 95% of the time amongst the 16-17 engineers. 2 weeks sprints with shipping at the end. Test Driven Development (TDD) & Continuous Integration (CI). Engineers estimate in story points.
With all this, they still had stories stuck or blocked for long periods of time.
So apply Theory of Constraints, (Book: The Goal — Eli Goldratt , or more recent IT oriented version: The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr and, George Spafford).
Also need more visual progress, so use Kanban board.
Kanban — use buffers to throttle upstream demand and reduce cycle time. Reduce Work In Progress (WIP): Ready, Doing, Done
Bottleneck was some times deployment. They had manual deployment process.
So use Continuous Deployment (CD)— automate deployment — Reduce cycle time of deploying value to customers as close to zero as possible.
dev -> continuous integration —> test in cloud —> Deploy & Monitor (system health, . . )
Note: Theory of constraints assume single, stable bottleneck.
With Knowledge work, the bottlenecks bounce around.
Kanban more systematically lays down constraints.
Typically delay in handoff between roles or back & forth between roles.
==> use tighter feedback loops to reduce stuck stories.
CD allows change to fixed length sprint structure. Sprint planning meetings continue, but fixed sprints becoming superfluous because of continuous deployment.
Not all features released produced the Key Performance Indicators (KPIs) they wanted. So use Innovation Accounting from book The Lean Startup.
Use the build-measure-learn loop to reduce the amount of uncertainty in new product development or process innovation.
Build smallest KPI change you can ship and run experiments.
Small lightweight experiments could be costly using full TDD and pair-programmed development. For short lived proto-typing code, may not need TDD. Also consider pair with Designer — Designer & Engineer to create experiments. Use experiments to validate business needs
A change from Agile to Lean was dropping story points in favor of Statistical Process Control (SPC) ala Shewhart and Demming.
Assume most stories flow normally, but analyze why outliers outside the range? What makes those work items special? Estimation time focused on risky (outlier) areas.
Team used electronic Kanban board (not Sam’s first choice of way to do it) that collected data, which was fortuitously used for SPC control chart.
Not all was rosy. CEO would make urgent requests to reprioritize. Which slowed original work down. How to do the tradeoff? Measure Cost of Delay.
Compare cost of delay for what you are doing now vs. what CEO wants now.
Cost of Delay: Quantifying the impact of delay on total life-cycle profits for each of your projects. Delay typically shifts when start recognizing revenue, without shifting end of life.
How to get costs? Spreadsheet of conversion rates, traffic, etc. from Finance.
Assumes you know cost of production: Engineering time spent and cost of payroll.
Quantify Risk using data — not intuition — to model, and validate, risk factors.
Books by Hubbard : How to Measure Anything & Failure of Risk Management.
Quantifying Risk of : Traffic -> convert user —> paid user retention
“all other risk” (without data) is just hand waiving.
Use Monte Carlo simulations — which parts are most sensitive to Risk.
Optional pair programming (E/E or D/E pairs)
Optional TDD & Continuous Integration
Use experiments to validate business needs
Use historical data to provide estimates, and asses risks.
Change daily stand ups from what I did, doing, and am blocked on
to talk about flow of work.
Moving KPIs in right direction.
How to make many small bets.
But don’t believe what I wrote! Watch the video with the graphics for more detailed descriptions.
Video of Sam McAfee’s Putting Lean Principles to Work for Your Agile Teams talk.
To visit Bay Area Agile Leadership Network, go here: http://www.meetup.com/BayALN/