what do you get if you cross kanban with extreme xanpan ... · xanpan “zan-pan” team centric...

Post on 22-Jun-2020

2 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

allan kellyTwitter: @allankellynethttp://www.allankelly.net

Xanpan“Zan-pan” Team centric Agile

What do you get if you cross Kanban

with Extreme Programming?

2014-2020

We don’t need another Methodology

Scrum

FDDASDPrince2

SSADM

Crystal(s)Method1 Lean

Kanban

Xanpan

Extreme

ProgrammingRUP

OUP

Pragmatic AgileScrumBan

DSDM

Choose your Cola

Kent BeckXP-Cola

Ken & Jeff’sScrum-Cola

David AndersonKanban-Cola

Allan KellyXanpan-Cola

Where did Xanpan come from?

• Experience (Lean+XP)– Blue-White-Red

• Kanban• XP• Plus – Seeing others– Reports of other cross-overs

• Making sense of what I see

XP Kanban & Lean

1First

concept

XP Kanban & Lean

Product Management

2

XP &

ScrumKan

ban

& Lean

Product

Management Other s

tuff3

Principles

• Iteration routine• Team Centric– Planned & Unplanned work– Team over projects

• Invest in Quality / “Quality is Free”• Dis-economies of Scale• Flow: Emphasize, Level, Span, Constrain• Goodhart’s Law• Constructivism learning• Visualise

Practice

1. XP Technical practices: TDD, CI, etc.2. Teams can work on more than 1 stream– Flow multiple projects/product to 1 team

3. Break Stories to Tasks– Colour code work– Estimate in Points– Small is better - Think Small!

4. Benchmark against self– Velocity

Practices

5. Flow– Use Product “Ownership” (Product Management

& Business Analysis) to control (restrict) flow– Apply WIP limits– Absolute Prioritization

6. Planning levels (horizons)7. Pick’n’Mix8. Action over words

Practices

9. Fit work to the time– Deadlines are good– Limit WIP

10.Evolutionary change– Small Bangs are OK – but Big Bangs are bad

Some detail….

Iterations & Flow

• Iterations bring structureBut• Strict iterations break flow– “Story must be finished in sprint”– “Story cannot be bigger than a sprint”– Sprint tail overwhelmed by finished stories– Testers drop standards

• Strict iteration– Difficult at first – learn to think small

Repeat

Thursday

Friday

Monday

Tuesday

Wednesday

Ends

Work

Release

Dem

oStart

Prio

ritiza

tion

Brea

kdow

nAg

reem

ent

Review &

Retrospective

Planning

meeting

Thursday

Friday

Monday

Tuesday

Wednesday

Iteration - 2 week routine

Iterations & Flow

• Stories spanning sprints levels work– Break down stories to tasks– Tasks only counted when completed– When all tasks done, Story done

• 3 Strikes and you are out!– Story span 1 Sprint, OK, good– Story spans 2 Sprints, umm… Red Flag– Story spans 3 Sprints, Out! Story too big

Breakdown

• In planning meeting• Part– Software Design– Requirements elicitation– Opportunity to reduce scope– Estimation exercise

Image from Paul Goyette, Creative Commons Licensehttp://commons.wikimedia.org/wiki/File:Wrecking_ball.jpg

Epic

StoryStoryStoryStory

Not essential, use if useful

Blues – Stories• Business facing• Have automatic business value• Deliverable in own right• Deliverable sometime soon • Typically software feature but

anything which brings value –documentation, etc.

TaskTaskTaskTask Whites – Tasks• Typically developer tasks• No business value alone

Estimation: useful but building on sand

Estimation

1st rule of estimation:

Estimate value before effort

2st rule of estimation:

Only effort estimate work which is expected to happen within 3 months

Estimation

3srd rule of estimation:

Use historic data when making forecasts

e.g. if team averages 18 points a sprint then expect about 18 points next sprint

Yes, Estimation

I’ve come to like Planning

Poker but choose your own poison

• Estimate White tasks in planning meeting– Ball-park estimate Blues

• Estimates in Points– Your currency £ $ €– One currency– Forget hours

Estimation worthwhile? “I can bring a project in to the day”

?

• For scheduling? Perhaps– Some teams report good results– Some teams placebo effect– Long run average accurate enough

• Provides Developers with safety valve• Useful input to design process(Forget actuals – retrospective estimates)

Estimation…

• Within 3 months effort estimates:– Generally right– Useful in designing & scheduling

• Beyond 3 months:– Estimates too variable– Work changes

• Value estimate beyond 3 months essential

Estimation

4rd rule of estimation:

Assess deliveries for benefit realizedClose the loop on value estimates

5th rule of estimation:

Count effort points but do not change retrospectively

Reds

YellowsUnplanned work

GreenSpecific to you

Planned & Unplanned work

• Work planned in planning meeting• Unplanned work allowed at any time– Tag it, e.g. Yellow card– Retrospective estimation

• At end of the iteration count points unplanned– Graph/Track planned v. unplanned– Incorporate into planning velocity

Velocity: planned & unplanned work

0

2

4

6

8

10

12

14

16

18

20

1 2 3 4 5 6 7 8 9 10 11 12

Planned work done Unplanned work done Total done

Light Sabre

Every team must design their own board

Quality…

… makes all things possible

Quality core

What qualities are important to you?

Goodhart’s Law

Any observed statistical regularity will tend to

collapse once pressure is placed upon it for control

purposes.

Professor Charles Goodhart, CBE, FBA

Velocity & points break down if abused … and so do other measurements

Is Xanpan useful?

• Maybe – Take it– Use it

• Inspiration– Roll your own

Image from Ildar Sagdejev under Creative Commons licensehttp://commons.wikimedia.org/wiki/File:2009-02-15_Rolling_a_cigarette.jpg

33

E-book http://leanpub.com/xanpanAmazon for eBook & printed – Audio coming soon

Which brand of Cola are you drinking?

allan kellywww.softwarestrategy.co.ukwww.allankelly.netallan@allankelly.netTwitter: @allankellynet

top related