magic of kanbanmydlc.com/pmi-mn/pres/2013a01_magickanban_tlennox.pdf · 2014-05-26 · 3013 january...

Post on 25-May-2020

3 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

The Magic of Kanban and the

Agile Movement

(Why you want to know more

about Kanban)

Tomo Lennox

Bow Tie consulting

3013 January 22 Kanban 2

6 Sigma

History of Programming

Junk(First Software)

StructuredProgramming

XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity

3013 January 22 Kanban 3

6 Sigma

Waterfall

Junk(First Software)

StructuredProgramming

XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity

Wate

rfall

3013 January 22 Kanban 4

Waterfall = Big Design Up Front

The idea is that you can save time and

money later by thinking smarter now.

3013 January 22 Kanban 5

Big Design Up Front

But humans are not smart enough to do it.

3013 January 22 Kanban 6

Big Design Up Front

• Nobody knows what they really want.

• Nobody is smart enough to precisely

specify anything complex.

• Few people can imagine the details of a

system they can’t try.

• Needs change and keep changing, so if

you did ever get everything right, it is

wrong now.

3013 January 22 Kanban 7

Waterfall

3013 January 22 Kanban 8

Big Design Analogy: Cannon Fire

• You have an old cannon, a barrel of cannon balls and a barrel of gun powder. Hit the target with a cannon ball.

3013 January 22 Kanban 9

Big Design Analogy: Cannon Fire

Θ

3013 January 22 Kanban 10

Big Design Analogy: Cannon Fire

• On the other hand, if you just shoot the cannon a

few times, you are likely to get it by trial and error in

a few tries. (Ready, Fire, Aim)

3013 January 22 Kanban 11

6 Sigma

Agile

Junk(First Software)

StructuredProgramming

XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity

Agile

3013 January 22 Kanban 12

QuickTime™ and a decompressor

are needed to see this picture.

3013 January 22 Kanban 13

Small Bites = Agile

Small bites flow.

Big bites hurt, and they might kill you.

3013 January 22 Kanban 14

6 Sigma

XP vs. Scrum

Junk(First Software)

StructuredProgramming

XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity

3013 January 22 Kanban 15

QuickTime™ and a decompressor

are needed to see this picture.

2 Methodologies

There were 2 methodologies that came

out of the Agile beginning:

• Extreme Programming (XP) - Kent Beck

• Scrum - Ken Schwaber, Jeff Sutherland

Scrum won. XP was left in the dust.

3013 January 22 Kanban 16

XP Principles

Fine scale feedback

• Pair programming

• Planning game

• Test-driven development

• Whole team

Continuous process

• Continuous integration

• Refactoring or design improvement

• Small releases

Shared understanding

• Coding standards

• Collective code ownership

• Simple design

• System metaphor

Programmer welfare

• Sustainable pace

Coding

• The customer is always available

• Code the Unit test first

• Only one pair integrates code at a time

• Leave Optimization until last

• No Overtime

Testing

• All code must have Unit tests

• All code must pass all Unit tests before it can be released.

• When a Bug is found, tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write)

• Acceptance tests are run often and the results are published

3013 January 22 Kanban 17

QuickTime™ and a decompressor

are needed to see this picture.

Scrum

3013 January 22 Kanban 18

QuickTime™ and a decompressor

are needed to see this picture.

• Pure Scrum is well defined.

• Pure Scrum takes discipline that stops you from doing whatever you want.

• Pure Scrum is not agile!

Scrum ButTake the parts of Scrum that

you like; ignore the parts that

are hard, and hope it works

3013 January 22 Kanban 19

Continuous Improvement

If you can’t change it, it doesn’t get any better

3013 January 22 Kanban 20

6 Sigma

Kanban

Junk(First Software)

StructuredProgramming

XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity

3013 January 22 Kanban 21

Kanban - David Anderson

Agree to pursue incremental, evolutionary changeAgree that continuous, incremental and evolutionary change is the way to

make system improvements and make them stick.

Respect the current process, roles & titlesBy agreeing to respect current roles, responsibilities and job titles we eliminate

initial fears. This should enable us to gain broader support for our Kanban initiative.

Leadership at all levelsActs of leadership at all levels in the organization from individual contributors to

senior management should be encouraged.

QuickTime™ and a decompressor

are needed to see this picture.Start with what you do nowStart with the roles and processes you have and stimulate continuous, incremental and evolutionary changes.

3013 January 22 Kanban 22

David Anderson’s core practices

1. Visualize (card wall)

2. Limit Work In Progress (WIP)

3. Manage flow (measure and report)

4. Make policies explicit

5. Implement feedback loops

6. Improve collaboratively, evolve experimentally (using models and the scientific method)

3013 January 22 Kanban 23

Work In Progress

The work that you

are scheduled to do

can get in the way

of the work you

are supposed to

be doing now.

3013 January 22 Kanban 24

Work In Progress

Juggling takes a

lot of energy and

concentration.

You get less

useful work

done when you

are juggling, and

some things get

dropped (rot).

3013 January 22 Kanban 25

Work In Progress

20th Century scheduling

systems try to keep people

busy all the time by giving

them lots of task to juggle.

It keeps people busy, but the

lack of focus cause lots of

errors that lead to a long debug

cycle on every project.

3013 January 22 Kanban 26

Work In Progress

• Small bites (iterations, features…) give you

less to keep in your head and for less time.

• Finish one task before starting another. (Juggling is hard, but you can run with just one or two balls.)

• Break for another task, only if you are stuck. (You are now starting to juggle. Two balls is okay, three is possible.

Don’t do four. This is not a circus; you get no points for juggling.)

• Reorganize features, schedules, team

structure….anything to minimize the people

who can’t finish the task they started.

3013 January 22 Kanban 27

Manage the Flow

More and faster can lead

to chaos.

3013 January 22 Kanban 28

Flow

Tight

feedback

between

train cars

allows

hundreds

of cars to

travel

together

3013 January 22 Kanban 29

Flow

Figure where the “tracks” run.

Keep things moving, but don’t allow pile-ups.

Don’t make anything that can’t be used now.

Eliminate waiting time by removing bottlenecks

Faster delivery means faster feedback.

3013 January 22 Kanban 30

6 Sigma

Kanban vs. Scrum

Junk(First Software)

StructuredProgramming

XP

Scrum

RUPC.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity

3013 January 22 Kanban 31

Kanban vs. Scrum

Out of the box

Kanban

• White board rules

• Principles

Scrum

• Roles (With certification)

• A Daily structure

• A Bi-weekly structure

• Ceremonies

• Charts and Graphs

(More than just principles)

3013 January 22 Kanban 32

Kanban vs. Scrum

Cycles

Kanban

• No cycles - you pull some work and get it done as soon as possible.

(Agile without iteration)

Scrum

• Time box (usually 2 weeks)

• Daily standup

3013 January 22 Kanban 33

Kanban vs. Scrum

Measurement

Kanban

• Feedback is critical

• Cycle Time is the most important measurement

• Improvements come from measurements

Scrum

• Feedback is important

• Velocity is the most important measurement.

3013 January 22 Kanban 34

Kanban vs. Scrum

MagicKanban

• Fasted possible feature deliver rate

• Work In Progress limits

• Continuous Improvement

• You only have to change what is not working.

Scrum

• Well defined

• You only have to think about one clump of features at at time.

• No changes to the features you are working on.

3013 January 22 Kanban 35

Scrumban - Corey Ladas

• Use Scrum to setup a

disciplined structure

• Use Kanban to evolve the

structure into something

better.QuickTime™ and a

decompressorare needed to see this picture.

QuickTime™ and a decompressor

are needed to see this picture.

3013 January 22 Kanban 36

Questions?

Tomo Lennox:

Cell - 612-385-4326

Email - tomo@tomoLennox.com

Blog - tomoLennox.com

3013 January 22 Kanban 37

6 Sigma

Lean Development

Junk(First Software)

StructuredProgramming

XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity

3013 January 22 Kanban 38

Waste

The stuff you make, but don’t use is killing your schedule and budget.

3013 January 22 Kanban 39

Waste

• Features that no one uses

• Documents that no one reads

• Leaving tasks half done, (to rot) while

you do other things

• Inefficient communication

• Debugging

3013 January 22 Kanban 40

Waste (Lean Development)

Scrum and some other Agile methodologies require detailed estimation to make every sprint the same size.

This is waste.

Measuring features delivered over time tells you everything you need to know.

top related