Get Started. It's Free
or sign up with your email address
Rocket clouds
Flow by Mind Map: Flow

1. Anti-patterns

1.1. optimising for resource efficiency

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.2. Instead, focus on flow efficiency: the efficiency with which a unit of work moves through the system

1.1.3. Flow efficiency trumps resource efficiency almost all of the time

1.2. plan is not adapted according to new information

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.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.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.2.3.1. This is called set-based engineering

1.2.3.2. variation is an essential element of the learning cycles that are the foundation of good product engineering

1.3. starting new work before current stuff is finished

1.3.1. see 1 and 3 above

1.4. the more features, the better

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.4.1.1. cost

1.4.1.1.1. dev effort

1.4.1.1.2. continued maintenance effort

1.4.1.1.3. impact on overall system -- increased codebase complexity, etc.

1.5. not learning early due to fear of failing

1.5.1. focus on high risk

2. Rules of the Game

2.1. 1. Limit work to capacity

2.1.1. What is your team's capacity?

2.1.1.1. tools:

2.1.1.1.1. yesterdays weather

2.1.2. Tip:

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

2.1.3. Ensure that the demand side are aware of your capacity

2.1.4. Encourage all excess demand to be dropped from team's backlog

2.1.4.1. oscillations in demand are one thing, an ever growing backlog is another

2.1.5. Why?

2.1.5.1. Consequences of demand > supply

2.1.5.1.1. best case: ever growing backlog

2.1.5.1.2. worst case: death by thrashing

2.2. 2. Minimize num of Units of Work in Progress

2.2.1. Why?

2.2.1.1. Reduce the negative impact of multi-tasking by limiting it

2.2.1.1.1. Teams should do one thing at a time and get it done, because task switching burns up a lot of cognitive overhead.

2.2.1.1.2. Partially done work that has been put aside gums up the workflow and slows things down.

2.2.1.2. Faster is better

2.2.1.2.1. earlier benefits

2.2.1.2.2. earlier chances for learning

2.2.1.2.3. less context switching

2.2.1.2.4. lower chance of change while in progress

2.2.2. Goal: Move Things through process faster

2.2.2.1. Little's Law gives two options: reducing WIP or increasing capacity

2.2.2.1.1. former doesn't directly impact the team dynamic and budget

2.3. 3. Minimize size of Units of Work (in progress)

2.3.1. Why?

2.3.1.1. Batching things together is a countermeasure to moving things faster through the process

2.4. 4. Establish a regular cadence

2.4.1. Why?

2.4.1.1. Timeboxed iterations allow one to:

2.4.1.1.1. gauge the sustainable throughput of a team over time

2.4.1.1.2. provide better focus (short term and specific goal)

2.4.1.1.3. define a limit for work in progress

2.5. 5. Use pull scheduling

2.5.1. work happens when there is capacity to do it

2.5.2. Why?

2.5.2.1. pushing work is a countermeasure to moving things faster through the process

2.6. 6. Even out the arrival of work

2.6.1. Why?

2.6.1.1. variation leads to queues

2.6.1.1.1. a queue is inventory, which is waste

2.6.2. how does your team handle swings in demand?

2.6.3. What variations should be expected/factored in?

2.6.4. Tips:

2.6.4.1. Allow slack time within team to be able to handle increases in demand that follow expected trends

2.6.4.2. Use temporary loaners and focused mercenaries to deal with demand increases beyond expected trends

2.6.4.3. T-shaped team members to promote swarming on bulges in specific work types