Bottom-up AdoptionThrough the Prism Of Flow

Steve Carter @sweavo

Who he?

• Steve Carter

• Software Developer

– In a small team

– On a large project

– For a large org

• People Person

• Scrum master

• Culture hacker

@sweavosweavo@gmail.com

FlowVariability

Queue Lengths

Batch Size

Work In Progress

Feedback

Synchronization

FlowVariability

Queue Lengths

Batch Size

Work In Progress

Feedback

Synchronization

Variability

• Generally bad

• Scrum and Kanban (lean manufacturing) try to eliminate variability

• Flow-based approach acknowledges variability and seeks to make better decisions

– In product development, variability is not going away, like it can in manufacturing.

Queue Lengths

• Once started, knowledge work starts to age

– (market or technology moves on)

• Better to start later than to commit then delay

• Queues delay work

– For all the items in the queue

• Cost is worse than linear in the queue length

Capacity Utilization and queues

Percent Utilization

Qu

eue Len

gth

80% 90%

Capacity Utilization and queues

Percent Utilization

Qu

eue Len

gth

80% 90%

Batch Size

• How much stuff must you complete before (handing off to next step / making money / getting feedback)

• Economies of scale, vs. economies of learning, feedback, and reduced cost of doing things you do often

Batch Size

Batch Size

Project Duration

Percentage O

verrun

WIP

+WIP

+Utilization

++Queues

+++Delay

Feedback

• In terms of customer feedback, yes

• But also in terms of control signals

• e.g. a queue reaching its limit might signal upstream to slow down and/or a reassignment of resources.

1 2 3 4 5

Cross-functional SynchronizationAKA: “handoffs are bad, m’kay?”

ScrumBacklogs

Story Slicing

Taskboard

Timeboxes

Standups

Review

Scrummaster

Scrum Master

Team

Product Backlog

• Not a queue

– Minimal holding cost

– Work is focused on the top priority stories

• Unless someone committed to the whole backlog: Then it’s a queue!

Story Slicing

• Reduce batch size

– Lower schedule variability

– More timely feedback

• Variability pooling

– Win some, lose some

• Decomposition on the level of product behaviour

– Not work breakdown

Sprint Backlog

• Limits batch size– If slicing is working

– If you do refuse large stories

– Unless a manager keeps negotiating up the sprint commitment

• (loose) limit on WIP– Unless you have to take on, e.g. support queries

mid-sprint

• Is a queue

Task Board

• Todo and Doing are queues

• Doing is WIP

– “snowplough” pattern tries to limit WIP more

– Unless “can someone start this one? I just want to see some progress”

Timeboxes

• Limit variability

– Time-based review always happens.

– Unless “we’re not reviewing it until it’s complete”

• “if you base reviews on scope rather than time, then the projects in trouble get reviewed less”—Reinertsen

Daily Standup

• Allows resources to be redeployed to bottlenecks

– Unless manager makes sure everybody has a job to do

• Synchronization across functions

– Unless your team is not cross-functional

– Or your PO does not attend/engage in standups

Sprint Review

• Demonstration of behavior gets fast feedback

– Unless customer/PO is not present or engaged

– Remote customer can mean handoffs between feature team and end-user, and delays in feedback

Scrum Master

• Shields the team from additional WIP

– Unless is “just a dev with a baseball cap on”

• Nurtures the adoption of good practice

– Optimize whole system

– Unless Scrum is regarded as “something teams do”

The Team

• Colocated, cross-functional, Self-organising– Fast feedback,

– Synchronization

– (Almost) no queue

– Reallocates to address bottlenecks

• Unless – “use this team in India for testing”

– WIP=team size, then you have a group of soloists sitting near one another, not a team

MIA?Backlogs

Story Slicing

Taskboard

Timeboxes

Standups

Review

Scrummaster

Scrum Master

Team

Suboptimization

• Flow shows us that “whole system” optimization is the rational way to optimize profit.

• “Agile in a bubble”: if the company is not paying attention to batch size of requests and feedback, it’s unlikely that the development engine will satisfy the business.

Culture Change

• There are significant harmful behaviors encouraged by BDOs, e.g.

– work harder to perfect the spec

– insert stage gates

– push team to high utilization

• Can these issues be addressed from the bottom up?

NO(To the nearest whole answer)

Culture Change as a flow problem

• Subject to handoffs up and down Org Chart

– Loss or corruption of message

• Cross-functional meetings might help

– More levels of management present

5

4

3

2

1

Culture Change as a flow problem

• People with different department heads do not have a common goal

– Overhead in uncovering others’ motivations and getting buy-in

• Get them To Read Reinertsen?

– Large batch size

Batch Size Of Culture Change

• How many elements need to be in place for success?

• Can you get better results than now with fewer elements?

• Start with visualizing work and reducing batch size of work.

• Even that can be a hard sell.

Work with Suboptimization?

• Instead of “lifetime profitability” go with a campaign of small victories.– With success you will get the ear of management

• Go in with eyes open– Success in one project might not translate to

another

– Watch batch size, queues, capacity utilization

• Depends on your company’s and your customer’s culture

Takeaways

• Read the book!

– Beware of large batches

– watch your queues

– Keep utilization low (70%-80% busy)

• Look for small success stories

• Without manager buy-in, success is limited

Thanks!Script and slides on sweavo.wordpress.com

Tweet or DM me feedback @sweavo

@NewRedo