KANBAN !=

KANBAN BOARD

Sudipta Lahiri22/11/2014

1

About me

25 years in the industry

Agile/Lean practitioner (75%)

Development of SwiftKanban and

SwiftALM products

Lean implementations of our products

Agile/Lean Coach (25%)

Run the LimitedWIP Societies in India

22/11/2014

2

Kanban Boards have become

common..

22/11/2014

3

Why? Lets see what happened

traditionally…

Project Managers do scope/work decomposition and assign tasks to people

Typically, done in a very deterministic manner

We make a MS Project schedule; gives a planned end date

Tasks start slipping

Multiple reasons: some in control of project team and some not...

Unscheduled tasks start coming in

Some anticipated and some unanticipated...

Defects: you don’t know how many will come and their flow

New RFPs/CRs that need to be estimated that may or may not ever fructify

Some visible to the Project manager and some not...

These get assigned to people who are already behind

Team members try to juggle between what is planned (and kept on schedule) + new arrivals!

In most cases, people avoid re-prioritization (you can’t do it for every incremental piece)

As a result:

Planned tasks start slipping

Quality drops because people multi-tasking and context switching

Management asks questions but very difficult to justify and show the problem!

Teams works in a reactive mode (as opposed to a planned proactive manner)

Team feels there is no time to breathe... the pressure seems endless!

4

22/11/2014

How a “Board” changes this?

Shows all work items, their current state of progress and the people who are on it

Work items move forward as they progress!

Brings out many “hidden” things that people are working on

Makes it obvious where work is getting piled up to everyone

You will see this when we show this in a fast simulation model

Colors help you visualize the pattern of work

For e.g., are you doing more value enhancement work or more rework?

Help collaborate between the project team:

Everyone knows what others are working on

If someone needs help, they can “block” without escalation/follow-up

If someone is overloaded, others in the team can respond

Provide for additional social tools to collaborate within project team

Chat/Threaded Discussions

All this can be done even for a Waterfall project!

5

22/11/2014

But... the board was just the

start!

22/11/2014

6

The 6 principles of Kanban: Visualize the Work

Map your value stream

Making invisible work, visible!

Limit Work in Process (WIP)

Manage Flow; Establish a Cadence Remove bottlenecks and improve the flow

Increase throughput

Make Process Policies Explicit

Improve Collaboratively, Evolve Experimentally (using models and scientific method) Implement Feedback Loops

Kanban’s objective:

Kanban is meant to be adaptive capability for

evolutionary change

Not a process definition or a framework to be

tailored

Drive to a culture of Continuous

Improvement

7

22/11/2014

But… why are we doing all this?

22/11/2014

8

The same “drivers” for anyone wanting to do

Agile!

Faster Value to Customer

• We exist for the customer!

Early Feedback

• Requirements have been weak!

• Frequent and regular demos

Make Continuous Improvement a

Habit!

• Never by happy with where you are!

Faster value to Customer!

22/11/2014

9

Measured by Cycle Time/Throughput

How to get there?

22/11/2014

10

With Kanban principles of Pull and WIP reduction

resulting in Flow

Defining Requirements that are small and

independent

Moving forward to make Regression testing faster

Let’s talk about these in the next few slides

Lean principles for “faster” value to

customer:

We don’t want to build features that nobody needs right now Write more specs than we

can code

Write more code than we can test

Test more code than we can deploy

Implemented with “buffer” lanes at hand-off points

Reduces multi-tasking Prevent context

switching Performing tasks one-

at-a-time yields results sooner

Maximizes throughput

Enhances teamwork Working together to

make things done Increase cross-

functionality 22/11/2014

11

Pull based execution Limit WIP

Flow

Flow

22/11/2014

12

Defining Requirements

22/11/2014

13

Agile teams that are used to User Stories (in the true spirit) don’t have this issue

For the rest of the community, defining Requirements using the “INVEST” model is a huge challenge:

We are used to a Scope Decomposition OR a Task Decomposition OR a combination of both

Sometimes, its a process drives work decomposition

Breaking them into small independent requirements is almost mission impossible!

User Story

22/11/2014

14

User story has a lot more context and significance than just small, independent requirements

If you have a well defined Requirement document from the customer, then trying to fit this in the User Story format is not most appropriate

However, you still do need to try and break this up into small independent requirements! Use methods like “User Story Mapping”

If you have decomposed the Requirement in a traditional manner, trying to decompose them as per the INVEST approach is near impossible! Start fresh!

Making regression faster!

Manual testing not an option!

TFIRSTDD is utopia...

The significance of “Testing” pyramid

Try hard not to land up with a “Inverted Testing” pyramid

22/11/2014

15

The key drivers... revisited

22/11/2014

16

Faster Value to Customer

• We exist for the customer!

Early Feedback

• Frequent and regular demos

Make Continuous Improvement a

Habit!

• Never by happy with where you are!

Early feedback/demos

22/11/2014

17

Make this part of the value stream

Functional

Demo to

Customer

Make Continuous Improvement a

habit!

22/11/2014

18

Involve the team; don’t make a Project

Manager only effort

Retrospectives, Retrospectives and

Retrospectives!

Templates abound...

22/11/2014

19

Sample template...

Our weakness

22/11/2014

20

Unfortunately, very little happens between

each retrospective

Slowly people lose faith in the retrospectives

Many causes are linked to organizational

issues and hence, beyond control

KRAs to encourage “lean”

behaviour...

22/11/2014

21

KRAs to encourage “lean”

behaviour...

22/11/2014

22

Having discussed the key

drivers...

22/11/2014

23

Faster Value to Customer

• We exist for the customer!

Early Feedback

• Frequent and regular demos

Make Continuous Improvement a

Habit!

• Never by happy with where you are!

... how do we figure where we are in this journey?

An approach to gradually measure and

improve your “lean” behaviour...

Depth of Kanban

22/11/2014

24

Measuring Kanban

Implementations

Use of “Kiveat” diagrams (Excel calls as

“radar”)

25

22/11/2014

Defining scales for

standardization For “Visualization”

Visualizing all Work elements

Of different Work Item Types

Workflow

Kanban Limits

Ready for pull ("done")

Blocking issues (special cause variations)

Capacity Allocation

Metrics-related aspects such as - lead time, local cycle time, SLA target

Inter-work item dependency (incl hierarchical, parent child dependency)

Inter-workflow dependency

Other risk dimensions - cost of delay (function shape & order of magnitude), technical risk, market risk

Score 1 for each aspect of visualization

For “Limit WIP:

Deferred commitment & dynamic staff assignment (no WIP limits) aka “last responsible moment”

Proto-kanban

Personal Kanban

WIP limit per person

workflow with infinite limits on "done" queues

Single workflow full pull system with WIP limits

Multiple interdependent workflows with pull system

Simple taxonomy of 4

26

22/11/2014

Defining scales for

standardization For “Manage Flow”

Daily meetings

Cumulative Flow Diagrams

Delivery rate (velocity/throughput)

control chart

SLA or lead time target

Flexible staff allocation or

swarming behaviour

Deferred pull decisions, or

dynamic prioritization

Metrics for assessing flow such as

number of days blocked, lead time

efficiency

Score 1 for each technique in

use

For “Make Policies

Explicit”

Workflow/Kanban System

policies explicit

Pull criteria (definition of

done, exit criteria)

Capacity allocation

Queue replenishment

Classes of service

Staff allocation / work

assignments

Score 1 for each aspect

made explicit

27

22/11/2014

Defining scales for

standardization For “Feedback Loops”

How many of the Kanban Kata are present?

Regular team meeting (typically daily) in front of

board or kanban system software

Mentor-mentee relationship between superior

and subordinate used to coach management

and

continuous improvement

Operations Review - business unit or

organization level, qualitative & quantitative

review of data from multiple kanban systems

to provide inter-workflow feedback

mechanism

Simple taxonomy of 3 (it is currently

assumed Ops Review does not exist without

a mentor-mentee relationship already

existing) Score 1 for each technique in use

For “Improve collaboratively, evolve

experimentally”

Evidence of local process evolution -

changes to workflow, policies, WIP limits

Evidence of increasing depth of Kanban

implementation on other 5 practices

Evidence that process evolution was model-

driven -use of metrics, identification of

bottlenecks, common/ special cause

variation, transaction/coordination costs,

other models not specified in current

literature

Evidence of process or management policy

evolution as a result of mentor-mentee

relationship

Evidence of inter-workflow process or

management policy evolution as a result of

operations review

Taxonomy of 5 (assumed there is an

adoption sequence & that 5 would not

happen before 4)

28

22/11/2014

SWIFT-Kanban Dev Team (Jan 2013)

29

5

3.52.5

8

22/11/2014

In closing...

22/11/2014

30

The benefits of Kanban don’t end with a Board

Use the Board to gain all the benefits of

transparency and visualization...

Continue the journey for simpler and “lean(er)”

execution

Reduce WIP, multi-tasking

Inducing pull and flow (vs) bottlenecks/working in

batches

Early feedback and faster value to customer

Reach me at:

@sudiptal

slahiri@digite.com

sudiptalahiri.wordpress.co

m

22/11/2014

31