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

May 29, 2015

Kanban from the Inside: 16. The Kanban Method

Filed under: Books,Kanban — Tags: , , , , , — Mike @ 12:29 pm

Chapter 16 of my book Kanban from the Inside condenses into a single chapter the following:

  • Some historical context
  • The principles and practices of the Kanban Method
  • “Contextualized Kanban” — Personal Kanban, Portfolio Kanban, and Scrumban
  • So-called “enabling concepts” —values, agendas, the Kanban Lens, etc
  • Implementation guidance —an overview of STATIK, to be covered in part III (chapters 18-23)

This week’s excerpt comes from that “Contextualized Kanban” section.


Scrumban

Scrumban is a name coined by Corey Ladas, for what happens when what you do now is Scrum and you apply Kanban.

I stress again the cautions of Chapter 13: Kanban does not mean recklessly throwing out all of your Agile discipline; rather it’s a transformative process that takes time, thought, care, and collaboration.

This progression is typical:

  • Already practicing a degree of visualization, the team organizes work according to its “done-ness.” This extends beyond “code complete,” “demo-able,” or “potentially shippable” to cover acceptance, deployment, and customer validation states.
  • Increasingly, standup meetings are organized around the board.
  • Already limiting work-in-progress through the sprint mechanism, the team pays more attention to the amount of work started but not yet finished. As a result, they start to see work items getting completed sooner. Immediately or after seeing the board operating well, explicit WIP limits may be introduced.
  • With work items completed sooner and more visibly, greater attention is given to the later stages of the process. Impediments to continuous delivery start being addressed. The nature of the sprint begins to change as releases are planned independently (if they need much planning at all).
  • Having decoupled releases from sprint planning, the system now easily accommodates work of different types and speeds. The team pays attention to the cost of delay of individual items and to the mix of work overall. Mid-sprint changes become much easier to accommodate; classes of service may be offered.
  • The rhythm of sprint planning continues, but the meeting itself gets easier. Estimating the right amount of work for the sprint seems less important; it’s enough to ensure that there is sufficient work of high enough value and quality and that the riskiest items have been identified and broken down where necessary.
  • With the need for customer validation made more visible, new feedback loops begin to emerge.

Different attitudes toward the Scrum practices and roles will of course lead to different outcomes. It’s not unusual for teams to go through changes of the kind described here and for them still to identify themselves with Scrum. That’s completely fine with us—it’s “Kanban with,” not “Kanban versus.”

The team I’m currently [mid 2014] working with as its interim development manager is a long way down this path. The planning rhythm is still there and I’m in no hurry to see it disappear. The highlight of my working fortnight is the “Show and Tell” (the sprint review), a lively meeting in which the project team is outnumbered by customer representatives and outside observers (as a “digital exemplar,” one of a number of pioneering citizen-facing projects delivering services online for UK Government departments, we often receive visitors from other departments and public agencies interested in how we do things). Not only do we review progress and show what we’ve recently built, we often review pertinent videos of outside customers interacting with the live system or with prototypes. These are highly motivating—sometimes even moving—and the shared experience adds to its impact.


 

Next up: 18 Understand Sources of Dissatisfaction. Previously: 15. Economic approaches to flow. Start from the beginning: 1. Transparency.

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.

September 4, 2013

Find ways to…

Filed under: Kanban,leadership,Portfolio — Tags: , , , , — Mike @ 9:55 am
  1. Find ways to visualize your work
  2. Find ways to limit your work in progress
  3. Find ways to manage flow
  4. Find ways to implement feedback loops
  5. Find ways to improve (collaboratively, using models and the scientific method)
  6. Find ways to encourage leadership (at every level)*

Then ratchet it up, in terms of both creativity and persistence. Keep finding ways to…

As Larry Wall (of perl fame) says: there’s more than one way to do it. We all think we know what a kanban system should look like, but the further you depart size-wise, speed-wise, scale-wise or complexity-wise from what’s typical – where the board sees a worthwhile and manageable amount of movement each day – the more creative you’ll need to be.

A card wall visualisation may not even be the best starting point. Look at what you have – your existing practices, your existing data. Kanban is after all the start with what you do now method.

(* Yes, that sixth one is a principle of the Kanban method rather than a core practice like the others, but it still works. See also Small Acts of Leadership.)

August 28, 2013

Upcoming

Filed under: Kanban,lean,Values — Tags: , , , , , — Mike @ 1:36 pm

It’s that time of year again, the season of mists, mellow fruitfulness, and a great series of European conferences:

I’m on the programme committee for LKUK13 and I know that there has been stiff competition for speaking slots at all these events. They’ll be great! And every year I’m surprised at how each one manages somehow to find a style all of its own.

Regular readers of this blog will know that 2013 has been for me the year of Kanban’s values. These form the backbone for my new introductory/something-for-everyone talk on Kanban. If you’re new to these ideas, why not come and join me? My talks are usually placed early in the programme so there’ll be plenty of opportunity for discussion afterwards.

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?

October 23, 2012

No-one said it would be easy…

Filed under: Kanban,leadership,lean,Portfolio — Tags: , , , , , , , , — Mike @ 8:33 pm

Much as expected, Lean Kanban Central Europe 2012 (#lkce12) turned out to be an excellent conference, probably the best-organised I’ve attended. Well done to the board (Markus, Pawel, Hermanni, Klaus and Karl) and everyone who helped behind the scenes.

The slides for my talk ‘Not “Portfolio Kanban” but “Kanban”’ are now up on Slideshare.  The most important slide is probably the one shown below (#30), which illustrates the scale of the what’s to be done “if we are serious as change agents” (a phrase I used more than once).

Four different directions of interaction to consider. Four different considerations (the “Agreement, Alignment, Models, Challenge”) for each direction. That makes 16 if all combinations are relevant (most will be). Hard work and worth tracking, so perhaps some new visualisations will be needed too – something to think about. I will be talking to David about incorporating some or all of this in the “Kanban depth” tool also.

October 19, 2012

How Deep is “How Deep is Your Kanban”?

[wonkish, sorry]

I’m busy putting the final touches to my portfolio-related talk for next week’s #lkce12 conference in Vienna. It owes a significant debt to David’s milestone talk How Deep is Your Kanban, but this leaves me with a couple of slightly embarrassing niggles.

Where in the assessment tool are:

  1. Agreement – “Agree to pursue incremental, evolutionary change” is a foundational principle of Kanban and the organisational scope of any agreement is surely assessable. As a change agent, have I achieved 360-degree agreement? If I have, won’t this help make change “stickier”?
  2. Challenge – The language of the tool is big on improvement, implicitly in the direction of “improved” or “fitter”. Isn’t this a bit weak? What about other drivers, direction-setters and pace-setters? Together with “leadership” and “alignment” (already well represented), adding “challenge” might go some way to address the “Kanban is too nice” perception and help complete the connection with Lean organisational practice.

Got that off my chest!

With that out of the way, keep an eye out in my talk for my son’s summer programming project – Kanban meets Design Factory meets Beyond Budgeting. It needs a better name than “Foo” though…

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?

June 25, 2012

Back from #klrat

Filed under: Kanban,leadership,lean,Portfolio — Tags: , , , , , , — Mike @ 2:02 pm

I’m just back after another week away from home – first a 2-day Kanban class in London, then the Kanban Leadership Retreat in Mayrhofen in the beautiful Austrian Alps. Such a treat!

You will not be surprised to hear that I found myself leading (or rather co-leading with Rich Turner) a further exploration into the application of Kanban to portfolio-level problems. By “Kanban” I mean not just kanban-style visualisations but conscious attention to WIP, flow, policies etc. I have to admit though that I got far more out of other sessions.

Yuval Yeret did us all a great service by (re)raising the topic of Crossing the Chasm. This spawned several intense discussions, mostly notably a “Compelling Reason to Buy” discussion that fully justified an additional session of its own.

Håkan Forss led a number of sessions, two of which I attended. The first was on Kanban Kata which he describes here and here – I have little to add except to say that (i) I love it and (ii) it fits very well with what I teach around the use of A3.

In Håkan’s second session he sought to challenge the sequence in which the practices of Kanban are listed. This might seem a trivial point (and at one level it is) but it led first to a fruitful discussion on rollout approaches and then to this, an unordered visualisation of the depth to which the practices are understood and applied:

Discussions like this get exciting when you realise that you’re part of something that will change the way we understand, teach and implement Kanban. My contribution was to make a connection between this picture and the use of the Story Mapping technique as a way to guide and organise a Kanban rollout. Probably the best introduction to the latter idea is this post of Yuval’s.

You could say that Håkan and Yuval had good conferences, but then we all did 🙂

Older Posts »

Powered by WordPress