Kanban in sw development

Kanban in SW developmentOur experience

Daniel Céspedes Daza

Agenda

1. Kanban in a nutshell2. Kanban in SW development3. Scrum – Kanban similarities4. Scrum – Kanban differences5. How to apply Kanban6. How we applied Kanban in our project7. Conclusions8. Questions9. Sources

1-Kanban in a nutshell• Kan-ban (看板 ) = Signal-card.

1-Kanban in a nutshell - JIT• In the late 1940s, Toyota started studying store and

shelf-stocking techniques from supermarkets

Taiichi Ohno

1-Kanban in a nutshell – Queue Mgmnt

• Cashier focuses on taking order• Barista focuses on supplying coffee• Separated by queue allowing variable demand

to be “absorbed”• Cashier moves to help Barista when no

customers waiting to order• Focus is on end to end FLOW = customer-centric

1-Kanban in a nutshell – Process Mgmnt Tool

PrinciplesMake work VisibleLimit Work In ProgressHelp the work Flow

2-Kanban in SW developmentThe Kanban method formulated by David J. Anderson.

1st virtual kanban system for SW engineering was implemented at Microsoft en 2004

Kanban method as an approach to change started to grow after Agile 2007 in Washington DC

2-Kanban in SW development• Is an approach to change management.

• It isn’t a software development process or project management methodology.

• Kanban is an approach to introducing change to an existing software development process or project management methodology.

2-Kanban in SW development• Kanban leverages many of the proven concepts from Lean including:

• Defining Value from the Customer’s perspective

• Limiting Work in Progress (WIP)

• Identifying and Removing Waste

• Identifying and Removing barriers to Flow

• Culture of Continuous Improvement

2-Kanban in SW development

• Kanban encourages incremental evolution of existing processes.

• Kanban does not ask for a revolution of how people work, rather it encourages gradual change.

2-Kanban in SW development• Kanban is based on a very simple idea. Work In Progress (WIP) should

be limited.

• The kanban (or signal card) implies that a visual signal is produced to indicated that new work can be pulled because current work does not equal the agreed limit.

3-Scrum – Kanban simmilarities

4-Scrum – Kanban differences

5-How to apply Kanban?

• The principle of Kanban is that you start with whatever you are doing now.

• You understand your current process by mapping the value stream.

• You agree to WIP limits for each stage in that process.

• You then start to flow work through the system by pulling it when kanban signals are generated.

5-How to apply Kanban?• Visualize the workflow

• Split the work into pieces, Stories we already do that.• Use named columns to illustrate where each item is in the workflow.

• Limit Work In Progress (WIP) – assign explicit limits to how many items may be in progress at each workflow state.

• Measure the lead time (average time to complete one), optimize the process to make lead time as small and predictable as possible.

5-How to apply Kanban?

Lead Time = Customer View

Cycle Time = Internal View

6-How we applied Kanban in our project?

• Process – we modeled our process

• Work – we decided the unit of work

• WIP limits – limit WIP to help work flow

• Policy – set quality policies

• Bottlenecks and flow – move resource to bottlenecks

• Class of Service – different work has different policies – done definition for each state

• Cadence – Releases, Plannings, Reviews

6-How to apply Kanban in our project?We modeled our process

6-How to apply Kanban in our project?Value Stream

6-How to apply Kanban in our project?

6-How to apply Kanban in our project?

iProtect : internal

6-How to apply Kanban in our project?

7-Conclusions

History:  Team: 14 members, 8 at Arg, 6 at US. 2 years doing Scrum with 1-week sprints (3 years Scrum in total) before shifting to Kanban

Kanban implemented 6 months ago on TFS (Visual WIP) with some Scrum practices (PO, Scrummaster, standup, review, retrospective)

7-Conclusions

BenefitsSimplified “pull” system to the team, visibility on workflow and bottlenecksStories defined as per valuable product rather than to fit within an iteration, with less and clearer gauges (lead time, WIP limit) with more focus on work productWith clearer “Done” criteria for each column (state of a work item) quality became integral part along dev process. Stabilization reduced from 2 months to 2 weeks.

7-Conclusions

To-doStill difficult to have mid-long term visibility (e.g. done-not done for next release)Results1st release done March with 15 stories and 160 bugs fixed. Beta released 2-month ago to experts and early adopters (1st time a beta is provided).Lead time 60 days average per story, while with Scrum it was ~90. (lead time ~45 days for next release).

8-Questions

Sources

1. Kanban - Wikipedia2. Lean Manufacturing - Wikipedia3. Taiichi_Ohno - Wikipedia4. TechDays Kanban5. Hydra Pros Cons discussion6. Kanban by Dave J Anderson

iProtect : internal