Positive Incline Mike Burrows (@asplake) moving on up, positively

May 23, 2015

Kanban from the Inside: 15. Economic approaches to flow

Filed under: Kanban,lean,Uncategorized — Tags: , , , , , — Mike @ 4:54 pm

We’re at chapter 15 of Kanban from the Inside, on economic approaches to flow. This excerpt expands on the third of three principles of Real Options as identified by Chris Matts and Olav Maassen [1, 2]:

  • Options have value
  • Options expire
  • Never commit early unless you know why

Never Commit Early Unless You Know Why

This looks like another truism, but it is well worth repeating. How different would most projects look if for every planned feature someone asked this question [3]:

What would have to be true for this option to look fantastic?

Where the answers to this question are unknown, a new layer of exploratory options can be generated.

Typically, the project provides the perfect mechanism for avoiding this question. Scope, duration, and cost are all decided before the questions are even asked, let alone answered. By design, changes to any of these cause drama and stress!

Contrast that to an options-based approach. Instead of a predetermined project backlog, we have a portfolio of options, a growing pool of uncommitted ideas that may or may not come to fruition. Options get exercised—that is, work gets pulled—when they will generate the most valuable information relative to all their alternatives.

Options thinking also does something interesting to risk management. Outside the development process, uncommitted options remain in the hands of those best placed to manage them, for example, those with the market knowledge to maximize opportunity. Once inside the system though, the risks change in both nature and ownership—there are expectations to meet. There is more than meets the eye in the act of pulling of work across these boundaries—it creates obligation and transfers risk. It is not to be done lightly.

[1]Chris Matts and Olav Massen. 2007. “Real Options” Underlie Agile Practices (InfoQ)
[2] Chris Matts, Olav Massen and Chris Geary. 2013. Commitment Hathaway te Brake Publications.
[3] Roger L. Martin, in Lafley, A. G. and Roger L. Martin. 2013. Playing to Win, How Strategy Really Works Boston: Harvard Business Press.

Next up: 16. The Kanban Method. Previously: 14. TPS and Lean. Start from the beginning: 1. Transparency.

October 4, 2013

My notes for the Portfolio Management panel at #lkfr13

Yesterday I had the privilege of sitting on a panel on the subject of portfolio management at Lean Kanban France. Our facilitator was Thomas Lissajoux and my co-panelists were Ian Carroll, Chris Young and David Joyce.

Thomas did us the great service of asking for some notes ahead of time. I found his headings really helpful, and I’ve decided to share my notes. And here they are…

How would you define ‘portfolio management’?

I see portfolio management as managing at that kind of level where maintaining the right balancing between competing projects is as big a challenge as any individual project.

What are the specifics of a lean/agile approach?

Depressingly, I see too many people talk about portfolio management like it was a sausage factory. The story goes like this: “just pay attention to the quality of ingredients going into the machine and success is guaranteed”. I doubt that this metaphor works very well even for sausages!

A lean approach means several things:

1)     Paying attention to the balance of demand and capability (supply), managing WIP relative to capacity and relative to lead time aspirations

2)     Paying appropriate attention to flow, because speed, predictability and timeliness matters (to the extent that there are economic penalties when we get these wrong)

3)     Expecting the way we manage the portfolio to keep evolving. That evolution needs to have some positive effects at project and organisational level that customers will recognise and appreciate, and there needs to be effective feedback in the other direction too (success and failures at project level should generate portfolio-level learning).

In which context/clients do you do portfolio management?

I’ve twice been in the role of portfolio manager myself, once with a $XXmillion annual budget, the second time at a smaller scale but with wider organisational impact.

Nowadays as a consultant I find that many problems on the ground point back to problems in portfolio management. Parts of the process get overwhelmed, and the organisational feedback loops aren’t fast or capable enough avoid real pain and cost. I’ve seen extreme cases where the whole portfolio seems to be grinding to a halt (there are reasons why this happens, a topic for another post maybe).

What about the previous situation and its shortcomings?

In many organisations, to get a project started it’s enough merely to sell the idea. The capability of the organisation to deliver and the impact on existing work is not given much consideration.

What key practices/tools/artefacts/meetings/metrics do you use?

  • The sheer number of projects (relative to the capability to manage them effectively)
  • Their value (with an understanding of the relationship between value and urgency)
  • Planned, potential and actual burn rates (making sure we have the capacity to deliver; too often the sum of all promises doesn’t match the sum of available effort)
  • Lead times
  • Amount of work in certain key states
  • $WIP

Tool-wise I’ve had success with

  • A3, as a means to test project rationale
  • Changes to portfolio reporting (feedback loops)
  • Customer validation – for its own sake and as a catalyst for process change
  • Regular customer meetings (cadenced)

What about the Kanban principles and practices at portfolio level?

They need to be applied with imagination. Add the phrase “Find ways to…“, perhaps “Find multiple ways to…”.

Core practices:

  • Find (multiple) ways to visualise work at portfolio level (transparency).
  • Find (multiple) ways to limit work in progress at portfolio level (balance).
  • Look at how policies can drive better portfolio performance (transparency again).
  • Pay attention to the feedback loops (and again!)
  • Keep improving and evolving (collaboration)

Foundational principles (or rather, their underlying values):

1)    Understanding: Make sure change is based on genuine understanding of how things work now, taking both internal and external perspectives

2)     Agreement: Always have the right people (ie those with a stake in the solution) solving problems at the right level, seeking agreements that will hold in practice

3)     Respect: the first two, plus creating the expectation that improvement will benefit people, not just the numbers

4)     Leadership: grow the next generation of portfolio managers (growing yourself in the process)

Additionally I would add that the portfolio mindset and Kanban are really complementary. Identify

  • different kinds of projects
  • different risk profiles
  • different stakeholders
  • different budgets/appetites

Make these dimensions visible (I mean an in-your-face, Kanban’s-killer-feature kind of visible, not just a filter on a report), aim for a healthy mix of work. With success comes trust in both your ability to deliver and the underlying principles and techniques that make it happen.

What challenges did you face?

Pretty much everywhere, far too many projects and projects that take far too long to deliver.

  • In one company, more projects than there were people, not just in IT but in the whole company!
  • In another, projects taking multiple years, little thought given to the possibility of incremental delivery

What key advice would you have for ‘change agents’ about to dig into portfolio management questions?

  • How is demand managed against capability?
  • Are lead times too long? (a very different question to the one of whether projects are late – dates tend to be genuinely critical on no more than 20% of a typical portfolio – though the long projects tend also to be ones most prone to delay)
  • Can you put a value on the amount of WIP (I refer to this as $WIP)? High shock value!
  • Another great metric once you understand it: What is that WIP costing in delayed business opportunity and delayed feedback?
  • Is the typical project process set up just to deliver to spec or to meet an evolving customer need? See recent posts Stand up meeting, thinking tool, leadership routine and Anticipating needs ahead of time.

What are the next steps? How can you improve/scale?

Quantify, visualise, sanity check. Look for imbalances. Look for sources of unpredictability, especially waiting. Look at the relationship between project size and predictability.

And remember that scale comes with addressing coordinating costs and other kinds of friction end-to-end, not from rolling out more process or adding layers on top.

December 27, 2012

My 2012 in books

I’ll get to my book of the year in a moment, but I begin with the two books that have had the most direct influence on my work in 2012.

The first is Coaching for Performance: GROWing Human Potential and Purpose: The Principles and Practice of Coaching and Leadership by John Whitmore (2009). I’ve been using the GROW model described in this book not just as a coaching tool but as a gateway to A3, really appreciating its teachability, memorability and its reminders of the importance of framing and challenge.

Like the first, the second is new to me but not a new book. From Lean Software Strategies: Proven Techniques for Managers and Developers by Peter Middleton & James Sutton (2005) I have taken away a much stronger appreciation of the word customer, and I find myself repeating its advice often.

My book of 2012

I choose Paul Tough’s How Children Succeed: Grit, Curiosity, and the Hidden Power of Character not because it’s still fresh in my mind but because it’s a book that I hope will be read widely. Readable, thought-provoking and inspirational, it’s a book for anyone with an interest in the relationships between environment, learning, character and life prospects. That should be most of us.

For the benefit of UK readers I should mention that I had to import it from the US but it will be available here in paperback next month.

Honourable mentions

I approached How to Measure Anything: Finding the Value of Intangibles in Business (2010) with some caution, the title preparing me for a book that might be overly analytical and worryingly money-centric. Instead, it’s a broad, insightful and practical book about making decisions and managing risk in the presence of uncertainty. I’m delighted that the author Douglas W Hubbard will be a keynote speaker at the 2013 Lean Kanban North America (#lkna13) conference.

Turning to fiction, I’m grateful to Dave Snowden for introducing me to anthropology-cum-science-fiction author Ursula le Guin.  Since reading The Dispossessed (1974) in preparation for the CALMalpha event I’ve enjoyed a number of her books, sharing some written for younger readers with our foster daughter.  This one remains my favourite though – I was genuinely disappointed that it had to come to an end! As a sci-fi fan, how did I not encounter le Guin previously?

Thinking, Fast and Slow by Nobel laureate Daniel Kahneman was for many reviewers a best book of 2011 and I got round to it in 2012.  Well worth the effort.

The surprise package

I carried around a review copy of Agile Project Management for Government: Leadership skills for implementation of large-scale public sector projects in months, not years in my suitcase for several weeks and was more than a little surprised and humbled to discover my name listed in the acknowledgements! It’s not an easy topic topic, but author and fellow Agile North speaker Brian Wernham has done a good job of drawing out valuable lessons from reference projects around the world and calling out the kind of leadership necessary for project delivery in the public sector to improve.

Since first meeting Brian I have myself joined a large public sector programme so the arrival of this book turned out to be very timely. I should get round to a longer review in the New Year.

Next up

Top of my list for next year (already purchased and downloaded onto my Kindle) is The Culture Game: Tools for the Agile Manager (2012) by Daniel Mezick. Do you confront culture and mindset head-on, or regard them as something emergent? That has been a favourite conversation topic on Twitter and in conference bars and I’m really looking forward to reading Dan’s take on this.

October 29, 2012

When will this project be ready? (and some better questions)

A couple of good articles have caught my eye recently, both extolling the virtues of Critical Chain Project Management (or aspects thereof), namely:

Also announced in the last few days: Troy Magennis’s (@t_magennis) new book Lean Forecasting (“Rapid Forecasting Likely Staff, Cost and Delivery Dates of Agile Software Projects”). Meanwhile there’s always the classic Waltzing with Bears by Tom DeMarco and Timothy Lister.

Here on positiveincline.com I’ve made some small contributions of my own on the subject of planning, for example:

But there’s a problem with these technical approaches…

Is the when will this project be ready question always a good one to ask?   And even when it is a reasonable question, are we guilty of rushing to answer it when more interesting questions need to be asked first?  Questions like:

  • Why do you ask?
  • What will we need to prove?
  • What parts should we deliver first?
  • What else needs to happen for this to be successful?

Moreover, we risk a lot of needless pain and waste if we don’t take the trouble find out what kind of date we’re talking about.  Is it a “bad things will happen if we’re a day late” kind of date, or “I need some cost information so that I can make a priority call” kind of date?

I don’t expect the need for forecasting and schedule risk management to to go away completely, but let me leave you with another:

  • What needs to change in our organisation for the when will this project be ready question to be asked only rarely?

Answer that one, and you’re probably on a good path to a kind of processes that deliver predictability in ways more valuable than just date compliance. Worth exploring, surely?

July 10, 2012

What’s your strategy for success?

All projects must have a strategy for success

So starts a thought-provoking post from Glen Alleman‘s blog Herding Cats; several months later and I’m still coming back to its central idea.  Ask yourself: what are you doing right now to ensure that the thing you’re building doesn’t just meet documented requirements, but is successful in achieving valuable business outcomes?

Before we get hung up on the word “projects”, how about:

“All initiatives must have a strategy for success”

If you’ve heard me speak in the past year or two you may have heard stories of how we used A3 as a way to get to the heart of what was important in our portfolio of initiatives, against which we could deliver value to the business (I’m deliberately steering clear of how that was organised – it’s not that relevant here).

Last year I majored on how A3 helped us identify the few business initiatives on which we needed to concentrate our efforts; this year in my portfolio-related talks I’ve drilled into one project whose A3 helped take it from #5 to #1 on our list of priorities.

Its strategy for success?

  1. Re-frame the initiative not as “deliver the next milestone on the roadmap” (in this case a new trade capture system) but as “face up to a set of significant challenges” – addressing some real business risks (which we quantified at the time) linked to some big-picture architecture issues which we planned to address incrementally.
  2. Reverse the implementation plan, starting not with the shiny new system but with something much more mundane, some strengthened business controls to create (i) some additional stakeholder “pull” and (ii) a safer environment for the several (and sometimes difficult) implementation steps that would follow.  A feedback mechanism designed both to amplify learning and to dampen any potential negative effects.

You may recognise part 1 of this strategy as the A3 approach working its magic.  Part 2 was explicit, documented in its A3, agreed.  What was seen previously as an IT delivery problem was now a business problem. And it worked!

Taking it down a level

What if we asked the “strategy for success” question more often?  For every piece of work?  Have it hanging in the air in every stand-up meeting?

I have in mind what might be described as a reversal of the V-model (article and image from Wikipedia):

Instead of that backwards-looking “Verification and Validation” arrow, what if we looked forward, asking ourselves questions like these:

  • How does the work we’re currently planning (and the way we plan to execute it) really stack up against stated business goals?
  • How do we know that the thing we will make operational tomorrow is what will be needed tomorrow, not just the thing that was specified yesterday?
  • For this current feature, do we know what sort of UAT experience we can expect? (And if not, why not?)
  • How many surprises should we expect in system test?  What are we doing to pre-empt them?
  • What am I doing to make my next handover (upstream or downstream) a zero-surprise non-event?

Asked daily, some of these questions are more tactical than strategic (in Kanban terms we’re in “manage flow” territory), but ask them often enough and we may crystallise out some new policies, refine our knowledge discovery process, perhaps trigger some concerted improvement activity – a strategy for change that’s supportive of our strategy for success.

So, looking at your work from business initiative right down to today’s work items, what’s your strategy for success?

May 31, 2012

More than mere tinkering

Not that I have ever needed much excuse to tinker, but LSSC12 has prompted me to make some significant updates to the materials for DJAA‘s 2-day class Successful Evolutionary Change with Kanban. And I don’t suppose it will be long before other providers follow suit.

Key changes, trailed by David at the conference after some testing on kanbandev:

  • Kanban’s foundational principles are gaining a fourth member on the subject of leadership, to be encouraged at every level from individual contributor upwards. I believe it fits very well – just as with the original three principles (which I like to summarise as “understanding, agreement, respect”), without leadership can you really expect success?
  • We are gaining an additional practice too (a 6th, to be inserted at #5): “Develop feedback mechanisms at workflow, inter-workflow and organizational levels”. A leaf out of Influencer‘s book, a good bit of Systems Thinking, and another reminder that Kanban is a method for driving organisational change, not a software development process, project management framework or process tool. Feedback mechanisms are a key part of what I’m already doing in the portfolio space and there’s no doubt in my mind that there is a lot of mileage in this practice.
  • References to “scientific method” have been replaced with “safe-to-fail experiments”, tying the improvement practices we already teach to the organisational understanding of Dave Snowden and other folks in the complexity community. Experiments were an important topic at LSSC12 and this change seems very timely.
  • There’s another acknowledgement of great thinking from outside the Kanban community in our adoption into our material of Michael Kennedy’s language concerning the “knowledge discovery process“. I love that we have found better words for what some of us already knew deeply but could explain only clumsily.

None of these changes are fundamental – rather they help to crystallise out some thinking that runs right through what we teach in our classes and bring to our consulting clients. That makes them easier to take away and to apply in imaginative ways, and that’s exciting.

My next public classes are in London (June 18th-19th) and Edinburgh (September 19th-20th) and you can register through our UK partners TeamProsource. And you might do yourself and your organisation a favour by sending your managers along to our 1-day event (June 11th). Not that managers (or for that matter non-techies) should feel the least bit excluded from our regular classes – some of the best designs of kanban systems I’ve seen in our classes have come from managers from outside of IT; they get it!

May 25, 2012

Kanban: Thinking tools for portfolio-level problems

This is followup #4/n to my LSSC12 debrief, probably the last of the series (n = 4) but who knows.  If you haven’t already read followup #2 Portfolio stuff (sic) at LSSC12 please do so now, what follows should then make a lot more sense.

I put the deck for my hastily-arranged talk “Kanban: Thinking tools for portfolio-level problems” up on slideshare a few days ago.  I had only a couple of days to prepare it (and it shows, no doubt), but presenting it was still a lot of fun. In contrast to my earlier talk where interaction was programmed in, here it just happened, a real pleasure.

I will be giving a reworked version of this talk at a management seminar in London in June (if you’re based in the UK, send your manager!) and I’ll release an updated deck after that event.  Meanwhile, I’ve done a better job of summarizing how the Kanban practice “Limit Work-in-Progress” (which was always about so much more than just avoiding multi-tasking) points towards the generation of flow at portfolio level:

  • Apply “traditional” WIP limits where effective
  • Test the logic of your investments with A3
  • Make the full cost of your inventory visible
    • Effort, time, money
    • Cost of carry
  • Manage your inventory down
    • Decide what to finish
    • Work out how to release customer value incrementally
    • Break habits of over-commitment & premature commencement
    • Balance work & capacity across the board, seeking smoothness

To explain the first bullet, limiting business initiatives at the highest level can be effective (I’ve helped to make it happen), and naturally we would recommend Kanban at the lowest levels.  But between those extremes of scale, traditional(!) Kanban-style WIP limits can be hard to apply if there are a large number of projects, orders-of-magnitude size differences between them, or glacially slow progress, ie just what you might expect in many larger organisations. Clearly we will need to be more creative in how we begin to control inventory here.  After that we might move away from projects (especially projects of the fixed-date kind) as the default container for work.

My references to A3 are based on real successes which I spoke about last year at #lkbe11 (Antwerp) and #lkce11 (Munich) and my updated deck will contain a simplified example. The phrase “Decide what to finish” also appeared in last year’s talks, along with the more desperate “Decide to finish something“!

The rest is newer.  If you have any financial information about the work in your portfolio, think about re-purposing it for inventory management, aiming to generate flow by managing inventory down.  Think about cost of carry; see how it incorporates both cost and time into one measure, see that it can help to bring value and risk into consideration too.

I would be the first to acknowledge that Kanban at this level is very much in the early adopter phase.  I make a virtue of this, in that we have the opportunity to explain the Kanban Method as a pragmatic and actionable strategy, neither a leap into the unknown nor something that is primarily tool-driven (although it’s good to see the tools coming along quite nicely). I see the techniques I and others are exploring leading to better organisational feedback mechanisms that help to drive organisations in the direction not only of faster delivery but also of smoother flow supported by more stable teams. Real change, in the direction of effective, economic and humane – isn’t that what we all want?

May 20, 2012

Portfolio stuff (sic) at LSSC12

This is followup #2/n to my LSSC12 debrief.

As I mentioned in my debrief, I organised an evening meeting on portfolio “stuff” to take place after the speakers’ reception. What kind of an idiot arranges a meeting for 20:45, after drinks, and with a deliberately vague title?  23 people showed up at that late hour, demonstrating a significant level of interest. If you’re one of those 23, thank you!

“Portfolio stuff” became “Portfolio-level problems” in my bonus talk the next day (my slot was extended due to the next speaker dropping out).  I’ll write up my talk more fully in the coming days, but what both titles indicate is a desire to spend some time identifying the problem rather than to announce that we have cracked how to do portfolio management.  To describe the problem (if there is indeed only one) in the terms of the presence or absence of a particular kind of solution is a kind of sloppy thinking I wish to avoid.

I must make plain that I take seriously the evolutionary approach of Kanban and its principles of “start with what you do now”, “respect current roles and responsibilities” etc. I use “understanding, respect, agreement, leadership” as a way of bringing together both these principles and some of the Systems Thinking approaches that we teach in our classes.

So lets start with a little understanding.  What does the problem space look like?

Limiting myself to the past 4 years, my direct experience ranges from leading a team of 15 (the whole of IT in that small company), responsibility for a team of 70 within a big name global enterprise, and looking at the work of an IT organisation of hundreds within one division of a major enterprise.  That’s quite a spread.

My Monday night group reported projects (if that’s the right word) ranging in duration from days to months. I’ve seen worse, ie years passing before anything gets delivered.  Orders of magnitude differences.

We defined “portfolio level problem” as problems seen, managed or originated (ouch!) above the organisational level of teams of individual contributors.

These include:

  • The challenge of translating the objectives of the organisation into actual work
  • The reverse of that challenge, seeing how actual work on the ground corresponds to organisational needs
  • Managing flow day-to-day, ensuring that important work has the help it needs to progress to completion
  • Managing and improving flow system-wide

Steering clear of:

  • Allocating individual people to their work (it distresses me that some writers seem to think that this is even a problem, let alone a solution).
  • Push, meaning any approach that seems to value starting over finishing. Includes any system with stage gates or focussed on backlog grooming that lacks strong mechanisms to balance supply and demand further down the pipeline.  It is not enough to limit what you start.

It’s a very interesting and wide-ranging problem space. “Portfolio management” might be the right name for it but I’d love to have a better one that didn’t carry the baggage of failing approaches.  “Portfolio Kanban” works well if it implies the method and thinking, less well if it means only stickies on whiteboards.  Perhaps we need to do some work to reclaim the phrase.

Upcoming posts will explore the applicability of the Kanban method and offer some techniques for use in this space.  Stay tuned. Meanwhile, a reminder to use hashtag #ppm for related posts to kanbandev.

May 3, 2012

Coming in June: Kanban comes to London!

After the big conference month of May comes a June that is packed with Kanban-related training opportunities in London. There’s something for nearly everyone: a one-day event you can send your manager to, an accredited 2-day class, and David Anderson is in town at the end of the month for his 3-day masterclass.

The first of these is on June 11th. Lean Thinking and Kanban for IT is aimed at managers and other senior leaders in IT. The speakers are Jack Strong of LeanKit in the UK (a long-standing user and proponent of visual management and Lean in industry), Patrick Steyeart and Johan Vanwelkenhuysen of TeamProsource in Belgium and the UK respectively (pushing boundaries on the application of Kanban and Lean for projects and programmes), and myself, of David J Anderson & Associates, Inc. We will show how visual management, Kanban, Lean and Systems Thinking can be applied to service delivery, to projects and programmes, and to the problems organisations so often face at portfolio level (a subject close to my heart).

I’ve mentioned Patrick a few times here and it’s fantastic that we have this first opportunity to work together.

June 18th-19th I’m teaching our accredited 2-day class Successful Evolutionary Change with Kanban, operated by our UK partners TeamProsource. Learn not just how kanban systems work at the nuts-and-bolts level, but also how the Kanban Method catalyses organisational change and improvement.  “Immensely valuable” was one recent piece of feedback on this class and I must say that I find it very satisfying to teach too.

You may recall my excitement early last year after attending David’s Kanban Leadership Workshop, the forerunner to his 3-day Advanced Kanban Masterclass, coming to London June 27th-29th. This is for you if you have a level of Kanban experience (or have at least attended a 2-day class) and wish to develop your knowledge and skills as a change agent, whether that is in a leadership role or as a coach. I really can’t recommend this class highly enough.

December 1, 2011

Real Kanban Questions #2: How does the team know that customers are factoring architectural significance into their selections?

Filed under: Kanban,Project Management — Tags: , , — Mike @ 12:16 am

This Real Kanban Question is based on a Twitter conversation with @ThinkBA.

One set of answers (David’s) assumes the existence or creation of a process step for assessing architectural impact:

  • Make sure that this step is reflected in the team’s kanban system
  • Have policies for feeding back on items whose impact is determined to exceed tolerance
  • Refine these policies by making them specific to a class of service, allowing (for example) non-urgent items to have greater impact than urgent ones without the need for some special decision making process
  • Have a class of service for items expected to be high impact (platform improvements, say) and reserve some capacity for these so that they are analysed in good time

But what if that assumption doesn’t hold (or can’t be made to hold cheaply)?

“How does the team know?” is a “smell”, meaning that there may be a dysfunction to sniff out here!  It begs a number of questions:

  • Why doesn’t the team know?
  • What are the architectural concerns that the team wishes the customers to take into account?
  • Are there perhaps architecturally significant pieces of work that the team is anxious to get prioritised?  And failing to?
  • Armed with better information, would the customer make better choices (better for all concerned)?

In other words, the question implies to me that the customer and team are insufficiently aware of each other’s concerns and priorities, indicating that collaboration doesn’t feature enough in work selection and (moreover) risk management.

Let’s return to the key paragraph of question #1 (interestingly, another “how do we know?” question):

One very cool but rarely discussed effect of limiting work in progress (WIP) with Kanban is that it pushes choice back upstream.  Or to put this the other way round: too much WIP and the prioritisation and risk management problem is sucked into the development team.  Horrible!  Better to keep it where it belongs: in a partnership between the team and its key stakeholders. Getting this right goes a long way towards neutralising the value question; difficulty here likely reflects broader problems in the organisation.

The opposite of “sucking the risk management problem into the development team” is “creating opportunity for collaborative risk management upstream”.  The more informed the customer’s choices, the better those choices will be, to the benefit of both customer and team.  Win!

Do you have a Real Kanban Question?

Older Posts »

Powered by WordPress