Scrum vs Kanban
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Scrum vs Kanban

on

  • 16,646 views

The presentation is about understanding the differences between Scrum and Kanban and underhand which Agile methodology is best suited for your needs . It's a special tool that must be used in the ...

The presentation is about understanding the differences between Scrum and Kanban and underhand which Agile methodology is best suited for your needs . It's a special tool that must be used in the right circumstances. I continue to promote Scrum first for projects focused on new features to increase customer satisfaction, but when teams enter hardening phases in their product life-cycle or fall in complete maintenance mode, instead of letting Scrum lose it's shine, I prefer to introduce Kanban or Scrumban.

Statistics

Views

Total Views
16,646
Views on SlideShare
14,486
Embed Views
2,160

Actions

Likes
18
Downloads
637
Comments
6

12 Embeds 2,160

http://www.torak.com 1081
http://blog.jaffamonkey.com 370
http://www.scoop.it 311
http://torak.com 280
http://www.linkedin.com 46
http://www.agiletestingframework.com 29
http://tracks.roojoom.com 28
https://www.linkedin.com 8
http://www.iliokb.com 3
http://pinterest.com 2
http://131.253.14.250 1
https://duckduckgo.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

15 of 6 Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • This is great Dimitri!

    One question, with a team of 9, how might I calculate the WIP limits for the team? One approach is dividing the team number by two and rounding down. Another approach is giving everyone a WIP limit of two, add the WIPs together and subtract one.

    What are your thoughts?
    Are you sure you want to
    Your message goes here
    Processing…
  • Excellent, thanks Dimitri
    Are you sure you want to
    Your message goes here
    Processing…
  • @harvinsingh There is no velocity since there is no iteration to associate a velocity. The capacity of a team is measured directly on the board by setting WIP limits on the columns. Ultimately in Scrumban we want as a team to focus on similar size stories, but even if the stories are not similar size, over time an average time for a card to get through the board can be calculated. This average time can be used to set the expected time for a card to get Done.
    Are you sure you want to
    Your message goes here
    Processing…
  • Thanks for the answers.
    In Scrum we derive velocity by the total story points completed by the team in each sprint. How do you derive velocity in Scrumban/ Kanban, or is velocity not measured ?
    Are you sure you want to
    Your message goes here
    Processing…
  • 1. No, in Scrumban there is no need to do iteration planning. The concept of time-boxing is removed in terms of having iteration cycles. This is a key reason that Agile teams evolve into Kanban, to embrace a continuous flow of work. With that said, the slide in this presentation illustrating release planning does show that although it's a continuous flow, we still conduct the Scrum ceremonies (planning, review, retrospective) at a set frequency by the team.

    2. The lead time can easily continue to be calculated from the time the card (work) hits the Kanban board (To Do column) and completes (Done column). The cycle time is also easily tracked when the card enters the WIP columns on the board. Just adding a couple of dates on the card and tracking it consistently will give you what you need to calculate these 2 metrics.

    Remember that the main distinction in adding Kanban to Scrum is the extreme focus on the Board. Visualizing all the work on the board (the entire process), reaching all the way to also include 'story creation / backlog management' is what is so enticing when considering the evolution to Scrumban.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Scrum vs Kanban Presentation Transcript

  • 1. Scrum vs. Kanban Migrating from Scrum to Kanban
  • 2. About Dimitri Ponomareff Agile Coach ● American Express ● Charles Schwab ● JP Morgan Chase ● Bank of America ● LifeLock ● First Solar ● Mayo Clinic ● AAA Insurance ● Phoenix Children's Hospital ● Choice Hotels International ● State of Arizona - First Things First, ADOT, ADE ● Wolters Kluwer ● Apriva ● JDA Software Group Facilitator of “The 7 Habits of Highly Effective People” Certifications ● Project Management Professional (PMP) ● Agile Certified Practitioner (PMI-ACP) ● Certified ScrumMaster (CSM) ● Certified Scrum Practitioner (CSP) IT Professional ● CIO - Concord Software ● Vice President Communications - PMI Phoenix ● Director of Web Technologies - I-ology www.torak.com
  • 3. Agenda ● Kanban overview ○ Visualizing the work ○ Making the Process explicit ○ Continuously improving the Flow ● Scrum vs. Kanban ○ Starting with Scrum, evolving to Kanban ○ Diagnosing a Scrum team ○ Scrum time-boxed challenges ● Kanban (When & How) ○ Ideal environments for Kanban ○ Kanban JIT Backlog ○ Estimates (or not) with Kanban - calculating Cycle Time ○ Release planning ● Blending Scrum & Kanban ○ Scaled Agile Framework (SAFe) ○ Scrum + Kanban implementations ○ Kanban board examples
  • 4. 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 It's not an inventory control system; it's a pull scheduling system that tells you what to produce, when to produce it, and how much to produce.
  • 5. 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/
  • 6. Kanban Board - Start a b to do in process done Start with a simple task board with 3 columns: to do, in process and done. Each card represent a work item in the current scope. Names can be associated with the cards. The key is to setup an easy way to visualize the work, and create an area for social interactions. c
  • 7. Kanban Board - Start a b to do in process done Start with a simple task board with 3 columns: to do, in process and done. Each card represent a work item in the current scope. Names can be associated with the cards. The key is to setup an easy way to visualize the work, and create an area for social interactions. b a to do in process done A problem with such a simplistic board, is the lack of rules and the concept of time-boxing. A typical problem is accumulating too much work in progress (WIP). Kanban is more than just adding work items on a board, it's also applying a PULL process. a b a b a cc c a c
  • 8. Kanban Board - Start a b to do in process done Start with a simple task board with 3 columns: to do, in process and done. Each card represent a work item in the current scope. Names can be associated with the cards. The key is to setup an easy way to visualize the work, and create an area for social interactions. b a to do in process done A problem with such a simplistic board, is the lack of rules and the concept of time-boxing. A typical problem is accumulating too much work in progress (WIP). Kanban is more than just adding work items on a board, it's also applying a PULL process. a b a b a cc c a to do in process done To truly embrace Kanban, we must regulate the volume of cards on the board. This can easily be accomplished by identifying clear thresholds associated to better defined stages of work (columns). 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 tasks with their names, this is a maximum of 2. b c a ready a c c 52
  • 9. Kanban Board - Mechanics to do in process done b c a ready a c to do in process done b c a ready a c to do in process done b c a ready a c a 1. Team member A completes a card and moves it to the "done" column. 2. Team member A pulls a new card from the "ready" column and starts working on it by placing it in the "in process" column. 3. The team responds to the pull event and selects the next priority card by moving it to the "ready" column. 2 5 5 5 2 2 2
  • 10. Kanban Board - Flow Now that we have established our team capacity and we have a pull system, we can streamline the ideal flow. to do in process done b c ready a c b to do specify done b c ready a c b execute 2 5 2 2 3
  • 11. Kanban Board - Flow Now that we have established our team capacity and we have a pull system, we can streamline the ideal flow. a backlog specify done b ready a c b complete execute c to do in process done b c ready a c b to do specify done b c ready a c b execute 2 5 2 2 3 28 3 2
  • 12. Roles Scrum Overview Product Backlog (prioritized) Sprint Backlog Sprint Planning Sprint Retrospective Sprint Review Daily Scrum Product Increment Sprint Task Board Sprint Burndown ScrumMaster Product Owner Team Stakeholders Users
  • 13. What Kanban likes about Scrum Roles Product Backlog (prioritized) Sprint Backlog Sprint Planning Sprint Retrospective Sprint Review Daily Scrum Product Increment Sprint Task Board Sprint Burndown ScrumMaster Product Owner Team Stakeholders Users
  • 14. Kanban with Scrum - or Scrumban Roles Backlog (JIT) Retrospective Daily Stand Up Continuous Increments Kanban Board Team Stakeholders Users ReviewPlanning
  • 15. Scrum vs. Kanban Scrum Kanban Board / Artifacts board, backlogs, burn-downs board only Ceremonies daily scrum, sprint planning, sprint review, sprint retrospective daily scrum, review/retrospective on set frequency and planning ongoing 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
  • 16. Scrum vs. Kanban Sprint Day 1 Mid-Sprint Sprint Last Day Any Day Kanban Scrum
  • 17. Diagnosing a Scrum team 3 Roles ● Team - Is the team 5-9 people? Is it cross-functional or specialized? ● ScrumMaster - Is there a real ScrumMaster or someone acting in the role? ● Product Owner - Who actually writes the stories? Is the Product Owner truly available? 4 Ceremonies ● Daily Scrum - Is it under 15 minutes? Does the entire team attend? ● Planning - Is it collaborative? Is it often the same tasks/estimates? ● Review - Do stories often carry over from sprint to sprint? ● Retrospective - Is it taking place every sprint? Is the team raising concerns with Scrum? A few artifacts ● Product Backlog - Is it mostly maintenance/operational work? ● Sprint Burndown - Are we burning story points or tasks? ● Task board - Has the board evolved passed the 4 typical Scrum columns?
  • 18. Scrum time-boxed challenges ● Time-boxes force stories to be smaller for the sole purpose of "fitting" into the sprint length ● Breaking down stories require unnatural breakpoints create difficulties for deployment and testing of the work ● Too small of stories are no longer valuable and are not potentially shippable product increment at the end of the sprint ● Increased dependencies between stories, which requires more coordination to plan the work ● Increased testing due to the need to test (and retest) many small incomplete stories that are difficult to test and require more scaffolding efforts
  • 19. Ideal environments for Kanban ● If Scrum is challenged by workflow issues, resources and processes ● Event driven work ○ help-desk/support ○ hardening/packaging phases ● Projects with frequent and unexpected user stories or programming errors ● Maintenance projects or sunsetting products ● Around Scrum teams focused on new product development ○ work preceding sprint development (R&D, procurement) ○ work following sprint development (system testing, release and deployment) ● Facilitating improvement communities across the organization
  • 20. Backlog Kanban JIT Backlog ● extend board to include story creation/elaboration ● avoid creating/analyzing too many stories and having duplicates, 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 2 5 2 Elaboration Development Testing Deploy 1 Done 8
  • 21. Queue Estimating (or not) in Kanban ● No need to estimate at the card level, each card is "similar size" ● Cards don't need to get broken down to tasks with estimates, the work is known by the team and they will swarm to figure it out ● Simply calculate the average Cycle Time for cards to get through the board ○ Done Date - Start Date = Cycle Time 2 4 2 Elaboration Development Testing Deploy 1 Done 12 days 24 days
  • 22. Agile Release Planning week 1 week 2 week 8week 7week 6week 5week 4week 3 Kanban team releasing every 2 weeks like Scrum sprint 1 sprint 3sprint 2 sprint 4 Scrum team releasing every sprint Kanban team releasing every week Kanban team release when ready/needed planning review & decision to release retrospective
  • 23. Blending Scrum and Kanban
  • 24. Scrum+Kanban Scrum KanbanScrumScrum Q1 Q2 Q3 Q4 Yearly Release (or very long ones) Some organization choose to release only once a year. Although not ideal in Agile because it removes the advantages of going to market as soon as something is ready, this scenario requires that you get it right the first time / the only time you release that year! When new features are planned at the beginning of the year, the team(s) will benefit from working in a structured environment with time boxes and discipline with regular ceremonies (Scrum). The challenge will be at the end when other groups join the effort to prepare the release of this work. The coordination and possible issues that arise will benefit from switching all efforts to hardening the release (no new development) and following a clear process (Kanban). Scrum Kanban
  • 25. Scrum+Kanban SOA Environments In Service Oriented Architecture (SOA) environments, building/maintaining services is a specialty and requires a certain type of developer. Since there are rarely enough SOA developers to be on every development team/project and there is a need to centralize work on services, the SOA development is a specialized process that received demands from multiple teams/areas. The key is to funnel all requests. The visual nature of Kanban is ideal for SOA because it forces to respect their WIP limits and all the work across the various areas is clearly visible to organize and prioritize. Also SOA requires experts and that is the huge difference between Scrum (cross-functional) and Kanban (specialized). Scrum Kanban Team 2Team 1 Team 3 SOA Team service A service B service C service D service E service F
  • 26. Scrum+Kanban Applications vs. Infrastructure Scrum and Kanban are both Agile methodologies. The key is that they share the same values and principles, and therefore the basis to improve behaviors to reach common organizational goals. Scrum tends to take the organization by storm in the spirit of increasing efficiencies, but if the IT groups are not also Agile, Scrum hits a wall. Scrum teams have roles/ceremonies that align the business and development sides, but once this is achieved there is another technical component (IT), which cannot be left at the end. The goal is to find common grounds to streamline the work across the organization. IT doesn't have the need/luxury of the Scrum roles, they need clear Agile processes (Kanban). Team 2 Team 3 Team 5 Network Team Scrum Kanban DBA Team ReleaseT eam Support Team Security Team Team 1 Team 4
  • 27. Kanban Board Example
  • 28. Kanban for Portfolio Management Queue In Process Release Done Concept Scope Development Testing Project Team #1 Project Team #2 Project Team #3 6 5 2
  • 29. Kanban for Architecture Queue In Process Release Done ModelingAnalysis Development Testing Service #1 Service #2 Service #3 6 5 2
  • 30. Backlog In Process Done Production Release Dev Support Project A Project B Analysis Specify Execute Kanban for IT 8 3 6
  • 31. Kanban for Support with multiple clients Backlog In Process DoneSpecify Publish Estimate C1 C4C3 C2 Design Code Test Package New Analysis Development Done Production Issues 3 2 3 42
  • 32. Kanban for Marketing Priorities In Design Done3rd PartyIdeas Release Web Event COM PR ValidateReviewSpecify Execute 2438
  • 33. Kanban for Sales Queue Create RFP Review Done RFP Ready In Progress Complete Sales Team #1 Sales Team #2 Sales Team #3 26 5
  • 34. Agile Coaching, Training and Staffing. Learn more at www.torak.com
  • 35. Thank You
  • 36. 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/
  • 37. This presentation was inspired by the work of many people and we have done our very best to attribute all authors of texts and images, and recognize any copyrights. If you think that anything in this presentation should be changed, added or removed, please contact us. http://creativecommons.org/licenses/by-nc-nd/3.0/