1 Kanban in Practice
2 Introductions Your Name, Job & Employer Any Agile Experience?Eg Scrum, DSDM, XP, Kanban, other Any Non-Agile Experience? PRINCE2™ APMP etc.
3 Domestics Timings Breaks Facilities Lunch arrangementsEmergency procedures Explain the course start and finish times, and the times and length of breaks Explain any emergency procedures, fire alarms and exist Explain your style for running the course, how to handle questions etc.
4 What’s in a name? The Kanban method Kanban Kanban systemsKanban: Sucessful Evolutionary Change for your Technology Business, Anderson, David J., 2010 Kanban Kanban systems p.48-49 Kanban itself is a Japanese term. Kan = visual & ban = card. Originally implemented by Toyota as part of their Toyota Production System (TPS) in the late 1940’s. TPS is the foundation of Lean, which in turn can be seen as the underpinnings of Agile.
5 The 3 Principles of KanbanVisualise Limit W.I.P Manage flow Implement Feedback loops Improve collaboratively, evolve experimentally Make process policies explicit
6 Be a radiator, not a fridgePros: Fresh Secure Accessible to remote teams Cons Have to ‘pull’ info. Can force your process Not a meeting point Access issues Pros: Pushes info. Infinitely flexible Creates a hub Readily understandable Cons Unsecure Takes up space Difficulties around remote team members p.60
7 The Kanban Board
8 Top tips for mapping workflowLet the board reflect your ACTUAL process Learn by DOING Don’t get attached to your board; it WILL change
9 Part I Draw up a simple Kanban board for a small BBQ party. You’ll need to manage only burgers and you only have one cook.
10 BBQ art I possible boardJust an example. What can we already spot is a problem here? There’s a bottleneck at rolls, why might that be? Could be there’s a queue for rolls
11 Part II Draw up a simple Kanban board for a small BBQ party. You’ll need to manage only burgers and you only have one cook. Let’s look for the queues this time.
12 BBQ part II possible boards
13 Why queues suck 46 weeks 38 weeks waiting! 82% wait time 82% wait time
14 Entry & exit criteria p.68 Primarily there to build consensus around what state a work item is in. You can see this as a way of Making Process Policies Explicit.
15 I can’t live on burgers alone!Work items can consist of different types or classes: Different classes of service may: Have different SLAs Move through you Kanban board differently May be handled by a parallel process New features Maintenance Bugs
16 How to balance work items
17 Handling urgent, important work
18 Who’s working on what?
19 Avatars
20 Tracking, size & progressAs a Wiki user I want to upload a file to the Wiki so that I can share it with my colleagues. Animation 1 Tracking IDs are important, this will point to your fridge, where other info is held. Animation 2 Not all User stories are take the same effort or have the same complexity. We’ll come on to estimating later, but for now lets record it here. ﻩ 5
21 Due dates, workflow & moraleAs a Wiki user I want to upload a file to the Wiki so that I can share it with my colleagues. !!!17 JUN 15!!! Doing: 07 MAY 15 Test: 08 MAY 15 Done: 09 MAY 15 5
22 How would you deal with blockers??#%!!!
23 Dealing with blockers better
24 Pass the pennies p.288
25 People idle or work idleWIP too high = work idle WIP too low = people idle
26 Effects of too much WIP Context SwitchingDelay causes extra work (the ripple effect) Decreased quality Increased risk Increased overhead Decreased motivation Context switching numbers from Gerald Weinberg. System hernia diagram from Scott Bellware, Design Flaws, Hernias, & Anemic Quality
27 What should we set our WIP to?Stop starting, start finishing It depends… Not limiting WIP is NOT the answer!
28 How can we look at WIP? Three broad approaches:Take a Whole Board Whole Team (WBWT) approach Limit WIP by columns Limit WIP by people
29 2 8 4 lowers lead times WBWT approaches Take 1! Take 2!Shrink the pool Start big & adapt Guess! 2 8 4 p
30 What about queues, do they have WIP?Limit WIP by columns lowers cycle times Start with the largest constraint Choose to improve collaboration Managing different sized stories What about queues, do they have WIP? p
31 Limiting WIP by people lowers… ??? Devpool Swimlanes
32 So, what should I do next? Help finish work that is already in process. Remove bottlenecks and impediments which are currently slowing down the system. Now, only now, pull a new work item – as long as this doesn’t break WIP limits. Do something interesting that you think will help the team.
33 DSDM Atern v2 Practitioner (1.0)Estimating effort DSDM Atern v2 Practitioner (1.0) Effort is estimated by Teams When estimating Effort, teams need to consider both size and complexity One job might be small, but complex, another large, but fairly straightforward E.g. a short steep, technical climb or a jaunt up a big hill The best estimates come from developer who really understand what they’re estimating. Why are we teaching you how to estimate effort if you aren’t going to do it? Good point, understanding how your team assesses effort is vital to good comms – the original version of this course didn’t have this in. The best estimates come from developer who really understand what they’re estimating. Patton (2014)
34 DSDM Atern v2 Practitioner (1.0)Story points DSDM Atern v2 Practitioner (1.0) How do we measure how much “Effort” each PBI will take? Some teams use number of Hours or number of Days. Ideal Days are often used. Many teams use a relative size measure, eg “T-shirt sizes” (S, M, L, XL, XXL etc) Story Points are popular – an arbitrary value assessing the size of a PBI Ideal Days: It’s now Tuesday. If I say a job will take me 2 days, that doesn’t mean I will be finished by Thursday. I have other stuff to do – hence 2 Ideal Days. Ideal Days usually have a ratio of 2:1 or 3:1 to real days.
35 DSDM Atern v2 Practitioner (1.0)Planning Poker cards DSDM Atern v2 Practitioner (1.0) 0 = No effort or already complete. ½ = Very small items. 1,2,3 = Small items. 5, 8 13 = Medium items. 20, 40 = Large items. You may want to consider breaking these down into smaller items! 100 = Very large items or ‘Epics’ – definitely consider breaking these items down further!
36 Planning Poker cards ∞ = Infinite, too large to even estimate.? = Can mean one of two things, either “We don’t understand this user story!” or “This is so far outside of my experience it would be futile for me to attempt an estimate!”. π = I’m sick of this, lets get some pie, tea etc.
37 Planning Poker exampleDSDM Atern v2 Practitioner (1.0) As a Wiki user I want to upload a file to the Wiki so that I can share it with my colleagues. TRAINERS NOTES Essential Scrum Chapter 7 Here’s an example of a team of 4 using Planning Poker to estimate a User Story. Each team member selects the card he or she thinks best represents the effort required to fulfil the User Story and places it face down on the table. All the cards are then revealed at the same time! We can see that tow of the team are in agreement, one is unsure as to how to estimate this requirement and another thinks it will take less time. Since there is a difference of opinion, it is time for the team to discuss why they placed the value they did on it. Once this has been done it is time to play the cards again…
38 Planning Poker exampleDSDM Atern v2 Practitioner (1.0) As a Wiki user I want to upload a file to the Wiki so that I can share it with my colleagues. TRAINERS NOTES Essential Scrum Chapter 7 We can see now that two of the team members have now reassessed their position. In addition to this, the team member who was unsure as to how to estimate the requirement has now made one using the collective judgment of his peers. However, we have still yet to reach consensus, so the process is repeated…
39 Planning Poker exampleDSDM Atern v2 Practitioner (1.0) Planning Poker example As a Wiki user I want to upload a file to the Wiki so that I can share it with my colleagues. 5 TRAINERS NOTES Essential Scrum Chapter 7 All team members have now agreed to an estimate, to keep things simple, this estimate is often written directly on the requirement itself. The team can now move on to their next requirement, or indeed go for π!
40 DSDM Atern v2 Practitioner (1.0)Relative estimating DSDM Atern v2 Practitioner (1.0) Have each team member give a fruit or two. Write them up. Ask the group to decide on which fruit is the easiest to prepare and consume. This fruit (typically a grape or blueberry) represent our benchmark story c.f. an easy piece of work, writing a dropdown menu, creating a simple SQL query with minimal joins, writing an A4 page of copy etc.
41 #NoEstimates ?#%!!!
42 Feedback Loops Most teams hold: A daily stand-up or daily kataA periodic review of their working practices aka: Retrospective Process review Implement Feedback loops
43 Kanban Pizza Game Iteration 1 Goal:Make as many Hawaiian pizza slices as possible while limiting wasted materials. Constraints: No more than three slices in the oven at once. Slices must be baked for 30 seconds. No adding or removing slice from the oven while baking.
44 Get Baking! 1
45 Kanban Pizza Game Scoring system: Finished slices score 10 pointsNow GO KANBAN! Scoring system: Finished slices score 10 points Wasted materials cost: 4 points per pizza base 1 point per topping
46 Get Baking! 2
47 Kanban Pizza Game Scoring system: Finished slices score 10 pointsWasted materials cost: 4 points per pizza base 1 point per topping New constraints: Pizza’s must now be built to order, all slices must be completed for an order to have value! New pizza type – Rucola – has seven pieces of spinach, but no ham or pineapple. Spinach must be added AFTER baking – it wilts!
48 Get Baking! 3
49 Kanban Pizza Game Scoring system: Finished slices score 10 pointsWasted materials cost: 4 points per pizza base 1 point per topping All prior constraints still apply!
50 Get Baking! 4
51 Finish!
52 Theory of Constraints The Five Focusing Steps:Identify the constraint or bottleneck Exploit the constraint Subordinate other work to support the exploitation Elevate the constraint Rinse and repeat p.161 Goldratt
53 Cycle vs. Lead Times Cycle time Lead time To Do Analyze Dev To TestIn Test Done Testing Lead time
54 Visualising Cycle Time
55 Visualizing Lead Time US129 US141 US131 US133 US132Graph assumes no story-points US141 US131 US133 US132
56 Visualizing Lead Time with Story PointsUS131 US133 US132 US129 US141 US132 (1) US133 (1) US141 (2) US129 (5) US131 (1) Graph assumes no story-points
57 Visualising Throughput
58 Visualising Throughput with Story Points
59 A little LSD is good for youLean Software Development (LSD) identifies 7 muda or wastes: Partially done work Extra features Relearning Handoffs Delay Task switching Defects
60 Visualising Bugs & BlockersDon’t let the team get blocked
61 Visualising Failure DemandEffectively UAT kickback
62 Which Metric? Cycle time = inspect individual processesLead time = inspect whole process Throughput = assess velocity Bugs & Blockers = assess technical & Agile maturity Failure Demand = assesses customer engagement Due date performance = assesses estimation Discarded ideas = assesses product innovation
63 Cumulative Flow Diagrams (CFD)Size of PBL Size of WIP Cycle time Lead time
64 Kanban convert? Try… Kanban in Action by Hammarberg & SundenKanban & Scrum: Making the Most Out of Both by Kniberg & Skarin Lean from the Trenches: Managing Large-Scale Projects with Kanban by Kniberg Kanban by Anderson Theory of Constraints by Goldratt