Download - 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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
LeanDevelopment
Toward beingSAFe™
Agile Scrum
KanbanXP – ExtremeProgramming
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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/
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
LeanDevelopment
Toward beingSAFe™
Agile Scrum
KanbanXP – ExtremeProgramming
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Kanban
Kanban - Introduction Kanban Principles &Practices
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
“Change begins with small things”
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Definition of Kanban
Kanban isa scheduling &
a change management system.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
A scheduling system
Kanban is a scheduling system that determineswhat to produce,
when to produce andhow much to produce
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Change management process
Kanban is achange management process/approach
that can be applied to any existing process.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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”
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Kanban Board
To fully adapt kanban,the understanding offollowing will be useful:
Theory of constraintsSystems thinkingUnderstanding of
variabilityConcept of waste from
TPS
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
“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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Kanban
Kanban - Introduction Kanban Principles &Practices
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Kanban Implementation
David Anderson –father of kanban for software has defined
foundation principles to followand
core practices to adapt
for successful implementation of Kanban
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Kanban Foundation Principle
1. Start with whatyou know
2. Agree to pursueincremental,evolutionarychange
3. Respect currentprocess, role,responsibilities andtitles
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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 ……
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Visualize
1. WorkitemIdentification /Kanban Cards
2. Value StreamMapping
3. KanbanBoard/Wall
FeaturesSpikeBugsUser StoriesQuality Requests
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Value Stream Mapping
• Used to understand visualize current system,future system and eliminate waste
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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)
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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”
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Kanban Board
Teams Organized by specialization. Resulting in handsoffs.Consider Cross Functional Teams.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
• 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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Advanced KanbanBoard
http://leansoftwareengineering.com/wp-content/uploads/2009/04/kanban_matrix.png
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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)
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Cumulative Flow Diagram• CFD is an area chart
that shows projectstatus used for trackingand forecasting
• Helps to identifybottlenecks, forecastdates and cycle times
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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?
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Teams
Servant Leader in actionManager in action
Traditional Agile
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Advanced Kanban Board
http://leansoftwareengineering.com/wp-content/uploads/2009/04/kanban_matrix.png
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Make Process Policies Explicit
1. Define Class ofService
2. Define Policies 3. Make policiesexplicit
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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)
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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)
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Implement Feedback Loop
Daily StandupMeeting
Pairing / PairProgramming
OperationalReview
ContinuousIntegration
SupervisorCoaching
CustomerReview/Demos
RegularRetrospectives
ContinuousPlanning
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
5 Monkeys experiment
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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”
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Problems are Jewels
- Toyota Saying
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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.
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Use Value Stream Map
UnderstandDirection
UnderstandCurrent
Condition
EstablishTarget
Condition
PDCAtowardsTarget
Condition
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Adopted from Mike Rother/Improvement Kata
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Adopted from Mike Rother/Improvement Kata
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Adopted from Mike Rother/Improvement Kata
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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)
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Kanban Board (Other Improvements)
Always try to keep Expedite swimlane empty
Use tapesto indicatea slot isavailable
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Finally ….
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
Key Concepts• Push Vs. Pull• Value Stream Mapping• Policies• WIP Limits• Input Cadence• SLA and predictability• Reporting & Metrics• Improvements
• Bottlenecks, wastes, variability
112
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
CFD for a Waterfall project
ChangeRequests
Features being dropped
Lead Time First Release
Copyright © Flow Cracker 2014. All other trademarks held by their respective owners.
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 Analyze Design Code Test Done
Ready Doing Ready Doing Ready Doing Ready Done
Pull -WIP limits perStage
Pull – WIPlimits for WIP& done
Routing done byupstreamprocess