Visualizing the value chain

Kanban - Chapter 6

Introduction

• Kanban optimizes the existing process• introduction of Kanban doesn’t change

workflow, job titles, roles, responsibilities or specific work practices→ avoidance of opposition

IntroductionMain goals of improvement

• optimizing the WIP• interfaces and interactions with up- and

downstream stations of the business process

Depict the value chain’s actual process, not the official one which isn’t really used.

1. Defining a start and end point

Where should the process visualization start? Where should it end?

→Interfaces to up- and downstream organization units

1. Defining a start and end point

• Successful teams:• visualization using cards• WiP restriction in the area you are able

to control yourself• new rules with up- and downstream

process partners

2. Task typesExamples:• Request• Feature• User Story• Use Case• Change Request

• Production error

• Maintenance

• Refactoring

• Bug

• Improval request

• Blocker

2. Task typesFurther possibilities:

• hierarchical task types(e.g. Epic = collection of User Stories)

• indication of source in the name(e.g. legal request, external work request, request for strategical planning)

2. Task typesTypical task sizes:

• small (a few days)• medium (< 1 month)• large (≥1 month)

• one service class per task size• visualization using ticket colors or swim

lanes

3. Drawing a Kanban board

• Kanban visualizes work, not persons, functions or function transfers

• sketching of the process (e.g. flow chart, stick figures, …)

• defining the Kanban board

3. Drawing a Kanban board

Defining the Kanban board:• columns represent work execution• column order = work order• start using a wipeable pen (changes

possible)• later e.g. vinyl strips

3. Drawing a Kanban board

Defining the Kanban board:• Splitting of columns: • visualization of the input

queue + downstream steps• adding of buffers and queues by

demand (visualization e.g. using cards turned by 45°)

CodingIn

progress Done

4. Demand analysisDemand analysis for every task type

• data from previous work exists: Use it for quantitative analysis

• no data exists: Reconstructed, subjective analysis

4. Demand analysisExample: Microsoft XIT

• PTCs:arrival in batches, small and quickly realizable→ negligible effects

• change requests:continuous arrival rate→ arrival rate can be visualized in a diagram→ Kanban system can be provided with fitting resources

• requests with seasonal demand→ assess demand and adjust Kanban

5. Distribution of capacity by demand

• Swim lanes per task type• Capacity of swim lanes by demand in %

5. Distribution of capacity by demand

• Swim lanes per task type• Capacity of swim lanes by demand in %

Arrival of a batch of PTCs:• reduced adherence to schedules• longer cycle times• bad predictability

5. Distribution of capacity by demand

• Swim lanes per task type• Capacity of swim lanes by demand in %

PTCs are allowed to exceed WIP• prevention of idle time• bad predictability with many PTCs

6. The ticket structure• informations must support the pull system

• enable employees to make their own decisions

• transparency over processes, project goals and risks

• self-organizing risk management mechanism• respect for the individuum• trust in the system

6. The ticket structure

Example

7. Electronic tracking

• essential for geographically distributed teams

• higher degree of organizational maturity

7. Electronic trackingExample software• Jira• Microsoft Team Foundation Server• Fog Bugz• HP Quality Center

Web solutions• Lean Kit Kanban• Agile Zen• Target Process• Silver Catalyst• Rad-Track• Kanbanery• VersionOne• Greenhopper for Jira• Flow.io• Kanbanize• Trello

8. Defining in- and output boundaries

• transparency for your own work• maybe later inclusion of up- and

downstream organization units

8. Defining in- and output boundaries

Input:Engineering

Ready

Output:Deployment

Analysis unit• reports to

different manager

development unit

little

trust

Distribution unit

no longer of concern

9. Handling concurrency

Concurrency:

• Two or more activities are taking place at the same timeExample: Software and test development

9. Handling concurrency

Solutions for modeling concurrency:

A. no model• shared column for both activities• multiple ticket colors or shapes

B. vertical splitting of the board into sections• markup mechanism for connecting tickets• e.g. connect upper right ticket corner• connect using an electronic ticket system

10. Handling non-sequential activities

Strategies:

A. ・ 1 column as container for multiple activities・ small checkboxes・ all boxes checked: ticket can be pulled

B. ・ tickets move vertically・ pull into areas for current activities

Conclusion• Define borders• Define task types• Model the flow through the system• Model the tickets• Use an electronic ticket system• Model concurrency• Visualize non-sequential activities