Scrum vs Kanban

Scrum vs. KanbanAn introduction to Scrumban

About Dimitri Ponomareff Agile Coach & Trainer ● Wolters Kluwer (Data-warehouse) ● Apriva (Mobile) ● Choice Hotels International (Web) ● First Things First / AZ ECDH (Data-warehouse) ● JDA Software Group (Software) ● Insight Enterprises (Web) Facilitator of “The 7 Habits of Highly Effective People” Project Manager ● Project Management Professional (PMP) ● Agile Certified Practitioner (PMI-ACP) ● Certified ScrumMaster (CSM) ● Certified Scrum Practitioner (CSP) IT Professional ● Vice President of Communications - PMI Phoenix Chapter ● Director of Web Technologies - I-ology ● E-Commerce Manager - Insight Canada

Agenda ● Scrum overview ● Kanban overview ● Scrumban overview ● Scrum vs. Scrumban ● Questions

Scrum Overview Roles Product Owner Scrum Master Team Sprint Stakeholder s Product Backlog Users Task (prioritized) Board Daily Scrum Sprint Sprint Sprint Product Sprint Burndown Planning Review Increment Backlog Sprint Retrospective

Scrum "redux" with Scrumban Roles Product Owner Scrum Master Team Sprint Stakeholder s Product Backlog Users Task (prioritized) Board Daily Scrum Sprint Sprint Sprint Product Sprint Burndown Planning Review Increment Backlog Sprint Retrospective

Scrum "redux" with Scrumban only Roles Team Stakeholders Users Planning Review Retrospective Backlog Scrum-ban Daily Continuous (JIT) Board Scrum Increments

Kanban Visualize the workflow ● Kanban literally means "signboard" or "billboard" Just-in-time (JIT) ● identify and eliminate wasteful activities, only build what you need Limit Work In Process (WIP) ● establish and respect your ideal capacity, do what works best to get the work done Manage and optimize the flow/process ● continually seeks ways to reduce the lead time for getting the work done ● make process policies explicit ● improve collaboratively Its not an inventory control system; its a pull scheduling system that tells you what to produce, when to produce it, and how much to produce.

Toyota Philosophy of complete elimination of waste "Just-in-Time" means making "only what is needed, when it is needed, and in the amount needed." source: http://www.toyota-global.com/company/vision_philosophy/

Kanbansource: http://finance.groups.yahoo.com/group/kanbandev/

Scrumban ● a methodology combining the best from both Scrum and Kanban ● a visual continuous workflow displayed on a board ● specialized functional teams are possible ● focused on continuous and empirical process optimization ● responding to change over following a plan, as soon as capacity becomes available

Kanban Board - Start to do in process done Start with a simple task board with 3 columns: to do, in process and done. a Each card represent a work item in the current scope. Names can be b associated with the cards. c The key is to setup an easy way to visualize the work, and create an area for social interactions.

Kanban Board - Start to do in process done Start with a simple task board with 3 columns: to do, in process and done. a Each card represent a work item in the current scope. Names can be b associated with the cards. c The key is to setup an easy way to visualize the work, and create an area for social interactions. to do in process done A problem with such a simplistic board, is the lack of rules and the concept a of time-boxing. b a b a a A typical problem is accumulating too much work in progress (WIP). b a c Kanban is more than just adding work items on a board, its also applying a c c PULL process.

Kanban Board - Start to do in process done Start with a simple task board with 3 columns: to do, in process and done. a Each card represent a work item in the current scope. Names can be b associated with the cards. c The key is to setup an easy way to visualize the work, and create an area for social interactions. to do in process done A problem with such a simplistic board, is the lack of rules and the concept a of time-boxing. b a b a a A typical problem is accumulating too much work in progress (WIP). b a c Kanban is more than just adding work items on a board, its also applying a c c PULL process. to do ready in process done To truly embrace Kanban, we must regulate the volume of cards on the a board. This can easily be accomplished by identifying clear thresholds a associated to better defined stages of work (columns). b c c Another improvement is to set a multi-tasking limit per user (2) and using late binding of tasks to owners. Note that not all team members must have 2 2 5 tasks with their names, this is a maximum of 2.

Kanban Board - Mechanics to do ready in process done a a b c c to do ready in process done a 2 5 a 1. Team member A completes b a card and moves it to the c c to do ready in process done "done" column. a a 2 5 a 2 2. Team member A pulls a new b card from the "ready" column c c and starts working on it by placing it in the "in process" 2 5 column. 3. The team responds to the pull event and selects the next priority card by moving it to the "ready" column.

Kanban Board - Flow to do ready in process done to do ready specify execute done b b a a b b c c c c 2 5 2 2 3 Now that we have established our team capacity and we have a pull system, we can streamline the ideal flow.

Kanban Board - Flow to do ready in process done to do ready specify execute done b b a a b b c c c c 2 5 2 2 3 Now that we have established our team capacity and we have a pull system, we can streamline the ideal flow. backlog ready specify complete execute done b a a b c c 8 2 3 2

Scrumban Board - Example

Scrum vs. Scrumban Scrum Scrumban Board / Artifacts board, backlogs, burn-downs board only Ceremonies daily scrum, sprint planning, sprint daily scrum (planning, review and review, sprint retrospective retrospective as needed) Iterations yes (sprints) no (continuous flow) Estimation yes no (similar size) Teams must be cross-functional can be specialized Roles Product Owner, Scrum Master, Team Team + needed roles Teamwork collaborative as needed by task swarming to achieve goals WIP controlled by sprint content controlled by workflow state Changes should wait for the next sprint added as needed on the board (to do) Product Backlog list of prioritized and estimated stories just in time cards Impediments dealt with immediately avoided

Scrumban Backlog ● extend board to story creation/elaboration ● avoid creating/analyzing too many stories - reduce waste ● assure the necessary level of analysis before starting development ● the backlog should be event-driven with an order point ● prioritization-on-demand - the ideal work planning process should always provide the team with best thing to work on next, no more and no less

Impediments and blocked work ● focus on lower priority work (spikes, analysis, etc...) ● invest in production capability improvement work ○ automation (testing, deployment, etc..) ○ re-factoring ○ personal development ● but NOT anything that will create work downstream

Boards - Scrum vs. Kanban Scrum Sprint Last Sprint Day 1 Mid-Sprint Day Kanban Any Day

Release - Scrum vs. Kanban week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Team 1 - Scrum sprint 1 sprint 2 sprint 3 sprint 4 Release every sprint Team 2 Release every 2 weeks Team 3 Release every week Team 4 Release when needed planning review & decision to release retrospective

When to consider Scrumban ● maintenance projects ● event driven work ○ help-desk/support ○ hardening/packaging phases ● projects with frequent and unexpected user stories or programming errors ● around sprint teams focused on new product development ○ work preceding sprint development (backlog, R&D) ○ work following sprint development (system testing, packaging and deployment) ● if Scrum is challenged by workflow issues, resources and processes ● to manage improvement communities during/after Scrum roll-out

Kanban for Portfolio Management In Process Queue 5 Release Done 6 Concept Scope Development Testing 2 Project Team #1 Project Team #2 Project Team #3

Kanban for Architecture Queue In Process Release Done 6 5 2 Analysis Modeling Development Testing Service #1 Service #2 Service #3

Kanban for IT Backlog Analysis In Process Done 8 3 Specify 6 Execute Production Release Dev Support Project A Project B

Kanban for Support with multiple clients New Analysis Development Done Production Issues Estimate In Process Done Backlog Specify Publish Design Code Test Package 3 2 3 2 4 C1 C2 C3 C4

Kanban for Marketing Ideas Priorities In Design 3rd Party Release Done 8 Specify 3 Execute Review 4 Validate 2 Web Event COM PR

Kanban for Sales Create RFP Queue 5 Review Done 6 RFP Ready In Progress Complete 2 Sales Team #1 Sales Team #2 Sales Team #3

PMI-ACP - Certification Training (3 days - 21 PDUs) March 28, 29 and 30, 2012 (Phoenix) May 23, 24 and 25, 2012 (Raleigh-Durham, NC) June 6, 7 and 8, 2012 (Phoenix) REAL-ILT Remote Education for Advanced Learning – Instructor Led Training Agile Exams will be included in your PMI-ACP Prep Workshop.

Agile Coaching, Staffing and Training. Learn more at www.torak.com

Thank You

Resources and References ● Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas ● Kanban and Scrum - making the most of both by Henrik Kniberg, Mattias Skarin ● Wikipedia - Scrum http://en.wikipedia.org/wiki/Scrum_%28development%29#Scrum-ban ● Toyota ○ Just-in-Time — Philosophy of complete elimination of waste ○ TPS (Toyota Production System) or "kanban system" ○ http://www.toyota-global.com/company/vision_philosophy/

This presentation was inspired by the work of many people and we have done our very best to attribute allauthors of texts and images, and recognize any copyrights. If you think that anything in this presentationshould be changed, added or removed, please contact us. http://creativecommons.org/licenses/by-nc-nd/3.0/

http://www.torak.com	517
http://blog.jaffamonkey.com	258
http://torak.com	142
http://www.iliokb.com	3

Scrum vs Kanban

by Dimitri Ponomareff on Jul 29, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 920

Statistics

Scrum vs Kanban — Presentation Transcript