1. Flow
1.1. Anti-patterns
1.1.1. optimising for resource efficiency
1.1.1.1. A focus on resource efficiency will almost always destroy overall efficiency, because fully utilized people and machines create huge traffic jams, which end up creating a lot of extra work.
1.1.1.2. Instead, focus on flow efficiency: the efficiency with which a unit of work moves through the system
1.1.1.3. Flow efficiency trumps resource efficiency almost all of the time
1.1.2. plan is not adapted according to new information
1.1.2.1. Following a plan and measuring variance from a plan is often justified by the slogan “Do it right the first time.”
1.1.2.2. Unfortunately, this approach does not allow for learning; it confines designs to those conceived when the least amount of knowledge is available
1.1.2.3. A commonly used and important practice in product development is to create variation (not avoid it) in order to explore the impact of multiple approaches.
1.1.2.3.1. This is called set-based engineering
1.1.2.3.2. variation is an essential element of the learning cycles that are the foundation of good product engineering
1.1.3. starting new work before current stuff is finished
1.1.3.1. see 1 and 3 above
1.1.4. the more features, the better
1.1.4.1. there is a cost to each feature -- a positive ROI isn't as common as one would be lead to believe
1.1.4.1.1. cost
1.1.5. not learning early due to fear of failing
1.1.5.1. focus on high risk
1.2. Rules of the Game
1.2.1. 1. Limit work to capacity
1.2.1.1. What is your team's capacity?
1.2.1.1.1. tools:
1.2.1.2. Tip:
1.2.1.2.1. Capacity is defined in terms of actual data for your average throughput for similar work under similar environment, not in terms of desired/aspired throughput
1.2.1.3. Ensure that the demand side are aware of your capacity
1.2.1.4. Encourage all excess demand to be dropped from team's backlog
1.2.1.4.1. oscillations in demand are one thing, an ever growing backlog is another
1.2.1.5. Why?
1.2.1.5.1. Consequences of demand > supply
1.2.2. 2. Minimize num of Units of Work in Progress
1.2.2.1. Why?
1.2.2.1.1. Reduce the negative impact of multi-tasking by limiting it
1.2.2.1.2. Faster is better
1.2.2.2. Goal: Move Things through process faster
1.2.2.2.1. Little's Law gives two options: reducing WIP or increasing capacity
1.2.3. 3. Minimize size of Units of Work (in progress)
1.2.3.1. Why?
1.2.3.1.1. Batching things together is a countermeasure to moving things faster through the process
1.2.4. 4. Establish a regular cadence
1.2.4.1. Why?
1.2.4.1.1. Timeboxed iterations allow one to:
1.2.5. 5. Use pull scheduling
1.2.5.1. work happens when there is capacity to do it
1.2.5.2. Why?
1.2.5.2.1. pushing work is a countermeasure to moving things faster through the process
1.2.6. 6. Even out the arrival of work
1.2.6.1. Why?
1.2.6.1.1. variation leads to queues
1.2.6.2. how does your team handle swings in demand?
1.2.6.3. What variations should be expected/factored in?
1.2.6.4. Tips:
1.2.6.4.1. Allow slack time within team to be able to handle increases in demand that follow expected trends
1.2.6.4.2. Use temporary loaners and focused mercenaries to deal with demand increases beyond expected trends
1.2.6.4.3. T-shaped team members to promote swarming on bulges in specific work types
2. Checklist
2.1. balancing demand to capacity
2.2. lead time and throughput metrics
2.3. trading off resource and flow efficiency
2.4. evening out the arrival of work
2.5. focus and swarming problems
2.6. introducing slack time
2.7. establishing a regular cadence
2.8. minimising the size of work items
2.9. limiting work in progress (WIP)
2.10. pull (rather than push) delivery
3. References
3.1. http://confluence.int.corp.sun/confluence/display/ALP/Muda%2C+Mura+and+Muri
3.2. http://info.int.corp.sun/sbs/Agile/Documents/KanbanMetrics.pptx
3.2.1. check out the slide on Little's Law and come back to me with questions!
3.3. Read these books:
3.3.1. The Goal: A Process of Ongoing Improvement: Eliyahu M. Goldratt, Jeff Cox: 9780884271956: Amazon.com: Books
3.3.1.1. Introduces Theory of Constraints (ToC) and drum-buffer-rope
3.3.1.1.1. A MUST read -- you wont regret it!
3.3.2. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win: Gene Kim, Kevin Behr, George Spafford: 8601410700966: Amazon.com: Books
3.3.2.1. gives an IT spin to ToC and provides some good motivation for Continuous Delivery
3.3.2.2. not as inspiring to read but more relevant
3.4. https://www.mindmeister.com/927925059/the-trap-of-encouraging-local-resource-efficiency-the-appeal-and-seduction-of-cost-accounting
3.4.1. this is still 'under construction' but it will soon be a linkedin article, so I would love to have your feedback for improvements