Your SlideShare is downloading. ×
0
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Agile series - Kanban
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile series - Kanban

1,750

Published on

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.

Published in: Technology, Business
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,750
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
60
Comments
0
Likes
6
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  1. 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
  2. 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/Program Manager, Location Delivery Head, Agile Coach  Industries: Telecom, Healthcare, Consumer Electronics, Automotive  Past few Clients: Avaya, Nortel, ALU, Microsoft, Qualcomm, Intel, Toshiba, Continental  Technologies: Web Technologies, Embedded, Legacy large systems  Developer, Project/Program Manager, Location Delivery Head, Agile Coach  Industries: Telecom, Healthcare, Consumer Electronics, Automotive  Past few Clients: Avaya, Nortel, ALU, Microsoft, Qualcomm, Intel, Toshiba, Continental  Technologies: Web Technologies, Embedded, Legacy large systems  Led large Telecom programs, IP Switches, Voice Messaging System, Contact Center, Consumer Electronics products, Automotive product development  Well versed in new age technologies as well as sun- set technologies  Trained and coached individuals and teams on Agile, Kanban, Scrum and SAFe methodologies  Regular public workshops on PMP, ACP and SAFe Certifications  Led large Telecom programs, IP Switches, Voice Messaging System, Contact Center, Consumer Electronics products, Automotive product development  Well versed in new age technologies as well as sun- set technologies  Trained and coached individuals and teams on Agile, Kanban, Scrum and SAFe methodologies  Regular public workshops on PMP, ACP and SAFe Certifications http://www.flowcracker.in/about-durgaprasad-b-r/ Contact: prasadbr@flowcracker.com. Cell: 9845558474
  3. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Lean Development Toward being SAFe™ Agile Scrum Kanban XP – Extreme Programming
  4. 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 to consider ideas across schools and heritages in order to find the ones that best suit the current situation. - DURGAPRASADhttp://oathofnonallegiance.com/
  5. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Lean Development Toward being SAFe™ Agile Scrum Kanban XP – Extreme Programming
  6. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Kanban - Introduction Kanban Principles & Practices
  7. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. “Change begins with small things”
  8. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Definition of Kanban Kanban is a scheduling & a change management system.
  9. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. A scheduling system Kanban is a scheduling system that determines what to produce, when to produce and how much to produce
  10. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Change management process Kanban is a change management process/approach that can be applied to any existing process.
  11. 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 difference processes and even industries. • The beauty of Kanban - it can be used as a standalone methodology or used alongside other methodologies Kanban Pre-requisite : “Sense of Urgency”
  12. 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, 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
  13. 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 a new shipment as material is consumed. These signals are tracked through the replenishment cycle and bring extraordinary visibility to suppliers and buyers. Pupose Logistics control system Implemented at Toyota Date Implemented 1953 http://en.wikipedia.org/wiki/Kanban
  14. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Kanban is like a chess board. Helps to visualize the plan better. 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.
  15. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board To fully adapt kanban, the understanding of following will be useful: Theory of constraints Systems thinking Understanding of variability Concept of waste from TPS
  16. 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 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. Alongside streamlining the process, the changes achieved are sustainable in nature.
  17. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. What Kanban isn’t? Kanban is not a team optimization method. It is a value creation chain optimization method. It is about optimizing FLOW and not the team. 17 Team Performance Optimization ≠ Value Creation Optimization
  18. 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 the non-value added activities” Taiichi Ohno
  19. 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 it yesterday Quick Fix Residual Effect/Technical Debt Work on Urgent Thing/Important Task Switching Increases Cycle time Increased Backlog
  20. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Kanban - Introduction Kanban Principles & Practices
  21. 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 follow and core practices to adapt for successful implementation of Kanban
  22. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Foundation Principle 1. Start with what you know 2. Agree to pursue incremental, evolutionary change 3. Respect current process, role, responsibilities and titles
  23. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Core Practices 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Shallow implementation Deep implementation
  24. 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 ……
  25. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Visualize 1. Workitem Identification / Kanban Cards 2. Value Stream Mapping 3. Kanban Board/Wall Features Spike Bugs User Stories Quality Requests
  26. 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 different work contexts •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
  27. 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 card to indicate assigned to Service Contracts Notify all Service Contract renewals 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 date Lead time = Delivery date – request date Sample Kanban Card
  28. 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 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 Service Contracts Notify all Service Contract renewals 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 date Lead time = Delivery date – request date Sample Kanban Card
  29. 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
  30. 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 • Current State Future State (not defined)Unclear Territory Adopted from Mike Rother/Improvement Kata
  31. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board 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.
  32. 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 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.
  33. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. 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 33 Be innovative and design your own Kanban
  34. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board 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
  35. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Core Practices 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Shallow implementation Deep implementation
  36. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board Problem with simple task board Accumulation of too many WIP work items Results in multitasking which in turn results in context switching 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
  37. 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 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 37 Multitasking has multiple impact – time, quality, ability to think deeply (From Gerald Weinberg research)
  38. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board 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 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 38 Limiting WIP means more valuable work to be completed faster
  39. 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 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
  40. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board Queue itself should have limit, to cushion variations from upstream processes 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
  41. 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, the upstream process will halt. Since, WIP is full, upstream process To Do cannot accept new work items beyond its WIP limit. The team focus, will be to complete items in WIP and move it to Done, to ensure smooth flow.
  42. 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 get pulled from “Backlog” queue to “To Do” Queue
  43. 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 the work item gets “Done” Problem: If you see no daily progress on the board WIP is the bottleneck and the slowest. There may be multiple subqueues within WIP waiting to be completed Break it down and make it visible Ensure there is a seamless “FLOW”
  44. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board Encourage Change Analyzing or designing too many stories, without completing results in Waste Keep To Do slim – focus efforts in completing activities than upfront analysis and design 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
  45. 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.
  46. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board Kanban systems create a positive tension in the workplace that forces discussion of problems ….. Increase in WIP or any Queue, means increase in time to deliver in near future The Queues start building up right in front of us immediately following a blockage Blocked up queues will slow down the entire system and flow It is important to see this blockage and immediately attend to it. 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
  47. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board Kanban exposes bottleneck thus throwing up opportunities to fix and improve. Makes it easy to see problems, improve and learn from. Expose Sub queues to understand the exact status of the work items.
  48. 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 a feature set team, row wise end to end and WIP limits defined row wise.
  49. 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 limit improves, slowly change the WIP limit.
  50. 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 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
  51. 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 “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 Pull Work … Not …. Push Work
  52. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Core Practices 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Shallow implementation Deep implementation
  53. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Manage Flow Roles and Responsibilities •Principle: Respect current roles and responsibilities •Managers – Servant Leaders, Coaches •Management responsible for CI •Not prescriptive of ceremonies •Most of the teams adopt ceremonies defined in Scrum •Waste – meetings with no value Ceremonies Bottleneck Measurement
  54. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Manage Flow •Agreeing on regular cadence improves predictability •Two Types of cadence •Output / Delivery •Input/Prioritization •Team members take decisions through consensus •Need to recognize role of leadership & team expertise Improvements Candence/ Heartbeats Self Organizing Teams
  55. 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 evolve as part of the continuous improvement process • Most of the new Agile projects /teams, adopt the roles clearly defined in Scrum • 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. Principles of Kanban 1. Start with what you know 2. Agree to pursue incremental, evolutionary change 3. Respect the current process, roles and responsibilities
  56. 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 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
  57. 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
  58. 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 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 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
  59. 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 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.
  60. 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 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.
  61. 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
  62. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Estimates 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 Avoid detailed estimation. Effort = # of (identical) work items * Cycle time Schedule = # of work items * Cycle time/Team Capacity To calculate the estimate use Team capacity Cycle time
  63. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Commitments If the team isn’t estimating, then how can it commit ? Commitments can be done in two ways : - Establish a regular cadence and deliver a set of features at regular intervals - Commit feature by feature or a set of features (Minimal marketable features/MMF’s)
  64. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Managing Change Requests 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
  65. 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 column It is not about you, it is about succeeding as a “TEAM” Stop Starting, Start Finishing Class of Service Ready Analyze Design Code Test Done WIP Done WIP Done WIP DONE Expedite Fixed Delivery Date Standard Intangible 8 5 Stop Starting, Start Finishing 1 3 9 3
  66. 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 of Service Ready Analyze Design Code Test Done WIP Done WIP Done WIP DONE Expedite Fixed Delivery Date Standard Intangible 8 5 Stop Starting, Start Finishing 1 3 9 3
  67. 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 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.
  68. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. 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
  69. 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.
  70. 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 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. New requirements being added Requirements being dropped CycleTime WIP Lead Time
  71. 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 near each process area and measure times with stop watches • 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. Widening area Bottleneck Lead Time
  72. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. 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
  73. 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 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.
  74. 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 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?
  75. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Daily Standup Attendees Product Owner, Team Members, and/or Project Manager, Interested stakeholder Input Individual team members State of work - current and completed Output 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
  76. 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 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
  77. 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
  78. 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 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 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
  79. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Teams Servant Leader in actionManager in action Traditional Agile
  80. 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 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.
  81. 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 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.
  82. 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
  83. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. 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
  84. 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 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
  85. 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 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, self-directed, 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
  86. 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 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.
  87. 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, 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.
  88. 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 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.
  89. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Core Practices 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Shallow implementation Deep implementation
  90. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Make Process Policies Explicit 1. Define Class of Service 2. Define Policies 3. Make policies explicit
  91. 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 WIP aside” Use “Class of Service” with different “swim lanes” to represent those work items
  92. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Class of Service – Priorities 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
  93. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Define Policies 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 Class of Service is a set of policies that determine the order in which work is pulled through a system
  94. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Make Process Policies Explicit CoS Type Description Example Policies Expedite The immediate business value of this work item outweighs all other considerations to treat it with highest priority. (Urgent work.)  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) Fixed Delivery Date This CoS is used when the workitem has to be delivered before a delivery date. (Deadline Driven 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 for implementation  Release : Immediate  Ontime: 95%  Delivery Time: < 7 days (bugs)
  95. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Class of Service – Examples CoS Type Description Example Policies Standard Bread and butter work for the team. (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 down into smaller workitems Intangible Workitems that does not directly add value to the customer, but is of immense value to the system like production bug fixes, technical debt servicing, refactoring, backup, tools and scripts etc. (Important but not urgent 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 priority work items are available  WIP limit: 3  Ontime: 50%  Delivery Time : 40 days (not guarantee)
  96. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Core Practices 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Shallow implementation Deep implementation
  97. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Implement Feedback Loop Daily Standup Meeting Pairing / Pair Programming Operational Review Continuous Integration Supervisor Coaching Customer Review/Demos Regular Retrospectives Continuous Planning
  98. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Core Practices 1. Visualize 2. Limit WIP 3. Manage Flow 4. Make Process policies explicit 5. Implement feedback loop 6. Improve Collaboratively Shallow implementation Deep implementation
  99. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. 5 Monkeys experiment
  100. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. 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”
  101. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Problems are Jewels - Toyota Saying
  102. 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.
  103. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Use Value Stream Map Understand Direction Understand Current Condition Establish Target Condition PDCA towards Target Condition
  104. 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 • Current State Future State Unclear Territory Adopted from Mike Rother/Improvement Kata
  105. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Value Stream Mapping Current State Future State Value Stream Level 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 Unclear Territory Adopted from Mike Rother/Improvement Kata
  106. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Value Stream Mapping Value Stream Loops Break future VSM into loops – Helps define challenges at individual work processes inside those loops Current State Target Condition Individual value stream loops Adopted from Mike Rother/Improvement Kata
  107. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. 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)
  108. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board (Other Improvements) Have Goal column to have a target: e.g Cycle time is 14 days (Done – Todo) Goal cards help to define focus and prioritize Reduce columns by moving Ready items below Use a separate track for high priority items Use Avatars (sticker or magnatic card) to identify the person assigned to easily
  109. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Kanban Board (Other Improvements) Always try to keep Expedite swimlane empty Use tapes to indicate a slot is available
  110. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Finally ….
  111. 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 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
  112. 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
  113. 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, project initiation, release, post release activities, deployments) • Sales and marketing activities …………… Kanban can be applied everywhere except for “dead on arrival” projects/programs
  114. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Socializing with other methods Kanban can be used along side other methods • In Scrum/SAFe™ ScrumXP, Used in managing Team backlog and iteration board to visualize the iteration backlog and the flow of user stories / work items • In SAFe Program level, used in managing Program backlog. Used to monitor 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 to manage the flow of Business & Architectural Epics. Also uses Kanban’s concept of Value Stream Mapping
  115. 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
  116. 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 : prasadbr@flowcracker.com Or contactus@flowcracker.com Cell: +91 984 555 8474 Thank You 116
  117. 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 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 • ` UNCONFIRMED APPROVED ASSIGNED RESOLVED REOPEN VERIFIED CLOSED Additional bugs found Bugs confirmed by Triag team Self assign by team member Assign bug to team member Change of ownership or Transfer to other team Resolved QA verified.QA verification failed. Re-assigned to Team member Originator approved fix Originator disapproves fix New defect reported Triag team confirms Not a Bug
  118. 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 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 • ` UNCONFIRMED APPROVED, WAITING TO BE ASSIGNED ASSIGNED RESOLVED REOPEN VERIFIED CLOSED Additional bugs found Bugs confirmed by Triag team Self assign by team member Assign bug to team member (WIP LIMIT) Push back to PO to reassign Resolved (WIP LIMIT) QA verified. (WIP LIMIT)QA verification failed. Re-assigned to other Team member Originator approved fix Originator disapproves fix New defect reported Triag team confirms Not a Bug
  119. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. CFD for a Waterfall project Change Requests Features being dropped Lead Time First Release
  120. Copyright © Flow Cracker 2014. All other trademarks held by their respective owners. Different Kanban modes Ready Analyze Design Code Test Done WIP Done WIP Done WIP Done Ready Analyze Wip AnalyzeD one Design WIP Design Done Code WIP Code Done Test Done Ready Analyze Design Code Test Done Ready Doing Ready Doing Ready Doing Ready Done Pull - WIP limits per Stage Pull – WIP limits for WIP & done Routing done by upstream process

×