Lean Kanban: Our Journey So Far - Amazon Web Services

Lean Kanban:Our Journey So FarSix months of board-wrangling

Lean Kanban - Our Journey

JAN FEB MAR

APR MAY JUN

JUL AUG SEP

OCT NOV DEC

1. Where we started

2.

3.

4.

5.


JAN FEB MAR

APR MAY JUN

JUL AUG SEP

OCT NOV DEC

1. Where we started

2. Training

3.

4.

5.


JAN FEB MAR

APR MAY JUN

JUL AUG SEP

OCT NOV DEC

1. Where we started

2. Training

3. 3 months

4.

5.


JAN FEB MAR

APR MAY JUN

JUL AUG SEP

OCT NOV DEC

1. Where we started

2. Training

3. 3 months

4. 6 months

5.


JAN FEB MAR

APR MAY JUN

JUL AUG SEP

OCT NOV DEC

1. Where we started

2. Training

3. 3 months

4. 6 months

5. The future

Who are we?

• Small, agile team

• Client-facing developers

• Consulting and professional services

What do we do?

• Effort divided across three work streams:

- Develop software

- Assist OpenMarket Sales

- Support live clients

How were we doing it?

• Software Development

• Agile; manual scheduling

• Sales

• Best effort

• Client-support

• As required

• Resources distributed reactively

How was that working out?

• Delivered software on time

• Problems:

- Work stream starvation

- Predictions were unreliable

- Difficult to react


JAN FEB MAR

APR MAY JUN

JUL AUG SEP

OCT NOV DEC

1. Where we started

2. Training

3. 3 months

4. 6 months

5. The future

Introduction to Lean Kanban

• Two days in May 2014

• Myself and my tech lead

What we liked

• Visibility of progress/problems

• Focus on finishing work

• Continuous improvement

What we feared

• Model all work items the same

• Impose strict WIP limits

• Past measurements inform future predictions

Model all work items the same• Technical sales• Product demos• RFPs• Security audits• Requirements gathering• Solutions design• Client training• Product maintenance• Managed services• Platform integration• Custom reporting• Bespoke web applications

Model all work items the same

If we model all work items the same, won’t our lead times and run rate vary wildly?

What we feared




Impose strict WIP limits

• Constrained resources

• Small team

• Lots of customers

• Limit work in progress

• Reduced utilisation


If we stick to strict WIP limits, won’t we get less done?

What we feared




Past measurements inform predictions

• Effort is:

- divided across Sales, clients and dev

- allocated reactively

- allocated inconsistently

- unevenly distributed


Last week:


Last week:

Next week:

? ? ? ? ? ? ?


Last week:

Next week:


Last week:

Next week: The picture can't be displayed.


If every day is different, won’t predictions based on past measurements be useless?

The picture can't be displayed.

It all averages out,over time.

Reassuring assertion

We were sceptical


Why Lean Kanban?

• We had problems to tackle:

- Work stream starvation

- Predictions were unreliable

- Difficult to react

• We were curious


JAN FEB MAR

APR MAY JUN

JUL AUG SEP

OCT NOV DEC

1. Where we started

2. Training

3. 3 months

4. 6 months

5. The future

Were our fears justified?






- If we model all work items the same, won’t our lead times and run rate vary wildly?


• Divided work into categories

• Tracked metrics per category

• High lead time variance

• Low run rate variance

• Many categories had similar profiles


• Merged categories over time:

• Pre-Sales

• Sales demos, RFPs, requirements gathering, etc.

• Post-Sales

• Software development


• High variance

• Conservative scheduling

• Working to reduce

• Scheduling:

• Easy

• Reliable


• High variance


• Working to reduce BAD IDEA

• Scheduling:

• Easy

• Reliable


• High variance


• Working to reduce BAD IDEA

• Scheduling:

• Easy LIES

• Reliable



- If we stick to strict WIP limits, won’t we get less done?

Pre-Sales Development

Not started

In progress

In review

Delivered


The picture can't be displayed. The picture can't be displayed.

41

2 3


The board


• Output has stayed about the same

• Professional Services:

• Steadier stream

• Projects take longer

• More predictable

• Reduce work stream starvation



- If every day is different, won’t predictions based on past measurements be useless?

• Scheduling based on run rate and lead time

• It does seem to be working

• Increasingly confident

Past measurements -> future predictions

• Scheduling based on run rate and lead time

• It does seem to be working

• Increasingly confident MORE LIES


Summary - up to month 3

• Consistent, predictable

• Low overhead

• More reactive

Summary - up to month 3

• Consistent, predictable ✗

- Regular surprises

• Low overhead ✗

- Scheduling fiddly & time-consuming

• More reactive ✓

- Swim lanes guard against total work stream starvation


JAN FEB MAR

APR MAY JUN

JUL AUG SEP

OCT NOV DEC

1. Where we started

2. Training

3. 3 months

4. 6 months

5. The future

Months 3 - 6

• Problems in months 0 - 3:

- Consistent, predictable ✗Pre-Sales flow

Lead time variability

- Low overhead ✗

Difficulty scheduling

53

Months 3 - 6




- Low overhead ✗


54

55

Flow of Pre-Sales work

• We try to maintain consistent effort allocation across work streams:

- Professional Services development

Sequence, short, road-mapped

- Pre-Sales Consulting tasks

Individual, long-running, interrupt-driven

56


• How to tackle long-running, interrupt-driven tasks in Kanban?

• Example: working with a client to architect a solution

- Concept discussions early on

- Lots of back and forth

- Waiting for decisions, data, budget approval…


• One enormous Kanban task to represent the whole process:

57

Architect Solutionand Agree with

Client


• One enormous Kanban task to represent the whole process

- Accurately reflects:Task could “wake up” at any time

Task owned by one individual

- Requires high WIP limits

- Can clog the board with stale work

- Unclear metrics58


• Lots of small kanban tasks to represent each step of the design agreement lifecycle:

59

Initial call Rough guesstimate Second call Draft

proposal

Workshop Finalproposal

Draft SoW Final SoW


• Lots of small kanban tasks to represent each step of the design agreement lifecycle

- Lower WIP limits

- Clear metrics

- Masks tasks pinned to an individual

- Each subsequent stage starts at the back of the queue

60


• Solution - we do both

- Choose how we optimise

- Responsiveness to this client/project vs throughput of other projects

61


• Business as usual:

• High-profile use case, tight deadlines:

62

Initial call Rough guess

Workshop Final proposal

Get it done

Months 3 - 6




- Low overhead ✗


63

• Metrics:

- Stable run rate

- Median lead time: ~6 days

- Std. dev.: ~8 days

• How to reduce?

64

High lead time variability

65

High lead time variability

• Don’t bother trying to reduce lead time variability

- Development tasks vary

- It is not necessary to fight this

- Accommodate in scheduling

Months 3 - 6




- Low overhead ✗


66


• We know our:- median lead time,- lead time std. dev.,- run rate

• If a project is 6 tasks - how to turn the above into a schedule?

67



• If a project is 6 tasks - how to turn the above into a schedule?- 6 * median lead time? ✗

68



• If a project is 6 tasks - how to turn the above into a schedule?- 6 * median lead time? ✗- 6 * (median lead time + 1 std. dev.)? ✗

69



• If a project is 6 tasks - how to turn the above into a schedule?- 6 * median lead time? ✗- 6 * (median lead time + 1 std. dev.)? ✗- (6 * median lead time) + (2 * 1 std. dev)? ✗

70


• Schedule based on run rate

- Run rate represents average progress

- Half the time run rate faster or slower

- Schedule for 1.5 * tasks

- Multiply number of tasks by 1.5 and divide by the average run rate

Provides a high confidence delivery date

71


• Schedule based on run rate

- Pros:

Simple and repeatable

High degree of confidence

- Cons:

Potentially over-conservative

72

Summary up to month 6

• Optimising Pre-Sales workflow

• Overcome scheduling difficulties

• Delivering predictably

• More reactive

• Driving tactical decision making

73


JAN FEB MAR

APR MAY JUN

JUL AUG SEP

OCT NOV DEC

1. Where we started

2. Training

3. 3 months

4. 6 months

5. The future

The future

• Threats to success:

- Complexity

- Frustration

- Skepticism

- Fatigue

75


The future

• Threats to success:

- Complexity

- Frustration

- Skepticism

- Fatigue

76

Complexity

• Continuous improvement and continuous change

• Temptation to handle every edge case with an enhanced process

• Can be hard to stay up-to-date

77

Complexity

• Continuous improvement and continuous change

• Temptation to handle every edge case with an enhanced process

• Can be hard to stay up-to-date

• Our process fully documented is ~1500 words

78

Frustration

• Complexity breeds frustration

- “What’s next” should be obvious

- Not the other side of a process discussion

• “Chair-spinning”

- Optimising for flow (not utilisation) can leave developers temporarily idle

- Demoralising to leave important work unstarted, even if it does reduce lead times overall

79

Skepticism

• Surprises breed skepticism

• Each time we have to intervene manually:

- Were we doing it wrong?

- Were we doing it right?

80

Exhaustion

• Complexity, frustration and skepticism could lead to exhaustion

• “Continuous improvement burn-out”

• We’re not there today

- It could become a problem

81

The future

• Monitor carefully

• Bias towards process simplicity

• Emphasise team involvement

82

The future

• There are dangers- We must remain vigilant

• Strong future with Lean Kanban- Real value

PredictabilitySimplicityPositive trajectory

83

Lean Kanban:Our Journey So [email protected]@thlant

Lean Kanban

1. Our Fears

2. Our Experience

3. Our Mistakes

Traps we fell into

• Making changes

- Before you understand your current process

- Before you have good data

- Before you have any data

- Making changes all the time

Traps we fell into

• Complexity creep

- New rules for every exception

- Fixing problems with process

- Swim lanes everywhere

Traps we fell into

• Misplaced confidence

- You want your new system to deliver

- Your real lead times might sound bad

Traps we fell into

• Failure to communicate

• Good communication is key

- Fear within

- Confusion outside

Summary

• Consistent, predictable

• Low overhead

• More reactive

The Future

• More work to be done

• Committed to continuous improvement with Kanban

92

Questions?

Pre-sales

• Technical sales, RFPs

• Optimised for quick turnaround

- First come, first served

• Time-boxed to 25% of available time

Post-Sales

• Software development

• Optimised for predictability

- Roadmapped commitments

• Time-boxed to 50% of available time

Client support

• Reacting to client system failure, questions

• Optimised for responsiveness

• Time is unrestricted

What do we do?

• Effort divided across three work streams:

- Develop software - Long running, scheduled tasks

- Assist OpenMarket Sales - Long running, interrupt driven tasks

- Support live clients - Short running, interrupt driven tasks

• Treat the team as a ‘black box’

• Predictions based on past measurements:

- Easy

- Accurate

• More reactive

98


• Treat the team as a ‘black box’

• Predictions based on past measurements:

- Easy Difficult

- Accurate Conservative

• More reactive ✓

99


Work stream effort variability

• We balance effort across Pre-Sales and Professional Services

• Metrics show historical effort distribution

• Difficult to translate into tactical decisions:

- “Can you do another project proposal for me this week?”

100


• Maybe forget this slide

• But how quickly can we start work?

• The first task needs to be on the board one median lead time before you start

• Not too fiddly

101

Lean Kanban: Our Journey So Far - Amazon Web Services

Documents

Transcript of Lean Kanban: Our Journey So Far - Amazon Web Services