Scaling kanban
•
13 likes•2,525 views
This is a draft for my upcoming talk at GOTO11 - http://gotocon.com/cph-2011/presentations/show_presentation.jsp?oid=2888 Kanban is a powerful and flexible system. One of the popular emerging ways of using it, is to create and manage product development flow. Whether for a single project, a program, or a portfolio, we will explore the need for product development flow, see how kanban fulfills this need in a couple of examples from real clients, and discuss the next frontiers for program management flow. One of the key topics will be the balance between flow and commitment. We will explore how a kanban system can satisfy the need for making and meeting commitments at various levels, exploiting emerging valuable opportunities AND enjoying the benefits of flow/pull.
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Scaling kanban
Similar to Scaling kanban (20)
More from Yuval Yeret
More from Yuval Yeret (20)
Recently uploaded
Recently uploaded (20)
Scaling kanban
- 1. @yuvalyeret
- 2. @yuvalyeret
- 3. @yuvalyeret
- 4. Geoffrey Moore’s - Crossing the Chasm @yuvalyeret
- 5. We Are HERE Geoffrey Moore’s - Crossing the Chasm @yuvalyeret
- 6. Early Majority Pragmatic Enterprises Risk Allergic Expect Complex Averse To Whole Environments Dogma Solutions Lots of Legacy/Debt @yuvalyeret
- 7. So Lean/Agile approaches as of 2011 need to… Help Be Develop a Answer issues of manage context- complete Scale and Legacy Risk Specific picture Not be Without requiring huge Risks day 0 Overhauls themselves @yuvalyeret
- 8. Some enterprise challenges we encounter “Doing agile at the team level is fine. But how do we deal with the things we cannot get into the team?” @yuvalyeret
- 9. @yuvalyeret
- 10. Step #1: identify and work with @yuvalyeret minimally valuable features
- 11. http://www.freefoto.com/images/41/03/41_03_4---Weight-Limit-Sign_web.jpg?&k=Weight+Limit+Sign Limit the size of work - at all levels @yuvalyeret
- 12. Visibility – Monitor and control the size of work @yuvalyeret
- 13. Step #2: Visualize Flow @yuvalyeret
- 14. Tool: The Cumulative Flow Diagram @yuvalyeret
- 15. How to do a CFD TO DO TO IN PROGRESS IN PROGRESS IN PROGRESS DONE DONE DO Mushon Inbar Inbar Elad 1 8 11 Mushon Elad Inbar 1 8 Mushon Elad @yuvalyeret
- 16. How to do a CFD 120 100 80 60 40 20 0 1 2 3 4 5 6 7 8 9 10 @yuvalyeret
- 17. What can teams learn from Cumulative Flow? Total Scope Dev Burnup Work Done Burnup in Average Cycle Time Real Done Process Burnup (WIP) @yuvalyeret
- 19. @yuvalyeret
- 20. @yuvalyeret
- 21. 1 2 3 Program-level Aggregate CFD Visualize Overall Progress @yuvalyeret
- 22. Nice reports are not enough! @yuvalyeret
- 23. Can you tell what these represent? @yuvalyeret
- 24. Some “smells” we see out there Longer Sprints Sprint Agile Teams Synchronized Waterfall Release Handoffs @yuvalyeret
- 25. Product Level Comp A Comp B Comp C Backlog Impact on Components Features in A Features in B Features in C Integrative Features @yuvalyeret
- 26. Product Level Comp A Comp B Comp C Backlog Impact on Components Features in A Team A Features in B Team B Features in C Team C Integrative ?????????? Features @yuvalyeret
- 27. Learn about Feature Teams @yuvalyeret
- 28. Iterations between Feature Teams Flow between Component Teams Component Teams @yuvalyeret
- 30. Use a Program-level Feature @yuvalyeret Kanban Board
- 31. Product Line Z Swimming Lanes per Product @yuvalyeret
- 32. Features and Stories hierarchy @yuvalyeret
- 33. @yuvalyeret Amdocs Project/Component Kanban Board @yuvalyeret
- 35. Projects Portfolio for a large IT shop @yuvalyeret
- 36. @yuvalyeret
- 37. Learn more about Kanban @yuvalyeret
- 38. @yuvalyeret
- 39. @yuvalyeret
- 40. Portfolio/ Program Level Product Z Product X Product Y Backlog Impact on Products Features in Z Comp A Comp B Comp C Backlog Impact on Components Features in A Features in B Features in C Integrative Features Features in Y Comp A Comp B Comp C Backlog Impact on Components Features in A Features in B Features in C Integrative Features Comp A Comp B Comp C Features in X Backlog Impact on Components Features in A Features in B Features in C Integrative Features Cross- Product ?????? Features @yuvalyeret
- 41. “We don’t yet have the political power or resolve to create real Feature Teams end to end. So what do we do?” @yuvalyeret http://www.flickr.com/photos/9422878@N08/2444616004/in/photostream/
- 42. WIP / Cycle Time / Management Overhead – Less is Better… Product Component Product Component Product Feature Product Teams w/ Full Cross-Product Teams w/ Iteration Teams w/ Flow Teams w/ Iteration Flow Feature Team Handoffs between Handoffs between them them @yuvalyeret
- 43. Best – Cross-Product Feature Team / Task Force @yuvalyeret Let them organize around the work
- 44. Cross- Product Task Forces Product Feature Teams w/ Flow Limit Task Forces in Progress... @yuvalyeret
- 46. What does Versatility mean at Scale? Collective ownership Try... Reducing the number of different skill sets, and generalizing some specializations @yuvalyeret
- 47. @yuvalyeret
- 49. No dependencies – @yuvalyeret Expand/Collapse
- 51. What about Coordination at Scale? @yuvalyeret
- 52. Anyone using Scrum of Scrum? @yuvalyeret
- 53. Questions about Scrum of Scrum • Are we doing it because we have Scrum+Scale? What problem are we trying to solve? • Is Scrum of Scrum used for coordinating 100% of the work, or just the exceptions? @yuvalyeret
- 55. @yuvalyeret
- 56. How about Improving at Scale? • How many of you can name a process improvement they are trying this month? @yuvalyeret
- 57. Early Process Feedback and Adjustment • Lean/Kanban - Improvement happens as part of flow • Retrospectives/Kaizen Events are still important @yuvalyeret
- 59. Try… an Improvement Service @yuvalyeret
- 60. Pull Improvement Needs from Teams @yuvalyeret
- 61. Will visualizing and managing flow in each of those roads be enough? @yuvalyeret
- 62. Need to visualize and manage the global end to end flow across shared resources @yuvalyeret http://sherisays.files.wordpress.com/2010/08/drivers-stuck-in-traffic-jam-for-9-days-in-china.jpg
- 63. Sharing http://www.flickr.com/photos/kwl/4809326028/ http://www.flickr.com/photos/justin_case/54087334/in/photostream/ @yuvalyeret
- 64. @yuvalyeret
- 65. @yuvalyeret
- 66. Example Policy - Classes of Service for Downstream Involvement Risk Profiling Involvement mode of the shared resource @yuvalyeret @yuvalyeret
- 67. What about Due Dates and Commitment? Does Flow mean no What do you mean tell the commitment? customers to go Agile? Come on! Be REAL! @yuvalyeret #AgileIL11
- 68. REAL reason to for Due Dates? Use Fixed Date class of service @yuvalyeret @yuvalyeret http://yuvalyeret.com/2010/09/19/kanban-early-warning-using-a-predictive-variant-of-spc/
- 69. @yuvalyeret http://yuvalyeret.com/2010/09/19/kanban-early-warning-using-a-predictive-variant-of-spc/
- 70. @yuvalyeret
- 71. What does it mean to Manage WIP at Scale? Projects Cross-Product Projects/Features in Features/Task Forces certain high attention Class of Service Fixed Date / Cost / etc. Shared Resources @yuvalyeret
- 72. Scaling Kanban Guidance for real enterprises Pragmatic approach to change Early Feedback, Learning, Managed Delivery – At Scale @yuvalyeret
- 73. yuval@agilesparks.com Get the slides at http://www.slideshare.net/yyeret Blogging at http://yuvalyeret.com @yuvalyeret
Editor's Notes
- Kanban is a powerful and flexible system. One of the popular emerging ways of using it, is to create and manage product development flow. Whether for a single project, a program, or a portfolio, we will explore the need for product development flow, see how kanban fulfills this need in a couple of examples from real clients, and discuss the next frontiers for program management flow. One of the key topics will be the balance between flow and commitment. We will explore how a kanban system can satisfy the need for making and meeting commitments at various levels, exploiting emerging valuable opportunities AND enjoying the benefits of flow/pull.
- The need for FlowHow to introduce flow into an EnterpriseStart with CFDStealth KanbanCommitment vs Flow? Cont Stabilization RecipeCCPM Versus Kanban for really large programsElasticityExpand/Collapse/HierarchySOS KOK ? Shared Resources? Understanding WIP at scaleAmdocs Case StudyHP Case Study
- Risk-Averse – want evolutions rather than revolutionsCare about Solutions to their problems, not visions of grandeur or perfect systemsAllergic to acronyms, dogma, disrespect to what’s currently workingSelf Organization gives them the creeps. Have a complex situation - for team agile to work need drastic revolutions and investments. If applied half-heartedly team agile will be painful and mediocre in results.
- Evolutionary approachAvoid BCUF – Small changes, then Focused Continuous Improvement. Organizations that want to improve fast – can accelerate the Focused improvement, but still doesn’t mean everything is needed. Decoupling “Self Organization” from “Value-Driven Development”. Enable Decentralized execution without emphasizing it as much.
- The need for FlowHow to introduce flow into an EnterpriseStart with CFDStealth KanbanCommitment vs Flow? Cont Stabilization RecipeCCPM Versus Kanban for really large programsElasticityExpand/Collapse/HierarchySOS KOK ? Shared Resources? Understanding WIP at scaleAmdocs Case StudyHP Case Study
- SyncSpeed
- Explicit expectation – can be via uniform size, or via some level of estimations.
- Examples of limiting size of work at various levelsPBG SBT 500K$ ProjectsControl chart for the size of work over time.
- Introduced in Lean Product Development by Don Reinertsen and David AndersonVisualize where the Features/Stories are in the workflow across time
- What does it mean to manage flow? Managers take action to stop the line in case of high WIPIdentify bottlenecks and divert resources / focusManagement attention
- Show several CFDs from HPWhat can you do with aggregate? If aligned release, you have a picture of the release.
- Show several CFDs from HPWhat can you do with aggregate? If aligned release, you have a picture of the release.
- Talk especially about its helpfulness while starting, before having cycle times. Once cycle times are available, they are a much easier
- Assuming a group of 50 peopleEach story is about a week of workIf we currently have 50 stories in progress, its about 50 weeks of work in progress, which means we have work for a week of the group currently in progress. Not bad!If we had 20 features in progress, each about 20 weeks of work, with a group of 100 people, it is 400 weeks of work in progress/ 100 people, which means 4 weeks of upcoming work. OkIf we had 40 features in progress, each about 30 weeks of work, with a group of 100 people, it is 1200 weeks of work, 12 weeks upcoming for the group, which is 3 months. Now that is a lot. It means we take 3 months to turn around what’s currently in the WIP. Of course, cycle times can show you this data, but only later on!
- Enable Task forces that can win – clear purpose, allocation/fencing, ability to make local decisions.
- Expand/collapse without dependenciesExpand/collapse with serializationExpand/collapse into a complex dependency map
- Use when the feature is big, there is a long-running theme, and it is worthwhile setting up the “persistent” connection between the relevant working people.
- When dealing with a pipeline of features, each with relative low touch time in each product, but consistent value stream structure, use the pipeline. e.g. discovery and handling of new kinds of network elements in a NMS – add discovery agent, add to database, add to GUI, create business logic correlation rules, etc.
- Expand to the impact on each group, then manage it (either at this hierarchy or not...)Collapse back to the Cross-Product Feature when all done and ready to move to the next phase as a Feature
- As dependencies grow more and more complex, the need for “dependency networks grow”Remember that the gross majority of features will not be cross productOf those that are, most will not have really complex dependenciesThose that are, you can focus on, provide dependency maps and maybe even use “Critical Chain” like approaches. But limit their WIP...
- TODO – summarize the tools/tips until nowPut the tips on the screen
- TODO – emphasize the shared resources
- Red– performance team Must be involved hands onYellow– performance team Advise/Consult, but most work is in TeamsGreen– don’t need any involvement from performance teamDrives collective ownership of performance (and other “Ilities”) – And is another form of subordinationto the constraint
- Best approach for service delivery (80% of software development in the world is V>1.0)Pragmatic approach to changeEnd to end optimization
- Recipe for Continuous Stabilization How to deal with Elasticity in Testing (and in general...)How to deal with Shared Test LabsClasses of treatment