Moving to Kanban

Tomas Sakalauskas

About me

• Lost 13 years in pursuit of best SW development methodology …

• … to find out there is none

Currently• Managing director of Prewise, UAB• Product manager of Eylean

Disclaimer

• I have no clue what Kanban is• It sounds good, like Agile or Scrum, so people

should attend the session ;)

Stop starting start finishing

Why Kanban?

• Minimal entry barrier• Flexible resource planning and using• Sometimes time-boxing doesn’t work• Focus on whole value stream, eliminates

inessential waste:– Artificial work breakdown– Estimation, planning and retrospectives for artificial

stories• Supports integrated processes

You have all it takes!

• Start with what you do now• Agree to pursue incremental, evolutionary

change• Respect the current process, roles,

responsibilities & titles

Kanban properties

• Visualize workflow• Limit WIP• Manage flow• Make Process Policies Explicit• Improve Collaboratively

#1. Visualize workflow

• Shared understanding of where you are• It may be ugly at first

The most basic board

#2. Limit WIP

• Less multitasking – less context switching• Better quality• No WIP limit = queue!• Queues increase cycle time, risk and overhead

Limits

Backlog

Lifecycle

Queue

Day 0

Day N

Pull not push

• Work items should be pulled into available spaces

• If stuck, something should be improved:– Help needed in downstream processes– WIP limits are wrong for the team– The task transitioned too early

– Don’t miss a learning opportunity

Releases

• Decouple release from development– Release whatever has been completed since the

last release– Regular releases without artificialness that

iterations impose• Goal oriented releases– Release when it’s ready– Meaningful releases without the risks of last-

nights work imposed by time-boxing

Blockers

Priority Lane

Multiple Projects

Multiple Projects

Deployment

Kanban team

• Continuous planning• Daily standup:– What can we do with blockers?– What can we do with bottlenecks?– How to move WIP items faster?

• It’s OK to find defect while packing the release. Pull the feature or delay the release

#3. Measure and improve flow

• Velocity could also mean a rate at which defects are produced!

• Flow metrics:– Active WIP vs. buffered WIP– Active time / cycle time– Blocked time / cycle time

• Outcome metrics:– Bugs in process– Failure demand / value demand

#4. Make Process Policies Explicit

• How to improve when no-one knows how it’s actually done?

• Don’t spend too much time – policies will evolve

• Example policies:– Kanban board columns– WIP limits– State transition policies

#5. Improve collaboratively

• There is no Kanban Software Development Process

orKanban Project Management Method

• Value stream is built by people for people• Improvement actions are agreed by consensus

Kanban in Eylean team

• Two asynchronous processes:– Goal oriented JIT planning:

• Decisions deferred till information is available• The only questions to be answered:

What should be done RIGHT NEXT and WHY?

– Production:• Do your BEST on current feature• Finish before you start!

• Spontaneous improvements to process and product

Product development is complex

• Self-organizing, non-linear, feedback systems are inherently unpredictable, they are uncontrollable

D. Meadows

• I wish someone told me this 13 years ago ;)

Celebrate failures too!

• Storing avoidance of failure patterns is a more successful strategy for the brain than imitation of success

ALE2011 closing keynote by David Snowden

Questions?

tomas.sakalauskas@prewise.lt