It’s 10 years since the post that changed my career

Happy New Year! For me it’s a big anniversary: this time in 2013 I had spent the New Year’s break taking the principles and practices of the Kanban Method, and from them abstracting a system of nine values. Then on January 3rd, I published Introducing Kanban through its values. Kanban’s values model was born.

Nine values are quite a lot to hold in one’s head at once, so I soon learned to present them in groups:

  • An initial six, or two groups of three: transparency, balance, and collaboration, then customer focus, flow, and leadership
  • Then understanding, agreement, and respect, which for reasons of brevity are often subsumed under leadership

In most of the decade since, it has been my most-read post each year. And it led to my first book, Kanban from the Inside (2014), which remains a Lean-Agile classic. Great! Now what?

I had no interest in making Kanban any more technical than it already was; if anything, the values model would always draw me in the opposite direction. Neither was I drawn to the emerging Kanban Maturity Model (or any other such model). What I did instead was to allow a common problem to bother me: why do so many people arrive at the training class not knowing why they are there? Tempting as it might have been to see that as a failure of administration or marketing, I saw it instead as a symptom that there were important organisational conversations that simply weren’t happening.

I realised quickly that this problem was far from unique to Kanban. To those that resent having had Scrum or (later) SAFe thrust upon them, the Agile manifesto’s “People and interactions over processes and tools” must ring rather hollow.

That took me away from Kanban into the realms of organisation, leadership, and strategy, to the development of Agendashift, and then sort of full circle, not back to Kanban and Lean-Agile specifically, but to business agility. Ten years on, as practice gets refined through use, as its message gets refined through the telling, and as we dig ever-deeper roots into the available theory, three main topic areas co-evolve together:

  1. As described now in two editions of the Agendashift book (2nd ed 2021), Agendashift the engagement model (thank you Daniel Mezick for describing Agendashift as such) and dialogic/generative organisation development approach (thank you Gervase Bushe & Bob Marshak), a way for practitioners to approach organisations without prejudging what solutions they will employ(/impose/inflict) and instead to help them have those missing conversations – engaging in participatory strategy, as it turns out
  2. The wholehearted organisation, a deliberately minimalistic values-based model of organisation and leadership, a spinoff from my third book, Right to Left: The digital leader’s guide to Lean and Agile (2019, audiobook 2020) that unexpectedly gained a life of its own
  3. The leadership development curriculum Leading with Outcomes, which compared to Agendashift minimises detail relevant mainly to practitioners, and instead distils some easily-learned patterns, strategies, and organisational models relevant to leaders at all levels, leaders in transforming organisations most especially

Explicitly in both Agendashift and Leading with Outcomes and implicitly in wholehearted, we have doubled down on the eighth value of that initial nine-value model, namely agreement. What if we put agreement on outcomes before solutions? One way or another, I’ve been asking that question for most of the past ten years, and I have no doubt that it will keep me going for a good while yet.

I no longer identify as a Kanban guy. That separation was necessary to what followed, but all these years later I remain proud of the work I did there, of that first book, and of the blog post that started it all. Not that I’m planning on retiring anytime soon, but I have long seen it as marking the beginning of the rest of my career.

[Comment on this post on LinkedIn]

Related:


Agendashift™: Serving the transforming organisation
Links: Home | Subscribe | Events | Media | Contact | Mike

Agendashift  Academy: Leading with Outcomes | Facilitator and Trainer Programmes

We help leaders and engaged team members at every level to gain fluency in the language of outcomes – developing and pursuing strategies together, innovating, learning, and adapting as the organisation renews and transforms itself from the inside.

Upcoming events

With me (Mike Burrows) unless otherwise indicated

*For the June events indicated with an asterisk, see Three days in sunny June, London – and note the recent date change!

On values, meaningfulness, and change – parallels with Bateson and Mead

Punchline first:

In the methods & frameworks world, I believe there is only one fight worth fighting, and it is not between frameworks. It is between those who would fit people and organisations to frameworks (branded or otherwise), and those who find that idea intolerable.

From a book I am taking the time to savour, here is acclaimed anthropologist and systems thinker Gregory Bateson, on the work of his former wife Dr Margaret Mead, another acclaimed anthropologist:

[If] we go on defining ends as separate from means and apply the social sciences as crudely instrumental means, using the recipes of science to manipulate people, we shall arrive at a totalitarian rather than a democratic system of life. The solution she offers is that we look for the “direction” and “values” implicit in the means, rather than looking ahead to a blueprinted goal and thinking of this goal as justifying or not justifying manipulated means. We have to find the value of a planned act implicit in and simultaneous with the act itself, not separate from it in the sense that the act would derive its value or from reference to a future end or goal.

Gregory Bateson, Steps to an Ecology of Mind (1972)

This passage resonated strongly with me. Translating from the social space to organisations, how, as leaders, do we make it easy for people to find meaning in work whilst still respecting their choice in the matter? And if it’s the job of leadership to take people to new places, can we make the process of change more meaningful, again without dictating what form that meaning should take for each individual concerned?

My biggest contribution in the frameworks space was a values model for the Kanban Method (2013). It explained why and how Kanban was meaningful to me, and it turned out to be helpful to other people too – to the extent that it become adopted as part of the method’s formal definition.

But I didn’t stop there. I was on a journey, and it wasn’t long after the publication of Kanban from the Inside (2014), that I found myself detaching myself from Kanban community. There was no big disagreement behind this move, and to be clear, I remain proud of that model and my first book. It was simply that there was a job to be done, and I felt that it would be easier done outside.

Bateson goes on:

This then is the type of discipline which has enabled Dr Mead to point out that a discrepancy – a basic and fundamental discrepancy – exists between “social engineering”, manipulating people in order to achieve a planned blueprint society, and the ideals of democracy, the “supreme worth and moral responsibility of the individual human person.” The two conflicting motifs have long been implicit in our culture, science has had instrumental leanings since before the Industrial Revolution, and emphasis on upon individual worth and responsibility is even older. The threat of conflict between the two motifs has only come recently, with increasing consciousness of, and emphasis upon, the democratic motif and simultaneous spread of the instrumental motif. … Are we to reserve the techniques and the right to manipulate people as the privilege of a few planning, goal-oriented, and power-hungry individuals, to whom the instrumentality of science makes a natural appeal? Now that we have the techniques, are we, in cold blood, going to treat people as things? Or what are we going to do with these techniques?

Again, parallels. In the methods & frameworks world, I believe there is only one fight worth fighting, and it is not between the frameworks. It is between those who would fit people and organisations to frameworks (branded or otherwise), and those who find that idea intolerable.

I am on that second side. My fight is against those so convinced of their rightness that they’re sure that the ends justify the manipulative or coercive means, or they lack the imagination, curiosity, or courage to consider that there might be alternative approaches to change. And there really are alternatives. Let no one tell you that change-by-imposition – legitimised the change management industry despite its repeated failures – is the only model. That wasn’t true even 20 years ago – Agilists take note – and it definitely isn’t true now.

That fight is what has energised me in the 8 years since my first book and I expect it to continue to sustain me for the rest of my career. It has taken me from method to values and then to outcomes, meaningfulness, wholeheartedness, leadership, and strategy. They’re integrated into a participatory approach to change and transformation, one that is more than capable of reconciling sophisticated thoughts on organisation design with utmost respect not only for the person but for the organisation that people create together.

It’s hard enough being a leader in a transforming organisation without your approach to change making things worse. If that could be you, check out the Agendashift Academy’s Leading with Outcomes self-paced training programme. And if your organisation is entering into a relationship with a process framework, make sure that the relationship is healthy one*.

*That’s my recent article on InfoQ: Adaptability by Agreement: Valuing Outcomes over Imposed Solutions. It’s the most complete written treatment yet of Agendashift’s three strategies model. Watch out for videos too, in particular from last week’s Lean Agile London (#LALDN22).


What if we put agreement on outcomes ahead of solutions?

Agendashift™: Serving the transforming organisation
Agendashift  Academy: Leading with Outcomes | Home | Store
Links: HomeSubscribe |
Become an Agendashift partner | Events | Contact | Mike
Resources: Tools & Materials | Media | BooksAssessments 
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

A postscript to ‘How I Choose my Models’

With a view to referencing it in the Agendashift 2nd edition I’ve been checking out the new Cynefin book Cynefin – Weaving Sense-Making into the Fabric of Our World (Dave Snowden & friends). It’s a book with many contributors and I wasn’t 100% sure what to expect but I’m enjoying it! If you have any interest in Cynefin I would definitely recommend it.

Despite appearances, this post isn’t about Cynefin. One contribution by Anne Caspari and Johann Entz von Zerssen really resonated with me, especially these two paragraphs from Anne (quoted with her permission):

I (Anne) come from 15 years of critical engagement with integral theory, adult development, and all kinds of change theories. When I started working with these theories and frameworks, they helped me immensely. They opened up my thinking and gave me a means to counteract both gross and subtle reductionism in practical work. This was especially helpful to me in my project management work in environmental planning and sustainability contexts. Adult development theory also helped me understand some of the phenomena I encountered in coaching and leadership work.

Over time, however, I experienced a growing scepticism around a new kind of reductionism that crept into most applications of these theories that often went unobserved by the respective communities. Examples include developmental bias (“we need to develop people”) in large parts of the integral theory scene and some very formulaic and linear applications of change theories (“step 5: find deeper meaning and purpose”).  Since this kind of uneasiness is hard to pinpoint and address, I just noticed that I kept away. I settled at the fringes of these communities and did my own thing. 

Yes! This! Exactly!

Anne’s struggle is the same as the one that triggered (via an outburst over Zoom of which I am not proud) the How I choose my models post. And the really funny thing: Andrea Chiou, the target of my outburst agrees with me. Violent agreement is a strange beast! From our Slack channel #what-i-am-reading (I pasted the above quote there as soon as I read it):

It is the ‘we need to’ of the ‘we need to develop people’ that annoys me. It separates ‘us’ from them -> increasing the gap between the ‘experts’ and the underdeveloped others.

And yes, you are doing your own thing.

It has been in fact a very interesting few weeks, one of those times when you’re really glad to be part of a diverse and supportive community with knowledge in areas I’ll never be expert in. My gut instinct hasn’t changed, I stand by every every word I wrote in How I choose my models, and yet I’ll be referencing some of that developmental stuff (caveated of course) in the 2nd edition.

The title of a new 6th and final chapter, Up and down the Deliberately Adaptive Organisation, is inspired by Robert Kegan & Lisa Lahey Laskow’s Deliberately Developmental Organisation (DDO), a model described in their interesting but slightly scary book An Everyone Culture. The surprise (not least to me) is that the DDO model comes from the same stable as Adult Development Theory, my “trigger”! I’m grateful to Jonathan Sibley for pointing me in that interesting direction, also to Teddy Zetterlund for some earlier seed-sowing.

I’ve learned that living by these three bullets of mine is harder than I thought:

  • Models that have withstood scrutiny over a length of time
  • Models that treat the individual’s agency, creativity, and problem-solving ability with the utmost respect
  • Models that help to scale up the preceding

If I’m not going to ignore a ton of potentially valuable and relevant work, there’ll be times when I will need to remind myself that the model, my reaction to it, and the reactions I observe in others or fear from them, are different things. What helps to win me – albeit cautiously – over to DDO is that this is part of the model itself. Not in an especially self-aware way methinks, but it’s a start.

A last word to Jonathan, which I apply first to myself:

A great challenge is to build a model and then hold it lightly. And sometimes, followers hold the model more tightly than the founder does!


Upcoming workshops

All the usual discounts apply: repeat visits (not uncommon), partners, gov, edu, non-profit, country, un- or under-employment, bulk orders. If you think that one might apply to you, do please ask.


Agendashift™, the wholehearted engagement model
Links: Home |
About | Our mission: Wholehearted | Become an Agendashift partner | Assessments | Books | Resources | Media | Events | Contact | MikeSubscribe
Workshops: Transformation strategy | Outside-in strategy | Short training
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

How I choose my models

As demonstrated by the models-sources-inspirations picture below, I like my models. If you’ve read my third book Right to Left, you’ll know also that I have little time for the idea that there is one best model – one best Agile framework, for example. And the fun isn’t in choosing between them, not even in recognising what each of them can bring, but in integrating them. And it doesn’t stop there: this is not a one-shot process design exercise, but a process of continuous transformation. In short, I’m a pluralist, and I love to see what happens when models and their underlying patterns are allowed to combine.

agendashift-inspiration-map-2020-06-29

Believe it or not, I am a picky though. In one of our weekly community Zoom sessions (see #community in Slack), that pickiness resulted in a conversation that was outside our usual norms (if the truth be told I was abrupt to the point of rudeness) and I reflected afterwards on what happened. Happily, we cleared things up quickly and had a much healthier conversation the following week after I had the chance to turn something heartfelt into something more articulate. What follows is a summary.

If Agendashift has taught me anything, it is to be very careful with assumptions. Credit for this goes to Clean Language, which turns the dial up to 11 on the discipline of its practitioners to minimise the influence of their private assumptions (which are SO not the point) on their conversations. This discipline applies most to their explicitly Clean conversations but it rubs off elsewhere in ways that need not mean “coachiness” when that is not called for. Practicing it subtly trains your brain to recognise when you are imposing yourself in ways that aren’t helpful.

You see that attention to assumptions in Agendashift’s outside-in strategy review. The way we make explicit its carefully minimal assumptions is of great help to the facilitator. See my recent Cutter paper for details (announcement included in my post last week); they’re also in Right to Left (chapter 5) and there will be brief coverage in the forthcoming 2nd edition of Agendashift also.

I tend to avoid models that encourage me to make assumptions about what is going in someone’s mind, how they will behave, how they will develop, and so on. The same at team level and organisation level, and I have come to be particularly sceptical of extrapolations from one of those levels to another. The replication crisis (en.wikipedia.org) gives me pause also.  For better or for worse therefore, you won’t see Agendashift depending on many “popular” models of psychology, development, or maturity. This is not to say that they are valueless, rather that they make potentially unreliable foundations.

What I do appreciate:

  • Challenges to my own assumptions
  • Ways to moderate the impact of unsafe assumptions
  • Ways to bring assumptions and misalignments to the surface at the right time
  • Ways to encourage people to find their own solutions in the pursuit of outcomes (authentically shared outcomes most especially)
  • Ways to sustain all of the above – engines of transformation

And supporting those:

  • Models that have withstood scrutiny over a length of time
  • Models that treat the individual’s agency, creativity, and problem-solving ability with the utmost respect (you’ll permit me some personal values and base assumptions there I trust)
  • Models that help to scale up the preceding

Thankfully, the list of helpful and reliable models compatible with my outlook of optimistic pluralism outlook is long, a fact to which my Models, Source, and Inspirations picture attests. And please do not take the omission of a favourite model of yours as a snub; if I don’t have time to throw yours into the Great Model Collider™ in the hope that something interesting will fly out, perhaps you (or someone else) will.

Opinions mine, strongly held it would seem. Thank you Andrea Chiou and Tom Ayerst for putting up with me – we got there in the end 🙂


What if we put agreement on outcomes ahead of solutions?

Agendashift™: Serving the transforming organisation
Agendashift  Academy: Leading with OutcomesHome | Store

Links: Home | Subscribe | Become an Agendashift partner Events | Contact | Mike
Resources: Tools & Materials | Media | Books | Assessments
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

From Reverse STATIK to a ‘Pathway’ for continuous transformation

It seems that my 2014 post Reinvigorating an existing Kanban implementation with STATIK is now gone. It is very likely the first mention of Reverse STATIK, and fortunately web.archive.org has saved it here, but 5 years on let me take the opportunity to revisit it.

We start with STATIK, the catchy acronym I coined for David J. Anderson’s Systems Thinking Approach To Introducing Kanban, which is quite a mouthful. STATIK looks like this (or at least it did in 2014):

  1. Understand sources of dissatisfaction
  2. Analyze demand and capability
  3. Model the knowledge discovery process
  4. Discover classes of service
  5. Design kanban systems
  6. Roll out

You may recognise those steps as the chapters of Part III of my first book Kanban from the Inside (hereafter referred to as KFTI); otherwise it was day 2 of the standard 2-day Kanban training. I don’t do much Kanban training these days (I don’t advertise it and for reasons of strategy rather than any falling out I’m no longer affiliated with the certification body), but when I do, I don’t use STATIK.

My main issues with STATIK aren’t the individual steps (there’s value in them all), but these:

  1. Even avoiding the middlebrow dismissal of “It’s too linear” (often thrown around rather unfairly), it’s much more likely to be understood and used as a discrete intervention (albeit a participatory one if it’s done the right way), not as a model for a continuous process.
  2. Even if I grant that you could in theory bail out of the process at any stage, it does rather assume that Kanban is the answer, so if we are to avoid the accusation of being solution-driven, something else has to come before it.

Aside (further to that second point, a bit of detail that doesn’t invalidate it): KFTI describes a step 0, ‘Understand the purpose of the system’, a phrase I borrowed (with full credit) from Goldratt’s Theory of Constraints (TOC). That has morphed into ‘Understand fitness for purpose’ (for the service you are applying STATIK to). This is OK as far as it goes, but the faster it turns (as seems to be its intent) into a conversation about metrics, the less time anyone spends actually exploring purpose. If I’m honest, this part leaves me a little cold, though in the interests of balance, it should be pointed out that Kanban still does far more than any other framework I know to encourage its introduction in ways consistent with its principles. If only the others were as careful; if they were, perhaps Agendashift would never have been so necessary!

My original idea with Reverse STATIK was to retrace one’s steps, working backwards through the STATIK process looking for improvement opportunities. Today, I see it as more than that, and find it useful in two ways, both of which may seem surprising:

  1. Reverse STATIK turns out to be a great way to introduce/teach Kanban too. You can start with the simplest to-do/doing/done kanban board design (not yet a WIP-limited kanban system) and at each step introduce multiple options for improving not just its detailed design, but much of the surrounding organisation design that makes it work. No longer a one-shot intervention, but a rich model for improvement
  2. You can strip out all the kanban-specific techniques, replace them with their corresponding outcomes (outcomes that might be achieved in myriad other ways), and revise for breadth of coverage. A few iterations later (much of it done in collaboration with Dragan Jojic) we arrived at the genuinely framework-agnostic assessment that in the early days was Agendashift’s most important tool (it’s still important today but there are newer parts that are more exciting).

Aside: I glossed over one important detail there: In most people’s first experience of the assessment tool, its ‘prompts’ are organised under headings of Transparency, Balance, Leadership, Customer Focus, Flow, and Leadership. These 6 values are the titles of KFTI’s first 6 chapters; moreover Leadership incorporates Understanding, Agreement, and Respect, the so-called ‘leadership disciplines’ of chapters 7, 8, and 9.  I make no apologies for retaining these; most people would recognise these values as having relevance in any Lean-Agile context.

Fast forward to 2019, Reverse STATIK (mostly under the framework-neutral name of ‘Pathway’) looks like this:

  1. Refine existing systems
  2. Improve the service experience
  3. Manage the knowledge discovery process
  4. Balance demand and capability
  5. Address sources of dissatisfaction and other motivations for change
  6. Pursue fitness for purpose

These headings appear in my aforementioned teaching materials, as an option in the assessment tool, and the spine of the ‘Pathway map’, a visualisation inspired by User Story Mapping (see chapter 3 of the Agendashift book, which also introduces the Reverse STATIK model).

Instead of (and I say this tongue-in-cheek) doing a bunch of analysis exercises before (tada!) a kanban system is designed, an improvement process that identifies opportunities at a wide range of challenge and sophistication, with kanban or without. The spine starts small, grows in sophistication, and ends on high with purpose, leadership behaviours, and other similarly challenging, bigger-picture issues of organisation design; what detail gets prioritised under whatever heading at any given time is a matter for participatory decision making.

Relentless commitments to 1) participation and 2) agreement on outcomes as the basis for change are what took me from Reverse STATIK to Agendashift. The former wasn’t quite the 21st century engagement model I was striving for but a decent first attempt, and it lives on, even if quite well hidden.

pathway-mappingRelated:


What if we put agreement on outcomes ahead of solutions?

Agendashift™: Serving the transforming organisation
Agendashift  Academy: Leading with OutcomesHome | Store

Links: Home | Subscribe | Become an Agendashift partner Events | Contact | Mike
Resources: Tools & Materials | Media | Books | Assessments
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

A question among the good luck emails

There’s a contact button on the landing page for Right to Left, and through it I got this question which I have permission to reproduce:

Keep up the good work, and btw how do you use the Kanban Method these days, after your current progression?

My reply (verbatim):

In Right to Left you’ll see Kanban as just one of a set of complementary patterns in the Lean-Agile space (none of them more important than the others), and a more general approach to organisation development and the leadership that goes with that.

In my own work, Kanban is still in the mix but I’m very definitely needs & outcomes first, not solutions/framework first. STATIK tries to do a bit of that* but it does rather presuppose the answer! I prefer Reverse STATIK anyway, and my very occasional Kanban training uses that. The principles and practices are abstracted in the values, and they live on through the Agendashift delivery assessment (a conversation-starter, not a checklist of practices).

*To be fair, it does this quite valiantly and self-consistently compared with peer frameworks, but my comment stands.

And a PS, sent moments later:

One thing to add: this is not to diminish anyone’s work on Kanban (my own included) or any other framework. Testing boundaries is learning. But it’s also healthy to draw back a bit and broaden one’s horizons from time to time. And integration is also learning.

Some links to help with decoding the above (I knew my correspondent to be familiar with most of them):


Autumn workshops
– Stockholm, Athens, London, Istanbul, Berlin, and online

Leading change in the 21st century? You need a 21st century engagement model:

Blog: Monthly roundups | Classic posts
Links: Home | Partners | Books |Resources | Events | Contact | Mike
Community: Slack | LinkedIn group | Twitter

A Grand Unification Theory for Lean-Agile?

The job of chapter 3 of the forthcoming book Right to Left: The digital leader’s guide to Lean and Agile is to introduce a number of important Agile, Lean-Agile, and associated frameworks. I have taken care to describe them not as alternative solutions that must be chosen between, but as patterns to be combined in interesting ways. That’s not a new idea, but what does seem remarkable is how helpful a right-to-left perspective is in explaining how they work together and complement each other. When I say right-to-left, we’re talking not just collaborative, continuous, pull-based, and so on (concepts conventionally associated with Lean-Agile) but something very explicitly outcome-oriented.

Almost verbatim from the manuscript:

  1. Scrum (and Scrum-based scaling frameworks, if that’s your bag): continuously iterating on and self-organising around goals (short term outcomes) in the pursuit of longer term outcomes – product vision, the team’s mission, broader organisational objectives, and so on
  2. Kanban, making progress on outcomes visible, concentrating effort on the ones that matter most, fostering a focus on completion
  3. XP and DevOps, right across development and production, providing the infrastructure of process, practice, and technology necessary to accelerate feedback on the delivery of outcomes
  4. Service Design Thinking (along with user research, user experience and so on), continuously discovering which outcomes are important
  5. Lean Startup, pursuing business viability through continuous deliberate experimentation, managing for impact (outcomes again), finding and continuously refining a business model that enables customer outcomes to be sustained

Here it really is outcomes that holds everything together, not (as you might expect) flow, collaboration, or some other shared value or technical principle. This way, we avoid saying “if you dig deep enough, they’re the same” (which I hear from time to time and strongly reject, believing that it does each framework’s creators and communities a huge disservice).

Neither are we saying “don’t use frameworks”, if (and it’s quite a big if) this means that you must always start from first principles. A sensible way to start is again outcome-oriented and has a measured and pragmatic attitude towards frameworks (quoting this time from chapter 4, Viable scaling):

  • Identify needs – looking at what kind of organisation you’re trying to be and at what you’re trying to achieve  – and the obstacles that currently prevent those needs from being met
  • Agree on outcomes, not just goals plucked out of the air, but the kind of outcomes that might be achieved when these obstacles are removed, overcome, or bypassed
  • On a just-in-time basis, prioritise outcomes and generate a range of options to realise them, using your favourite frameworks as sources of ideas (not excluding other sources, but valuing coherence nevertheless)
  • In manageably small chunks of change and through a combination of direct action and experimentation (choosing between those approaches on a case-by-case basis according to the level of uncertainty and risk involved), begin to treat change as real work: tracking it, validating its impact, and reflecting on it just as we would for product work

In a nutshell, I’ve described Agendashift, which is of course a right-to-left approach to change and transformation. Other engagement models exist – see OpenSpace Agility (OSA) for another excellent, well-documented, and highly complementary example. Whichever approach you choose, take care to choose one that models Lean and Agile values, lest the dissonance proves too great and you fatally undermine your work, a very real risk. To sow disengagement would be a truly bad outcome!

Related:


Subscribe here for monthly roundups and very occasional mid-month announcements

Upcoming public Agendashift workshops (India*2, US*2, UK, Netherlands):

Also: Channel #agendashift-studio in the Agendashift Slack if interested in a cozy workshop with me at Agendashift HQ (Derbyshire, England).


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

 

Stand up meeting, thinking tool, leadership routine

[Originally posted on positiveincline.com September 16 2013, restored to blog.agendashift.com February 13, 2018. Links are to web.archive.org.]

My last post was on the provocative side; to restore this blog’s usual balance, here are some antidotes to some of the problems I described. These are ways to use your kanban board to help you look at your process from the perspectives of customer focus and flow, two values from that middle direction layer [2018: the other one being leadership].

Imagine you’re facilitating a stand-up meeting in front of your board. If you have a physical board, you’re probably heading (in your mind at least) towards the board’s right hand side so that you can stand looking left across the board. If you use an electronic kanban tool, you can achieve a similar effect by turning your laptop or monitor monitor to the left a bit (ok, I’m kidding).

Now scan the board from right to left (in other words working your way backwards from the end of your process towards the start) and ask these questions of the columns:

Customer focus

  • Whose needs are explored in this stage of the process, and how? Whose aren’t, and what risks does that pose?
  • What do we learn in this stage that we don’t (or can’t) know earlier? In what ways do the activities of this stage help us anticipate what will be needed?
  • What is still to be learned? Are outstanding uncertainties best dealt with by pressing on or by going back?

Flow

  • How do work items leave this stage in the process? By what criteria do we know that they’re ready? How are those criteria expressed? How is the state change communicated?
  • Typically, how much time do work items spend in this stage? How much (if any) of that time is spent in active work?
  • What are the most significant sources of unpredictability? In the work in or the waiting? Waiting for internal availability or for external dependencies to be resolved?
  • How much of this stage’s capacity is absorbed in rework? Or in failure demand, which arrives only because previous work failed to meet customer needs adequately?
  • How do work items arrive into this stage? How do we know that they’re ready to be worked on?

You may find it helpful to ask some of these questions of individual work items too.

What we’ve done is to turn a popular protocol for standup meetings into a thinking tool. You can try it with other values, for example transparency (is it sufficiently clear what’s going on here?) or balance (are we overburdened here?), or some other concern that seems relevant.

Caution: questions like these already assume the following:

  1. That the process has sensible objectives (to deliver the right kind of things)
  2. That the work flow is scoped sensibly (starts with the right kind of questions, finishes with the right kind of result)
  3. That the work flow is organized sensibly (sequenced to generate high value learning as quickly as possible)

I’ve encountered plenty of processes where these assumptions are open to challenge. For example:

  • A change management process whose objective was the approval or rejection of design changes, disconnected from any actual implementation process. Needless to say, any customer satisfaction delivered out of that process was somewhat short lived.
  • My bank’s account opening process. A frustrating process and several weeks later and I still don’t have online banking, let alone two additional products that I would be willing to pay for. I sense an institutionalised lack of curiosity into my needs and what might be in the way of delivering on them.

Some acknowledgements are in order:

  • The first set of questions questions are heavily influenced by Michael Kennedy and the model of the Knowledge Discovery Process. That’s a Lean product development model, but I find that many processes are usefully understood in those terms.
  • The “whose needs?” questions (the first bullet) point to the very important question: “who holds a veto on delivery?”. This is one of many good customer focus takeaways from Lean Software Strategies by Peter Middleton and my friend Jim Sutton.
  • The idea of understanding a process by walking through it backwards is an old Lean trick. I don’t know for sure how it was discovered and popularised, but Steven Spear describes very well its use as a leadership routine inside Toyota in his book The High-Velocity Edge.
  • Failure Demand is a concept I associate (in the nicest possible way) with John Seddon.

These are all great ideas. Combining them with visual management and practised routine makes them (as well as the values) accessible and actionable, don’t you think?

Introducing Kanban through its values

Update: First published several years ago today on January 3rd 2013, this post is reproduced from my now defunct personal blog positiveincline.com. It was a career-changing moment – the start of a journey from practice-based methods to the outcome-oriented approach we see now in Agendashift. The values-based stance of this post was a crucial first step. My first book Kanban from the Inside soon followed, and years later the model continues to enjoy two parallel lives, one as a first-class component of the Kanban Method, the other outside of Kanban as the structure of the Agendashift Delivery Assessment (as described in the book Agendashift: Outcome-oriented change and continuous transformation and as used in the inside-out strategy module of the Agendashift Academy‘s self-paced training programme, Leading with Outcomes).

valueswordle

[Translations: German, French]

Introductions to the Kanban method tend to start with a description of the kanban card wall (a tool) and lead on to a description of its core practices. If you’re lucky, you’ll get to hear about Kanban’s foundational principles too.

Here, I’m attempting a different approach, one that gives equal weight both to the principles (which I believe should come first – they’re not called “foundational” for nothing) and the core practices by identifying the values that underpin them. In doing so we’ll cover most of the main elements of the method, so perhaps this works as a teaching framework too?

Regardless, the result is holistic (the values are widely applicable at multiple levels), remains true to Kanban’s purpose of driving evolutionary organisational change, and helps to address three misconceptions:

i.         that Kanban is somehow a software development process

ii.         that Kanban doesn’t have at its heart the kind of values that will both challenge an organization and guide its agents of change, and

iii.         that Kanban is only for number-crunching tool-heads in control-driven organisations (I exaggerate this last misconception only slightly)

Moreover, I hope to demonstrate also that a values-based description is useful for other, more constructive reasons.

My starting point

From Kanban’s Foundational Principles in their usual sequence I identify four values: understandingagreement,  respect and leadership. The first of these requires a little justification but the other three can be read directly into the principles as they are typically worded.

The values behind Kanban’s six Core Practices are a little trickier, not because the they aren’t there but because the correspondence isn’t exactly one-to-one. I chose another four (that’s eight so far): transparencybalanceflow and collaboration. However, I found it helpful to depart from the this obvious sequence and was compelled to add an additional one – customer focus – making nine in total.

As I expand on each of these we’ll uncover a few more candidates for inclusion – I’ll highlight in bold anything that looks like a value (abstract nouns, basically). These however are less important, less axiomatic, less “core”.

Nine core values of Kanban

1.    Understanding

Understanding is one of the less obvious values of Kanban. I read it into the first foundational principle,  “Start with what you do now”. Understand the thing you’re changing, whether it’s the nitty-gritty details of a process, the way a process performs under conditions of stress, or something as abstract as your organisation’s overall approach to change.

Insist on understanding because a healthy process that can’t defend itself is a sign that you’ve forgotten what you believe.
The Process Myth, Rands in Repose

In our Kanban training we teach a Systems Thinking approach that places understanding very high on our list of priorities. It’s right there in our early introductions to the method, the basis of the very first class exercise. Where does work come from? What characterizes different kinds of work? What approaches to the problems of change and improvement tend to succeed or fail, both generally and in your organisation specifically? Why might that be?

By definition, the absence of understanding is what characterises cargo cult implementations. Even with good intentions there’s a likelihood that understanding will be lost when change is driven top-down, justified weakly (over-relying on appeals to best practice for example) and passed unthinkingly between organisational layers.  It’s no small surprise therefore that change projects have a tendency to disappoint. Unfortunately for the lazy or unskilled manager, understanding and its allied values of learning and alignment take effort.

2.    Agreement

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)?

This principle might seem to suggest another value, that of incrementalism. I would however shy away from describing this this as a core value, for the reason that we promote incremental, evolutionary change because it has a high chance of success, not because its alternatives in radicalism or conservatism are never better alternatives. And if pragmatism is a value, it is a rather slippery one.

3.    Respect

Respect for people” is a pillar of Lean. Kanban applies this to the problem of organisational change in its third principle, “Initially, respect current roles, responsibilities & job titles”.

As in life, respect is a good guide when implementing change. Will it increase your chances of success if you start by implying that people are doing a bad job, or their roles are worthless? Probably not. Is it helpful to assume bad motives? Again, probably not. But does respect just mean “be nice”? Again no:

Showing respect for people does not mean you have to like them, agree with their views, and fail to challenge any half baked reasoning.
Stephen Parry

That kind of respect takes courage, taking us to our next value.

4.    Leadership

Leadership features in most stories of success but it was only in 2012 that it was added as a foundational principle, in the form “Encourage acts of leadership at all levels in your organization – from individual contributor to senior management”.

Much has been written on leadership and I won’t add to it here except to make a few quick observations:

i.         You might wish for an autocrat – a Steve Jobs (or a Steve Ballmer) perhaps – but the “at every level” kind of leadership is something different.

ii.         Not only is leadership something to value, management isn’t inherently something to despise either (remember respect?).

iii.         Furthermore, neither leadership nor management precludes self organisation, where individuals, teams and systems have the capacity to adapt without central or senior direction. Rather, good leadership and good management create the conditions in which self organisation thrives.

iv.         Good leadership involves challenge (we’ve used this word already). As agents of change we must be prepared both to challenge and to be challenged.

5.    Flow

Turning to the practices, we start with the third one, “Manage flow”.

The management part of this practice speaks of tactical organisation and decision-making aimed at progressing work for optimal outcomes (effectiveness). At some level – though with widely varying degrees of success – this is universal.

Flow adds something much less common, a sense of smoothness and predictability; addressing impediments to these systematically is a powerful improvement approach, exemplified in Lean.

We also value flow in Csikszentmihalyi’s sense, that very positive state of complete absorption in what we’re doing. This kind of flow is hard to find when distraction, interruption and constantly changing priorities dominate the work environment.

6.    Customer Focus

We haven’t finished with “Manage flow” yet! An expanded version of this practice might read something like

Manage to timely completion the smooth flow of customer-recognised value over a range of timescales

Value is meant in the sense of purpose (understanding the customer’s “why”) as much as in any monetary sense (taking care not to confuse utility with mere cost). A customer-focussed concern for completion means going beyond an activity-centric “task complete” or a product-centric “potentially shippable product”. In my experience, this is a surprisingly challenging concept whose impact can be dramatic.

Work done but not yet benefiting the customer is just sunk cost. We’ll return to this issue and address the “over a range of timescales” phrase when we look at the value of balance.

7.    Transparency

Transparency underpins three of Kanban’s core practices: the first, “Visualise [work]”, the fourth, “Make policies explicit”, and the fifth (another 2012 addition), “Implement feedback loops”.

Kanban creates transparency at multiple levels:

i.         In making work visible

ii.         In making visible the workflows that work items go through and the states that actual work items occupy at any given time

iii.         In making visible the parameters, policies and constraints that guide decision-making and ultimately drive the overall performance of the system

iv.         In making visible the impact of all the above in customer-focussed measures of performance

The first two types of visibility flow naturally from the kanban systems after which the Kanban method is named. The first three together create leverage points – points in our systems at which significant change can be effected for relatively little cost or effort. The fourth (a feedback loop) tells us that change is taking us in the right direction.

Kanban then is a way to evolve systems that learn and adapt, a strategy for organisations to find greater fitness relative to the competitive ecosystems they inhabit.

8.    Balance

The second core practice is “Limit work-in-progress (WIP)”. Limiting WIP across a process has multiple benefits:

  • Thanks to Little’s law, lead times (and therefore feedback cycles) tend to shorten; the customer is satisfied sooner and learning accelerates.
  • Work gets started only when capacity becomes available. This creates flow from the work item’s perspective and keeps supply and demand in balance from the team or worker’s perspective (respect!).
  • With just a little extra sophistication we can easily find balance between different kinds of operational work and between operational work and improvement work.

This last point suggests another principle, “Embrace variety”. Systems that behave well in the face of variety can be described as having a resilience that is good for customer, organization and worker alike, another example of balance. Kanban’s help in evolving resilient systems that can deliver predictability for a variety of work item types with a range of performance expectations (timescales perhaps ranging from hours or days to months or more) really is a killer feature.

For more on the role of balance in Kanban see David Anderson’s talk When is Kanban not appropriate [video] [slides]. My talk Kanban the hard way [video] [slides] includes an exploration of variety and resilience.

9.    Collaboration

Collaboration features in the sixth (and last) core practice, “Improve collaboratively, evolve experimentally [using models [and the scientific method]]”.

Building on agreementrespect and customer focuscollaboration creates the expectation that we will look beyond our own team’s boundaries in addressing impediments to flow.

The full version of this practice (with the two optional parts included) speaks of working systematically in a way that improves understanding through observation, model-building, experimentation and measurement (empiricism).

Using models” has a second sense that suggests values of curiosity and even generosity. Kanban actively encourages its practitioners to look outside the method to a growing body of knowledge. Kanban acknowledges roots in Lean, Theory of Constraints and Agile, foundations in queuing theory and complexity science, influences as diverse as Lean Startup and family therapy. Individual practitioners have their own personal favourite models – I for example draw on A3, GROW, and Influencer.

Why stop at nine?

It bothered me that the Lean value of customer focus can’t be inferred in any obvious way from the standard wordings of Kanban’s foundational principles and core practices – you could say that I had to cheat! I think though it fully deserves its place.

Less so these others that I’ve identified:

  • Learning and alignment have strong associations with understanding. I fully recognise that a strong case can be made for each of these but I’ve gone with the one that I think best reflects Kanban’s roots in System Thinking. My most-referenced article emphasises learning, so this was a tough one!
  • Challenge (also vision) and courage overlap sufficiently with leadership that I don’t regard them as axiomatic. See related post Dole out the 3C’s.
  • Self organisation would rank high as an organisational design value but respect seems to be an adequate guide for the change agent. All else being equal, respect would prefer a solution allowing or building on self organisation over one that doesn’t.
  • Resilience features strongly in my thinking but it describes outcome more than approach. Smoothness and predictability similarly.

Putting values to work

Let’s see our nine values together then:

Understanding, Agreement, Respect,
Leadership, Flow, Customer Focus,
Transparency, Balance, Collaboration

Admittedly, that’s quite a long list – longer than the initial three or four that I have quoted at every opportunity for some time – but not so long that we’re incapable of debating, remembering and referring to them.

Do any of these resonate with you more strongly than others?  What does that say to you?  I might explore that one at a leadership retreat – the differences between practitioners might be revealing!

Do any seem to be missing in your current environment? Again, what does that say to you? Does that suggest to you some things that really need to be put right?

For example, I can look back at times where lack of the right kind of agreement either slowed the pace of change or resulted in change that could revert too easily. From what I read, I don’t believe I’m unique in this.

Reflection

I’ve made values explicit – this is transparency at work – creating an opportunity for challenge (namely that I want to see customer focus feature more explicitly in the core method), and increasing my understanding of at least one source of ineffectiveness. In an eat-your-own-dog-food kind of way, the system works! I like that.

Whether you or the wider community would choose the same values is an interesting question worthy of group exploration. How else might you go about it? I’d love to see some alternative attempts. Could the values I’ve chosen benefit from some additional structure or from being sequenced differently? Or are values so fragile that they’re better left unsaid?

Continuing a line of thought started a couple of months ago in my post How Deep is “How Deep is Your Kanban”, could values provide a better foundation for a second-generation Kanban assessment tool? Does the current tool’s emphasis on practices hide the method’s true purpose? I really think that it might.

As to whether this is a good way to introduce Kanban, this can only be answered by testing it. I intend to!

[Update: I’ve written some stronger conclusions in a followup post, Values, understanding & purpose]

20 Comments

  1. […] […]Pingback by Sticky notes do not make Kanban | scalable ravings — January 4, 2013 @ 12:31 am
  2. Very good article with which I completely agree. I’m so glad to read an article that does not describe Kanban with sticky notes and a card wall 😉Comment by Matthias Jouan — January 4, 2013 @ 12:37 am
  3. Great post! There are so many posts out there with practices and principles, but only so few with the values behind Kanban. If people ask me about Kanban’s values, I’ll refer them to this great article. Thanks, Mike!Comment by Bernd Schiffer — January 4, 2013 @ 12:54 pm
  4. […] […]Pingback by Kanban digest #1 | Morisseau Consulting — January 4, 2013 @ 3:00 pm
  5. Great Post, Mike!
    For me the value “Respect” is also deeply incorporated in the 1st principle “Start with what you do know”. When coming to a new client, this principle means to me that I acknowledge the fact that the organization is doing a lot of things right! They must have made many good decisions in the past – otherwise they already would have been gone.
    Cheers,
    ArneComment by Arne Roock — January 4, 2013 @ 4:18 pm
  6. Hi Arne, completely agree. There’s some overlap between the principles but they each contain good advice so I don’t mind too much! Naturally that makes overlap hard to avoid in the values also, but again, I think it’s ok. Each one resonates with different people in different ways, and that’s ok too.Comment by Mike — January 4, 2013 @ 4:47 pm
  7. I think instead of “Agreement” from “Agree to pursue incremental, evolutionary change” we can extract “Evolutionary”. Of course “Evolution” is not a value but is the real meaning, because you can have Agreement to start a Revolution. Evolution implies that one Respects the present state. I would say Evolution implies all of Understanding, Agreement, Respect… English is not my native language so I am not able to come with a word for “Evolution” as a value…Comment by Dimitar Bakardzhiev — January 4, 2013 @ 5:49 pm
  8. Hi Dimitar, you have reminded me to make a small fix, clarifying the purpose of Kanban which is to drive evolutionary organisational change.Comment by Mike — January 4, 2013 @ 6:01 pm
  9. Mike, your comments on understanding reminds of one of Myron Tribus’s quotes – “You can manage what you do not understand; but you cannot lead it.”GregComment by Greg Brougham — January 6, 2013 @ 9:19 am
  10. Mike, nice article. Thanks.For Understanding, individuals may have their own understanding. So I think it is important that this is a ‘shared understanding’. This understanding will become transparent as the team models the flow of work through the value chain.ChrisComment by Chris Chan — January 9, 2013 @ 1:23 am
  11. Hi Chris, that’s a good point, and it shows how the values reinforce each other, understanding + agreement for example.Reflecting again, there have definitely been times when I’ve been guilty of keeping my understanding or my models to myself. That’s ok when they’re not much more than a hypothesis, but there comes a point where it’s disrespectful (there goes another!) not to share. I hope I make that mistake less often now.I polled my audience at LKCE12 in Vienna to find out how many people had managers who shared with them an understanding of Little’s law. Just two or three hands went up. That’s quite scary, at several levels…See also my followup post and the remarks on “Agreement in practice”. The kind of agreement that’s entered “eyes open” is more likely to be based on understanding I think.Comment by Mike — January 9, 2013 @ 11:03 pm
  12. Hi Mike,I think you wrote a very important post, but I have some concerns about it. I don’t want to criticise your thoughts, and I don’t want to be a troll either. I’m sure that it will be referenced in the future and therefore I think it is important to talk about it thoroughly.Definition of ValueWhen I first read you post I was unsure which definition of value you were referring to. The most two common ones I’ve found:(1) “An amount, as of goods, services, or money, considered to be a fair and suitable equivalent for something else; a fair price or return.” (1st definition in http://www.thefreedictionary.com/value)(2) “(plural) the moral principles and beliefs or accepted standards of a person or social group a person with old-fashioned values.” (5th definition in the second section in http://www.thefreedictionary.com/value)According to definition (1) the post summaries those things which I’ll get if I’m using the Kanban Method. These things (values) are “generated” by using the core principles. Definition (2) is more like a philosophical one (http://plato.stanford.edu/entries/value-theory/): the values you were writing about helps us decide what is good and what is bad in an organisation where the Kanban Method is applied. In other words: those are the things we live by. I assume that you were referring to values according to definition (1) and they were generated from the core principles.

    Values we Get and Don’t Get

    Based on my experience after applying the Kanban Method we really get understanding, agreement, transparency, balance and collaboration, but I wasn’t able to find a way to get the leadership, flow, customer focus and respect from the core principles.

    Although I favour and support leadership and respect, but I simply doesn’t see them as something I’ll get if I introduce Kanban in my organisation. They are something I need to do in order to deliver the mentioned values, so they are more like an input than an output to me. From another aspect, they feel into definition (2): we value respect, we value leadership…

    Besides that the phrase customer focus is misused, I don’t see it as a value. If you ask an executive of any organization, she won’t say that they aren’t customer focused. On the contrary, all the organizations are customer focused, because that’s why there were created: serving the customers (it is true even for the public sector). The problem is that the level of awareness differs in an organization. So, if the customer focus is always there, there is no way that any method can add it as a value. Additionally, you cannot get customer focus from any of the core principles ((1) definition). At the moment the only thing I can think of is to remove the word “customer” from the value, and use only the word “Focus”. It is cleaner and although you cannot get focus from the core principles, the practice shows that the organizations who have applied are more focused on what (and how) they are doing, and you can have focus on all the levels of an organization.

    I don’t see flow as a value either. It is present – however without understanding you may not see it -, it is something which generates value, or it is a mental state. Therefore I like the effectiveness and predictability instead.

    What do you think?

    Comment by Zsolt — January 10, 2013 @ 10:45 am

  13. Hi Zsolt,

    I think you wrote a very important post, but I have some concerns about it. I don’t want to criticise your thoughts, and I don’t want to be a troll either. I’m sure that it will be referenced in the future and therefore I think it is important to talk about it thoroughly.

    I thank you and others both for the encouragement and for helping me by their feedback to express myself better 🙂

    Definition of Value

    When I first read you post I was unsure which definition of value you were referring to. The most two common ones I’ve found:

    (1) “An amount, as of goods, services, or money, considered to be a fair and suitable equivalent for something else; a fair price or return.” (1st definition in http://www.thefreedictionary.com/value)

    (2) “(plural) the moral principles and beliefs or accepted standards of a person or social group a person with old-fashioned values.” (5th definition in the second section in http://www.thefreedictionary.com/value)

    According to definition (1) the post summaries those things which I’ll get if I’m using the Kanban Method. These things (values) are “generated” by using the core principles. Definition (2) is more like a philosophical one (http://plato.stanford.edu/entries/value-theory/): the values you were writing about helps us decide what is good and what is bad in an organisation where the Kanban Method is applied. In other words: those are the things we live by. I assume that you were referring to values according to definition (1) and they were generated from the core principles.

    You’re right, I didn’t define “values”. Another definition from the same site that’s closer to what I had in mind is this one:

    4. A principle, standard, or quality considered worthwhile or desirable

    but your “those are the things we live by” is spot on. We might go on to ask whether we live by them unconsciously (not noticing them until confronted by something in ourselves or others that does’t fit), or whether we make the effort to reflect on them and let this process modify our behaviour.

    Aside: I’m currently reading Dan Mezick’s book The Culture Game. One of his named patterns is Pay explicit attention, using the example of Kanban as “paying explicit attention to flow”. Reflecting on Kanban’s values is an internalised form of paying attention to our roles as change agents, and I’ve made it more explicit by writing about it. The conversations we’re having as a result are a loosely-structured way of paying attention as a community. It would be very cool if we could somehow turn this interaction into a repeatable practice (or “culture game”). Revisiting the “How deep is my Kanban” assessment tool with both values and Dan’s ideas in mind might achieve that, or perhaps it’s enough simply that we’ve added to our vocabulary.

    Values we Get and Don’t Get

    Based on my experience after applying the Kanban Method we really get understanding, agreement, transparency, balance and collaboration, but I wasn’t able to find a way to get the leadership, flow, customer focus and respect from the core principles.

    I presume you mean “get” in the sense of “derive as a benefit” rather than “read into” the foundational principles or core practices.

    Before answering these next points in detail, it should be clear now that the values underlying Kanban and the value derived from Kanban are two meaningful but very different concepts. In the first of my two articles (ie this one) I really had the former concept in mind; in the second (followup) article I was still thinking mostly the former but got into the latter as I made an attempt at identifying Kanban’s purpose.

    Although I favour and support leadership and respect, but I simply doesn’t see them as something I’ll get if I introduce Kanban in my organisation. They are something I need to do in order to deliver the mentioned values, so they are more like an input than an output to me. From another aspect, they feel into definition (2): we value respect, we value leadership…

    Leadership is actually pretty straightforward. “Encourage acts of leadership at every level in the organisation” is the fourth foundational principle; if you’re deeply enough into the method, you’ll be finding ways to do that. Admittedly the core method definition doesn’t say how but it’s no accident that David’s 3-day class used to be called a “Leadership workshop”. Referring again to Dan’s book, if leadership is influencing others in a social context, it’s hard to see how organisational/process change of any kind can happen without it. Putting up a board can be one small act of leadership from which many others will follow.

    Like leadership, respect is something we’re called upon to value by the foundational principles. We show respect (all the time, not just initially). Making it explicit when we explain that this is how Kanban approaches the problem of change encourages others to do the same. The process continues with disrespectful organisational behaviour getting called out or by displacing disrespectful practices with more respectful ones.

    Besides that the phrase customer focus is misused, I don’t see it as a value. If you ask an executive of any organization, she won’t say that they aren’t customer focused. On the contrary, all the organizations are customer focused, because that’s why there were created: serving the customers (it is true even for the public sector). The problem is that the level of awareness differs in an organization. So, if the customer focus is always there, there is no way that any method can add it as a value. Additionally, you cannot get customer focus from any of the core principles ((1) definition). At the moment the only thing I can think of is to remove the word “customer” from the value, and use only the word “Focus”. It is cleaner and although you cannot get focus from the core principles, the practice shows that the organizations who have applied are more focused on what (and how) they are doing, and you can have focus on all the levels of an organization.

    As I admitted in my first article, customer focus is hard to “read into” the foundational principles or core practices and I cheated a little by expanding the core practice Manage flow. However, when you look at the impact of properly understanding demand, getting end-to-end feedback on the process, collaborating outside our immediate span of control, applying the increasingly common practice of building validation (in the Lean Startup sense) into our process designs, it seems to be an almost inevitable result. Making it an explicit value makes that result all the more likely.

    I understand that focus is a Scrum value and it’s easy to see that it’s a good fit – no problem with that at all. Kanban has the very specific practice Limit work-in-progress and I chose balance as the underlying value because it allowed me to say so much more than I could have done with focus, taking in some of the more advanced aspects and outcomes of the method. Choosing focus would have made it harder to avoid perpetuating the myth that limiting WIP is mostly about multi-tasking, and I had the opportunity to cover the mental side of focus as part of flow.

    I don’t see flow as a value either. It is present – however without understanding you may not see it -, it is something which generates value, or it is a mental state. Therefore I like the effectiveness and predictability instead.

    Flow is interesting because by valuing it we get it! We pay explicit attention to it, address impediments to it. Most frameworks would claim to deliver effectiveness; Lean and Kanban make flow a constant strategic priority from which learning, effectiveness and predictability follow.

    Does that help?

    Mike

    Comment by Mike — January 11, 2013 @ 2:22 pm

  14. > I presume you mean “get” in the sense of “derive as a benefit” rather than “read into” the foundational principles or core practices.
    Exactly. This is what I had in my mind.> Does that help?
    I would say partially. 😉 Judging a trilogy by its first piece might not be a good idea, so I’ll take my time, wait and see where this initiative is going.Thank you for answering my long comment, and if you would like to discuss the topic further you know where to find me.Comment by Zsolt — January 11, 2013 @ 8:40 pm
  15. Very interesting article / approach!
    We just started with implementing kanban and never came across following principles:“Encourage acts of leadership at all levels in your organization – from individual contributor to senior management”.
    “Implement feedback loops”.How can I keep on track with further changes of the kanban principles?
    I do not find a source like the scrum guide.Thank you in advance!
    Alex

    Comment by Alex — January 14, 2013 @ 2:29 pm

  16. Hi Alex, good question.There is as yet no guide, but one is in the works, probably to be released by Lean-Kanban University. For now we have the kanbandev homepage – not very detailed but what’s there is definitive.David first floated the idea on his blog here then solicited feedback on kanbandev here. Subsequently, speakers spread the message at a number of conferences and the LKU-accredited training community incorporated the new principle in their materials or will do so very soon.Short answer: kanbandev is the place where anything like this will get announced and discussed (in fact this article and its followup are currently under discussion there).Regards,
    Mike

    Comment by Mike — January 14, 2013 @ 3:09 pm

  17. Thanks for the replyComment by Alex — January 16, 2013 @ 4:48 pm
  18. […] appreciate that Mike Burrows started a great conversation in the Kanban community when he posted his view on Kanban values. Thank you, Mike, because you’ve probably saved lots of people from further coffee attacks […]Pingback by 99 Second Presentation: Kanban Values or How I Almost Attacked a Manager With Hot Coffee » Agile Trail — January 22, 2013 @ 1:51 pm
  19. Great post Mike. I like how you framed a number of key ideas that has been discussed. Especially nailing Understanding. Thanks!Comment by Mattias Skarin — January 23, 2013 @ 10:28 pm
  20. […] Kanban durch seine Werte einführen, Dikussionsgrundlage – DE: http://www.software-kanban.de/2013/01/kanban-durch-seine-werte-einfuhren.html – EN (orig.): positiveincline.com/index.php/2013/01/introducing-kanban-through-its-values/ […]Pingback by 20. Treffen der Limited WIP Society Cologne | Limited WIP Society Cologne — January 29, 2013 @ 8:34 pm

What if we put agreement on outcomes ahead of solutions?

Agendashift™: Serving the transforming organisation
Agendashift  Academy: Leading with OutcomesHome | Store

Links: Home | Subscribe | Become an Agendashift partner Events | Contact | Mike
Resources: Tools & Materials | Media | Books | Assessments
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter