agile series - kanban

Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.

Kanban

Speed, Scale, Skills, Simplicity

http://www.flowcracker.com

1

Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.

Principle Consultant – Durgaprasad B. R

2

Durgaprasad B. R 20+ Years of IT experience B. E (E & C), Alumni of

IIM,Bangalore Certifications

PMI-PMP, PMI-ACP SCP from Scaled

Agile Academy

Durgaprasad B. R 20+ Years of IT experience B. E (E & C), Alumni of

IIM,Bangalore Certifications

PMI-PMP, PMI-ACP SCP from Scaled

Agile Academy

Developer, Project/ProgramManager, Location DeliveryHead, Agile Coach

Industries: Telecom,Healthcare, ConsumerElectronics, Automotive

Past few Clients: Avaya,Nortel, ALU, Microsoft,Qualcomm, Intel, Toshiba,Continental

Technologies: WebTechnologies, Embedded,Legacy large systems

Developer, Project/ProgramManager, Location DeliveryHead, Agile Coach

Industries: Telecom,Healthcare, ConsumerElectronics, Automotive

Past few Clients: Avaya,Nortel, ALU, Microsoft,Qualcomm, Intel, Toshiba,Continental

Technologies: WebTechnologies, Embedded,Legacy large systems

Led large Telecomprograms, IP Switches,Voice Messaging System,Contact Center, ConsumerElectronics products,Automotive productdevelopment

Well versed in new agetechnologies as well as sun-set technologies

Trained and coachedindividuals and teams onAgile, Kanban, Scrum andSAFe methodologies

Regular public workshopson PMP, ACP and SAFeCertifications

Led large Telecomprograms, IP Switches,Voice Messaging System,Contact Center, ConsumerElectronics products,Automotive productdevelopment

Well versed in new agetechnologies as well as sun-set technologies

Trained and coachedindividuals and teams onAgile, Kanban, Scrum andSAFe methodologies

Regular public workshopson PMP, ACP and SAFeCertifications

http://www.flowcracker.in/about-durgaprasad-b-r/Contact: [email protected]. Cell: 9845558474


LeanDevelopment

Toward beingSAFe™

Agile Scrum

KanbanXP – ExtremeProgramming


THE OATH OF NON-ALLEGIANCE

I promise not to exclude from consideration any idea based on its source, but toconsider ideas across schools and heritages in order to find the ones that best suit thecurrent situation.

- DURGAPRASADhttp://oathofnonallegiance.com/


LeanDevelopment

Toward beingSAFe™

Agile Scrum

KanbanXP – ExtremeProgramming


Kanban

Kanban - Introduction Kanban Principles &Practices


“Change begins with small things”


Definition of Kanban

Kanban isa scheduling &

a change management system.


A scheduling system

Kanban is a scheduling system that determineswhat to produce,

when to produce andhow much to produce


Change management process

Kanban is achange management process/approach

that can be applied to any existing process.


Things to know• Kanban : A Japanese Word - Literal meaning “Sign card”• Developed by – Taiichi Ohno @ Toyota

• Adopted to Software by David J. Anderson• Kanban was never designed for Agile• Kanban doesn’t contradict Agile manifesto.

• Kanban is neither a project management or development method.

• It is used for “workflow management” and has wide use across differenceprocesses and even industries.

• The beauty of Kanban - it can be used as a standalone methodology orused alongside other methodologies

Kanban Pre-requisite : “Sense of Urgency”


Original Kanban System

@Toyota Motomachi Plant, Japan

“Under this setup, employees created signboards, or kanban, totransfer information between processes, such as the number of partsthat had to be filled. The Kanban System eventually helped theproduction flow function more smoothly, a fact reflected in quality andproductivity. Kanban took on many forms as part of the Just-in-TimeSystem.”http://www.toyota-global.com/company/toyota_traditions/quality/mar_apr_2004.html


Kanban (from Wiki)

Kanbans (sign card) maintain inventory levels, a signal is sent to produce and deliver anew shipment as material is consumed. These signals are tracked through thereplenishment cycle and bring extraordinary visibility to suppliers and buyers.

Pupose Logistics control systemImplemented at ToyotaDate Implemented 1953 http://en.wikipedia.org/wiki/Kanban


Kanban

Kanban is like a chessboard. Helps to visualizethe plan better.

However, a game isn’tchess, just because it’splayed on a chessboard !

Similarly, it isn’t kanban justbecause you are using akanban board.


Kanban Board

To fully adapt kanban,the understanding offollowing will be useful:

Theory of constraintsSystems thinkingUnderstanding of

variabilityConcept of waste from

TPS


Why Kanban ?• Increases visibility of the project flow to everyone in the team and

management

• Allows the team to deliver product/services faster and betterquality due to WIP limits

• Makes hidden problems visible and makes it everyone’s (team)problem to be addressed

• Removes waste, reduces effort & brings focus

• Limiting the WIP, connects the disconnected process. Connectedprocesses makes the problems visible.

Alongside streamlining the process, the changes achieved aresustainable in nature.


What Kanban isn’t?

Kanban is not a team optimization method. It isa value creation chain optimization method.

It is about optimizing FLOW and not the team.

17

Team Performance Optimization ≠ Value Creation Optimization


“All we are doing is looking at the timeline,from the moment the customer gives us an order

to the point where we collect the cash.

And we are reducing the time line by reducing thenon-value added activities”

Taiichi Ohno


Vicious Circle of being busy

19

Need Flow Control to get out of vicious cycle of overwork.

I want ityesterday

Quick FixResidual

Effect/TechnicalDebt

Work on UrgentThing/Important Task Switching

Increases CycletimeIncreased Backlog


Kanban

Kanban - Introduction Kanban Principles &Practices


Kanban Implementation

David Anderson –father of kanban for software has defined

foundation principles to followand

core practices to adapt

for successful implementation of Kanban


Kanban Foundation Principle

1. Start with whatyou know

2. Agree to pursueincremental,evolutionarychange

3. Respect currentprocess, role,responsibilities andtitles


Kanban Core Practices

1. Visualize

2. Limit WIP

3. Manage Flow4. Make Process

policies explicit

5. Implementfeedback loop

6. ImproveCollaboratively

Shallow implementation

Deep implementation

Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. 24

Start with Shallow adoption by “Visualizing”. Then apply WIP limit,Manage flow and others ……


Visualize

1. WorkitemIdentification /Kanban Cards

2. Value StreamMapping

3. KanbanBoard/Wall

FeaturesSpikeBugsUser StoriesQuality Requests


Workitem types

Features

Spike

Bugs

User Stories

Quality Requests

•Work item types can be different in differentwork contexts

•Work item may have different workflowsteps, hence different VSM

•Each work item will have a kanban card andof different colors

•If the workitem is large and can be splitindependently, teams should do so, toimprove the flow


Kanban Cards• Can add additional data like

• Unique ID number• Short Description• Detailed description• Priority : High, Medium, Low• Initial Estimate• Updated Estimate• Acceptance test cases• Requested By• Assigned To• Notes• Capture more date related info as card

moves from left to right at each column.• Avatars - Identification (thumnail

picture/icon) for team members on the cardto indicate assigned to

Service ContractsNotify all Service Contractrenewals before a pre-configured date (e.g. 15 days)

Dates:Request Start Delivered

01/10/2013 14/10/2013 17/10/2013

Cycle Time = Delivery date – Start dateLead time = Delivery date – request date

Sample Kanban Card


Kanban Cards• Kanban cards can contain the following

(but not limited to) information:• Feature / User story details• Data to collect Metrics

• Project teams can define their ownkanban cards. No standards exist for thecard size, information collected etc.

• User story cards, feature cards, epic cardformat used in Scrum can also be used inKanban

• Teams can use different colors toindicate priority or activity type or classof service or assigned users

Service ContractsNotify all Service Contractrenewals before a pre-configured date (e.g. 15 days)

Dates:Request Start Delivered

01/10/2013 14/10/2013 17/10/2013

Cycle Time = Delivery date – Start dateLead time = Delivery date – request date

Sample Kanban Card


Value Stream Mapping

• Used to understand visualize current system,future system and eliminate waste


Value Stream Mapping• Tool to support attainment of strategic objective• Used to map future state map to focus on improvement towards shared Direction• Don’t use VSM map of the current map to highlight problems and jump to fix it.• The goal of drawing the current VSM is not to see problems, wastes, improvement

opportunities, but to provide the bases for designing a future state

•

CurrentState

FutureState

(not defined)Unclear Territory

Adopted from Mike Rother/Improvement Kata


Kanban BoardKanban Board helps to Visualize the

work and an area for the team tointeract

Start with a simple task board with 3Columns

- Backlog(prioritized items)- Work In Progress- Done

Each card is a work item. The currentwork items may be large batches.


Work Item identification• Advantage with software world

• Any software activity can be split up intosmall work items which can be

• Done independently (with proper sequencing)

• Develop work items in a continuous flowdelivering incremental value to customers

• Unlike manufacturing, Kanban insoftware does not use physical cards onthe trays.

• In software kanban, the kanban cards arevirtual and represented on the boardrepresenting the status of the workitems.


Workspace for Kanban board

• Use a wall, board (cork board, blackboard, white board) for your kanban

• Ideally it should be visible when youenter/exit team workarea

• Plan for enough space for the teamto stand in half circle comfortably infront of the board and havediscussions

33

Be innovative and design your own Kanban


Kanban BoardReady list

In development projects, the Backloglist, should reflect the currentunderstanding of the business needs

In operations and support projects, theBacklog list, reflects the pending tasksassigned to the team.

In case the backlog list is huge, this canbe omitted from the board, whenthere is a “To Do” or “Waiting”column with selected work items



1. Visualize

2. Limit WIP


policies explicit




Deep implementation


Kanban BoardProblem with simple task board

Accumulation of too many WIPwork items

Results in multitasking which inturn results in contextswitching

Cost of multitasking can be fatal!!!

36

“To do two things at a time is to do neither “– Publilious Syrus, a Latin writer 100 BC


Kanban Board –Cost of multitasking

Problem with multitasking

Accumulation of too many WIP work items

In knowledge work, we need to keep lot ofinformation is present in temporary memory

On context switching, this information is flushedout and new information is loaded.

Reloading the flushed out information, needsinformation to be reconstructed which maybe time consuming, error prone and stressful

The escalating cost of this switching activity canbe high and needs to be avoided

37

Multitasking has multiple impact – time, quality, ability to think deeply

(From Gerald Weinberg research)


Kanban BoardSolution: Regulate the amount of cards on the board

Need the follow “Stop Starting, Start Finishing” rules byevery one

How to enforce this rule?

Define WIP Limits

Regulate number of cards on the board

This can be done by defining the multitasking limits perstage

e.g. Team size = 4 & Multitasking limit = 2, then WIP limitcan be 4* 2 = 8

38

Limiting WIP means more valuable work to be completed faster


Why limit Work in Progress ?• Focus should be on completing the work in hand than picking up new work.

Hence“Stop Starting. Start Finishing”

• Avoids multi-tasking : discourages team members to keep aside problematic workitem and pickup another work item

• In case of major obstacles, the team needs to put all-heads-together and bail out the teammember from the current obstacle

• Delivery value as fast as possible at regular interval. Avoids piling up of WIPinventory

• Context switch from one task to another decreases productivity (~20%+)

• Avoids Procrastination: Forces the organization in removing the impediments(obstacles)

Stop and fix problems


Kanban Board

Queue itself should have limit, to cushion variations from upstreamprocesses

Problem: The inflow of work items are asynchronousand irregular. Asynchronous and irregular flowaffects flow and prioritization due to work itemvariations.

Solution: Define buffer (queue) to cushion out thesevariations.

Define a “To Do” or “Waiting” queue in betweenBacklog and WIP.

This To Do queue controls the variations in the inflow ofwork. This also acts as a ideal work planningprocess to help the team to pick the next highpriority task to do. The To Do should also be limited.

Product owner will be responsible to fill up this queue,whenever, kanban cards are less than the WIP Limit


Kanban Board

Stop Upstream Process, if down stream process is not busy.Use upstream efforts to resolve downstream bottlenecks.

WIP Limit – What does it mean ?

If a particular Queue is filled up, theupstream process will halt.

Since, WIP is full, upstream process To Docannot accept new work items beyondits WIP limit.

The team focus, will be to complete items inWIP and move it to Done, to ensuresmooth flow.


Kanban Board

Pull Work … Not …. Push Work

What is “Pull” System ?

- The science behind Lean/kanban

Suppose Team member “C”,completes a work item, then “C”,the work item will move into Done.

“C” can then pull the work item from“To Do” into WIP

Another Work item can then getpulled from “Backlog” queue to“To Do” Queue


Kanban Board

Have the right people at the right place at the right time to ensure thework item gets “Done”

Problem: If you see no dailyprogress on the board

WIP is the bottleneck and theslowest. There may bemultiple subqueues withinWIP waiting to be completed

Break it down and make itvisible

Ensure there is a seamless“FLOW”


Kanban Board

Encourage Change

Analyzing or designing toomany stories, withoutcompleting results in Waste

Keep To Do slim – focus effortsin completing activities thanupfront analysis and design

Prioritize just in time – helpsmanage change. Changesdoes not affect the team asteam has not put any effortin upfront analysis or designof unscheduled work item


Kanban Board

Teams Organized by specialization. Resulting in handsoffs.Consider Cross Functional Teams.


Kanban Board

Kanban systems create a positive tension in the workplace that forcesdiscussion of problems …..

Increase in WIP or any Queue, meansincrease in time to deliver in near future

The Queues start building up right in front ofus immediately following a blockage

Blocked up queues will slow down the entiresystem and flow

It is important to see this blockage andimmediately attend to it.

Limit, Queue size and the age of the workitem within the Queue are leadingindicators of problem we will encounter

Empty neck indicates bottleneck gettingformed in the upstream process


Kanban Board

Kanban exposes bottleneck thus throwing up opportunities to fix andimprove. Makes it easy to see problems, improve and learn from.

Expose Sub queues to understand the exact status of the work items.


Flow – specialized vs. cross functional

In Kanban, cross functional teams are optional.

In case of specialist teams, the task are assigned column wise

In case of cross-functional team, the task is assigned to a developer or afeature set team, row wise end to end and WIP limits defined row wise.


• As a thumb rule (and when clueless),• start with an average WIP Limit of 2x

• (x = number of team members).

• When the understanding of WIP limitimproves, slowly change the WIP limit.


WIP Limit and Slack• Use WIP limits to create slack. Don’t utilize team 100%

• Use that slack time to allow team members to participatein process improvement activities

• When the team faces blocking issues, the team memberscan swam on problems to resolve it

• Planning for slack also allows team members to addressexpedited issues without delaying work in hand


Limit WIP - Summary•Focus should be on completing the work in

hand than picking up new work. Hence “StopStarting. Start Finishing”

•Avoids multi-tasking : discourages teammembers to keep aside problematic workitem and pickup another work item

• In case of major obstacles, the team needsto put all-heads-together and bail out theteam member from the current obstacle

•Delivery value as fast as possible at regularinterval. Avoids piling up of WIP inventory

•Context switch from one task to anotherdecreases productivity (~20%+)

•Avoids Procrastination: Forces theorganization in removing the impediments(obstacles)

Stop and fix problems

Pull Work … Not …. Push Work



1. Visualize

2. Limit WIP


policies explicit




Deep implementation


Manage Flow

Roles andResponsibilities

•Principle: Respectcurrent roles andresponsibilities

•Managers – ServantLeaders, Coaches

•Managementresponsible for CI

•Not prescriptive ofceremonies

•Most of the teamsadopt ceremoniesdefined in Scrum

•Waste – meetingswith no value

Ceremonies Bottleneck Measurement


Manage Flow

•Agreeing on regularcadence improvespredictability

•Two Types of cadence•Output / Delivery• Input/Prioritization

•Team members takedecisions through consensus

•Need to recognize role ofleadership & team expertise

Improvements Candence/Heartbeats

Self OrganizingTeams


Roles in Kanban• Kanban is not prescriptive about roles and responsibilities

• On implementing kanban, roles and responsibilities can evolveas part of the continuous improvement process

• Most of the new Agile projects /teams, adopt the roles clearlydefined in Scrum

• Product Owner• Team Members• Scrum Master as Project Manager

• Managers play a role of Servant Leaders involved in coachingteam members, removing impediments

• Unlike Scrum, Kanban / lean does not differentiate managementand team into “Chickens and Pig”

• In Kanban/Lean, the management is responsible for driving thecontinuous improvement initiative as the team members arebusy delivering the product/services.

Principles of Kanban

1. Start with what youknow

2. Agree to pursueincremental,evolutionary change

3. Respect the currentprocess, roles andresponsibilities


Ceremonies in Kanban• Kanban is not prescriptive about Ceremonies

• On implementing kanban, new ceremonies may get added, modified orremoved from the process as part of the continuous improvementinitiative based on the value those ceremonies deliver

• Most of the new Agile projects /teams, adopt ‘some of’ the Ceremoniesclearly defined in Scrum suitable for their team

• Daily Standups• Planning meeting (Similar to sprint review)• Demo’s (when the feature sets are ready to deliver)• Retrospectives

• Kanban considers meetings which deliver no value/low value as waste


Cadence or Heartbeat

• Cadence or heartbeat is the interval between events

• Agreeing on regular cadence improves predictability

• There are two types of cadence which improves predictability

• Output Cadence / Delivery Cadence• Input Cadence / Prioritization Cadence


Delivery Cadence

• Short time boxed iterations are sometimes inefficient due to high release co-ordination and transaction cost involved

• Plan for regular releases as it improves certainty and customer confidence.

• Start with conservative release (e.g. once a month) then improve cadence beforecommitting shorter release cycles.

• Improved cadence should also result in lower transaction and co-ordination costs.This will allow the process to achieve capability for on-demand / ad-hocemergency releases.

• The value delivered in a release should be higher than the total cost includingtransaction and coordination costs


Improving Delivery Cadence• Improving Cadence involves improving flow. This involves

• improving the skills and process capabilities and continuouslyimprovement by challenging the as-is process simultaneously

• Improving as-is process involves improving code quality, datamigration, build process, deployment process, regression testing, testautomation etc.


Prioritization Cadence• Prioritization Cadence means having regular interval between meetings to

prioritize new work into the input queue

• Input Cadence involves both co-ordination and transaction costs• co-ordination cost involves cost of prioritization of work items like user stories, issues,

change requests involving members from multiple teams• Transaction cost involves cost of facilitating the prioritization activity

• Frequent prioritization meeting builds trust and focus. Prioritization cadence canbe established by having prioritization decision making as regularly as isreasonable based on transaction and coordination costs

• Ad-hoc and on-demand prioritization meeting makes sense only with highmaturity organizations having lower transaction and coordination costs with clearpolicies for prioritization.


Advanced KanbanBoard

http://leansoftwareengineering.com/wp-content/uploads/2009/04/kanban_matrix.png


EstimatesDo not focus on estimating individual

work item in detail, unless requiredSmaller the average work item size,

lesser the work estimationDo simple exercise like “T” shirt size

estimates based for large featuresAssume average cycle time and

apply to allTeam will figure out the work item and

break them down into multiplework items if it is too big

Redirect estimation efforts towardsimplementation

Avoid detailed estimation.

Effort = # of (identical) work items * Cycle timeSchedule = # of work items * Cycle time/Team Capacity

To calculate the estimate useTeam capacityCycle time


CommitmentsIf the team isn’t estimating, then howcan it commit ?

Commitments can be done in twoways :

- Establish a regular cadence anddeliver a set of features atregular intervals

- Commit feature by feature or aset of features (Minimalmarketable features/MMF’s)


Managing Change Requests

Most of the work items will be in the backlogstate. Not much time and effortinvestment has gone into these items.

Any changes in backlog or some extent “ToDo” state do not affect the team

Any changes in the WIP work items affectsrework. However these workitems aresmall in number

Once the work item is picked from the “ToDo” list, the focus should be incompleting the task as fast as possible

“We need to figure out a way to deliver software so fast that ourcustomers don’t have time to change their minds”

- Mary Poppendick


Decision making in Kanban

When deciding on what to do next ……Start form the right side of the board and go left.

See if you can help expedite any of the items nearer to the DONE columnIt is not about you, it is about succeeding as a “TEAM”

Stop Starting, Start FinishingClass ofService

Ready Analyze Design Code Test Done

WIP Done WIP Done WIP DONE

Expedite

Fixed DeliveryDate

Standard

Intangible

8 5

Stop Starting, Start Finishing

1

3

9

3


Decision making in Kanban

What if a work item is too big ?Break it down into parts and continue working. Don’t worry about the work

affecting the WIP limits. Remember “Value” over “Flow”If the work parts are independent, move it back to the To Do/Backlog queue

Class ofService


WIP Done WIP Done WIP DONE

Expedite

Fixed DeliveryDate

Standard

Intangible

8 5

Stop Starting, Start Finishing

1

3

9

3


Is WIP limit sacred ?

• Yes. But, there are instances where the team may have totemporarily exceed the WIP Limit. E.g.

• Team realizes a workitem is large or consists of more than1 part, then it can split into multiple workitems. Team caneither move these back to ready state or continue to worktowards “Done”.

• If fixed delivery date swimline is empty and standardswimline is full, but the ready has only standardworkitems, team can pickup standard workitem and workon it. This may temporarily break the WIP limit.


Cumulative Flow Diagram• CFD is an area chart

that shows projectstatus used for trackingand forecasting

• Helps to identifybottlenecks, forecastdates and cycle times


Decision Map in Kanban

When in doubt or conflict make decision based on

Value over Flow over Waste Elimination

If “FLOW” affects Value being delivered,sacrifice “FLOW”

If “Waste Elimination” efforts affect “FLOW”,sacrifice “Waste Elimination”

Continuously “Eliminate Waste” if it does not affect“FLOW”. This improves cycle time.


Key Metrics Data• Lead time = Delivery date – request date• Cycle time = Delivery date – start date

Approximate average Lead time - used topredict and inform outside world on how

long it will take to deliver *

Approximate average Cycle time – used topredict and inform outside world on how

long it will take to deliver the prioritized orurgent user story/feature/any service*

CFD Charts help to calculate approximateaverage Lead and Cycle time.

• Assumed that user stories of similar size. In case work items are of varied size then weighted method is usedby estimating the story points for each work item.

• Why “Approximate” – the items that started on the left side are not the items that gets delivered on theright side, when we calculate lead time.

Newrequirementsbeing added

Requirementsbeing dropped

CycleTimeWIP

Lead Time


Bottlenecks• Bottlenecks in a process are not easy to

spot. With CFD, would need to stand neareach process area and measure timeswith stop watches

• Breaking down the WIP into multipleactivities and plotting the CFD helps ingetting details about the process flow

• To find the bottleneck in the process lookout for a widening area. This wideninggenerally happens above the processwhich progressing slowly.

• Bottleneck is the activity below thewidening band

* Assumed that user stories of similar size. In case work items are of varied size thenweighted method is used by estimating the story points for each work item.

Wideningarea

BottleneckLead Time


Control Chart• The control chart has three

reference lines: Average, UpperControl Limit and Lower controllimit.

• For the work items whose cycletime is beyond LCL and UCL, theroot cause analysis (5Whys) isperformed to detect corrective andpreventive actions.

• When the variation of the cycletime reduces, the system can bereducing the UCL, LCL limits (e.,g +/-20 % from +/- 40%)

• If the work items are not of similarsize, the story points can be used tocalculate the weighted avg. cycletime


Daily Standup

• Any team member can get all the information he/she needs from the Kanbanboard

• However, Standup meeting is meant to give an update to their peers and beaccountable

• This is also a forum which helps to get the issues out. Team members cannotgive false update in front of their peers who can see through issues after fewupdates

• This is also a forum for the team members to highlight blocking issue and askfor help

• Ideal time for Standup meeting are generally first thing in the morning, orjust before the lunch break. Any other time would interrupt the teammembers thought process and interrupt the flow.


Daily Standup• Purpose:• A standing meeting that facilitates

team communication

Agenda:The 3 questions which are typically addressed by eachteam member include:What have you done since we last met?What are you planning to do until we met again?What, if any, impediments are you encountering that

are preventing you from making forward progress?


Daily StandupAttendees

Product Owner,Team Members,and/or Project Manager,Interested stakeholder

Input

Individual team membersState of work - current andcompleted

Output

Team communication andunderstanding of individualand iteration progress, taskstatus, critical issues orimpediments

Key Considerations• Only people with work assigned in the iteration should speak• Topics outside the 3 questions should be addressed outside the meeting• The team should report progress to the team as opposed to one member or a ScrumMaster

or manager• An unaddressed impediments and issues should be noted

Common Obstacles• All team members are not present• Non-core members consume the meeting with discussion• Time is spent on general discussion or detailed tangents vs. targeted progress


Ceremonies in Kanban

• Kanban is not prescriptive about Ceremonies

• On implementing kanban, new ceremonies may get added, modifiedor removed from the process as part of the continuous improvementinitiative based on the value those ceremonies deliver

• Most of the new Agile projects /teams, adopt ‘some of’ theCeremonies clearly defined in Scrum suitable for their team

• Daily Standups• Planning meeting (Similar to sprint review)• Demo’s (when the feature sets are ready to deliver)• Retrospectives

• Kanban considers meetings which deliver no value/low value as waste


Cadence or Heartbeat

• Cadence or heartbeat is the interval between events

• Agreeing on regular cadence improves predictability

• There are two types of cadence which improves predictability

• Output Cadence / Delivery Cadence• Input Cadence / Prioritization Cadence


Delivery Cadence

• Short time boxed iterations are sometimes inefficient due to highrelease co-ordination and transaction cost involved

• Plan for regular releases as it improves certainty and customerconfidence.

• Start with conservative release (e.g. once a month) then improvecadence before committing shorter release cycles.

• Improved cadence should also result in lower transaction and co-ordination costs. This will allow the process to achieve capability foron-demand / ad-hoc emergency releases.

• The value delivered in a release should be higher than the total costincluding transaction and coordination costs


Teams

Servant Leader in actionManager in action

Traditional Agile


Improving Delivery Cadence

• Improving Cadence involves improving flow. This involves

• improving the skills and process capabilities and continuouslyimprovement by challenging the as-is process simultaneously

• Improving as-is process involves improving code quality, data migration,build process, deployment process, regression testing, test automationetc.


Prioritization Cadence• Prioritization Cadence means having regular interval between meetings to prioritize

new work into the input queue

• Input Cadence involves both co-ordination and transaction costs• co-ordination cost involves cost of prioritization of work items like user stories, issues,

change requests involving members from multiple teams• Transaction cost involves cost of facilitating the prioritization activity

• Frequent prioritization meeting builds trust and focus. Prioritization cadence can beestablished by having prioritization decision making as regularly as is reasonablebased on transaction and coordination costs

• Ad-hoc and on-demand prioritization meeting makes sense only with high maturityorganizations having lower transaction and coordination costs with clear policies forprioritization.


Advanced Kanban Board

http://leansoftwareengineering.com/wp-content/uploads/2009/04/kanban_matrix.png


Background of “Command andcontrol”

• Self organization is a default behavior of any system

• Anything a manager “does not” constrain, self organizes

• Every self organized team works has a direction and limited by the context(organization environment)

• Self organized teams make no distinction between good or bad, virtues or vices,moral or immoral.

• Self organized teams do whatever environment allows them to do

• Thus humans came up with “command and control” to drive the teams towardsmaximizing value for society, stakeholders etc.

• Over time teams assume “command and control” as default system and “selforganizing teams” as evolutionary technique


Self Organizing Teams• Agile Principle #11:• The best architectures, requirements, and designs emerge from self-

organizing teams

• In a self organizing team, team members take decisions together throughconsensus

• However teams consist of a mix of people – members who to avoidtaking responsibility, avoid conflict, avoid working, dominate others,

• In the absence of command and control, we now have a team that willhave new members emerge to realize their objectives throughconvincing, conning, ignoring, bullying, guiding opinions, outplaying,pressurizing others


Leading Self Organizing Teams• Scrum contains “anti-management” bias that may be counter productive.

• Developers and management need to have equal place in the leadership of theproject

• Need to recognize the role of leadership and expertise of the team

• Some take extreme view of teams which need to be responsible, self-directed,self organized.

• If the team has self-organized in a way that it impedes its work, the manager orthe Scrum Master should find a way to agitate, stir-up, disturb the status quo sothat the team adjusts to a productive way of doing things.

• Agile leaders influence in subtle and indirect ways.

“There is more to leading a self-organizing team than buying pizza andgetting out of the way” – Mike Cohn


Leading Self Organizing Teams• For self organizing teams to deliver value aligned with

greater organization, need clear rules

• Leaders can help define these rules for the team

• Improvements that teams can achieve are local in naturewith low impact. Leaders can look beyond teams and drivecontinuous improvement initiatives with high impact

• Leaders should become coaches and help team membersdevelop personally. This should be main attribute of anymanager within the organization.


Organizing Self Organizing Teams• Self organized teams are aware of team members strength and weakness

allowing team to maximize the output than produce average output

• Analogy:In an operation theater (OT), team consists of surgeon, anesthesiologist, otherdoctors and nurses.If team as a whole made a decision with nurse having the same weightage as asurgeon, things will be disastrous.The Surgeon should have the final call. However, everyone including the nurse,should get involved in the activity and be aware of their responsibilities andcontribute to the success of the operation.

• Similarly, in agile teams, activities like Architecture, should be driven by asenior Architect with inputs by other team members.

• This ensures that team does exceptional decisions and not average decisions.


Organizing Self Organizing Teams• For self organizing teams to be successful, we need to define clear

rules that govern the boundaries of self-organizing behavior, which isdefined by the teams and by organization governance.

• Self organizing teams are dependent on individual team members,their ability to lead themselves and their ability to work as a team.

• Generally, the teams are sensible and adhere to the team rulesdefined by themselves.

• Teams generally have potential to conduct themselves to far higherstandard than they have defined for themselves. When this happens,teams depend less on the managers.

• Good managers are generally good coaches who help the team toself-organize and develop people.



1. Visualize

2. Limit WIP


policies explicit




Deep implementation


Make Process Policies Explicit

1. Define Class ofService

2. Define Policies 3. Make policiesexplicit


Class of Service(Not all work items are equal)

Not all work items are same. Some work items are of different types (bugs,features, queries) and of different priorities (urgent, normal, nice to have)etc.

The Urgent work items needs to be prioritized by keeping the current WIPaside”

Use “Class of Service” with different “swim lanes” to represent those workitems


Class of Service – Priorities

Kanban as defined by DavidAnderson has fourpredefined Class ofService –

ExpediteFixed Delivery DateStandardIntangible

These are predefined andteams are free to define ormodify with their own CoSwhich suit their context


Define Policies

Define policies for each class of service to aidprioritization decisions

Policies can include- Pull decisions (Definition of Done, Condition

of Satisfaction)- WIP Limits- Queue replenishments- Cycle time- Guidance to team member to choose the

next workitem- Explicit over-ride and authority- Risk constraintsAnyone in the team should be able to make adecision based on the policiesPolicies should strike a balance betweenpriority, business value, cost of delay etc.

E.g.FDD should enter swimlanes based on cycletime + bufferWIP limit for Expedited COS = 2Expedited and FDD takes precedence overStandard COS

Class of Service is a set ofpolicies that determine the

order in which work is pulledthrough a system


Make Process Policies ExplicitCoS Type Description Example Policies

Expedite

The immediate business value ofthis work item outweighs allother considerations to treat itwith highest priority. (Urgentwork.)

Card Type: White WIP Limit: 1 Qualified team member should be

assigned immediately by keeping thecurrent workitem on Hold

Ontime: 100% Delivery Time : < 3 days (bugs)

Fixed DeliveryDate

This CoS is used when theworkitem has to be deliveredbefore a delivery date. (DeadlineDriven work.)

Card Type: Purple WIP Limit: 3 Can be pulled in preference over less CoS

workitems Priority upgraded to “Expedite”, if delayed “T” shirt sized estimate will be done to

schedule the work to be picked up forimplementation

Release : Immediate Ontime: 95% Delivery Time: < 7 days (bugs)


Class of Service – ExamplesCoS Type Description Example Policies

Standard

Bread and butter work for theteam. (Increasingly urgent work.)

Card Type: Yellow Queuing policy: FIFO WIP Limit: 9 Ontime: 95% Delivery Time: < 15 days No estimation will be done. However, if the

workitem is large, it can be broken downinto smaller workitems

Intangible

Workitems that does not directlyadd value to the customer, but isof immense value to the systemlike production bug fixes,technical debt servicing,refactoring, backup, tools andscripts etc. (Important but noturgent work.)

Card type: Green Queuing Policy: Cost of Delay and FIFO Release: Next scheduled release Picked up for implementation as some

capacity is available and no high prioritywork items are available

WIP limit: 3 Ontime: 50% Delivery Time : 40 days (not guarantee)



1. Visualize

2. Limit WIP


policies explicit




Deep implementation


Implement Feedback Loop

Daily StandupMeeting

Pairing / PairProgramming

OperationalReview

ContinuousIntegration

SupervisorCoaching

CustomerReview/Demos

RegularRetrospectives

ContinuousPlanning



1. Visualize

2. Limit WIP


policies explicit




Deep implementation


5 Monkeys experiment


5 Monkeys experimentScientists placed 5 monkeys in a cage with a ladder in the middle of the cageand banana on top. Every time a monkey went up the ladder, scientistssprayed other monkeys with cold water. After a while, every time a monkeywent up the ladder, the others beat up the one on the ladder. After certaintime, no monkey dared to go up the ladder regardless of the temptationScientists removed the cold water muzzle. Scientists then decided to replacethe monkeys one by one repeated the experiment. No monkeys allowedanyone else to climb the ladder. Experiment continued till all the originalmonkeys were replaced and no monkey had experienced the cold watertreatment.

New members never climbed the ladder, not knowing why !!!

“I don’t know – that’s how things are done around here”


Problems are Jewels

- Toyota Saying


Why Continuous Improvement?• Traditional Organization

• Management by Standards/Output• Ensure there is “No Problem”

Lean/Agile Organization

Management by Continuous Improvement“No Problem = A Problem”Wabi Sabi = Nothing is perfect/Beauty in

imperfection.


Use Value Stream Map

UnderstandDirection

UnderstandCurrent

Condition

EstablishTarget

Condition

PDCAtowardsTarget

Condition


Value Stream Mapping• Don’t find faults / improvements in current VSM• You haven’t yet mapped where you want to go• The next step after current value stream map is to ask “How do we

want our VSM to be after 3 years in the future?”• Then you can draw the VSM of the future state

•

CurrentState

FutureState

Unclear Territory



Value Stream Mapping

CurrentState

FutureState

Value Stream Level

Improvement Kata gives a practical means of moving towards a future state – stayingfocused and learning along the way

Once future state VSM is drawn, work towards that goal by applying improvement kataat the individual processes

Unclear Territory



Value Stream MappingValue Stream Loops

Break future VSM into loops – Helps define challenges at individual work processesinside those loops

CurrentState

TargetCondition

Individual value stream loops



Continuous ProcessImprovement Philosophy

“Certainly the thieves may be able to follow the design plans andproduce a loom. But we are modifying and improving our looms

everyday. So by the time the thieves have produced a loom from theplans they stole, we will have already advanced well beyond that point.And because they do not have the expertise gained from the failures it

took to produce the original, they will waste a grate deal more timethan us as they move to improve their loom. We need not be concerned

about what happened. We need only continue as always, making ourimprovements”

Toyota Founder Sakichi Toyoda(response to someone once stealing the design plans for a loom)


Kanban Board (Other Improvements)

Have Goalcolumn tohave a target:e.g Cycletime is 14days(Done –Todo)Goal cardshelp todefine focusand prioritize

Reduce columnsby movingReady itemsbelow

Use aseparatetrack forhigh priorityitems

Use Avatars (stickeror magnatic card)to identify theperson assigned toeasily


Kanban Board (Other Improvements)

Always try to keep Expedite swimlane empty

Use tapesto indicatea slot isavailable


Finally ….


Remember• Teams decide if the iterations are useful. Kanban works without

iterations, with fixed iterations or with variable iterations

• Each team and context are different. Teams retrospect and choseprocess that suit them

• Agile / Lean does not dictate iterations, standups, planning gamesetc.

• Kanban does not stop anyone from using iterations, standups,planning games etc..

Use whatever works for your team


Key Concepts• Push Vs. Pull• Value Stream Mapping• Policies• WIP Limits• Input Cadence• SLA and predictability• Reporting & Metrics• Improvements

• Bottlenecks, wastes, variability

112


When to go for Kanban• Maintenance projects

– bug fixing, feature development, technical support• Operations

• Helpdesk / Support• Trouble tickets, Field support

• Product Development• Program Management• Portfolio Management• Within Scrum

• Activities before and after Scrum (system testing, regression, projectinitiation, release, post release activities, deployments)

• Sales and marketing activities

……………

Kanban can be applied everywhere except for “dead on arrival”projects/programs


Socializing with other methodsKanban can be used along side other methods

• In Scrum/SAFe™ ScrumXP, Used in managing Team backlog anditeration board to visualize the iteration backlog and the flow ofuser stories / work items

• In SAFe Program level, used in managing Program backlog. Used tomonitor the capacity allocation for Architectural and Business Epics,refactoring etc. Excellent tool to plan and avoid Technical Debt.

• In SAFe Portfolio level, used in managing the Portfolio backlog tomanage the flow of Business & Architectural Epics. Also usesKanban’s concept of Value Stream Mapping


How to make Kanban Agile ?Ensure that you use the following good practices from Scrum

• Customer demos (for product/feature dev)• Incremental working software delivery• Customer involvement (similar to Sprint Reviews)• Product Backlog, User Stories• Regular retrospectives / Lean daily kaizen

115

Flow, Value, Feedback, Collaboration

Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.

Flow Cracker#7, 3rd Floor, Srishti Building,8th Main, Basaveshwar Nagar,Bangalore - 560079

Email :

[email protected] [email protected]

Cell: +91 984 555 8474

ThankYou

116


Traditional Sustenance Model• Assumed Backlog = 100 issues• Team size = 10• Average Bug/member = 10

• Concerns• Team members need to give status to all stakeholders

(internal, external) when asked• High number of bugs in every team members bucket,

making it difficult to track• When struck with difficult bug, makes sense for team

members to keep it aside and take up low priority bugs.Unresolved bugs/ zombie bugs pile up unwilling

• Consolidating reports from team. Unnecessarily timewasted on tracking and updating status on out of focusbugs

• No one point contact for consolidated status of all bugs• Difficult to track duplicate bugs, related bugs

• `

UNCONFIRMED

APPROVED

ASSIGNED

RESOLVED

REOPEN VERIFIED

CLOSED

Additionalbugs found

Bugsconfirmed byTriag team

Selfassign byteammember

Assign bug toteam member

Change ofownershipor Transferto otherteam

Resolved

QA verified.QA verificationfailed.

Re-assigned toTeam member

Originatorapproved fix

Originator disapprovesfix

New defectreported

Triag teamconfirms Not aBug


Kanban Sustenance Model• Assumed Backlog = 100 issues• Team size = 10• WIP Limit per team member = 2• Bugs in Fix in progress = WIP * TS = 20• Bugs backlog with PO = 80

• Solutions• Team members focus only on “fix in progress“ bugs and give

status for those bugs only• PO responsible to provide overall status and priority for the

bugs to all stake holders• Team members puruse closure of hard bugs. In case of

difficulty, PO can reassign it to other members or work outan alternate plan with everyone to get the issues resolvedpoitically

• Easy for Product owner to find duplicate bugs, or groupsimilar bugs for closure.

• Easy for Product owner to foresee a trend in bug arrival andplan preventive actions

• Team updates bug status on kanban board.• Bugs out of sight in kanban are out of focus

• `

UNCONFIRMED

APPROVED,WAITING TO BE

ASSIGNED

ASSIGNED

RESOLVED

REOPEN VERIFIED

CLOSED

Additionalbugs found

Bugsconfirmed byTriag team

Selfassign byteammember

Assign bug to team member(WIP LIMIT)

Push backto PO toreassign

Resolved (WIP LIMIT)

QA verified. (WIP LIMIT)QA verificationfailed.

Re-assigned toother Teammember

Originatorapproved fix

Originator disapprovesfix

New defectreported

Triag teamconfirmsNot a Bug


CFD for a Waterfall project

ChangeRequests

Features being dropped

Lead Time First Release


Different Kanban modesReady Analyze Design Code Test Done

WIP Done WIP Done WIP Done

Ready AnalyzeWip

AnalyzeDone

DesignWIP

DesignDone

Code WIP CodeDone

Test Done


Ready Doing Ready Doing Ready Doing Ready Done

Pull -WIP limits perStage

Pull – WIPlimits for WIP& done

Routing done byupstreamprocess

agile series - kanban

Technology