Downloaded 44 times
Uploaded byMike Burrows
LKCE12 mike burrows portfolio kanban
The document discusses the evolution of using Kanban practices at multiple levels of an organization. It describes three stories of using Kanban at the team, program, and portfolio levels over time. It emphasizes that truly applying Kanban requires agreement, alignment, models, and challenge at all levels of an organization.
More Related Content
Similar to LKCE12 mike burrows portfolio kanban
LKCE12 mike burrows portfolio kanban
- 1. Not “Portfolio Kanban” but“Kanban!” Mike Burrows (@asplake) mike@djaa.com http://positiveincline.com @asplake #lkce12
- 2. What do wemean by “Portfolio Kanban”? What does the term evoke for you? @asplake #lkce12
- 3. “One sticky perproject” “Working on the organisation at the level where the portfolio is (or should be) managed” @asplake #lkce12
- 4. Three stories and adirty secret @asplake #lkce12
- 5. Story 1, circa 2007 @asplake #lkce12
- 6. How our workwas organised Initiative Release Team Feature Task State @asplake #lkce12
- 7. Team level: push! Initiative Release Team Feature Task State @asplake #lkce12
- 8. Reporting by release& team Initiative Release Team Feature Task State @asplake #lkce12
- 9. Reporting by release& team Release n (Production) Team A Feature W Feature X (explanation) Feature Y (explanation) Team B Feature Z … … Release n+1 (Deployment) Release n+2 (Testing) Release n+3 (Development) @asplake Release n+4 (Planning) #lkce12
- 10. Reporting by release& team Release n n n-4 n-3 n-2 n-1 n n n n Deplo Done Plan Dev Test Implement Team y (Validated) A X Y W B Z C @asplake #lkce12
- 11. Initiative-centric conversation Initiative Release Team Feature Task State @asplake #lkce12
- 12. How deep wasour Kanban? 1. Visualise 6. Improve & 2. Limit WIP evolve 5. Feedback 3. Manage Loops Flow 4. Make Policies Explicit @asplake #lkce12
- 13. Story 2, somewhere soon, maybe @asplake #lkce12
- 14. Limited $WIP, Limited$CARRY @asplake #lkce12
- 15. Limited $WIP, Limited$CARRY @asplake #lkce12
- 16. Limited $WIP, Limited$CARRY @asplake #lkce12
- 17. Limited $WIP, Limited$CARRY @asplake #lkce12
- 18. Limited $WIP, Limited$CARRY @asplake #lkce12
- 19. How deep? 1. Visualise 6. Improve & 2. Limit WIP evolve 5. Feedback 3. Manage Loops Flow 4. Make Policies Explicit @asplake #lkce12
- 20. Story 3, “Portfolio Kanban” @asplake #lkce12
- 21. “Portfolio Kanban” Done Initiativ Plan Dev Test Deploy Implement (Validated) e X W I Z Y J K @asplake #lkce12
- 22. Huh? 1. Visualise 6. Improve & 2. Limit WIP evolve 5. Feedback 3. Manage Loops Flow 4. Make Policies Explicit @asplake #lkce12
- 23. What’s missing? 1. Visualise 6. Improve & 2. Limit WIP evolve 5. Feedback 3. Manage Loops Flow 4. Make Policies Explicit @asplake #lkce12
- 24. 1. Agreement “Agree to pursue incremental, evolutionary change” @asplake #lkce12 Foundational Principle #2
- 25. 2. Alignment “Evidence ofprocess or management policy evolution as a result of mentor-mentee relationship” @asplake #lkce12 How Deep is Your Kanban, Anderson 2012
- 26. 3. Models “Evidence that process evolution was model-driven” @asplake #lkce12 How Deep is Your Kanban, Anderson 2012
- 27. 4. Challenge “Encourage actsof leadership at all levels in your organization” @asplake #lkce12 Foundational Principle #4
- 28. Agreement, Alignment, Models,Challenge ? Alignment ? @asplake Collaboration #lkce12
- 29. Agreement, Alignment, Models,Challenge • What would you like to have happen? What’s the challenge? Goal • What will “done” look like? • Drivers? • What happens now? How do you interpret the available data? Reality • What is the impact? How you quantify that? • Root causes? • What could you do? What should you do? Options • How have similar things been achieved in the past? • Who might help? • What will you do? What comes first? Why? Way Forward • Who will be impacted? Other obstacles? • How does your plan address your root causes, meet its goals? @asplake #lkce12 after: Coaching for Performance, Whitmore 2010
- 30. Agreement, Alignment, Models,Challenge Managers, Higher Organisation, Corporate Systems Peers, Customers YOU Others Impacted Team @asplake #lkce12
- 31. Don’t despair 1. Visualise 6. Improve & 2. Limit WIP evolve 5. Feedback 3. Manage Loops Flow 4. Make Policies Explicit @asplake #lkce12
- 32. Story 1 +Kanban 1. Visualise 6. Improve & 2. Limit WIP evolve 5. Feedback 3. Manage Loops Flow 4. Make Policies Explicit @asplake #lkce12
- 33. Story 2 +Kanban 1. Visualise 6. Improve & 2. Limit WIP evolve 5. Feedback 3. Manage Loops Flow 4. Make Policies Explicit @asplake #lkce12
- 34. Better Together 1. Visualise 6. Improve & 2. Limit WIP evolve 5. Feedback 3. Manage Loops Flow 4. Make Policies Explicit @asplake #lkce12
- 35. What do wemean by “Portfolio Kanban”? What does the term evoke for you? @asplake #lkce12
Editor's Notes
- #3 Evokes a focus on the work, not on changing the organisation“One sticky per project” or “working on the organisation at the level where the portfolio is (or should be) managed”
- #4 There’s truth in both of courseDon’t want to get bogged down in definitions for these things right now, so I’ll cheat
- #5 Don’t want to get bogged down into giving a tighter definition, so I’ll cheat
- #6 Global dev manager, large distributed team. Mature process evolved over a number of years (getting on for a decade).Over the years evolve integrated tool support covering tracking, build, test automation and deploymentThe model behind the system looked something like this:
- #7 Multiple teams delivering through planned releases against multiple long-running initiativesWork organised into multiple features (quite chunky features)Broken down into tasks – could be subfeatures but for annoying tool-related reasons sometimes horizontal slices.[aside: More annoying: tasks like “write unit tests”, “do some refactoring”.And some of the features were just buckets of tasks that represented defects. Tasks referred to by “bug number”developers would say “good news – I’ve delivered a bug!]Tasks have state, and state transitions are constrained so that we have a workflow model.A few wrinkles, but ok so far
- #8 Far too much concern over prioritised but unstarted tasks. I as the anxious dev manager am as guilty as anyone in that regard!In Stephen Parry’s terms, this is “Waste pain” generating more waste and more pain.
- #9 Thankfully, the way we reported progress externally was rather healthier, much more focus on what is to be delivered
- #10 Much more “What can we get over the line?”, “What’s holding us back from finishing” rather than “What can we start”Turn this on its side, and we kinda get this:
- #11 Big batches moving between the columns up to deployment, independent flow of work items from deployment to done – done meaning validated – we’re happy that the customer and the support team is happyWe have teams rather than initiatives down the left hand side, but…
- #12 Customer conversation was very much at initiative level. Discovering and exploring what’s important, not pushing from a backlogInitiatives sponsored from both sidesExtrapolate two pieces of advice here:don’t base your key customer conversations on a lists of low-level work items but on what they (and you) need to achieve.don’t sell yourself short by merely taking orders: you’ve been given stewardship of a system so take some responsibilityThat’s the scenario – let’s use the tools of 2012 on the team of 2007
- #13 That’s the scenario – let’s use the tools of 2012 on the team of 2007Visualise: some attempt to present work items and workflow, blockers, hierarchyWIP limited mainly through release planning. Some attempts at per-person WIP but I’m probably being over-generous hereFlow managed informally but effectivelyProcess very well definedOperational review – particularly around quality, performance and capacityAnd evidence that those feedback loops supported an improving & evolving processBut dirty secret!
- #14 This story is more fantasy than experience report,a combination of thetraditional portfolio management that I’ve worked with as manager and consultantplus ideas exchanged with Don Reinertsenplus ideas borrowed from Beyond Budgeting
- #15 What we’re looking at here is a portfolio reporting tool, built by my son Simon & I during his summer vacation from university[Like every good father, I thought he should learn some Coffeescript – and in 367 lines of Coffescript we have a tool to slice & dice a portfolio in interesting ways]What you need to imagine, is the following scenario…We’re in an organisation that practices “beyond budgeting”.My boss manages the whole IT portfolio; I’m responsible for a part.I’ve submitted a forecast as part of my “Ambition to Action” and my boss isn’t impressedI’m forecasting a big bulge in the burn rate, building up an inventory that cost a lot of money to accumulate and continues to cost us significant amounts of money to carry.My release (and therefore my cumulative flow) is lumpy, not smooth
- #16 You can see from the numbers that I represent some 60% of his inventoryproblem!Challenge:“You can do better than this”“If it helps you to have a target to shoot for, try to reduce your cost of carry by 20%”“I predict that some of those other problems will largely go away if you achieve that.”
- #17 I drill down to identify the initiative responsible for most of the problem
- #18 To help understand what we’re seeing, I’ve selected a project – a simple one rather than the worst oneA million-dollar one-day project has the same carry cost as a project costing just a few thousand but taking a yearAny attempt at constraining cost of carry forces us to look very closely at lead times, and in turn manage down inventories.There’s no escaping Little’s Law!
- #19 We burn money, accumulate inventory (knowing full well that we’re going to do it – the pale stuff hasn’t happened yet)And on that accumulated inventory we charge interest – the carry cost – at rates representative of the feedback opportunity lost.I won’t go into details right now but it’s easy to justify carry rates of 25, 30, 40 or more percent.A way to begin quantifying the benefits of improvementReduce planned inventory (height) and lead times (width) to reduce cost of carry.Constraining it forces us to think harder about what we do in parallel and how long we allow things to take
- #20 Limiting WIP is absolutely my top focus, aimed at improving flow.The feedback loops are mostly between me & my manager, so we’re missing some of the things we saw in the first story.Left with a mirror image
- #22 A resourceful dev manager decides that a department-widekanbanboard is the way to improve things. That’s what they’re for, right?There are some good things here:we’re seeing blockers, we have validation (a customer feedback loop)He got the message about not over-organising people so he organise the work by initiative rather than team.It’s not clear how he is going to limit WIP, but that’s not his biggest worry
- #23 “Mike, I ran the Kanban depth tool and I get this! What’s up? Help me! What’s missing?”
- #24 We could answer the “what’s missing” question by diving into the tool and list the practices it’s looking for, but that would be missing the point.I want to answer the “what’s missing question” with four keywords
- #25 The first of these 4keywords references one of Kanban’s foundational principle, actually the 2nd one.Perhaps you heard this for the first time in Ketil’s introductory presentation yesterday morning.How does a change agent expect to be successful without agreement?This isn’t considered in the assessment tool but it easily could be – I’ll explain how in a moment – and I would argue that it should.
- #26 The second is alignment, not called out explicitly in the method but we’re close.“weak and strong alignment”Weak: Making sure that what I’m trying to achieve supports what you’re trying to achieve.Strong: combined, we’re planning to succeedAgreement and alignment can exist without the other. Both need to be explicit.We can both agree on a whole list of things but our goals and plans needn’t align. I can rationalise what I’m doing by telling myself that it supports your goals, but there’s no agreement there.
- #27 This one is explicitly called out in the method. Ketil and Yuval in their talks both described it.As a change agent, you know when you’re winning when the language begins to change.Q? Shared understanding of concepts such as WIP, bottleneck, variation.The presence of shared models changes the way we frame problems. So long as we have the right models, this is very powerful
- #28 Of my four keywords, challenge is the one least explicitly called out.I’ve only recently come to realise it, but I think that’s something we might want to fix.Challenge is very much part of Lean (recall Steve’s & Hakan’s talks yesterday)Somehow we must connect vision, current reality and necessary action, and this word describes that well.
- #29 Four quite abstract words, but now look at them in context, with you in the middle as an agent of changeAre you, your teams, your peers and your managers agreed on the desirability of change?Do your goals and your plans align?Are you speaking the same language? What’s are the models behind that?Are you content with merely fixing problems, keeping things under control, or will you rise to a serious challenge, to take your part of the organisation somewhere new?What goes in those question marks? More models – models of interaction
- #30 Yesterday we saw the Toyota katas and the Kanban katas.Many of you will be familiar with A3 too.I want to share another routine, one that puts the challenge or the goal first.Structuring improvements, exploring necessary innovationA strong correspondence with A3 and the katas but with less formal language.
- #31 360 degreesAssessable, useful not just as a maturity indicator, also as a personal plan
- #32 Back to our portfolio kanban implementation.Don’t despair - Kanban helps us learn from what’s there already,Keep what is good (and hopefully amplify it),surface (and help fix) what is not so good.It’s not about the sticky notes, it’s about evolutionary organisational change
- #33 Story 1 plus Kanban means story 1 plus transparency, models, and (most of all) challenge, and more targetted improvement.This team’s dirty secret: success measured in its own terms, leading to complacency. No model for performance other than its own process.Happy with its predictable 6-week heartbeat, rather quiet about its 18-24-week lead time
- #34 Story 2 plus Kanban means connecting a model of financial performance with models of what happens day-to-day on the ground.Alignment in other words
- #35 The trick I’ve played here of course is that the first two stories each had kanban-shaped holes in them.But so have many organisations that are in need of a way to get unstuckAnd even the best implementations have holesMaturity isn’t achieved overnight, and don’t be too concerned if it doesn’t seem to be there at the start.If you want to change it, it is important that you understand properly your organisational context and your position in it as change agent.
- #36 So to finish, let me ask once again…