Agile series - Kanban
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Agile series - Kanban

on

  • 1,667 views

This presentation is part of the series of Agile presentations shared as part of the Agile training, workshops and coaching. Focus is on providing wholesome information about using Agile beyond the ...

This presentation is part of the series of Agile presentations shared as part of the Agile training, workshops and coaching. Focus is on providing wholesome information about using Agile beyond the skeleton frameworks.

Statistics

Views

Total Views
1,667
Views on SlideShare
1,490
Embed Views
177

Actions

Likes
6
Downloads
51
Comments
0

1 Embed 177

http://localhost 177

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agile series - Kanban Presentation Transcript

  • 1. Agile Series - Kanban Durgaprasad B. R Flow, Value, Feedback, Collaboration -dp-
  • 2. -dp-
  • 3. Background Kanban Introduction Kanban Principles & Practices -dp-
  • 4. “Change begins with small things” -dp-
  • 5. Background Manufacturing History Toyota Production System/ Lean Agile -dp-
  • 6. Manufacturing History Armour Meat processing plant Early 1900’s Ford’s highland park plan by Albert Kahn 1910+ Toyota – Motomachi Plant (Japan) 1950+ Principle moving products & Stationary workers Reduced assembly time for Model T from 728 minutes to 93 minutes Toyota Production System – elimination of waste -dp-
  • 7. Background Manufacturing History Toyota Production System/ Lean Agile -dp-
  • 8. Things to know • Lean – manufacturing developed by Toyota between 1950’s & 80’s Developed by – Taiichi Ohno @ Toyota Lean - reason for Toyota’s consistent success in a stagnant industry • Initial Agile enthusiasts were inspired by lean manufacturing. • • • Mary Poppendick (Manufacturing) and her husband Tom Poppendick (software developer) mapped Lean principles to Software developments in their books • Both Mary & Tom are founding members of Agile Alliance • Lean Software Development term usually refers to contents of these books • Lean Software Development contains broad set of Lean Principles applied to software industry. • You don’t do Agile or Lean. You do both !!! -dp-
  • 9. Toyota Production System “Only after American carmakers had exhausted every other explanation for Toyota’s success, including better suppliers, cheaper labor, a heavier investment in robots etc., did they finally acknowledge that the true differentiator lay in harnessing the intellect of ordinary employees ” - Mary Poppendick (Lean Software Development) -dp-
  • 10. Toyota Production 1. Heijunka on line (Load Balancing) e.g. 2 People carriers, 1 two door, 1 saloon car, 2 people carriers, 1 two door, 1 saloon car 2. Lightened logisitcs, small trains, setting up flows 3. Small Containers, less stock 4. Line side compression (reduced line spaces increases value add), concentration on value add, reduced muda 5. Heijunka flexible multi-product line, better use of production resources 6. Operators creating value http://www.vision-lean.com/lean-manufacturing-in-action/heijunka-flexible-production/ -dp-
  • 11. What did Taiichi Ohno do ? Flexibility • • • • • • • For different models of car, the assembly line had to change the dies. This was a day long activity in Ford. Ohno reduced it just “three minutes” and eliminated the need for die-change specialist (Single Minute Die change – SMED) Making small batches – eliminating the carrying cost of parts, huge inventories Making only a few cars, forced to do it without defects and defects were seen as an immediate improvement opportunity Team work – teams were asked to do their work and continuously improve Quality control – focus was on process improvement and Kaizen events – continuous incremental improvement On the line quality checking – detect errors at source than finding them downstream when it is expensive to fix -dp-
  • 12. Queuing Theory • • • • Clearing the queue takes longer than making it Mismatch in rate of arrival and processing, results in queue Processing time is non linear with the arrival rate Cycle time increases with resource utilization • E.g. Cycle time may be lowest at <50% utilization, starts increasing at >50% utilization and increases non-linearly even before it reaches 100% The focus of managing queue should be on improving the output, than utilization of the workers/resources (hence watch the baton and not the runner) -dp-
  • 13. Ensuring smooth “FLOW” Eliminate queue in between process steps • • Eliminate multi tasking • • Avoid working on multiple work items simultaneously Reduce variability and improve predictability • • • • Use automation tools, cross skilled team instead of specialists, reduce batch size Reduce batch sizes and equal/similar sized batches Average cycle time improves when batch sizes are small and of similar size Make hidden queues in the process visible and make the bottlenecks explicit, which then needs to be fixed -dp-
  • 14. Improving FLOW • • • FLOW can be improved by Developing Skills (People) and Challenging them (Continuous improvement) When people are challenged, they are engaged, when they are engaged distractions disappear. But, challenging without developing skills creates anxiety and developing skills without challenges creates boredom. -dp-
  • 15. Background Manufacturing History Toyota Production System/ Lean Agile -dp-
  • 16. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. -dp-
  • 17. How much Agile? Bureaucratic Chaos sweatspot? Individuals and interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan ?    Chaos Bureaucratic Sweat Spot? -dp-
  • 18. The triple constraint in Agile Traditional Approach Fixed Scope Estimated Cost Estimated Time Agile Approach Estimated Scope Fixed Cost Fixed Time Analogy: Traditional: 10 Km Marathon (variable time, fixed distance) This is to certify that Mr/Mrs. Joy has run annual 10K marathon in 1 hour 6 minutes. Agile way: 1 hour Marathon (variable distance, fixed time) This is to certify that Mr/Mrs. Joy has run annual 1 hour marathon covering a distance of 9.253 kilometers. The Iron triangle: Assuming Quality is not negotiable in any methodology. -dp-
  • 19. Being Agile User Stories, Product Backlog Empowered Team Pair Programming Self Organizing Team Flow, Display Boards Collaboration Metaphors Transparency Coding Standards Servant Leadership Test Automation Commitment Continuous Integration Technical Excellence Continuous Deployment …… ……. For sustainable success, Agile needs a combination of top leadership XP Scrum Kanban DFDM Lean Crystal Clear RUP commitment and a culture of continuous improvement -dp-
  • 20. Being Agile • • • Methods Tools Best / Common Practices Agile Mindset The World has been trying to copy the wrong things - Mike Rother (Toyota Kata) -dp-
  • 21. Background Kanban Introduction Kanban Principles & Practices -dp-
  • 22. Definition of Kanban System Kanban is a scheduling & a change management system. -dp-
  • 23. A scheduling system Kanban is a scheduling system that determines what to produce, when to produce and how much to produce -dp-
  • 24. Change management process Kanban is a change management process/approach that can be applied to any existing process. -dp-
  • 25. 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 a change management process. • One Pre-requisite required for Kanban: “Sense of Urgency” -dp-
  • 26. Original Kanban System @Toyota Motomachi Plant, Japan “Under this setup, employees created signboards, or kanban, to transfer information between processes, such as the number of parts that had to be filled. The Kanban System eventually helped the production flow function more smoothly, a fact reflected in quality and productivity. Kanban took on many forms as part of the Just-in-Time System.” http://www.toyota-global.com/company/toyota_traditions/quality/mar_apr_2004.html -dp-
  • 27. Kanban Board Back log Back log Analyz e Design B Code Test B D C D 4 1 1 Kanban is like a chess board. Helps to visualize the plan better. A C A Done 4 2 However, a game isn’t chess, just because it’s played on a chess board ! Similarly, it isn’t kanban just because you are using a kanban board. -dp-
  • 28. Kanban Board Back log Back log Analyz e Design B Code Test A Done To fully adapt kanban, the understanding of following will be useful: C B A  D C D 4 1 1 4   2  Theory of constraints Systems thinking Understanding of variability Concept of waste from TPS -dp-
  • 29. Why Kanban ? • Increases visibility of the project flow to everyone in the team and management • Allows the team to deliver product/services faster and better quality 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. Connected processes makes the problems visible. -dp-
  • 30. Kanban Implementation David Anderson – father of kanban for software has defined foundation principles to follow and core practices to adapt for successful implementation of Kanban -dp-
  • 31. Kanban Foundation Principle 1. Start with what you know 2. Agree to pursue incremental, evolutionary change 3. Respect current process, role, responsibilities and titles -dp-
  • 32. Kanban core practices Shallow implementation 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Deep implementation -dp-
  • 33. Start with Shallow adoption by “Visualizing”. Then apply WIP limit, Manage flow and others …… -dp-
  • 34. “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 the non-value added activities” - Taiichi Ohno -dp-
  • 35. Background Kanban Introduction Kanban Principles & Practices -dp-
  • 36. Kanban core practices Shallow implementation 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Deep implementation -dp-
  • 37. Visualize 1. Workitem Identification / Kanban Cards 2. Value Stream Mapping 3. Kanban Board/Wall -dp-
  • 38. Workitem types Work item types can be different in different work contexts Features Spike Bugs User Stories Quality Requests Work item may have different workflow steps, hence different VSM Each work item will have a kanban card and of different colors If the workitem is large and can be split independently, teams should do so, to improve the flow -dp-
  • 39. Kanban Cards Can add additional data like • • Sample Kanban Card • Service Contracts Notify all Service Contract renewals before a preconfigured date (e.g. 15 days) • • • • • • Dates: Request 01/10/2013 • Start 14/10/2013 Delivered • 17/10/2013 • Cycle Time = Delivery date – Start date Lead time = Delivery date – request date • 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 card to indicate assigned to -dp-
  • 40. Kanban Cards Kanban cards can contain the following (but not limited to) information: • Sample Kanban Card Service Contracts Notify all Service Contract renewals before a preconfigured date (e.g. 15 days) Dates: Request 01/10/2013 • • • • Start 14/10/2013 Delivered 17/10/2013 Cycle Time = Delivery date – Start date Lead time = Delivery date – request date • Feature / User story details Data to collect Metrics Project teams can define their own kanban cards. No standards exist for the card size, information collected etc. User story cards, feature cards, epic card format used in Scrum can also be used in Kanban Teams can use different colors to indicate priority or activity type or class of service or assigned users -dp-
  • 41. Value Stream Mapping Used to understand visualize current system, future system and eliminate waste -dp-
  • 42. 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 Current State Unclear Territory Future State (not defined) Adopted from Mike Rother/Improvement Kata -dp-
  • 43. Kanban Board Ready WIP Done Kanban Board helps to Visualize the work and an area for the team to interact Start with a simple task board with 3 Columns Backlog(prioritized items) Work In Progress Done Each card is a work item. The current work items may be large batches. -dp-
  • 44. Work Item identification Advantage with software world • Ready WIP Done Any software activity can be split up into small work items which can be • • • • • Done independently (with proper sequencing) Develop work items in a continuous flow delivering incremental value to customers Unlike manufacturing, Kanban in software does not use physical cards on the trays. In software kanban, the kanban cards are virtual and represented on the board representing the status of the work items. -dp-
  • 45. Workspace for Kanban board Use a wall, board (cork board, black board, white board) for your kanban Ideally it should be visible when you enter/exit team workarea Plan for enough space for the team to stand in half circle comfortably in front of the board and have discussions Be innovative and design your own Kanban. -dp-
  • 46. Kanban Board Ready WIP Done Ready list In development projects, the Backlog list, should reflect the current understanding of the business needs In operations and support projects, the Backlog list, reflects the pending tasks assigned to the team. In case the backlog list is huge, this can be omitted from the board, when there is a “To Do” or “Waiting” column with selected work items -dp-
  • 47. Kanban core practices Shallow implementation 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Deep implementation -dp-
  • 48. Kanban Board Problem with simple task board Ready WIP Done Accumulation of too many WIP work items Results in multitasking which in turn results in context switching Cost of multitasking can be fatal !!! “To do two things at a time is to do neither “ – Publilious Syrus, a Latin writer 100 BC -dp-
  • 49. Kanban Board – Cost of multitasking Problem with multitasking Accumulation of too many WIP work items In knowledge work, we need to keep lot of information is present in temporary memory On context switching, this information is flushed out and new information is loaded. Reloading the flushed out information, needs information to be reconstructed which may be time consuming, error prone and stressful The escalating cost of this switching activity can be high and needs to be avoided (From Gerald Weinberg research) Multitasking has multiple impact – time, quality, ability to think deeply -dp-
  • 50. Kanban Board Backl og WIP Done Solution: Regulate the amount of cards on the board Need the follow “Stop Starting, Start Finishing” rules by every one How to enforce this rule? Define WIP Limits Regulate number of cards on the board 8 This can be done by defining the multitasking limits per stage e.g. Team size = 4 & Multitasking limit = 2, then WIP limit can be 4* 2 = 8 Limiting WIP means more valuable work to be completed faster -dp-
  • 51. 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 work item and pickup another work item • • In case of major obstacles, the team needs to put all-heads-together and bail out the team member from the current obstacle • Delivery value as fast as possible at regular interval. Avoids piling up of WIP inventory • Context switch from one task to another decreases productivity (~20%+) • Avoids Procrastination: Forces the organization in removing the impediments (obstacles) Stop and fix problems -dp-
  • 52. Kanban Board Backl To Do og WIP A B Done A C D B C 4 8 Problem: The inflow of work items are asynchronous and irregular Asynchronous and irregular flow affects flow and prioritization due to work item variations. Solution: Define buffer (queue) to cushion out these variations. Define a “To Do” or “Waiting” queue in between Backlog and WIP. This To Do queue controls the variations in the inflow of work. This also acts as a ideal work planning process to help the team to pick the next high priority 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 -dpQueue itself should have limit, to cushion variations from upstream processes
  • 53. Kanban Board Backl To Do WIP og A Done A B C D B C WIP Limit – What does it mean ? If a particular Queue is filled up, the upstream process will halt. Since, WIP is full, upstream process To Do cannot accept new work items beyond its WIP limit. C 4 Upstream process 8 The team focus, will be to complete items in WIP and move it to Done, to ensure smooth flow. Stop Upstream Process, if down stream process is not busy. Use upstream efforts to resolve downstream bottlenecks. -dp-
  • 54. Kanban Board Backl To Do og 2 WIP A Done A B C C D B C 3 D 4 Pull Work 8 1 C 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 get pulled from “Backlog” queue to “To Do” Queue … Not …. Push Work -dp-
  • 55. Kanban Board Back log To Do Analyz e Design B Code Test A C B A D 1 WIP is the bottleneck and the slowest. There may be multiple subqueues within WIP waiting to be completed D C 4 Done Problem: If you see no daily progress on the board 1 4 2 Break it down and make it visible Ensure there is a seamless “FLOW” Have the right people at the right place at the right time to ensure the work item gets “Done” -dp-
  • 56. Kanban Board Back log To Do Analyz e Design B Code Test A C B A D 1 Keep To Do slim – focus efforts in completing activities than upfront analysis and design D C 4 Done Analyzing or designing too many stories, without completing results in Waste 1 Changes to unscheduled work items does not affect the flow. Changes are encouraged any time. Encourage change 4 2 Prioritize just in time – helps manage change. Changes does not affect the team as team has not put any effort in upfront analysis or design of unscheduled work item -dp-
  • 57. Kanban Board Back log Analyz e Design Phase Coding Design Ready To Do Code Ready Design Testing Code Test Ready Done Test C A A B D 4 1 1 4 2 Teams Organized by specialization. Resulting in handsoffs. Would be wise to consider multiple buffer queues for each task Queue Buffer -dp-
  • 58. Kanban Board Back log To Do Analyz e Design B Code Test Increase in WIP or any Queue, means increase in time to deliver in near future Done A Blocked up queues will slow down the entire system and flow B A It is important to see this blockage and immediately attend to it. D D 4 1 1 4 The Queues start building up right in front of us immediately following a blockage 2 Limit, Queue size and the age of the work item within the Queue are leading indicators of problem we will encounter Empty neck indicates bottleneck getting formed in the upstream process Empty Column Kanban systems create a positive tension in the workplace that forces discussion of problems ….. -dp-
  • 59. Kanban Board Backlo g Analyze To Do WIP Design Done WIP B Done Code WIP A A  C D D 1 Done DONE B 4 Test 1 4 C 2 Expose Sub queues to understand the exact status of the work items. Kanban exposes bottleneck thus throwing up opportunities to fix and improve. Makes it easy to see problems, improve and learn from. -dp-
  • 60. Flow – specialized vs. cross functional COS Bac klog To Do Analyze Design Code Test Done A Features /Change requests 1 F Expedite 5 E 1 Bug fixes 1 A A B 4 B 8 C C D D X 16 4 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 a feature set team, row wise end to end and WIP limits defined row wise. -dp-
  • 61. 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 limit improves, slowly change the WIP limit. -dp-
  • 62. WIP Limit and Slack Use WIP limits to create slack. Don’t utilize team 100% Use that slack time to allow team members to participate in process improvement activities When the team faces blocking issues, the team members can swam on problems to resolve it Planning for slack also allows team members to address expedited issues without delaying work in hand -dp-
  • 63. Kanban core practices Shallow implementation 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Deep implementation -dp-
  • 64. Manage Flow Roles and Responsibilities Improvements Ceremonies Cadence/ Heartbeats Bottleneck Self Organizing teams Measurements -dp-
  • 65. Roles in Kanban Kanban is not prescriptive about roles and responsibilities • On implementing kanban, roles and responsibilities can evolve as part of the continuous improvement process • Principles of Kanban Most of the new Agile projects /teams, adopt the roles clearly defined in Scrum • • • 1. Start with what you know 2. Agree to pursue incremental, evolutionary change • • • 3. Respect the current process, roles and responsibilities • Product Owner Team Members Scrum Master as Project Manager Managers play a role of Servant Leaders involved in coaching team members, removing impediments Unlike Scrum, Kanban / lean does not differentiate management and team into “Chickens and Pig” In Kanban/Lean, the management is responsible for driving the continuous improvement initiative as the team members are busy delivering the product/services. -dp-
  • 66. Ceremonies in Kanban Kanban is not prescriptive about Ceremonies • On implementing kanban, new ceremonies may get added, modified or removed from the process as part of the continuous improvement initiative based on the value those ceremonies deliver • Most of the new Agile projects /teams, adopt ‘some of’ the Ceremonies 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 -dp-
  • 67. 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 -dp-
  • 68. 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 before committing shorter release cycles. • • Improved cadence should also result in lower transaction and coordination costs. This will allow the process to achieve capability for on-demand / ad-hoc emergency releases. The value delivered in a release should be higher than the total cost including transaction and coordination costs -dp-
  • 69. Improving Delivery Cadence Improving Cadence involves improving flow. This involves • • • improving the skills and process capabilities and continuously improvement by challenging the as-is process simultaneously Improving as-is process involves improving code quality, data migration, build process, deployment process, regression testing, test automation etc. -dp-
  • 70. 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 be established by having prioritization decision making as regularly as is reasonable based on transaction and coordination costs Ad-hoc and on-demand prioritization meeting makes sense only with high maturity organizations having lower transaction and coordination costs with clear policies for prioritization. -dp-
  • 71. Advanced Kanban Board http://leansoftwareengineering.com/wpcontent/uploads/2009/04/kanban_matrix.png -dp-
  • 72. Estimates Back log Back log Analyz e Design B Code Test Done A C B A D C D 4 1 1 4 2 12 Do not focus on estimating individual work item in detail, unless required Smaller the average work item size, lesser the work estimation Do simple exercise like “T” shirt size estimates based for large features Assume average cycle time and apply to all Team will figure out the work item and break them down into multiple work items if it is too big Redirect estimation efforts towards implementation To calculate the estimate use Team capacity Effort = # of (identical) work items * Cycle time Schedule = # of work items * Cycle time/Team Capacity Cycle time Avoid detailed estimation. -dp-
  • 73. Commitments Back log Back log Analyz e Design B Code Test Done If the team isn’t estimating, then how can it commit ? Commitments can be done in two ways : A C B A - D C D 4 1 1 4 2 Establish a regular cadence and deliver a set of features at regular intervals 12 - Commit feature by feature or a set of features (Minimal marketable features/MMF’s) -dp-
  • 74. Managing Change Requests Back log To Do Analyz e Design B  Code Test Done  A C B A  D C D 4 1 1 4  2 12 Most of the work items will be in the backlog state. Not much time and effort investment has gone into these items. Any changes in backlog or some extent “To Do” state do not affect the team Any changes in the WIP work items affects rework. However these workitems are small in number Once the work item is picked from the “To Do” list, the focus should be in completing the task as fast as possible “We need to figure out a way to deliver software so fast that our customers don’t have time to change their minds” - Mary Poppendick -dp-
  • 75. 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. -dp-
  • 76. Decision making in Kanban Stop Starting, Start Finishing Class of Service Analyze Ready WIP Expedite Done WIP Done Code WIP Test Done DONE 1 Fixed Delivery Date Design 3 Standard 9 Intangible 3 8 5 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 column It is not about you, it is about succeeding as a “TEAM” -dp-
  • 77. Decision making in Kanban Stop Starting, Start Finishing Class of Service Analyze Ready WIP Expedite Done WIP Done Code WIP Test Done DONE 1 Fixed Delivery Date Design 3 Standard 9 Intangible 3 8 5 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 -dpqueue
  • 78. Is WIP limit sacred ? Yes. But, there are instances where the team may have to temporarily exceed the WIP Limit. E.g. • • Team realizes a workitem is large or consists of more than 1 part, then it can split into multiple workitems. Team can either move these back to ready state or continue to work towards “Done”. If fixed delivery date swimline is empty and standard swimline is full, but the ready has only standard workitems, team can pickup standard workitem and work on it. This may temporarily break the WIP limit. -dp-
  • 79. Cumulative Flow Diagram CFD is an area chart that shows project status used for tracking and forecasting Helps to identify bottlenecks, forecast dates and cycle times -dp-
  • 80. Key Metrics Data New requirements being added Requirements being dropped Lead Time WIP CycleTime   Lead time = Delivery date – request date Cycle time = Delivery date – start date Approximate average Lead time - used to predict and inform outside world on how long it will take to deliver * Approximate average Cycle time – used to predict and inform outside world on how long it will take to deliver the prioritized or urgent user story/feature/any service* CFD Charts help to calculate approximate average Lead and Cycle time. • • Assumed that user stories of similar size. In case work items are of varied size then weighted method is used by 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 the right side, when we calculate lead time. -dp-
  • 81. Bottlenecks Bottlenecks in a process are not easy to spot. With CFD, would need to stand near each process area and measure times with stop watches Widening area Bottleneck Lead Time Breaking down the WIP into multiple activities and plotting the CFD helps in getting details about the process flow To find the bottleneck in the process look out for a widening area. This widening generally happens above the process which progressing slowly. Bottleneck is the activity below the widening band * Assumed that user stories of similar size. In case work items are of varied size then weighted method is used by estimating the story points for each work item. -dp-
  • 82. Control Chart The control chart has three reference lines: Average, Upper Control Limit and Lower control limit. For the work items whose cycle time is beyond LCL and UCL, the root cause analysis (5Whys) is performed to detect corrective and preventive actions. When the variation of the cycle time reduces, the system can be reducing the UCL, LCL limits (e.,g +/- 20 % from +/- 40%) If the work items are not of similar size, the story points can be used to calculate the weighted avg. cycle time -dp-
  • 83. Daily Standup Any team member can get all the information he/she needs from the Kanban board However, Standup meeting is meant to give an update to their peers and be accountable This is also a forum which helps to get the issues out. Team members cannot give false update in front of their peers who can see through issues after few updates This is also a forum for the team members to highlight blocking issue and ask for help Ideal time for Standup meeting are generally first thing in the morning, or just before the lunch break. Any other time would interrupt the team members thought process and interrupt the flow. -dp-
  • 84. Daily Standup Purpose: • A standing meeting that facilitates team communication Agenda: The 3 questions which are typically addressed by each team 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? -dp-
  • 85. Daily Standup Attendees Input Output Product Owner, Team Members, and/or Project Manager, Interested stakeholder Individual team members State of work - current and completed Team communication and understanding of individual and iteration progress, task status, critical issues or impediments 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 -dp-
  • 86. Teams Traditional Manager in action Agile Servant Leader in action -dp-
  • 87. Background of “Command and control” 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 towards maximizing value for society, stakeholders etc. Over time teams assume “command and control” as default system and “self organizing teams” as evolutionary technique -dp-
  • 88. Self Organizing Teams Agile Principle #11: The best architectures, requirements, and designs emerge from selforganizing teams • • • In a self organizing team, team members take decisions together through consensus However teams consist of a mix of people – members who to avoid taking responsibility, avoid conflict, avoid working, dominate others, In the absence of command and control, we now have a team that will have new members emerge to realize their objectives through convincing, conning, ignoring, bullying, guiding opinions, outplaying, pressurizing others -dp-
  • 89. 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 the project • Need to recognize the role of leadership and expertise of the team • Some take extreme view of teams which need to be responsible, selfdirected, self organized. • • If the team has self-organized in a way that it impedes its work, the manager or the Scrum Master should find a way to agitate, stir-up, disturb the status quo so that 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 and getting out of the way” – Mike Cohn -dp-
  • 90. 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 nature with low impact. Leaders can look beyond teams and drive continuous improvement initiatives with high impact Leaders should become coaches and help team members develop personally. This should be main attribute of any manager within the organization. -dp-
  • 91. 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, other doctors and nurses. If team as a whole made a decision with nurse having the same weightage as a surgeon, 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 and contribute to the success of the operation. Similarly, in agile teams, activities like Architecture, should be driven by a senior Architect with inputs by other team members. This ensures that team does exceptional decisions and not average decisions. -dp-
  • 92. 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 is defined 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 rules defined by themselves. Teams generally have potential to conduct themselves to far higher standard 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 to self-organize and develop people. -dp-
  • 93. Kanban core practices Shallow implementation 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Deep implementation -dp-
  • 94. Make process policies explicit 1. Define Class of Service 2. Define Policies 3. Make policies explicit -dp-
  • 95. Class of service (Not all work items are equal) COS Bac klog To Do Analyze Design Code Test Done A Features /Change requests 1 F Expedite 5 E 1 Bug fixes 1 A A B 4 B 8 C C D D X 16 4 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 WIP aside” Use “Class of Service” with different “swim lanes” to represent those work items -dp-
  • 96. Class of Service – Priorities Back log To Do Analyz e Design B Code Test Done A C B A D C D 4 1 1 4 2 12 Kanban as defined by David Anderson has four predefined Class of Service –  Expedite  Fixed Delivery Date  Standard  Intangible These are predefined and teams are free to define or modify with their own CoS which suit their context -dp-
  • 97. Class of Service – Policies Back log To Do Analyz e Design B Code Test Done A C B A D C D 4 1 1 4 2 12 Class of Service is a set of policies that determine the order in which work is pulled through a system Define policies for each class of service to aid prioritization 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 constraints Anyone in the team should be able to make a decision based on the policies Policies should strike a balance between priority, business value, cost of delay etc. E.g. FDD should enter swimlanes based on cycle time + buffer WIP limit for Expedited COS = 2 Expedited and FDD takes precedence over Standard COS -dp-
  • 98. Class of Service – Examples CoS Type Expedite Description The immediate business value of this work item outweighs all other considerations to treat it with highest priority. (Urgent work.) This CoS is used when the workitem has to be delivered before a delivery date. (Deadline Driven work.) Fixed Delivery Date Example Policies  Card Type: White  WIP Limit: 1  Qualified team member should be assigned immediately by keeping the current workitem on Hold  Ontime: 100%  Delivery Time : < 3 days (bugs)  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 for implementation  Release : Immediate  Ontime: 95%  Delivery Time: < 7 days (bugs) -dp-
  • 99. Class of Service – Examples CoS Type Standard Intangible Description Example Policies Bread and butter work for the  Card Type: Yellow team. (Increasingly urgent work.)  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 down into smaller workitems Workitems that does not directly  Card type: Green add value to the customer, but is  Queuing Policy: Cost of Delay and FIFO of immense value to the system  Release: Next scheduled release like production bug fixes,  Picked up for implementation as some technical debt servicing, capacity is available and no high priority refactoring, backup, tools and work items are available scripts etc. (Important but not  WIP limit: 3 urgent work.)  Ontime: 50%  Delivery Time : 40 days (not guarantee) -dp-
  • 100. Kanban core practices Shallow implementation 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Deep implementation -dp-
  • 101. Implement Feedback Loops Daily Standup Meeting Supervisor Coaching Operational Review Pairing / Pair Programming Continuous Integration Customer Review/Demos Regular Retrospectives Continuous Planning -dp-
  • 102. Kanban core practices Shallow implementation 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Deep implementation -dp-
  • 103. Problems are Jewels - Toyota Saying -dp-
  • 104. Definition of Kanban System Kanban is a scheduling & a change management system. -dp-
  • 105. Why Continuous Improvement ? Traditional Organization Lean/Agile Organization Management by Standards/Output Management by Continuous Improvement Ensure there is “No Problem” “No Problem = A Problem” Wabi Sabi = Nothing is perfect/Beauty in imperfection. -dp-
  • 106. Use Value Stream Map Understand Direction Understand Current Condition Adopted from Mike Rother/Improvement Kata Establish Target Condition PDCA towards Target Condition -dp-
  • 107. 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 Current State Unclear Territory Adopted from Mike Rother/Improvement Kata Future State -dp-
  • 108. Value Stream Mapping Value Stream Level Unclear Territory Current State   Future State Improvement Kata gives a practical means of moving towards a future state – staying focused and learning along the way Once future state VSM is drawn, work towards that goal by applying improvement kata at the individual processes Adopted from Mike Rother/Improvement Kata -dp-
  • 109. Value Stream Mapping Value Stream Loops Individual value stream loops Current State  Target Condition Break future VSM into loops – Helps define challenges at individual work processes inside those loops Adopted from Mike Rother/Improvement Kata -dp-
  • 110. 5 Monkeys experiment -dp-
  • 111. 5 Monkeys experiment Scientists placed 5 monkeys in a cage with a ladder in the middle of the cage and banana on top Every time a monkey went up the ladder, scientists sprayed other monkeys with cold water After a while, every time a monkey went up the ladder, the others beat up the one on the ladder After certain time, no monkey dared to go up the ladder regardless of the temptation Scientists removed the cold water muzzle. Scientists then decided to replace the monkeys one by one repeated the experiment. No monkeys allowed anyone else to climb the ladder. Experiment continued till all the original monkeys were replaced and no monkey had experienced the cold water treatment. New members never climbed the ladder, not knowing why !!! “I don’t know – that’s how things are done around here” -dp-
  • 112. Continuous Process Improvement Philosophy “Certainly the thieves may be able to follow the design plans and produce a loom. But we are modifying and improving our looms everyday. So by the time the thieves have produced a loom from the plans 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 time than us as they move to improve their loom. We need not be concerned about what happened. We need only continue as always, making our improvements” Toyota Founder Sakichi Toyoda (response to someone once stealing the design plans for a loom) -dp-
  • 113. Kanban Board (Other Improvements) Expedite Goals Backl og To Do Analyz e Design Phase Codi ng Testi ng Done Use a separate track for high priority items 14 Have Goal column to have a target: e.g Cycle time is 14 days (Done – 4 Todo) Done and waiting Goal cards help to define focus and prioritize 1 1 4 2 Use Avatars (sticker or magnatic card) to identify the person assigned to easily Reduce columns by moving Ready items below -dp-
  • 114. Kanban Board (Other Improvements) Expedite 1 Goals Backl og To Do 14 Analyz e Design Phase Codi ng B A Testi ng Done C Use tapes to indicate a slot is available D 4 1 1 4 2 Always try to keep Expedite swimlane empty -dp-
  • 115. Finally …. -dp-
  • 116. Key Concepts Push Vs. Pull Value Stream Mapping Policies WIP Limits Input Cadence SLA and predictability Reporting & Metrics Improvements • • • • • • • • • Bottlenecks, wastes, variability -dp-
  • 117. Kanban is flexible • 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 chose process that suit them • Agile / Lean does not dictate iterations, standups, planning games etc. • Kanban does not stop anyone from using iterations, standups, planning games etc.. Use whatever works for your team -dp-
  • 118. 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, project initiation, release, post release activities, deployments) Sales and marketing activities …………… except dead on arrival projects/programs !!! • -dp-
  • 119. Six step recipe for kanban success* • • • • • • Focus on quality Reduce WIP Deliver often Balance demand against throughput Prioritize Attack sources of variability to improve predictability * As defined by David Anderson ** Better approach than asking team members to change behavior -dp-
  • 120. Remember Kanban is a scheduling & a change management system. • Kanban can be applied to any existing process like Scrum, XP, maintenance, technical support, pure 3rd party verification. program management, accounting process or even “Waterfall” -dp-
  • 121. 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 Flow, Value, Feedback, Collaboration -dp-
  • 122. Next step….. -dp-
  • 123. Thank You Durgaprasad B. R prasadbr@hotmail.com Cell - +91 9845558474 -dp-
  • 124. Traditional Sustenance Model New defect reported Additional bugs found UNCONFIRM ED Triag team confirms Not a Bug Bugs confirmed by Triag team Self assign by team member APPROVED Change of ownership or Transfer to other team Re-assigned to Team member 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 time wasted on tracking and updating status on out of focus bugs No one point contact for consolidated status of all bugs Difficult to track duplicate bugs, related bugs • • Assign bug to team member • ASSIGNED Resolved • RESOLVED QA verification failed. • QA verified. • REOPEN VERIFIED • Originator disapproves fix Originator approved fix CLOSED ` -dp-
  • 125. Kanban Sustenance Model New defect reported UNCONFIRM ED Triag team confirms Not a Bug Push back to PO to reassign Bugs confirmed by Triag team 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 • • Additional bugs found • • APPROVED, WAITING TO BE ASSIGNED Self assign by team member • 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 out an alternate plan with everyone to get the issues resolved poitically Easy for Product owner to find duplicate bugs, or group similar bugs for closure. Easy for Product owner to foresee a trend in bug arrival and plan preventive actions Team updates bug status on kanban board. Bugs out of sight in kanban are out of focus • Assign bug to team member (WIP LIMIT) Re-assigned to other Team member Solutions • • • ASSIGNED Resolved (WIP LIMIT) • RESOLVED QA verification failed. • QA verified. (WIP LIMIT) • • REOPEN VERIFIED • Originator disapproves fix CLOSED Originator approved fix ` -dp-
  • 126. CFD for a Waterfall project Change Requests Features being dropped Lead Time First Release -dp-
  • 127. Feedback loops There are three kanban feedback mechanism • The daily meeting Improvement Katas • The operations review • -dp-
  • 128. Different Kanban modes Analyze Ready Design Code Test WIP Ready Ready Done WIP Done WIP Analyze Done Design WIP Design Done Code WIP Code Done Test Done Done Analyze Wip Done Analyze Ready Design Doing Ready Doing Code Ready Doing Test Ready Done Pull WIP limits per Stage Pull – WIP limits for WIP & done Done Routing done by upstream process -dp-
  • 129. Migrating to Kanban • Easier to introduce to Waterfall/ XP/ Scurm teams • Can be started with the current workflow • • Can be started without changing the current organization roles and responsibilities Identify all the steps from the idea to deployment -dp-