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.
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
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
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
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
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
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
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
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/
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
Notas do Editor
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