Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AgileDC 2019 Kanban Antipatterns: What you don't know *can* hurt you

177 views

Published on

In this interactive workshop we will examine multiple examples of Antipatterns observed in real-world Kanban boards. In each case we will identify the issues and discuss ways to improve the situation. We will review a number of better alternatives and see how the improvements map to the core principles of Kanban such as visualization, managing flow, and making policies explicit. Brand new to Kanban? Learning by example is a great way to get started! A long-time Kanban veteran? Come to see how many antipatterns you recognize and help firm up our Kanban Antipattern taxonomy and nomenclature!

Kanban is an extremely versatile and effective Agile method that has seen significant growth in popularity over recent years. Kanban’s flexibility has led to widespread adoption to manage business processes in disparate contexts such as HR, loan processing, drug discovery, and insurance underwriting, in addition to Information Technology. Like snowflakes, no two Kanban boards are alike. The downside to this flexibility is there is no well-known and easily accessible library of patterns for designing effective Kanban boards. Like Apollo engineers, teams are expected to design their board starting from first principles. Unfortunately, sometimes teams get stuck with board designs that may not provide the visibility and insight into their workflow they hope to see. Worse, some designs actually may serve only to obscure the situation. Working within the limitations of an electronic board can exacerbate the problem even further. Is all hope lost? Certainly not!
Let’s learn more about effective Kanban system design by examining what to avoid and why. Learning by example is effective and fun!

Published in: Software
  • Be the first to comment

  • Be the first to like this

AgileDC 2019 Kanban Antipatterns: What you don't know *can* hurt you

  1. 1. 1 Kanban Antipatterns: What You Don’t Know Can Hurt You Craeg Strong CTO, Ariel Partners September 23, 2019 Washington, DC
  2. 2. 2 Agenda • Introduction • Analysis of Anti-Patterns and Discussion of Alternatives – Pre-Assignment – Blocker Column – Missed Queues – Expedite Exploitation – Lobotomized Board – Board Designed by Megamind – Losing Ground – Mixing Apples and Oranges • Wrap Up
  3. 3. 3 Craeg Strong Software Development since 1988 Large Commercial & Government Projects Agile Coach / DevOps Engineer Kanban Trainer / SpecFlow Trainer Performance & Scalability Architect Certified Ethical Hacker New York & Washington DC Area CTO, Ariel Partners AKT, KMP, CSM, CSP, CSPO, ITILv3, PMI-ACP, PMP, LeSS, SAFe www.arielpartners.com cstrong@arielpartners.com @ckstrong1
  4. 4. 4 Antipattern 1: Pre-Assignment Backlog Analyze Implement Verify Done Doing Done Doing Done MKKM PC AB DP CS CWPC (6) (3)(4) EW IL WF RO MKKM PC AB DP CS CW PC © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  5. 5. 5 Analysis 1. Ensuring everyone has something to do, esp. with distributed teams 2. Maybe we have a fixed deployment interval or replenishment interval a la scrum 3. Ensuring we don’t get starved for a particular specialist resource by “forecasting” needs in advance 4. Planning cross-training by assigning mentor + mentee to items normally done by senior resource alone 1. Suggests work is being pushed rather than team allowed to pull 2. Limits options: what if someone else becomes available before assigned resource? 3. Increases psychological need to pull additional work in rather than helping others finish, i.e. “stop starting, start finishing” Why is this an antipattern? What good intentions could lead to this? © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  6. 6. Backlog Analyze Implement Verify Done Doing Done Doing Done MKKM PC AB DP CS CWPC (6) (3)(4) Refactoring: Maximize Pull Optionality EW IL WF RO © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 6
  7. 7. Backlog Analyze Implement Verify Done Doing Done Doing Done (6) (3)(4) WC Benefits System Disability Case Management Compliance System Refactoring: Visualize Work Item Types © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 7
  8. 8. Cross-Training Up Next Backlog Analyze Implement Verify Done Doing Done Doing Done MKKM PC AB DP CS CWPC (6) (3)(4) Refactoring: Plan for Cross-Training EW IL WF RO IL RO DP KMVictor Pauline FC KG © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 8
  9. 9. 9 Antipattern 2: Blocker Column Ready Analyze (3) Implement (2) Verify (2) Done Doing Done DoneDoing Blocked (6) © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  10. 10. 10 Analysis 1. Allows team to continue working while they are waiting on external resources 2. Team wants to appear responsive to business when they present higher priority work items 3. I can take a new, small work item and get it done quickly since my current work item is a lot bigger than I thought. It all has to get done anyway, right? 1. Can’t tell where blocked items were/are in the workflow 2. May conflate different kinds of blockers, or non-instant availability items 3. Items may be “forgotten” in blocked column purgatory; team may miss opportunities to unblock Why is this an antipattern? What good intentions could lead to this? © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  11. 11. Refactoring: Named Blocker Area (common cause) Ready Analyze (3) Implement (5) Verify (3) Done Doing Done DoneDoing Waiting on App Store Approval Late against SLA © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 11
  12. 12. Refactoring: Blocker Flags (special cause and common cause) Ready Analyze (3) Implement (5) Verify (3) Done Doing Done DoneDoing Waiting on clarifications from legal Need server upgrade Waiting for Defect Resolution © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 12
  13. 13. Refactoring: Queue for Non-Instant Availability Resource Ready Analyze (3) Implement (5) Ready to Approve (8) Done Doing Done DoneDoing Test (5) Approval activity happens “on the line.” © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 13
  14. 14. 14 Antipattern 3: Missed Queues Ideas Hypothesize (10) Refine (7) Explore (4) Ready for Implementation Validate (4) © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  15. 15. 15 Analysis 1. Just starting out with Kanban 2. Want to limit WIP, but either not familiar with CONWIP or our software does not support CONWIP 3. We don’t like to use the word “done” until the very end 1. Can’t tell which items are actually being worked on, versus waiting for the next stage 2. No easy way to add queues to account for downstream blockers, e.g. non-instant availability like approval 3. Difficult to compute flow efficiency Why is this an antipattern? What good intentions could lead to this? © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  16. 16. Refactoring: Add Ready Queues Ideas Hypothesize (10) Refine (7) Explore (4) Ready for Implementation Validate (4) Ready In Progress Ready In Progress © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 16
  17. 17. 17 Antipattern 4: Expedite Exploitation a. Using the expedite lane for non-expedite work. Show the examples from Dan Vicanti actionable agile metrics. Options Discover (8) Implement (10) Verify (6) Done Doing Done DoneDoing Expedite
  18. 18. 18 Analysis 1. Team wants to appear responsive to business when they present higher priority work items. 2. Team needs to hit a high priority deliverable 3. Business lost confidence in team’s ability to deliver according to a schedule, so all fixed date deliverables are “pre-expedited.” 1. Overusing expedite causes large variations in cycle time 2. Dan Vicante calls this “flow debt” which creates less predictability in your process. Flow debt is when cycle time is artificially reduced for some items of work in progress by borrowing cycle time from other items of work in progress 3. Expedited items typically skip parts of the workflow, which could lead to quality issues Why is this an antipattern? What good intentions could lead to this? © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  19. 19. Refactoring: Swim Lanes and Reduced WIP Options Discover (3) Implement (4) Verify (2) Done Doing Done DoneDoing Expedite VIP System (5) Maintenance (4) Reducing WIP increases cycle time, decreasing need to Expedite © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 19
  20. 20. Refactoring: Fixed Date Class of Service Options Discover (3) Implement (4) Verify (2) Done Doing Done DoneDoing Expedite VIP System (6) Maintenance (3) Automatically Becomes Expedite when Date Gets Near © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 20
  21. 21. Refactoring Ideas  Capture and make visible expedite policies  Reduce WIP so that cycle time is low– so there is less temptation to abandon work  Gain agreement to finish work in progress before starting Expedite © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 21
  22. 22. 22 Antipattern 5: Lobotomized Board To Do Doing Done © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  23. 23. 23 Antipattern 5: Lobotomized Board To Do Doing Done A: analyze A: codeA: peer review A: test A: integrate with ext A: document B: analyze B: code B: peer review B: test B: integrate B: document B: upgrade schema C: analyze C: code C: peer review C: test C: document C: obtain charts C: install server21 © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  24. 24. 24 Analysis 1. Need to keep everyone busy, esp. distributed teams 2. Moving from Scrum 1. No insight into where things are in the workflow. We have to read all the tasks in order to find out. 2. Difficult to understand overall progress without referring to external chart e.g. burndown 3. No insight into where the bottlenecks are. How do we know where to add resources? Why is this an antipattern? What good intentions could lead to this? © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  25. 25. Refactoring: Add Progress Indicator Backlog Ready Doing Done <50% 50%-90% 90%+ © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 25
  26. 26. Refactoring: Add Workflow Steps Backlog Ready Analyze Implement DoneReady for Approval Done In Progress Done In Progress Test © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 26
  27. 27. 27 Antipattern 6: Board Designed by MegaMind Ready Analyze Doing Done Develop Manual Test Doing Done Peer Review Manual Test Doing Done Doing Done Doing Done Develop Gherkin Test Peer Review Gherkin Test Doing Done Doing Done Develop Code Peer Review Code Document Doing Done Integration Test UAT UAT Prep UAT In Process © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  28. 28. 28 Analysis 1. Fully analyzed workflow 2. Previously missed steps 3. New to Kanban systems analysis 1. Board becomes so busy, we can no longer see a clear message 2. Some items that look serial may actually happen in parallel sometimes– we may be tempted to move items backward through the workflow 3. May lead to too much WIP since there are a lot of places to put stuff Why is this an antipattern? What good intentions could lead to this? © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  29. 29. Refactoring: Enhance Ticket Design Ready Analyze Doing Done Implement Doing Done Integration Test UAT UAT Prep UAT In Process X X X X Gherkin Test Manual Test Coding Documenting Req. Done © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 29
  30. 30. 30 Antipattern 7: Losing Ground Ready Analyze Doing Done Implement Doing Done Test Done © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  31. 31. 31 Analysis 1. Finding defects in a feature, we don’t want to call it done 2. Buyer’s remorse– pulled a ticket but realize I want another one 3. Customer indicates they want something else higher priority 1. First– this may be appropriate behavior for a given level of Kanban process maturity 2. It may indicate that columns are being used as waterfall-style steps, rather than knowledge-gaining stages 3. Moving tickets backwards is pushing work into an area which may already be at full capacity. 4. If we are abandoning work, we may lose the ability to measure impact of that Why is this an antipattern? What good intentions could lead to this? © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  32. 32. Refactoring: Record/Clone Abandoned Tickets Ready Analyze Doing Done Implement Doing Done Test Done B A Clone of A B Abandoned Original A Clone Ticket and move to Abandoned. Retro Topics:  Why did we abandon A?  What was the impact?  How could we avoid in future? © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 32
  33. 33. Refactoring: Block Ticket for Defects Ready Analyze Doing Done Implement Doing Done Test Done Defect In A A Abandoned Defect In A KMPs will recognize this pattern from GetKanban Defect may or may not be expedited © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 33
  34. 34. 34 Antipattern 8: Mixing Apples And Oranges Ready Analyze Doing Done Implement Doing Done Integration Test UAT UAT Prep UAT In Process B A C D Feature Project User Story © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  35. 35. 35 Analysis 1. Want to keep the board design simple 2. Many different workflows, hard to separate out 1. (If using electronic tool) Difficult to set WIP limits, because columns have more than one issue type, and the types are order of magnitudes different in size. 2. Board is busy 3. Cycle time metrics may be more difficult to compute Why is this an antipattern? What good intentions could lead to this? © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394
  36. 36. Refactoring: Multi-Level Board Ready In Progress Done B Initiatives 50% D A 80% Ready Analyze Doing Done Implement Doing Done Integration Test UAT Prep Doing Initiative A (16) Initiative B (10) Done Done May be 2 linked boards, or one board with swim lanes © Copyright Ariel Partners 2019 *sales@arielpartners.com ((646) 467-7394 36
  37. 37. 37 Parting Thoughts Don’t just copy another board, analyze Lessons learned, current pain points Sources and pattern of demand Delivery capability Workflow Classes of service Make sure your board speaks to you If you encounter a bad situation and the board didn’t telegraph it, time to review the board design! Use swim lanes, colors, and card design
  38. 38. 38 Discussions, Q & A Craeg Strong Savant Financial Technologies, Inc. d/b/a Ariel Partners Cell: (917) 992-0259 cstrong@arielpartners.com www.arielpartners.com @arielpartners Thank You!

×