Intro to Agile: Scrum vs. Kanban

909 views
794 views

Published on

A whirlwind tour of Agile methodologies, focusing on Scrum and Kanban.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
909
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
29
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Intro to Agile: Scrum vs. Kanban

  1. 1. Intro to Agile (Scrum & Kanban) by Craig L. Jones cjones@picsauditing.com © Craig L. Jones, 2011-13. All rights reserved.
  2. 2. 32 Years Software Development 14 Years Agile (mostly XP, Scrum, & Kanban) CSM & Scrum Coach Recovering Over-engineer-er http://tech.picsauditing.com
  3. 3. Agile Scrum Kaizen Scrumban Le a n Kanban XP
  4. 4. Late 40's (Japan & Europe) Late '90's (Global) Agile XP Scrum DSDM Crystal Clear RUPkanban Kaizen Six Sigma BSC TQM Lean ISO 9000 CMM Kanban Drum-Buffer-Rope MRP CONWIP Scrum ScrumBan
  5. 5. Scrum
  6. 6. Scrum
  7. 7. Scrum Rugby term for “huddle” – refers to the “Daily Scrum” (stand-up meeting)
  8. 8. Scrum Team ● One Product Owner (representing many stakeholders) ● One Scrum Master ● Many Developers (7 ± 2)
  9. 9. Product Owner ● Represents all of the stakeholders - “a single, wringable neck” ● Understands the big picture and the value each story brings to it ● Considered the hardest job in the company (if done well)
  10. 10. Scrum Master ● Coaches everyone on the Scrum process ● Facilitates the ceremonies ● Stats Tracker ● Impediment Unblocker ● Half-time job (if done well) ● Might also Scrum Master a second team, or ● Might also be a Developer ● Must NOT also be the PO
  11. 11. Developer ● Cross-Functional (anyone devoted to the product development) ● Programmers (front end, back end, database) ● Designers (UX, packaging, industrial) ● Writers (tech, copy) ● Artists ● Testers (SDET, ad-hoc, certification)
  12. 12. Scrum “Ceremonies” ● Backlog Grooming (ongoing) ● Sprint planning (first 5% of the Sprint time; thus 2-8 hours) ● Daily Scrums (15 min) ● Sprint Demo (1-2 hours) ● Retrospective (<1 hour)
  13. 13. Scrum Artifacts ● Vision & Mission Statements ● Product Backlog ● Definition of Ready ● Definition of Done ● Sprint Backlog ● Burndown Charts ● Burnup Charts ● Velocity Record
  14. 14. Definition of Ready / Done ● Service Level Agreements for inbound/outbound work. ● Ready: Guarantees made to the team before a ticket is placed in the “Ready” column for them to pick up and process ● Done: Guarantees made by the team when a ticket is completed. ● Done: Most importantly lists what's not done (e.g. internationalization/localization).
  15. 15. Burndown Chart
  16. 16. Sprint Planning ● Story 1 (13 pts) ● Story 2 (3 pts) ● Story 3 (8 pts) ● Story 4 (13 pts) ● Story 5 (20 pts) ● Story 6 (3 pts) ● Story 7 ● Story 8 ● Story 9 ● Story 10 ● Story 11 ● Story 12 ● Story 12 (1 pt) ● Story 9 (5 pts) ● Story 1 (13 pts) ● Story 2 (3 pts) Prioritized Product Backlog Sprint Backlog During Sprint planning, the developers suggest that, even though Story 12 is not highly valued by the PO, it's a quick win (1 point) and something everyone can rally around. They also suggest that Story 9 is high risk and ought to be tackled early. The PO agrees. All other things being equal, Stories 1 & 2 are pulled from the top of the prioritized backlog.
  17. 17. A Scrum Board Ready Test DoneDevDesignStory White = Story (4x6 cards and blue masking tape) Yellow = Sub-Task (3x3 Post-It note)
  18. 18. A Scrum Board Ready Test DoneDevDesignStory
  19. 19. A Scrum Board Ready Test DoneDevDesignStory Stories stay in the left column while tasks progress to the right
  20. 20. A Scrum Board Ready Test DoneDevDesignStory
  21. 21. A Scrum Board Ready Test DoneDevDesignStory
  22. 22. A Scrum Board Ready Test DoneDevDesignStory
  23. 23. A Scrum Board Ready Test DoneDevDesignStory
  24. 24. Product Backlog ● Epics ● User Stories ● Technical Stories ● Bug Tickets – or – ● Epics ● Features – User Stories – Technical Stories – Bug Tickets
  25. 25. Product Backlog ● Portfolio of Epics (18 month horizon) ● Program of Features (9 month horizon) ● Roadmap of Stories (3 month horizon)
  26. 26. Story Template As a _______________________, I want ______________________ so that ______________________ “As an administrator, I want a way to control which users can perform which tasks, via roles and permissions, so that we can pass a Sarbanes Oxley audit.”
  27. 27. Acceptance Test Given _______ and _______ When _______ and _______ Then _______ and _______ Given that I am logged in as an administrator, when I create a user John, and I create a role Clerk, and I assign the ReconcileReport permission to the Clerk role, and I make John a Clerk, then John should be able to log in and print the Reoncile Report.
  28. 28. INVEST = Well-Written Stories ● Independent ● Negotiable ● Valuable ● Estimable ● Small ● Testable
  29. 29. INVEST = Well-Written Stories Small vs. Independent ______ As small as possible, yet still has intrinsic value
  30. 30. Kanban
  31. 31. Kanban means “Sign Board” Kanban is an element of just-in-time (JIT) production, as invented by Taiichi Ohno for Toyota in the late 1940's – based on studies of inventory systems used in supermarkets at the time.
  32. 32. kanban card = “signal card” “kanban” with a lower-case “K”
  33. 33. kanban card = “signal card”
  34. 34. “Kanban” System “Kanban” with a Capital “K” refers to a system (framework) for tracking work in progress. “Signal” Cards Work Cards
  35. 35. Kanban & Scrum Share... ● Easy to Learn the Basics ● Big, Visible Charts ● Regular Cadence ● Retrospectives (“Inspect & Adapt”) ● Cross-Functional Collaboration ● Maximizing Value (by Eliminating Waste) ● Early Feedback ● Formal Definitions of Ready/Done
  36. 36. Kanban vs. Scrum ● It's all just “Work” ● Steady “Flow” by Limiting Work in Progress (“WIP”) ● Measure Cycle Time & Throughput ● “Pull” System ● Stories, Epics & Tasks ● Incremental Delivery via (2 week) Sprints ● Measure Velocity ● Sprint Planning/ Negotiating
  37. 37. How to Choose? Kanban: ● Operations Work ● Software Maintenance Work ● Coming from Rigid Legacy Methods (Waterfall) ● Compartmentalized, Siloed Teams Scrum: ● Greenfield Project ● Many Stakeholders ● Must Coordinate Around a “Roadmap” ● Lots of Epic Stories
  38. 38. A Simple Kanban Board Ready Doing Done No distinction between Stories and Subtasks. They are all just Tasks.
  39. 39. A Simple Kanban Board Ready Doing Done Vertical “Lanes”
  40. 40. A Simple Kanban Board Ready Doing Done “Sub Lanes”
  41. 41. A Simple Kanban Board Ready Doing Done Horizontal “Swim Lanes” !
  42. 42. A Simple Kanban Board Ready (3) Doing (3) Done “WIP Limits”
  43. 43. A Software Dev Kanban Board Ready (6) Test (5) Done Example of a team workflow with progressive steps (by different handlers) Dev (3)Design (3)
  44. 44. An Event-Planning Kanban Board Ready (6) Finalize (5) Done Example of a (one-person) workflow with phases – nothing to do with engineering work Short List (3) Research (3)
  45. 45. The Broader Picture Ready (3) Doing (3) DoneBacklog Reflect
  46. 46. A Typical Kanban Board for Software Development Ready (6) Test (5) DoneDev (3)Design (3)
  47. 47. “Pulling” Kanban Cards Ready (6) Test (5) Done Sub-lanes show when steps are completed (ready to be pulled) Dev (3)Design (3) Available to be pulled Still in progress
  48. 48. Why Limit Ready Column? ● Enforces delaying decisions until last responsible moment ● It's how the Product Owner “negotiates” with the team – PO (representing stakeholders) decides what, Team decides in what order (by pull) ● Work is tracked according to the time it enters the Ready column until it lands in the Done column (“lead time”). A ready limit makes that meaningful.
  49. 49. Highlighting Priorities Ready (6) Test (5) Done ! Some options: Notation symbols on the cards, color coding of the cards, sub-lanes, or a combination thereof. Dev (3)Design (3) ! B A
  50. 50. Differentiating Work Ready (6) Test (5) Done Feature (value to customer) Dev (3)Design (3) ! ! Infrastructure (value to team) For example...
  51. 51. Flagging Impediments Ready (6) Test (5) Done Impeded Dev (3)Design (3) ! !
  52. 52. Flagging Impediments Ready (6) Test (5) Done Impeded Dev (3)Design (3) ! ! Impeded work is still WIP-limited
  53. 53. What About Story Size? Ready (6) Test (5) Done It doesn't seem to matter. Kanban case studies, so far, indicate that it's much more lucrative to be concerned with idle time between activity than the activity time itself. Dev (3)Design (3) Adjust them? Denote them? Track them?
  54. 54. Kanban Analysis Types ● By reflecting on outlier stories ● By looking for patterns on the Kanban Board ● By tracking cycle time ● By tracking flow
  55. 55. Reflecting on Outlier Stories Ready (3) Doing (3) Done _ Backlog Reflect ___ _ _ __ Outlier: Work with Extra-Long, or Extra-Short Cycle Time .
  56. 56. Reflecting on Outlier Stories Ready (3) Doing (3) Done _ Backlog Reflect ☹ ☺ ___ _ _ __ Outlier: Work that was Particularly Pleasant or Unpleasant .
  57. 57. Possible Actions: Outliers ● Is it a problem/opportunity? ● Dig deep (“5 Whys?”) to get from the proximate cause to the root cause ● How might the delay have been mitigated? ● Retool &/or Retrain ● Definition of Ready issue? Definition of Done issue?
  58. 58. Development Bottleneck Ready (6) Test (5) Done Step-completed still counts in WIP Limit Dev (3)Design (3)
  59. 59. Testing Bottleneck Ready (6) Test (5) Done Step-completed still counts in WIP Limit Dev (3)Design (3)
  60. 60. Design Bottleneck Ready (6) Test (5) DoneDev (3)Design (3)
  61. 61. Possible Actions: Bottlenecks Note: Occasional bottlenecks are good. They interject welcomed slack time. What you want is a roughly even distribution of slack time across the functions. If not, then ... ● Cross-functional “swarming” ● Add manpower ● Retool &/or Retrain ● (DO NOT just increase WIP Limits)
  62. 62. Recurring Impediments Ready (6) Test (5) Done Impeded Dev (3)Design (3) ! !
  63. 63. Possible Actions: Impediments ● Revise the Definition of Ready – Don't start the work until you know it won't be impeded that way ● Reassign responsibility for impediment-causing work to the Team (i.e. make the external resource join the team) ● (Rarely) revise the Definition of Done to exclude the impeded work (i.e. pushing responsibility for that part off the Team)
  64. 64. Tracking Cycle Times Ready (3) Doing (3) DoneBacklog Reflect Born Begin WIP Done
  65. 65. Cycle Time Ready (3) Doing (3) DoneBacklog Reflect
  66. 66. Lead Time Ready (3) Doing (3) DoneBacklog Reflect
  67. 67. Counting Flow Ready (6) Test (5) DoneDev (3)Design (3) 3 1 5 2
  68. 68. Cumulative Flow Diagram Done Test Dev Design
  69. 69. Actions: Encroaching Channels This is basically early detection for bottlenecks, so... ● (Same actions as Bottlenecks)
  70. 70. Control Chart X-axis: One column per story completed Trend line (running average) Y-axis: Lead time (subtract Begin date from Done date)
  71. 71. Control Charts Compared
  72. 72. Possible Actions: Wavy Trendline Can the hiccups be explained? If not, then... ● Smaller stories ● Reduce the WIP limits (yes, reduce) ● Attend to impediments ● Remove distractions
  73. 73. Take-Aways All of the various Agile Methodologies attempt to... 1. Eliminate waste. They “Maximize the work not done.” 2. Only provide a framework. You must “Inspect & Adapt” 3. Only illuminate problems. There is no silver bullet. 4. Boost communication. When stakeholders and developers are on the same page, the methodology has done its job.
  74. 74. © Craig L. Jones, 2011-13. All rights reserved. cjones@picsauditing.com http://tech.picsauditing.com

×