On the quality and nature of backlogs

From the Agendashift and Agile and Lean Software Development LinkedIn groups (the second by request):

If you’re building systems for use by humans, ploughing through backlogs of requirements  – however well they might be written – rarely delivers anything better than mediocrity. Conversely, in a high feedback environment (where ideas get tested very quickly), even apparently low-quality inputs can deliver great results, if the inputs do at least focus collaboration and innovation on the right challenges.

Not that the “upstream” folks get a free ride from me – it’s their job to ensure a ready supply of those right challenges to work on, options developed to an appropriate level of detail just-in-time. What’s “appropriate” here is highly contextual, depending as it does on the degree of uncertainty involved and the skillset of the team. Focussing on the quality of the backlog as a whole would be a mistake and not a metric I would want anyone to take seriously.

That’s taken a little out of context and there is no doubt a risk that I’ll be misunderstood, but the comment stands alone well enough I think. One thing is for sure: I completely stand by the idea that ploughing through backlogs is a recipe for mediocrity, particularly when the system under construction is mainly for use by real people. I said it before in Agendashift and I’ll be saying it again (albeit for a different audience) it in Right to Left.

As to the idea that focussing too much on the quality of the backlog can be a trap for the unwary, let me quote from the draft of Right to Left. Here we’re describing close collaboration between development and its ‘upstream’ process in a digital context where this kind of working is now very well proven:

[They] learned to stop thinking of [their ‘upstream’ process] as a phase broken down into stages with gates in between; now they understand it as managing a portfolio of options for the best possible return. The best ideas will be released quickly, perhaps even before they are fully formed – the opportunity being great enough that more eyes and hands should be involved sooner. Some ideas take longer to mature, the cost/benefit equation being sufficiently marginal that a few rounds of prototyping and user testing might save the team some wasted effort later. The least promising ideas will languish for a while before a positive decision is made to reject them. No-one mourns a rejected option; each one is a bullet dodged, waste avoided.

Focus less on the backlog itself and more on the job that it has to do!

Upcoming Agendashift workshops

See recent blog post: Agendashift workshops in Seattle, London, Boston, and Berlin

Facilitated by Mike Burrows unless otherwise indicated:


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…

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!


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…


Engagement: more than a two-way street

September 14th, 2018 is the second anniversary of Agendashift’s public launch. I’m marking the occasion with a post that describes a key motivation and gives some clues about where we’re headed. And while we’re here, if you haven’t recently checked our programme of upcoming workshops, there are four listed at the bottom. Enjoy!

We all know what employee disengagement looks like, how it saps energy and creativity, and not just in the unengaged. I won’t go into all the causes and symptoms here, but briefly, if you take away people’s agency – their perceived ability to make choices for themselves – a stress response is provoked, and not the kind of stress that you would want to find in an organisation that hopes to see people working at their best [1].

Just as anywhere else, disengagement is a very bad sign in the context of [Lean-]Agile transformation. It’s a sign that the change agents (managers, consultants, coaches, etc) don’t know what they’re doing! If people are disengaging because there’s the perception that they have no say in how things are going to work inside their teams, it strongly suggests that they have been denied the opportunity to participate meaningfully in the transformation process. This represents an inexcusable failure to engage on the part of the change agents responsible. It would seem that engagement is a two-way street (actually it’s more four-way intersection than two-way street, but we’ll come to that).

In short, 20th century-style rollout projects and managed change programmes run the risk of destroying engagement. Not only do the ends not justify the means, the means don’t work if the goal is an engaged and creative workforce. That it keeps happening is “an absolute travesty”, as Martin Fowler (an Agile Manifesto signatory) recently put it [2].

So ‘Big Agile’ bad, ‘Small Agile’ good? Not so fast. Agilists lamenting a lack of Agility in the organisation is not engagement. Tweeting false dichotomies about management vs leadership is not likely to engage many managers. Praying for viral adoption is not much of a growth strategy. And don’t get me started on the passive aggression (“We’re so Agile, we only let our stakeholders talk to us in the Sprint review” [3]).

A plague on both their houses then? No! The arguments between the two sides keep missing the crucial point that success depends on engagement. It’s a phony war, fought on the wrong battleground, few shots landed. The apparently less exciting good news: the more that they do engage, the less obviously top-down or bottom-up they become and the more that they have in common. Funny that.

It should now be clear why engagement models [4] such as Agendashift [5], OpenSpace Agility (OSA) [6], Systemic Modelling [7], BOSSA nova [8], and TASTE [9] are so necessary. Non-prescriptive by design, they work happily with frameworks big or small, branded or home-brewed, and with each other. In their various and complementary ways, they bring people together from multiple levels of the organisation, help the organisation collectively to reveal to itself what needs to change, and come to agreement on what needs to change.

But we can go further. In a transformation of any reasonable size, it is inevitable that different parts of the organisation will move forward at different speeds, and this will keep on throwing up new challenges. If we want the ‘new’ to survive and then thrive, then its surrounding organisation must too. If the new is to grow, then the old must adapt. Both have needs, those needs will evolve over time, and attending to them is key to the viability [10] of not just the transformation, but the organisation itself.

What’s needed then is another kind of engagement: not person-to-person but system-to-system. It raises questions like these:

  • How does strategy work going forward? How will ‘old’ and ‘new’ participate in the processes of strategy development and deployment?
  • On the day-to-day stuff of delivery, how will old and new coordinate with each other effectively?
  • How might this play out over time, and what implications will that have for the easily-forgotten, slower-changing, but still critical parts of the organisation? (For example, what role do HR and Finance play in the staffing, skilling, and funding of a very different-looking organisation?)
  • How will we know that it’s working? How will we know to intervene when it is not?
  • How will we know that we’re winning? Then what?

These questions could easily be re-framed so that Agendashift-style tools can be used to explore this evolving landscape. For example:

  • What obstacles will prevent ‘old’ and ‘new’ participating in the processes of strategy development and deployment as we move forward?

(Then from obstacles to outcomes (FOTO) [11] – you know the drill)

Whether we’re talking about Agile process frameworks or engagement models, I don’t honestly think it’s sensible to expect off-the-shelf products to have answers to these questions. What’s important is that they’re asked and answered, then re-asked and re-answered as the transformation progresses. Instead of glossing over them, how about embracing them? Does this not invite management from both sides of any old/new divide to become more engaged, to take more responsibility for the process, and for new kinds of leadership to develop as a result?

Screenshot 2018-09-14 05.50.14
No shortage of opportunities for both kinds of engagement [12]
I believe this represents a massive opportunity for the engagement models. It’s not that we didn’t already kinda know this, but we’re going to make it more explicit, both because it’s important in its own right and because it further exposes the bankruptcy of approaches based on imposition and other negligent forms of non-engagement. A concerted effort is gathering a head of steam here in Agendashift-land [13], and we collaborate with our friends in our peer communities too. No lack of choice there!

Notes & references

[1] I credit the phrase “working at your best” to Caitlin Walker’s From Contempt to Curiosity: Creating the Conditions for Groups to Collaborate Using Clean Language and Systemic Modelling, Caitlin Walker (2014, Clean Publishing). You can see its influence in the Agendashift True North (agendashift.com/true-north).

[2] The State of Agile Software in 2018 (martinfowler.com). Key quote:

The Agile Industrial Complex imposing methods on people is an absolute travesty

[3] A sensible enough short-term policy designed to protect the newly-forming team becomes dogma, to the long-term detriment of all.

[4] Engagement model: For Daniel Mezick’s quick introduction to the concept, see Engagement (openspaceagility.com). Key quotes:

Engagement Model (noun) : Any pattern, or set of patterns, reducible to practice, which results in more employee engagement, during the implementation of an organizational-change initiative.

If you cannot name your Engagement Model, you don’t have one.

[5] Agendashift™: agendashift.com, and of course the book, with communities on Slack and LinkedIn. Twitter: @agendashift

[6] OpenSpace Agility™: openspaceagility.com, with communities on Facebook and LinkedIn.

[7] Systemic Modelling™: See Clean For Teams: An Introduction to Systemic Modelling (cleanlearning.co.uk) and Caitlin Walker’s book above [1].

[8] BOSSA nova: See the website and the book by Jutta Eckstein and John Buck. Twitter: @AgileBossaNova

[9] TASTE: Karl Scotland’s take on Lean strategy deployment, with the X-Matrix as a key artefact. See the blog posts TASTE Impacts, Outcomes and Outputs and TASTE Success with an X-Matrix Template. Karl is also a leading collaborator on Agendashift; the upcoming Brighton workshop (see Upcoming Agendashift workshops below) includes both.

[10] My choice of the word ‘viability’ is deliberate. Its conventional meaning works fine, but I’m also alluding to Stafford Beer’s Viable System Model (VSM). Rather than the somewhat impenetrable Wikipedia page I would wholeheartedly recommend Patrick Hoverstadt’s excellent book The Fractal Organisation.

[11] 15-minute FOTO (agendashift.com/15-minute-foto), our Clean Language-inspired coaching game, Creative Commons licensed, available now in several translations.

[12] Figure based on Agendashift chapter 5 and my keynote Inverting the pyramid.

[13] Channels #right-to-left and #systhink-complexity in the Agendashift Slack. Note the title of the pivotal fourth chapter of Right to Left (due 2019). Twitter: @RightToLeft3

Acknowledgements: I’m grateful to Allan Kelly, Daniel Mezick, Philippe Guenet*, Karl Scotland*, Mike Haber, Thorbjørn Sigberg*, Andrea Chiou*, and Jutta Eckstein for their feedback on earlier drafts of this post. Asterisks indicate Agendashift partners.

Upcoming Agendashift workshops (UK, IT, DE)

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…

A True North for Lean-Agile?

You may have noticed that the blurb for our workshops and for the new book always starts with this:

Imagine… everyone able to work consistently at their best:
 • Individuals, teams, between teams, across the organisation
 • Right conversations, right people, best possible moment
 • Needs anticipated, met at just the right time

It’s taken from one of our Discovery exercises (chapter 1), an early opportunity for participants to explore different ways of working not from the perspective of prescribed practices, but in terms of what it is like – how it feels, what’s different, and so on.

Some of the groups I’ve facilitated have found the exercise so cathartic that they ask repeatedly for more time. It’s not hard to see why:

  • If you feel that you’re rarely given the opportunity to work at your best, your team doesn’t work well, or you’re painfully aware that teams aren’t working work well together, it can come as a relief to be given the chance to imagine a different reality
  • Whether you’re a front line worker or a manager, conversations happening at the wrong time (or not at all) can be very frustrating
  • For most of us, knowing that we’re meeting needs is crucial to finding meaning in our work

The current text of the book doesn’t identify these words as a True North statement (a compass direction rather than a destination), but it probably should. A True North for Agendashift certainly, and I’d like to put it forward as a True North for Lean-Agile also. It’s consistent with the Lean pillars of respect for people and just in time. Consistent with the Agile manifesto, it elevates individuals and interactions, combining those with a sense of timeliness (I joke that Agile seems to imply lots of meetings, the beginning – one hopes– of true collaboration).

In its favour as a worthy True North:

  • It is easy to understand, worth striving for, and will remain always just out of reach. Transformation must be continuous, not a one-off project
  • It works at every scale – from individual to organisation, and at scales in between
  • In its last bullet, it conveys much-needed senses of proactive discovery (needs don’t get consistently anticipated by accident) and purpose (needs being met)

Also, it’s not specifically about software, or even about product development. That’s a departure from the Agile manifesto, but I have no doubt that this is in its favour too.

So… Does it work for you?


Screenshot 2017-05-22 13.42.56

Blog: Monthly roundups | Classic posts

Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

From the Department for Dodgy Mnemonics: DUL and POWT

From DfDM, the Department for Dodgy Mnemonics, two for the same day, April 18th, 2017.

Mnemonic 1: DUL

Don’t blame Schein for the awful nmemonic, but do thank him for the process:

  1. Discomfirmation: when we come to the (perhaps difficult) realisation that past assumptions, values, or solutions either don’t hold, cause as many problems as they solve, or must make way for something else
  2. Unlearning (or unfreezing): when we work through the implications of that realisation, and become open to alternatives
  3. Learning: when we begin to work with a new set of assumptions, values, and solutions

Source: Organizational Culture and Leadership, Edgar H. Schein. I can vouch for the audiobook also.

Mnemonic 2: POWT

Or if you prefer, POOO, or GOOO. It’s a pattern we use repeatedly:

  1. Prompts (or prioritised goals): We prioritise assessment prompts (or similar descriptions of how we would like things to be) because we realise that they represent – in a positive way – something that isn’t working as it should. See also DUL.
  2. Obstacles: We identify things that stop those prioritised prompts or goals from being realised as we would like. See also DUL.
  3. What would you like to have happen?: We identify outcomes hiding behind those obstacles.
  4. Then what happens?: More outcomes – the outcomes behind the outcomes.

Worst case, we get to discover what’s beyond our most immediate outcomes. Better (and quite likely) case: we agree on outcomes more interesting and achievable than the ones we started with.

Blog: Monthly roundups | Classic posts

Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter


I don’t mind admitting it: I was struggling a bit with chapter 5 (the last chapter of Part I and the main obstacle to initial publication). Then came London Lean Kanban Days 2017 and corridor conversations with Karl Scotland, Greg Brougham, Patrick Steyaert, and Ray Edgar that continued on Slack afterwards.

I was only too happy to scrap my first attempt and start again. What got the juices flowing again was this simple picture:

Screenshot 2017-04-06 05.34.27

It occurs to me that there’s a trap that Lean, Agile, and Lean-Agile folks fall into more often than they realise: believing that responsiveness (of delivery) implies adaptability, the ability to develop new capabilities and new levels of capability in the organisation. There’s a correlation certainly, but the trap is another way of describing the issues I raised a few weeks ago in Why Agile needs some 21st century Lean thinking. To what extent is responsiveness just a local optimisation, doing what we do increasingly quickly, but never breaking out of our comfort zone?

The rewritten chapter 5 takes the Agendashift Values-based delivery assessment and refocuses it on adaptability. The original version doesn’t completely ignore capability and adaptability but as its name implies, it is mostly about delivery. It turns out however that necessary modifications are very modest, an almost mechanical translation: yes there definitely is a relationship between responsiveness and adaptability, a kind of duality even.

These dualities aren’t new. Lean Startup demonstrates that tools for process improvement can be applied to product development, and vice versa. If your organisation can get to understand that change is work and value them both the same, much of the rest follows.


Blog: Monthly roundups | Classic posts

Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Why Agile needs some 21st century Lean thinking

At least as far as the textbooks go, 21st century Lean is quite a different beast to its 20th century forebear. The best of the more modern Lean literature is now explicit in its recognition that you can’t just take the Lean tools out of one context, drop them into another, and expect the same results. Just because it works for Toyota, doesn’t mean it will work for you. Just because it works in a car factory… I hardly need to complete that sentence!

Not unmodified, that’s for sure. The kind of Kanban I described in Kanban from the Inside that works so well for people engaged in creative knowledge work is almost unrecognisable from the canonical kanban systems of the automotive factory. Many of the underlying principles are the same – for example visual management, controls on work-in-progress, the quest for flow – but their physical or electronic realisations are very different. In one, cards move left to right (downstream) on a kanban board to reflect the progress of work; in the other, cards are sent upstream when some downstream activity wishes to signal a need for some just-in-time replenishment.

But that’s just technical detail. The best of the 21st century Lean authors have been humble enough to make an even more important admission: even within the manufacturing domain you can’t (as the 20th century writers tried to suggest) transplant the tools whilst ignoring the management systems that guide, support, and sustain them, and still expect good results. An important case in point is continuous improvement (or kaizen, if you prefer). Don’t get me wrong: continuous improvement will always be a good idea. Unfortunately though, it is rarely sustained for long through goodwill alone. Asking your workforce for continuous improvement as a low-commitment way to achieve real transformation will almost certainly result in disappointment, even harm.

We in the Agile community know all this of course – how often do we see retrospectives fall into a state of neglect once the easy changes have been made? Unfortunately, we make it harder for ourselves, and by design! As an end-of-century reaction to 20th century top-down and plan-driven management styles wholly unsuited to the challenges of rapid product development in uncertain environments, Agile rightly sought to wrest control back to the teams doing the work. The unfortunate side-effect: blindness to the power of the kind of internal structures that create regular opportunities for mutual reflection, support, and accountability well beyond the team. How is the Agile team supposed to help the organisation become more Agile when it is determined to live inside its own protected bubble? This is how inspect-and-adapt (Agile’s continuous improvement) runs out of steam. Even at team level it’s hard enough to sustain; expecting it to drive broader change without support is, well, optimistic.

I’m not looking to throw the baby out with the bathwater. I’m not suggesting any backsliding on Agile values. I’m not making the case for 20th century top-down management (in fact quite the opposite). I’m asking that we look beyond the delivery-centric processes and tool (most especially beyond the determinedly team-centric ones) and start to think about what that cross-boundary support and accountability could look like.

In particular:

  • What will drive Agile teams and their host organisations to help each other to serve their customers’ and each other’s needs more effectively?
  • Where are the joint forums for reflection?
  • What mechanisms will provide support and ensure follow-through, even when the necessary changes become more challenging on both sides?
  • Where are the opportunities for people to engage seriously in the development and pursuit of organisational goals?
  • What skills will be  needed to make these things happen?

Outside the Agile mainstream, Kanban and Lean Startup have opinions (if not explicit guidance) on many of these questions. Helping people pay attention to concerns such as these is one Agendashift’s main motivations. Much of Agile however still seems to ignore them, sometimes recognising the need for end-to-end thinking but still wary of “at every level” thinking.

The good news is that these concerns are largely orthogonal to delivery. Agile delivery frameworks probably don’t need to be any bigger than they are today (let’s hope so). Some awareness of organisational context and its journey will be necessary though, and it may mean leaving aside the rhetoric of past battles. Welcome to the 21st century!

Blog: Monthly roundups | Classic posts

Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter