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

January 3, 2016

“Introducing Kanban through its values”, three years on

Filed under: Uncategorized — Mike @ 2:51 pm

Exactly three years ago today I published Introducing Kanban through its values. Not only is it still (and by some considerable margin) the most popular post on this blog, it is no exaggeration to say that January 3rd 2013 was a career-changing moment for me. Suddenly, I was Kanban’s “values guy”.

By July 2013 I was pitching what was to become Kanban from the inside. My book came out in September 2014, excerpts of which you can read here in a series that starts with Transparency, the first of the nine values. Now I can add “author” to my bio!

In one regard, I was a little cautious. In the chapter that pulls together the main referenceable elements of the method (the Foundational Principles, Core Practices, etc), I introduced the values alongside other “enabling concepts and tools” with these words:

These may or may not be considered first-class components of the Kanban Method (to me they are) but they’re certainly important and helpful enough to be worth identifying here.

Happily, such caveats are no longer necessary. Published a few weeks ago, the Essential Kanban Condensed Guide by David J Anderson and Andy Carmichael gives the values early billing, even describing Kanban as “a values-led method”. And we’ve come full circle: the principles from which I first abstracted four of the nine values have been updated so that the correspondence is now very much more obvious. I won’t reproduce them here; instead download the guide (it’s free!) and look for understanding and customer focus in the change management and service delivery principles (these replace and augment the foundational principles and are very welcome).

With these and other signs of progress happening, how come Positive Incline been so quiet in recent months? The simple answer is Agendashift, a vehicle for tools and services supporting an “opinionated” (and very much values-based) framework for Lean-Agile transformation. Add “founder” too!

Agendashift launched this year with the values-based delivery assessment, an online tool extracted and adapted the final chapter of my book. We used the assessment as the template for a survey, publishing some key findings on InfoQ in November in a Q&A on Agendashift with Mike Burrows (questions by Ben Linders). A ‘mini edition’ of the full assessment is now the template for the 2016 survey, open to all.

Over on the Agendashift blog (more active than this one now) and our LinkedIn group (join us!) I’m still in the process of describing the framework; meanwhile in consulting work and in training workshops – the 1-day Values-based change with Agendashift and Kanban and the 2-day Values-based leadership – it is already being used to help characterise and properly contextualise a range of Lean-Agile transformation strategies.

In the pipeline: tools for hypothesis-driven (and of course values-based) change management to support what’s already taught in the workshops, and a third training workshop “Not just for startups” focusing on user needs and customer outcomes, rounding out coverage of the framework.

That’s a very satisfying three years of work centered on Kanban’s values. I hope Agendashift will provide a strong impetus for more!

June 26, 2015

Kanban from the Inside: 20. Model workflow

Filed under: Books,Kanban,Uncategorized — Tags: , , — Mike @ 11:33 am

The end is in sight – this the 20th excerpt from my 23-chapter book. This week, two excerpts for the price of one!


This chapter looks at three different approaches to modeling the workflow that our kanban system is going to support:

  1. Sketching it out
  2. Top-down decomposition
  3. Bottom-up organization

It’s important to remember that the result that we’re working toward is a working kanban system, not a static model. It’s best not to get too attached to the products of this exercise—they will quickly lose their value once the system begins to evolve.

I’ll keep this simple by assuming that there is just one main workflow involved. If you have more than one, you can take each workflow in turn or use one as the baseline by which the others are described.


Review

Before we move on, here are some good ways to check and improve what you have so far:

  • Quickly combine approaches to validate your model, such as:
    • Produce a sketch from your top-down or bottom-up model.
    • Make sure that actual work items map to your sketch or top-down model, then use the “what does this item need?” questions.
    • Consider whether it would be helpful to group, consolidate, or break down categories.
  • Check that queues are adequately represented and that you know where your commitment points belong.
  • Look to see where the dissatisfactions and frustrations discussed in Chapter 18 might originate.
  • Identify the kinds of knowledge discovery associated with each active state.
  • Seek to de-emphasize functional organization.
  • Present it to other people.

None of this should take long. Remember, sketchy!


Next up: 21. Discover classes of service. Previously: 19. Analyze demand and capability. Start from the beginning: 1. Transparency.

My book Kanban from the Inside was published in September 2014 by Blue Hole Press, publishers of David Anderson’s Kanban book, aka the “blue book”. Complete with an awesome foreword by Luke Hohmann, it is available in paperback and now on Kindle onamazon.com, amazon.co.uk, amazon.de and amazon.fr and (no doubt) other amazons also. A PDF e-book is also available via the djaa.com store.

 

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.

November 28, 2014

Featureban updates

Filed under: Kanban,Uncategorized — Tags: , , , — Mike @ 3:43 pm

For the uninitiated, Featureban is a simple and fun kanban simulation game.

Minor tweaks to wording on the facilitation deck (slideshare, pdf; drop me an email if you’d like the source pptx file):

Featureban from Mike Burrows

There is now a metrics spreadsheet (xls):

Screen Shot 2014-11-28 at 13.22.28

If you or players change the rules in the interests of flow that’s fine, but bear in mind that the flow efficiency calculation assumes that work items require a touch time of two days. Today’s team cheated for a while and ended up with a calculated flow efficiency of 111%!

Fun (almost) guaranteed!

2014-11-28 09.57.57

June 3, 2014

“How deep” rebooted: values-based depth assessment

Filed under: Kanban,leadership,Uncategorized,Values — Tags: , , , , , — Mike @ 3:23 pm

[Update 1: do read this post in conjunction with the previous one—Pulling change through the system—I don’t make it clear enough here that the purpose of the assessment is to help generate priorities for change]

[Update 2: the assessment tool has come a long, long way since the version still downloadable from here. Do yourself a favour and go to agendashift.com to use the latest version online.]

It’s fair to say that I have a complicated relationship with the Kanban Depth Assessment tool. With some excitement, I tweeted this picture from the 2102 Kanban Leadership retreat:

A few months after that tweet, I blogged How Deep is “How Deep is Your Kanban”?. Fortunately, I was able to channel my frustrations into something positive, and the eventual result was Introducing Kanban Through its Values.

Meanwhile, I find the tool useful in practice, even if flawed. That’s awkward!

Two years on from the Mayrhofen retreat we’re in Cascais, Portugal for this year’s retreat (#klrpt), and I have the opportunity to test a values-based realisation of our original idea, which I drafted only last week for the final chapter of my book (yay!).

Focusing on outcomes more than benefits, I asked participants to identify and categorise aspects or features of systems they would expect to see in mature Kanban implementations. This picture shows just a small selection:

2014-06-03 12.44.06

(I should explain that “Leadership & the Leadership Disciplines” pragmatically lumps together leadershipunderstandingagreement, and respect. I was actually rather gratified that Pawel Brodzinski expressed the concern that I didn’t give them sufficient individual prominence.)

Now for the measurement part. Sebastian Sanitz presented the Agile Fluency Model (Diana Larsen and James Shore), which uses a simple four-point measurement scale; Sebastian used the metaphor of learning a new language to explain what the different points on the scale feel like.

Since this morning’s workshop I have replaced my prototype’s ten-point scale with this more well-defined four point scale:

  1. Our system exhibits this aspect barely, if at all
  2. Our system is somewhat capable of exhibiting this aspect
  3. Our system exhibits this aspect convincingly, for the most part
  4. Our system departs from this only very exceptionally, understanding and managing the consequence when it does

These are applied per aspect; there are typically half a dozen or so of these per value category. I aggregate results within each category using a geometric mean (compared with a simple arithmetic mean, this gives more weight to lower/weaker scores, ie the aspects likely to be in most need of attention).

You can download the spreadsheet here: values-based depth assessment.xlsx. Some screenshots of the assessment worksheet and the radar chart visualisation are shown below. For the book, I will incorporate a time-based view from Ruben Olsen.

Screen Shot 2014-06-03 at 15.05.42

 

Screen Shot 2014-06-03 at 15.07.24

I honestly believe this to be an improvement on the old tool, but I know that there will be those that would still prefer to see it based on a checklist of low-level practices. I’m afraid to say that you’re unlikely to get that from me! Still, I’d be grateful for feedback, soon enough that I can accommodate it before the book’s publication (September, fingers crossed). If it takes additional work to separate the tool from the book—context matters, after all—that’s fine.

October 15, 2013

Kanban’s Organisational Design Principles?

Filed under: Kanban,leadership,Uncategorized,Values — Tags: , , — Mike @ 6:06 pm

Give or take a word or two, the Kanban method’s Foundational Principles have looked like this for a couple of years now:

  • Start with what you do now
  • Agree to pursue evolutionary change
  • Initially, respect existing roles, responsibilities and job titles
  • Encourage acts of leadership at every level – from individual contributor to senior manager

Does that last one really belong in that list? Much as I like the principle, I wonder. In the language of values, understandingagreement & respect (leadership disciplines, the environment and working agreements around the process and conduct of evolutionary change) then leadership (which tends to go hand in hand with change of any kind; we encourage an at-every-level variety).

Let’s try for size this new list (a list of concepts, not a serious attempt at canonical wording):

  • Service-orientation, by which customers have their needs met through single services or multiple coordinated services
  • Decentralised control and self-organisation, improving adaptability and responsiveness, easing reconfiguration both between and within services
  • Leadership, sustaining the system and change therein

These aren’t quite so foundational to the Kanban method, but are the kinds of organisational design principles that successful Kanban implementations seem to follow.

Would this change my values model? Not really. Leadership stays because it must. Self-organisation is a significant theme when I explain transparency; decentralised control slots fits both there and with leadership. Service-orientation fits with flow just as comfortably.

We’d be left with this:

  1. The foundational principles returned to their original three
  2. The six core practices as they currently are
  3. Three organisational design principles

We like?

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.

August 5, 2013

Economy and survival

Filed under: Uncategorized — Tags: — Mike @ 2:00 pm

Via Willam Zinsser’s On Writing Well (a real gem):

Economy and survival are the two key words in nature. Examined out of context, the neck of the giraffe seems uneconomically long, but it is economical in view of the fact that most of the giraffe’s food is high in the tree. Beauty as we understand it, and as we admire it in nature, is never arbitrary.
Moshe Safdie, Beyond Habitat

January 31, 2013

Agreement: it’s not about you

Filed under: Kanban,leadership,Uncategorized,Values — Tags: , , , , , — Mike @ 7:22 pm

Google this morning gives 62 hits on “agreement” for positiveincline.com. Admittedly that includes some dupes, but it’s definitely an itch I keep scratching. Most recently:

Agreement is right there in the second foundational principle, “Agree to pursue incremental, evolutionary change”. I like to turn this around: would you reasonably expect to be successful in implementing change without it? Could it be that it’s lack of agreement that’s limiting your progress? Or perhaps there is some agreement but it’s not deep enough – you’re agreed on the existence of a problem but not on its impact or causes (see understanding)?
Introducing Kanban through its values (January 2013)

On agreement, Greg Brougham brought to my attention Ackoff’s distinction between agreement in principle (a theoretical kind of agreement) and agreement in practice (an agreement to live with the consequences of a decision, accepting that agreement on “better” can be effective where consensus on perfection is impossible).
Kanban: values, understanding & purpose (January 2013)

Where in the assessment tool [is] 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”?
How deep is “How deep is your Kanban” (October 2012)

That last one needs some modification. 360-degree agreement is all very well, but it places me at the centre. What happens when I go away? How much agreement is left? If the agreement is about change, is that change really going to stick? David Anderson this week reminded me that change often fails to survive a generational change in leadership. That’s a sobering thought if you’re in the culture game.

I’m struck by the difference in coaching models aimed at getting to “what will you do now?” and other models (the Triad model [1] is a great example) that are more indirect but no less deliberate. Could it be that we invest too much in getting agreement from other people and too little in supporting agreement between people?

I’m pleased to report that I do see some very encouraging signs of the latter kind of agreement in my own consulting and coaching work. It takes time though! I wish I could give some recent concrete examples, but NDAs & such prevent. One day perhaps.

You may enjoy Jason Yip’s article We agree… but… meanwhile. I did!

[1] See The Culture Game – a book by Dan Mezick – Triads are described about half way through the article, and the book it describes is well worth a read.

December 15, 2009

Prettyprinter for Pylons routes

Filed under: Uncategorized,Web Integration — Tags: , , — Mike @ 7:27 pm

No, not described_routes, just something basic to plug a gap. For those suffering Rails-envy there’s no “paster routes” command, but it’s easy enough to use in the Paster shell:

bash-3.2$ paster shell test.ini
Pylons Interactive Shell
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)]

  All objects from encore.lib.base are available
  Additional Objects:
  mapper     -  Routes mapper object
  wsgiapp    -  This project's WSGI App instance
  app        -  paste.fixture wrapped around wsgiapp

>>> print mapper
Route name   Methods Path
                     /error/{action}
                     /error/{action}/{id}
home         GET     /
things       GET     /things
create_thing POST    /things
new_thing    GET     /things/new
thing        GET     /thing/{id}
...

It works by subclassing routes.Mapper (I have other reasons to do this which I’ll explain soon) and you’ll need to use this new Mapper in your config/routing.py.

That should be all you need to know. The code for the new Mapper class is below. Note: That second from last join() isn’t coming out very well – it has a backslash and an ‘n’ in it – honest!

Enjoy!

import routes.mapper

class Mapper(routes.Mapper):
    #
    # Pretty string representation - returns a string formatted like this:
    #
    #    Route name   Methods Path
    #                         /error/{action}
    #                         /error/{action}/{id}
    #    home         GET     /
    #    things       GET     /things
    #    create_thing POST    /things
    #    new_thing    GET     /things/new
    #    thing                  GET     /thing/{id}
    #
    #    etc
    #
    # Enter 'print mapper' in the paster shell to use it, or (TBD) run it via a
    # configured paster command.
    #
    def __str__(self):
        def format_methods(r):
            if r.conditions:
                method = r.conditions.get('method', '')
                return method if type(method) is str else ', '.join(method)
            else:
                return ''

        table = [('Route name', 'Methods', 'Path')] + [
            (
                r.name or '',
                format_methods(r),
                r.routepath or''
            )
            for r in self.matchlist]

        widths = [
            max(len(row[col]) for row in table)
            for col in range(len(table[0]))]

        return '
'.join(
            ' '.join(
                    row[col].ljust(widths[col])
                    for col in range(len(widths))
                ).rstrip()
            for row in table)
Older Posts »

Powered by WordPress