Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

From Scrum to ScrumBan or Kanban- Process Evaluator Workshop using Excel.pptx

•Download as PPTX, PDF•
•
Ravi Tadwalkar
Ravi Tadwalkar

This document provides context and information for a workshop on evaluating process frameworks like Scrum, Scrumban, and Kanban using a questionnaire in Excel. The workshop aims to help a struggling team determine what process could work best for them by discussing a series of questions. The document includes an example questionnaire comparing Scrum, Scrumban and Kanban on factors like planning, decomposition, estimation, responsiveness, and culture fit. It also summarizes key differences between the frameworks in areas like planning, timeboxing, and metrics.

1 of 15
From Scrum to Scrumban/Kanban: Process Evaluator Workshop using Excel Ravi Tadwalkar Lean/Agile/DevOps Coach Co-founder, “Cisco Internal Coaches Network” (2011-13) Event Co-organizer, KIN20xx conferences (2017-current) This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Context for the workshop: Process Evaluator Workshop using Excel • Assume that we are a team struggling to do iterative development with Scrum, but the needle is not really moving, customers are not happy, and everything is just like before Scrum, or even worse at times. • How do we come out of this status quo situation and move the needle? • Let's talk about what can work for our team. • We will go thru' series of questions in a spreadsheet format to understand how to evaluate what process framework can work for our team. • Create 2-3 teams among the audience to compare and contrast process outcome, perhaps group by company/industry, and I will fire up Excel spreadsheet to go thru’ each “team”. – We will use common sense (not culture models) when forming and storming during this workshop 
Process Framework Evaluator – An Example Questionnaire Questions Explanation Planning: Despite the PO trying to do so, is it impossible to lock down the scope for your chosen timebox? Do you have more than 25% scope churn during the chosen timebox? Scrum: Scrum works best when requirements are stable for the duration of the Sprint so that the team can commit to their delivery. Kanban: Some scope change can be accommodated. By dropping the fixed timebox, Kanban can allow teams to adapt more easily to quickly changing priorities. Scrumban: Iteration planning is done at a regular interval, with the goal of planning is to fill the slots available - not fill all of the slots, and certainly not to determine the number of slots. Decomposition: Even after trying your best, is it impossible to break features into incremental pieces of value to be delivered within the chosen timebox? Both Scrum and Kanban work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can help new teams recognize deficiencies (work not completed at the end of the sprint) and adapt (retrospective). Scrumban: Can you decompose work to lock scope for the timboxed duration? Estimation: Is it hard or impossible for the team to size the work in the chosen timebox? Does estimation take more than 3 hours? Kanban: Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items. Work should be comprised of similarly sized activities for Kanban. Scrum: Scrum absolutely requires that all work be estimated so that the team can commit to the sprint. Scrumban: Scrumban does not require estimation. Responsiveness: Is your top priority to optimize responsiveness to customer needs? Must work begin in the current timebox (cannot wait until the next one)? Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity. Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the potential cost of productivity. Predictability & Productivity: Is your top priority predictability and productivity for larger projects? You can achieve predictability and a high level of productivity using any agile framework. Scrum provides more guidance on how to handle release planning and progress tracking so is preferable for new teams. Process Oriented Culture: Does your team culture demand a higher degree of process ceremonies? Although Scrum has fewer ceremonies and artifacts than many other methodologies, it has more than Kanban and can more easily be integrated into a culture requiring them. Shared Team Members: Do you share engineers with other teams? Does your team lack all the required skills to complete the work? Scrum: Scrum teams work best when they do not have dependencies on people outside of the team . Kanban: With Kanban, others can see when there is work for them to do and pick it up at that time. Variety in work (complexity & size): Are your work items of approximately similar size & complexity? Both Scrum and Kanban work very well with similar sized work items. However, in Kanban the variability between different sized items makes it difficult to adhere to SLAs.
Compare & Contrast Scrum, Scrumban & Kanban: Do Planning to fill available (not all) slots Card Template • Scrumban/Kanban process is about moving cards as fast as you can across the value stream to have shortest lead time. This requires slightly different way to look at requirements than following Scrum-style user story templates. – While it does help when you use a user story template with tasks associated for teams that prefer that kind of card on their board, it can very well be at a granular task level if all other cards on the board are of similar sizes, more like activities rather than stories. Unlike Scrum framework, in Kanban (and Scrumban), there is no need to take a particular stance on this. – Stories hover around typical size for Kanban/Scrumban teams (e.g., 3,5,8 if average size is a 5-point story). • Kanban manifesto could very well begin with this one liner: We prefer having typical sizes over following user story template! • Kanban does not put emphasis on estimation of work, as long as all work items have similar levels of effort, complexity & risk. – Decomposition- using patterns for splitting (i.e., slicing) work- remains same; Scrumban adds timeboxing on top of Kanban board. Planning mechanism • This is another area where contrasting Scrumban with scrum and Kanban makes a lot of sense, based on Corey Ladas's blog about Scrumban. In Scrumban (& Kanban), planning is done to fill the available (not all) slots: just in time & slack. Timeboxing • Scrumban does not distinguish between sprints/releases. It’s better to call it "timebox". – That way team will know that in Scrumban, burndown is less important than Lead Time and Cycle Time. Here are quotes from the Scrumban creator Corey Ladas whose blog exemplifies this. Please refer to slides in appendix for 3 excerpts from his blog post.
From Scrum to Scrumban/Kanban: Practitioner’s Way to improve Flow Efficiency A team improves its average lead time and flow efficiency by applying explicit policies, WIP limits for queues/swim-lanes, at regular cadence! Mature Kanban teams calculate lead time when accepting cards flowing on the physical/virtual card wall, with Scrumban-style regular cadence. After participating in release planning, such Kanban teams commit to iterative development/support on a cadence to finish work in 1-2 weeks. Sautéing with Jira Kanban board - perhaps using a physical card wall with it! That’s one way to acclimatize with transition to Scrumban/Kanban! Scrumban Level 1 - Scrum but no commitment to the content - Team gets most value out of daily standups, retrospectives, grooming and to a lesser degree planning (at least some planned work is done) - Aim to empty the queue in each timebox - Don't split stories Scrumban Level 2 - Essentially Kanban but timeboxed - It forces stories to be broken down so work is completed (versus open ended Epics) - Aim to empty the queue in each timebox - Don't split stories
Appendix
It all began with what the west calls “Lean”
And who started the “Lean” moment?
Kanban for knowledge work • David J Anderson created “K”anban, now known as Kanban Method. Kanban for knowledge work is a management method of just-in-time delivery based on capacity to do work. As such, here the focus is not to overload the team members. • In Kanban, the process workflow, from definition of work to its delivery to the customer, is displayed for participants to see and team members pull work from each queue. • Kanban for software development means a visual process management system that tells what to produce, when to produce it, and how much to produce- inspired by the Toyota Production System and Lean Manufacturing. Source: : David J Anderson (2010)
Done F E I Engineering Ready Deployment Ready G D GY PB MN 2 ∞ P1 AB Ongoing Development Testing Done Verification Acceptance 3 3 DE Proto-Kanban You may have used or seen a Kanban board for running events like conference or even hackathon. Whenever a team starts visualizing work with a Kanban board, that team is doing proto-Kanban! Explicit policies & WIP Limits based on queues (aka lanes or columns) Lead time ends at 1st infinite queue! There could be additional queues with no WIP limit. Lead time “clock” starts at the 1st queue aka input queue!
Done F E I Engineering Ready Deployment Ready G D GY PB MN 2 ∞ P1 AB Ongoing Development Testing Done Verification Acceptance 3 3 Expedite 1 3 Fixed Date Standard Intangible 2 2 DE Lead time ends at 1st infinite queue! Lead time “clock” starts at input queue! NPD i.e. New Prod Dev (60%) Defect& Tech Debt (30%) Innov ation (10%) Getting Beyond Proto-Kanban Getting beyond visual board: Hedge risk by allocating capacity, by defining WIP limits to shape demand (total WIP) for queues/swimlanes. Explicit policies & WIP Limits based on classes of service & work type! 5 2 1 In my Kanban coaching experience, Kanban "flow & pull" aspect orientation forces you to "stop starting, start finishing", better than scrum "inspect & adapt" orientation. Kanban being workflow management tool, requires solid engineering practices for teams to succeed in lean software development. However, it's non- prescriptiveness can let newbies fall back on practices & controls that worked in waterfall world. For those, I have always found Scrumban to be a practical middle-ground since it brings best from both scrum and Kanban.
Burndown is less important than Lead Time and Cycle Time "With the pull system in place, our flow will become smoother as our process capability improves. We can use our inter-process buffers and flow diagrams to show us our process weaknesses and opportunities for kaizen. As we get closer to level production, we will start to become less concerned with burndown and more concerned with cycle time, as one is the effect and the other is the cause. Average lead time and cycle time will become the primary focus of performance. If cycle time is under control and the team capacity is balanced against demand, then lead time will also be under control. If cycle time is under control, then burndowns are predictable and uninteresting. If burndowns are uninteresting, then goal-setting and risky heroic efforts are unnecessary. If burndowns are uninteresting, then iteration backlogs are just inventory for the purpose of planning regularity and feeding the pull system. As such, they should be the smallest inventories possible that optimize planning cost."
Sprint backlog- Smallest Inventory to Optimize Planning Cost "A simple mechanism that fits the bill is a size limit for the iteration backlog. Rather than go through the trouble of estimating a scope of work for every iteration, just make the backlog a fixed size that will occasionally run to zero before the planning interval ends. That’s a simple calculation. It’s just the average number of things released per iteration, which in turn is just a multiple of average cycle time. So if you have 5 things in process, on average, and it takes 5 days to complete something, on average, then you’ll finish 1 thing per day, on average. If your iteration interval is two work weeks, or 10 work days, then the iteration backlog should be 10. You can add one or two for padding if you worry about running out. This might be a point that’s been lost on the Scrum community: it’s never necessary to estimate the particular sizes of things in the backlog. It’s only necessary to estimate the average size of things in the backlog. Most of the effort spent estimating in Scrum is waste."
Why estimate the average size of things in the backlog? "In our final incarnation of Scrumban, iteration planning still happens at a regular interval, synchronized with review and retrospective, but the goal of planning is to fill the slots available, not fill all of the slots, and certainly not determine the number of slots. This greatly reduces the overhead and ceremony of iteration planning. Time spent batch processing for iteration planning estimation can be replaced with a quality control inspection at the time that work is promoted to the ready queue. If a work item is ill-formed, then it gets bounced and repeat offenders get a root cause analysis."
References & External Links There is more continuous improvement happening in Lean Kanban community with contributors like Arne Roock (known for “Stop Starting Start Finishing!”), Russell Healy (getKanban.com game creator), Christophe Achouizntz (known for Kanban team assessment survey) or Hakan Forss (creator of flow efficiency metric as the primary Kanban metric). References • Pre-requisite #1: “STOP Starting, START finishing” by Arne Roock • Pre-requisite #2: Anderson, David (April 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press. • Pre-requisite #3: Anderson, David (April 2012). Lessons in Agile Management- On the road to Kanban. Blue Hole Press. • Pre-requisite #4: Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas • External links – David Anderson’s blog posts & Henrik Kniberg’s blog posts – InfoQ eBooks by Henrik Kniberg & others [e.g. Jasper Boeg (2012-02). "Priming Kanban" (in English). InfoQ] – The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban – Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas – What is Kanban? by Joseph Hurtado – Aspects of Kanban by Karl Scotland – De-mystifying Kanban by Al Shalloway of Net Objectives – Kanban Applied to Software Development: from Agile to Lean – What is Best, Scrum or Kanban? – Kanban for Teams by Al Shalloway – Open Kanban Presentation – Open Kanban Documentation – LKNA conferences & related links • https://plus.google.com/113439681622341364754/videos • http://leanKanban.com/case-studies • http://blackswanfarming.com/cost-of-delay/

More Related Content

From Scrum to ScrumBan or Kanban- Process Evaluator Workshop using Excel.pptx

  • 1. From Scrum to Scrumban/Kanban: Process Evaluator Workshop using Excel Ravi Tadwalkar Lean/Agile/DevOps Coach Co-founder, “Cisco Internal Coaches Network” (2011-13) Event Co-organizer, KIN20xx conferences (2017-current) This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
  • 2. Context for the workshop: Process Evaluator Workshop using Excel • Assume that we are a team struggling to do iterative development with Scrum, but the needle is not really moving, customers are not happy, and everything is just like before Scrum, or even worse at times. • How do we come out of this status quo situation and move the needle? • Let's talk about what can work for our team. • We will go thru' series of questions in a spreadsheet format to understand how to evaluate what process framework can work for our team. • Create 2-3 teams among the audience to compare and contrast process outcome, perhaps group by company/industry, and I will fire up Excel spreadsheet to go thru’ each “team”. – We will use common sense (not culture models) when forming and storming during this workshop 
  • 3. Process Framework Evaluator – An Example Questionnaire Questions Explanation Planning: Despite the PO trying to do so, is it impossible to lock down the scope for your chosen timebox? Do you have more than 25% scope churn during the chosen timebox? Scrum: Scrum works best when requirements are stable for the duration of the Sprint so that the team can commit to their delivery. Kanban: Some scope change can be accommodated. By dropping the fixed timebox, Kanban can allow teams to adapt more easily to quickly changing priorities. Scrumban: Iteration planning is done at a regular interval, with the goal of planning is to fill the slots available - not fill all of the slots, and certainly not to determine the number of slots. Decomposition: Even after trying your best, is it impossible to break features into incremental pieces of value to be delivered within the chosen timebox? Both Scrum and Kanban work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can help new teams recognize deficiencies (work not completed at the end of the sprint) and adapt (retrospective). Scrumban: Can you decompose work to lock scope for the timboxed duration? Estimation: Is it hard or impossible for the team to size the work in the chosen timebox? Does estimation take more than 3 hours? Kanban: Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items. Work should be comprised of similarly sized activities for Kanban. Scrum: Scrum absolutely requires that all work be estimated so that the team can commit to the sprint. Scrumban: Scrumban does not require estimation. Responsiveness: Is your top priority to optimize responsiveness to customer needs? Must work begin in the current timebox (cannot wait until the next one)? Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity. Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the potential cost of productivity. Predictability & Productivity: Is your top priority predictability and productivity for larger projects? You can achieve predictability and a high level of productivity using any agile framework. Scrum provides more guidance on how to handle release planning and progress tracking so is preferable for new teams. Process Oriented Culture: Does your team culture demand a higher degree of process ceremonies? Although Scrum has fewer ceremonies and artifacts than many other methodologies, it has more than Kanban and can more easily be integrated into a culture requiring them. Shared Team Members: Do you share engineers with other teams? Does your team lack all the required skills to complete the work? Scrum: Scrum teams work best when they do not have dependencies on people outside of the team . Kanban: With Kanban, others can see when there is work for them to do and pick it up at that time. Variety in work (complexity & size): Are your work items of approximately similar size & complexity? Both Scrum and Kanban work very well with similar sized work items. However, in Kanban the variability between different sized items makes it difficult to adhere to SLAs.
  • 4. Compare & Contrast Scrum, Scrumban & Kanban: Do Planning to fill available (not all) slots Card Template • Scrumban/Kanban process is about moving cards as fast as you can across the value stream to have shortest lead time. This requires slightly different way to look at requirements than following Scrum-style user story templates. – While it does help when you use a user story template with tasks associated for teams that prefer that kind of card on their board, it can very well be at a granular task level if all other cards on the board are of similar sizes, more like activities rather than stories. Unlike Scrum framework, in Kanban (and Scrumban), there is no need to take a particular stance on this. – Stories hover around typical size for Kanban/Scrumban teams (e.g., 3,5,8 if average size is a 5-point story). • Kanban manifesto could very well begin with this one liner: We prefer having typical sizes over following user story template! • Kanban does not put emphasis on estimation of work, as long as all work items have similar levels of effort, complexity & risk. – Decomposition- using patterns for splitting (i.e., slicing) work- remains same; Scrumban adds timeboxing on top of Kanban board. Planning mechanism • This is another area where contrasting Scrumban with scrum and Kanban makes a lot of sense, based on Corey Ladas's blog about Scrumban. In Scrumban (& Kanban), planning is done to fill the available (not all) slots: just in time & slack. Timeboxing • Scrumban does not distinguish between sprints/releases. It’s better to call it "timebox". – That way team will know that in Scrumban, burndown is less important than Lead Time and Cycle Time. Here are quotes from the Scrumban creator Corey Ladas whose blog exemplifies this. Please refer to slides in appendix for 3 excerpts from his blog post.
  • 5. From Scrum to Scrumban/Kanban: Practitioner’s Way to improve Flow Efficiency A team improves its average lead time and flow efficiency by applying explicit policies, WIP limits for queues/swim-lanes, at regular cadence! Mature Kanban teams calculate lead time when accepting cards flowing on the physical/virtual card wall, with Scrumban-style regular cadence. After participating in release planning, such Kanban teams commit to iterative development/support on a cadence to finish work in 1-2 weeks. Sautéing with Jira Kanban board - perhaps using a physical card wall with it! That’s one way to acclimatize with transition to Scrumban/Kanban! Scrumban Level 1 - Scrum but no commitment to the content - Team gets most value out of daily standups, retrospectives, grooming and to a lesser degree planning (at least some planned work is done) - Aim to empty the queue in each timebox - Don't split stories Scrumban Level 2 - Essentially Kanban but timeboxed - It forces stories to be broken down so work is completed (versus open ended Epics) - Aim to empty the queue in each timebox - Don't split stories
  • 7. It all began with what the west calls “Lean”
  • 8. And who started the “Lean” moment?
  • 9. Kanban for knowledge work • David J Anderson created “K”anban, now known as Kanban Method. Kanban for knowledge work is a management method of just-in-time delivery based on capacity to do work. As such, here the focus is not to overload the team members. • In Kanban, the process workflow, from definition of work to its delivery to the customer, is displayed for participants to see and team members pull work from each queue. • Kanban for software development means a visual process management system that tells what to produce, when to produce it, and how much to produce- inspired by the Toyota Production System and Lean Manufacturing. Source: : David J Anderson (2010)
  • 10. Done F E I Engineering Ready Deployment Ready G D GY PB MN 2 ∞ P1 AB Ongoing Development Testing Done Verification Acceptance 3 3 DE Proto-Kanban You may have used or seen a Kanban board for running events like conference or even hackathon. Whenever a team starts visualizing work with a Kanban board, that team is doing proto-Kanban! Explicit policies & WIP Limits based on queues (aka lanes or columns) Lead time ends at 1st infinite queue! There could be additional queues with no WIP limit. Lead time “clock” starts at the 1st queue aka input queue!
  • 11. Done F E I Engineering Ready Deployment Ready G D GY PB MN 2 ∞ P1 AB Ongoing Development Testing Done Verification Acceptance 3 3 Expedite 1 3 Fixed Date Standard Intangible 2 2 DE Lead time ends at 1st infinite queue! Lead time “clock” starts at input queue! NPD i.e. New Prod Dev (60%) Defect& Tech Debt (30%) Innov ation (10%) Getting Beyond Proto-Kanban Getting beyond visual board: Hedge risk by allocating capacity, by defining WIP limits to shape demand (total WIP) for queues/swimlanes. Explicit policies & WIP Limits based on classes of service & work type! 5 2 1 In my Kanban coaching experience, Kanban "flow & pull" aspect orientation forces you to "stop starting, start finishing", better than scrum "inspect & adapt" orientation. Kanban being workflow management tool, requires solid engineering practices for teams to succeed in lean software development. However, it's non- prescriptiveness can let newbies fall back on practices & controls that worked in waterfall world. For those, I have always found Scrumban to be a practical middle-ground since it brings best from both scrum and Kanban.
  • 12. Burndown is less important than Lead Time and Cycle Time "With the pull system in place, our flow will become smoother as our process capability improves. We can use our inter-process buffers and flow diagrams to show us our process weaknesses and opportunities for kaizen. As we get closer to level production, we will start to become less concerned with burndown and more concerned with cycle time, as one is the effect and the other is the cause. Average lead time and cycle time will become the primary focus of performance. If cycle time is under control and the team capacity is balanced against demand, then lead time will also be under control. If cycle time is under control, then burndowns are predictable and uninteresting. If burndowns are uninteresting, then goal-setting and risky heroic efforts are unnecessary. If burndowns are uninteresting, then iteration backlogs are just inventory for the purpose of planning regularity and feeding the pull system. As such, they should be the smallest inventories possible that optimize planning cost."
  • 13. Sprint backlog- Smallest Inventory to Optimize Planning Cost "A simple mechanism that fits the bill is a size limit for the iteration backlog. Rather than go through the trouble of estimating a scope of work for every iteration, just make the backlog a fixed size that will occasionally run to zero before the planning interval ends. That’s a simple calculation. It’s just the average number of things released per iteration, which in turn is just a multiple of average cycle time. So if you have 5 things in process, on average, and it takes 5 days to complete something, on average, then you’ll finish 1 thing per day, on average. If your iteration interval is two work weeks, or 10 work days, then the iteration backlog should be 10. You can add one or two for padding if you worry about running out. This might be a point that’s been lost on the Scrum community: it’s never necessary to estimate the particular sizes of things in the backlog. It’s only necessary to estimate the average size of things in the backlog. Most of the effort spent estimating in Scrum is waste."
  • 14. Why estimate the average size of things in the backlog? "In our final incarnation of Scrumban, iteration planning still happens at a regular interval, synchronized with review and retrospective, but the goal of planning is to fill the slots available, not fill all of the slots, and certainly not determine the number of slots. This greatly reduces the overhead and ceremony of iteration planning. Time spent batch processing for iteration planning estimation can be replaced with a quality control inspection at the time that work is promoted to the ready queue. If a work item is ill-formed, then it gets bounced and repeat offenders get a root cause analysis."
  • 15. References & External Links There is more continuous improvement happening in Lean Kanban community with contributors like Arne Roock (known for “Stop Starting Start Finishing!”), Russell Healy (getKanban.com game creator), Christophe Achouizntz (known for Kanban team assessment survey) or Hakan Forss (creator of flow efficiency metric as the primary Kanban metric). References • Pre-requisite #1: “STOP Starting, START finishing” by Arne Roock • Pre-requisite #2: Anderson, David (April 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press. • Pre-requisite #3: Anderson, David (April 2012). Lessons in Agile Management- On the road to Kanban. Blue Hole Press. • Pre-requisite #4: Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas • External links – David Anderson’s blog posts & Henrik Kniberg’s blog posts – InfoQ eBooks by Henrik Kniberg & others [e.g. Jasper Boeg (2012-02). "Priming Kanban" (in English). InfoQ] – The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban – Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas – What is Kanban? by Joseph Hurtado – Aspects of Kanban by Karl Scotland – De-mystifying Kanban by Al Shalloway of Net Objectives – Kanban Applied to Software Development: from Agile to Lean – What is Best, Scrum or Kanban? – Kanban for Teams by Al Shalloway – Open Kanban Presentation – Open Kanban Documentation – LKNA conferences & related links • https://plus.google.com/113439681622341364754/videos • http://leanKanban.com/case-studies • http://blackswanfarming.com/cost-of-delay/

Editor's Notes

  1. A Wine (or tea) tasting session based on Ravi Tadwalkar’s training during KCP (Kanban Coaching Professional) Masterclass for Kanban practitioners taught by LKU (David Anderson), during 2014, Apr 28 – May 2; and LKNA 2014, during 2014, May 5-8- both events held at SFO. New to Kanban? The name ‘Kanban' originates from Japanese[かんばん] (Chinese: 看板), and translates roughly as "signboard" or "billboard". In both Japanese and Chinese, the syllable “kan” is used a verb and it means “to see”; and “ban” means “billboard”. While we are starting this workshop, glance thru’ a tiny booklet titled “STOP Starting, START finishing” by Arne Roock. I usually distribute ~10 copies that I use for this kind of event. We can play getKanban game at a later time when possible. In my Kanban coaching experience, Kanban "flow & pull" aspect orientation forces you to "stop starting, start finishing", better than scrum "inspect & adapt" orientation. Kanban being workflow management tool, requires solid engineering practices for teams to succeed in lean software development. However, it's non-prescriptiveness can let newbies fall back on practices & controls that worked in waterfall world. For those, I have always found Scrumban to be a practical middle-ground since it brings best from both scrum and Kanban. In this session, we will discuss 5 important topics related to Kanban and Scrumban, comparing & contrasting with scrum, as and when needed.
  2. References: https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf (Chapter 6) http://leansoftwareengineering.com/ksse/scrum-ban/ http://www.eylean.com/blog/2013/04/scrum-vs-Kanban-vs-Scrumban-iterations-work-routines-and-scope-limits/ http://www.netobjectives.com/blogs/why-contrasting-Scrumban-and-Kanban-belies-lack-understanding-both http://www.ontheagilepath.net/2013/09/scrum-Kanban-Scrumban-fast-overview-and.html Kanban Applied to Software Development: from Agile to Lean What is Best, Scrum or Kanban?
  3. The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard". The term Scrumban was introduced by Corey Ladas in his original blog: http://leansoftwareengineering.com/ksse/scrum-ban/ Scrumban Level 1 - Scrum but no commitment to the content - Teams get most value out of daily standups, retrospectives, grooming and to a lesser degree planning (at least some planned work is done) - Aim to empty the queue in each timebox - Don't split stories   Scrumban Level 2 - Essentially Kanban but timeboxed - It forces stories to be broken down so work is completed (versus open ended Epics) - Aim to empty the queue in each timebox - Don't split stories
  4. Proto-Kanban is a term used for teams new to Kanban, and is not meant to be derogatory term such as scrumbut. It’s their first step on a lean journey! In my Kanban coaching experience, Kanban "flow & pull" aspect orientation forces you to "stop starting, start finishing", better than scrum "inspect & adapt" orientation. Kanban being workflow management tool, requires solid engineering practices for teams to succeed in lean software development. However, it's non-prescriptiveness can let newbies fall back on practices & controls that worked in waterfall world. For those, I have always found Scrumban to be a practical middle-ground since it brings best from both scrum and Kanban. In this session, we will discuss 5 important topics related to Kanban and Scrumban, comparing & contrasting with scrum, as and when needed.
  5. New to Kanban? The term ‘Kanban' originates from Japanese[かんばん] (Chinese: 看板), and translates roughly as "signboard" or "billboard". In both Japanese and Chinese, the syllable “kan” is used a verb and it means “to see”; and “ban” means “billboard”. While we are starting this workshop, glance thru’ a tiny booklet titled “STOP Starting, START finishing” by Arne Roock. I usually distribute ~10 copies that I use for this kind of event. We can play getKanban game at a later time when possible. We will focus on these 5 topics for discussion: Comparing “Toyota Kanban” with “software Kanban” Scrum vs. Scrumban vs. Kanban Feedback Loops in Kanban Kanban Metrics Kanban Depth Framework
  6. Source: Ohno, Taiichi (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. p. 176. ISBN 9780915299140. I would relate to lean manufacturing literature (including TQM & six sigma related information) only for comparisons. What works for TPS does not work for knowledge work. As such, I would stop there to avoid any confusion around terminology and maintain my focus on “Kanban for knowledge work”. I refer you to read the blue book by David J. Anderson, creator of “Kanban for knowledge work”, instead of lookup on Wikipedia or any other literature that is not considered the gold standard for knowledge work related Kanban framework and David Anderson’s Kanban Method.
  7. From Wikipedia, the free encyclopedia: http://en.wikipedia.org/wiki/Kanban_%28development%29
  8. Proto-Kanban is a term used for teams new to Kanban, and is not meant to be derogatory term such as scrumbut.
  9. Expedite swimlane: You can use this swimlane to visualize a single work item that is allowed to violate work in progress (WIP) limits. Intangible swimlane: You can use this swimlane for intangible work such as architectural refactor. Cards in this swimlane are similar EPICs that bubble up (i.e. become tangible) from stack of product backlog items in scrum. Already doing Kanban? Read the blue book (David Anderson’s Kanban book), page 70, figure 6.5 for an example of Kanban board with work type based swim lanes indicating capacity allocation. In my Kanban coaching experience, Kanban "flow & pull" aspect orientation forces you to "stop starting, start finishing", better than scrum "inspect & adapt" orientation. Kanban being workflow management tool, requires solid engineering practices for teams to succeed in lean software development. However, it's non-prescriptiveness can let newbies fall back on practices & controls that worked in waterfall world. For those, I have always found Scrumban to be a practical middle-ground since it brings best from both scrum and Kanban.
  10. The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard". The term Scrumban was introduced by Corey Ladas in his original blog: http://leansoftwareengineering.com/ksse/scrum-ban/
  11. The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard". The term Scrumban was introduced by Corey Ladas in his original blog: http://leansoftwareengineering.com/ksse/scrum-ban/
  12. The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard". The term Scrumban was introduced by Corey Ladas in his original blog: http://leansoftwareengineering.com/ksse/scrum-ban/
  13. In summaryKanban is a catalyst for change through small, incremental improvements to your existing process – be it scrum or otherwise. Rooted in lean manufacturing, Kanban is a signaling system that can be effectively applied to software development, DevOps, IT operations, and many other processes.