Recommended
More Related Content
What's hot
What's hot (20)
Similar to Kanban Explained Clearly
Similar to Kanban Explained Clearly (20)
Kanban Explained Clearly
- 1. Kanban “like playing Frisbee … with your dog!” Andrew Lloyd 6/20/2011 MissedMemo@GMail.com
- 2. me
- 3. You?
- 4. Agenda: • History: Agile pragmatism/fundamentalism seesaw • Misconceptions: What Kanban is – and is NOT! • Mechanics: How & why it works • Questions, discussion, sample Kanban boards…
- 5. Incompetence is no barrier to success !
- 6. Agile Fundamentalism: "Critics of the first edition have complained that it tries to force them to program in a certain way... I'm embarrassed to say that was my intention... in this edition, I have tried to rephrase my message in a positive, inclusive way“ -- Kent Beck, “Extreme Programming Explained” 2nd ed.
- 7. “Agile” defined by Principles • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Working software is the primary measure of progress. Agile processes promote sustainable development. • The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility. • Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (not specific practices)
- 8. Scrum...
- 10. “Kanban is not a software development cycle methodology or an approach to project management. It requires that some process is already in place so that Kanban can be applied to incrementally change the underlying process“ -- David Anderson (originator of Kanban) Kanban
- 11. Kanban is Simple! 1. Visual representation of your ACTUAL process (3 Requirements)
- 12. Scrum board (over-simplified): To Do In Progress… Done ! A B C E D
- 13. A B C E D To Do In Progress… Done !2 Scrum board vs. Kanban board: D
- 14. Kanban is Simple! 1. Visual representation of your ACTUAL process 2. Limit “Work in Progress” (WIP) (3 Requirements)
- 15. Actual board may have many columns… Backlog On Deck Done ! A Dev. Test B C D EF G H J K M N (2) (2) (1) Done
- 16. Kanban is Simple! 1. Visual representation of your ACTUAL process 2. Limit “Work in Progress” (WIP) 3. Track and optimize “flow” (3 Requirements)
- 17. Demo… Backlog On Deck Done ! A Dev. Test B C D EF G H J K M N (2) (2) (1) Done
- 18. A B C D E F G H JK M N Demo… Backlog On Deck Done !Dev. Test (2) (2) (1) Done
- 19. A B C D EF G H J K M N Demo… Backlog On Deck Done !Dev. Test (2) (2) (1) Done 2
- 20. A B C D E F G H J K M N Demo… Backlog On Deck Done !Dev. Test (2) (2) (2) Done
- 21. “Flow” Summary:
- 22. Cumulative Flow Diagram: # Days # Features in Each Column Development On Deck Test Done! WIP on day #4 = 9 Lead Time = 6 days By tweaking WIP ! ( seek to MINIMIZE )
- 23. Kanban “like playing Frisbee … with your dog!”
- 24. So, why all the hate? “The surprising thing for me is that many smart Agile people - people I know to be intelligent insightful people - seem bugged by Kanban... I'm seeing Agile people behave as strangely about Kanban as traditional process folks behaved about Agile. They seem threatened." -- Jeff Patton, (Agile speaker and author)
- 26. Kanban and Scrum: Making the Most of Both Definitive Resources: by Henrik Kniberg & Mathias Skarin (http://www.infoq.com/minibooks/kanban-scrum-minibook) Kanban: Successful Evolutionary Change for Your Technology Business by David J. Anderson Kniberg also authored Scrum and XP From The Trenches *
- 27. a Confession… "In theory, there is no difference between theory and practice. In practice, there is“ -- Yogi Berra
Editor's Notes
- If you remember one thing… Borrowed analogy -- we’ll come back to what it means later
- NOT consultant/selling services 20yr dev. interest in improving process -- Here’s why (sample) ! Lots co. & proj. size/types = IMPORTANT! – diff environs req diff process (highly-motivated talent at web start up vs. complacent 20/1000 HW ISO) C, C++/MFC x10, C#/.Net x8, Rails/Linx/Vim 2 startups, several med-large corps Shrink-wrap SF/TM, Congo, 15yr-old 2.6MLOC ODBC/RPC/MFC + 3K gotos MCP/CSM – hope no one’s impressed!
- Assuming Agile familiarity -- want to get some idea of level… XP? Scrum? Kanban? -- Frisbee? Anderson/Kniberg? CSM? Actively using form of Agile (team, not solo)? Found mgmnt/devs eager to adopt, clean/maint/ext code, short stress-free cycles? Web apps? Mobile? Enterprise Apps? Shrink Wrap?
- Cover history of Agile & how Kanban fits in, from diff perspective – prag vs. fund swings (“How dare you corrupt our methodology!” while entire BASIS of Agile is pragmatism) LOT’S of misconceptions! Mike @ S.F. Agile Meetup: 2yr. wait, Kanban unrecognizable – acc. to ORIGINATORS Misconceptions UNDERSTANDABLE due to the way Kanban works Describe mechanics and trace through simple demo to see how Kb handles typical events FireStarter vs. 3hrs = plenty of time for Q’s/discussion/alt. views – however misguided
- Important to keep in mind! + difficult for consciencious devs to accept ex: Jp co. = no code rev/stds, no SCM, step-thru, train to Osaka… but shipped! Possible, even COMMON to ship software wi. horrible process + great team can make ANY process work, while NO process can make up for poor team Agilist attitude often all-or-nothing, but… Should be seeking INCREMENTAL improvement – want to HELP dysfunctional co.s BECOME Agile! ( but WHICH process elements to target first for biggest effect? )
- (read quote) We see this again & again: “MUST do X” vs. Popendieck, Shalloway etc. “adapt to YOUR unique situation” (Flame wars also confusing/disturbing to non-dev. mgr considering Agile adoption) Kent Beck triggered first widespread AWARENESS of “lightweight” process via XP in 1999 (technically, Scrum predates XP from early 90’s, but no one heard of it) XP = 13 engineering practices, based on observing practices of effective devs & teams Small change + test => TDD Obsession with code quality => refactoring Value in 2nd pair of eyes/asking Q’s => pair programming etc. Strictly ENGINEERING focus Initial attitude = MUST DO ALL 13 Practices! Backlash (didn’t fit dev. reality) Reject pairing (dev. & mgr), assumed skill level (poor coders != good tests), role of PM… Book: “Extreme Programming Refactored: The Case Against XP” – incl. failure @ Chrysler Beck’s apology = admission of need to adapt to YOUR situation
- In 2001, 17 proponents of “lightweight” methods authored Manifesto + PRINCIPLES In terms of pragmatist vs. fundamentalist arguments, remember… ANY process generally consistent with these principles IS AGILE! (common?) example of co. adopting practices while ignoring PRINCIPLES: 2.6MLOC ODBC/RPC/MFC = client-server HW/DB… 3yr. rewrite wi. corporate devs + new tech. Suggested “Walking Skeleton”: exercise architecture, 2 leads, good tests, review code… Mgmnt: estimate “tasks” (unfamiliar tech!), plot in proj plan, sign in blood, randomly assign… 6 mos. Later = indep. “features”, no review, panic meetings on “cuts” + cancel vacations Unit testing and CI server, but SO WHAT?! Note principle #12: Should apply to PROCESS itself (not just activities UNDER specific process)
- Growing adoption of Scrum with 2001 book on subject (Scrum actually dates from early ‘90s) Moves agile beyond engineering, to coord. with product management Usually adopts XP practices – “Should we use XP, or Scrum?” makes no sense! Simplified Scrum activities (ignoring roles, philosophy etc) to compare wi. Kanban: (note demands made on marketing “owner” etc.) Backlog of features in form of User Stories, prioritized by “owner”, and sized (T-shirt or story pts) Meet wi. owner: desired features in 2 weeks “sprint” vs. portion devs feel can complete Devs meet separately, to break down stories and take on tasks (self-org.) Devs meet in daily 15min. “stand up” with 3 questions (owner may observe) After 2 weeks, meet wi. owner (and anyone else), to demo Devs meet separately, to review process and make adjustments Work planned vs. completed = better estimates next round Rinse & repeat…
- CSM instructor frustration (co. “won’t accept”) + separate QA question Like XP, issues encountered by MANY Scrum teams in practice AUTHORITY to change process differs in startup vs. corp. Devs don’t get to DICTATE to external groups! (ability to request SOME changes is assumed) Attempts to work around = “Scrum-but” criticism – trying to solve REAL problems! (ironic, since Scrum today != “original” Scrum) 2wk. sprint and many planning/review elements added later Specific example: $1B pub co., 20devs/1000, ISO/customer audits, shared QA, FDA/EEC… Go to marketing dept. (“owners”) and insist… Submit requests in form of user stories (or acceptance tests) Meet half day every 2 weeks – you request, we say “no” Evaluate 2week (partial) features Go to proj. manager and say “we’ll make decisions” (vs. THEIR manager’s expectations) QA manager discovers you’ve been suggesting integration of QA Ask UIX designer to work incrementally, without knowing full set of features to be integrated Owner response: BUSY meeting wi. Customers, visiting Jp office wi. CEO… avail. via mail etc. Also developer resistance: “Do I really have to read all of this?” Also problems wi. defined process itself – failed sprints Agile consultant’s message = Steve Martin’s “I can make YOU a MILLIONAIRE!”
- (read quote) This is from ORIGINATOR! – Many criticisms/promotions of Kb not even Kanban! Just like “Scrum vs. XP”, “Kanban versus Scrum” makes no sense! Kanban is something you ADD to EXISTING process! (Obviously, if you able to start fresh, will borrow from XP/Scrum) Kanban first presented publically in 2007 INSPIRED by lean manufacturing -- but very different! Doors and palace grounds examples = signalling system Anyone can “stop the line”, focusing everyone’s attn. on resolving issue Immed. reports of dramatic results – incl. from many experienced Scrum practitioners! Easier “buy in” (requires few changes, makes few demands) Leads to gradual adoption of more Agile practices as SIDE EFFECT of tracking “flow”
- Kanban is simple/trivial 3 practices you can apply to ANY existing process, incl. textbook Scrum or Waterfall If you are doing textbook Scrum, ALREADY doing one of practices! because… (click)
- …Scrum board IS a visual representation of your dev. process! Note we specified “ACTUAL” process (tendency to show MANDATED process vs. process actually being followed – 5” ISO binder)
- Difference between Scrum board vs. Kanban board – watch carefully! We’ve defined an “arbitrary” limit on work in progress and that is…
- …the SECOND Kanban requirement! How to decide number to use? Doesn’t matter! Usually some number LESS than number of devs Self-correcting, as we will see Note just one example of change in mindset: silos/pair resistance
- Columns do NOT represent “waterfall” – QA may plan tests for item in dev. etc. ( Think of it as things that need to be “checked off” for item to be “done” ) Design? User Documentation? Localization? Security review? Code review? Do not have to get columns “correct” right away – adjust as you go No formal “owner” etc. roles required – remember, just 3 requirements! (Tech lead could select from backlog during architecture phase etc.) Add colors, “swim lanes” etc., but beware “creeping complexity” – shouldn’t need user manual! (8 color codes, misc. attachments, 6 horiz. lanes, 8 cols subdivided, multiple projects… = defeat purpose!) Loses at-a-glance transparency on “flow” of work items + FAIL TO SPOT PROBLEMS ! Can no longer tell mgr. “Don’t need status reports, just glance at board” Board lets us instantly (and AUTOMATICALLY) identify inefficiencies ie: “items moving quickly through dev. but spending long time in Test…” which brings us to the final (and MOST IMPORTANT) item…
- NOT passively “watching” items move across board! Kanban has directed PURPOSE/goal Seeking to minimize avg. time between item start (“On Deck”) and marking it “Done” Everyone’s attention should CONTINUALLY be focused ON THIS ONE THING! (fundamental Agile principle of ensuring sustainable, comfortable pace… still applies.) Do not ignore this! Teams that fail to adjust high WIP numbers risk long lead times etc. (focus on eliminating impediments to smooth work item flow turns out to maximize throughput) Some more specific benefits of focusing on “flow”: Provides guidance to “owner”: “Currently processing item ea. 6wks. What 2 items do you want in 6wks?” Provide EVIDENCE to management: “Items getting stuck in Test. Hire more testers?”
- This is just SIMPLIFIED example to illustrate “flow”… Note we don’t show breakdown into tasks (approaching limits of what you want to be doing wi. PowerPoint animation!)
- When system “clogged” everyone’s attention is focused on issue = incentive for permanent fix (same as “Stop The Line” in lean manufacturing) Not just tracking “clogs”, but TIME spent in queue! (With explicit columns, never have to “guess” why things are taking too long) WIP too low = “clog”, too high = long time spent in queue (example: 4 devs, WIP of 1, 3 devs not working… items spend long time in “On Deck” queue!) Not just “waiting” for problems – expected to actively TWEAK process elements and see effect on lead time so, we need a simple metric…
- Commonly track via “Cummulative Flow Diagram” (may use many additional metrics, incl. Scrum “burn down” charts etc.) (run demo) “Narrow” bands = short lead time! Some teams track Minimum Marketable Features (MMF) What owner cares about and can “evaluate” (MMFs of different size/duration, so others prefer story points etc.) Scrum = how many items can we do in 2 weeks? (“velocity”) Kanban = how long, on average, does it take to complete an item? (“lead time” or “cycle time”)
- There ARE NO RULES on how to play Frisbee with your dog ! Don’t even have to throw Frisbee (assume Frisbee + dog, adjusting activity consistent with goal of “fun”) Similarly, Kanban does not prohibit ANYTHING, or mandate anything beyond 3 items! Expected to continually analyze and ADAPT to your unique project/org. requirements (visitor to Anderson shocked that ea. team’s board was completely different!)
- Many experienced Scrum practitioners HAVE TRIED and love Kanban Found it resolves common problems with Agile adoption in real world Many others criticize purely on PHILOSOHICAL grounds! “It’s waterfall”, “it’s Scrum-but”… Most upsetting to Scrum “purists” = teams DROPPING estimation & fixed iterations Scrum teams reported they GRADUALLY determined these practices no longer added value Teams creating a process from scratch found no need to adopt these practices (source of misconception that Kanban PROHIBITS estimation/iterations) If you remove estimation and fixed iterations, aren’t you missing out on proven benefits of Scrum? Management seems to quickly become happy with accuracy of “lead time” estimates No “unreasonable” time/effort requirements imposed on external groups Less ceremony for developers (daily stand up becomes quick focus on impediments) Development can be continuous, with SEPARATE schedules for release and retrospectives Releases can occur only when Minimal Marketable Feature is ready Retrospectives can occur at whatever frequency makes the most sense etc.
- There is debate on value of digital versus physical boards… Many (Scrum and Kanban) orgs use digital for remote sharing, but still meet around physical (also contributes to “information radiator” effect)
- Recommend reading Kniberg (forward by Anderson) (Quick read, free, Kanban essence, recognized Scrum authority) Anderson includes complex OPTIONAL metrics + details = distract from understanding
- Debated whether this should have been 1st slide… My interest in Kanban from recognizing how it could have helped transition to Agile at previous co. (Push for full-blown Agile rejected, but project shipped “successfully” 3yrs, half features, bad code) Have not actually been on team working under Kanban!