Magic of Kanbanmydlc.com/pmi-mn/PRES/2013A01_MagicKanban_TLennox.pdf · 2014-05-26 · 3013 January 22 Kanban 21 Kanban - David Anderson Agree to pursue incremental, evolutionary

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


6 Sigma

Waterfall



XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity

Wate

rfall


Waterfall = Big Design Up Front

The idea is that you can save time and

money later by thinking smarter now.


Big Design Up Front

But humans are not smart enough to do it.


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.


Waterfall


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.



Θ



• 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)


6 Sigma

Agile



XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity

Agile


QuickTime™ and a decompressor

are needed to see this picture.


Small Bites = Agile

Small bites flow.

Big bites hurt, and they might kill you.


6 Sigma

XP vs. Scrum



XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity




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.


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




Scrum




• 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


Continuous Improvement

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


6 Sigma

Kanban



XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity


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.


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.


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)


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.


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).


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.


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.


Manage the Flow

More and faster can lead

to chaos.


Flow

Tight

feedback

between

train cars

allows

hundreds

of cars to

travel

together


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.


6 Sigma

Kanban vs. Scrum



XP

Scrum

RUPC.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity


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)


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


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.


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.


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.




Questions?

Tomo Lennox:

Cell - 612-385-4326

Email - [email protected]

Blog - tomoLennox.com


6 Sigma

Lean Development



XP

ScrumRUP

C.I.

Kanban

The Navy

Way

OOP

Rapid

prototyping

CMMCMMI

PMBOK

Lean Dev.

TSP/PSP

Time

Pro

du

ctivity


Waste

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


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


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.