Details, details, details

This weekend I really enjoyed Jason Gorman’s post Everything Else is Details.

The first thing to like is the title. Compare Jason’s “Everything else is details” to my “the rest is ‘just’ the How” which I blogged about just a couple of weeks ago. Mine needed scare quotes and Jason’s doesn’t. I already prefer Jason’s!

And from the post itself just a sample (emphasis mine):

The trick to this – a skill that’s sadly still vanishingly rare in our industry – is to paint a clear picture of how the world will look with our software in it, without describing the software itself. A true requirements specification does not commit in any way to the implementation design of a solution. It merely defines the edges of the solution-shaped hole into which anything we create will need to fit.

We know of course that what works for product development often translates into organisational change and vice versa (just look at how Lean Startup transfers ideas and techniques in both directions). Let’s make the highlighted sentence less specific to software:

Learn to describe the world with the thing without describing the thing itself

It goes a long way to explaining how Agendashift works: without any mention of Lean, Agile, Lean-Agile, or their practices, we help people to paint a picture of a more Lean-Agile organisation – broad brush initially, and then in more detail around areas of opportunity. In this way we facilitate agreement on outcomes (goals in Jason-speak). After that, Everything Else is Details.

Not that we don’t care about Details – actually we care quite a lot and have tools for managing them – but we know better than to start with them. As an industry, we seem to be great at them, but have a habit of moving on before anyone dares to ask why the results are so often so mediocre!

I put much of that mediocrity down to the institutionalisation of these twin delusions:

  1. The delusion that when requirements are met, needs will be satisfied
  2. The delusion that when problems are solved, meaningful outcomes will inevitably be achieved

Delusions that are perhaps not so surprising given an industry so thoroughly in love with its ability to deliver Details. Easily explained? Yes. Excusable? I don’t think so.

How I read the Scrum Guide


  1. The good: Things the Scrum Guide™ reinforces that would otherwise get lost
  2. The ugly: Things that should not be accepted at face value
  3. How I approach it

I’m going to assume that you have at least a passing acquaintance with Scrum, either as it’s generally taught and discussed, or as defined in the Scrum Guide. The guide itself has been updated in the past few days, there now being a 2017 edition:

The guide is ©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at and also described in summary form at

I haven’t checked to see when this license model was applied, but nice move.

1. The good: Things the Scrum Guide reinforces that can easily get lost

My biggest “Aha!” moment for Scrum was when I realised that it wasn’t about story points, velocity, Fibonacci numbers, and the like. Although tools like these do seem to work effectively enough for some people, others find them a recipe for (i) busywork or (ii) setting teams up for regular disappointment, making them a popular target for sniping. Rightly, there is no mention of them at all in the guide.

The guide instead talks of the sprint backlog as both a set of items selected for the sprint, and – crucially – a plan for delivering them. And get this: the sprint backlog is subordinate to something else, the sprint goal:

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Imagine you’re working in an organisation that typically takes months or even years to deliver anything of note (I exaggerate not). Now give people the chance to work together on achieving a meaningful goal in a matter of days. And again. And again. That’s powerful. Could that be done without Scrum? Does it happen without Scrum? Of course it could and of course it does, but Scrum is often the vehicle by which people experience this for the first time, and that’s something to celebrate.

I also have to give credit to Ken and Jeff for being explicit about Scrum’s applicability:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

I don’t highlight this quote as some kind of backhanded compliment, a way to put Scrum back into its box. The domain described here is huge! And it’s important for reasons explored in chapter 5 of the Agendashift book. To operate a Lean, Agile, or Lean-Agile process worthy of that name, you must embrace the idea that the often challenging, sometimes messy, and always necessary work of helping the organisation to change must be treated as real work, to be carried out not just alongside delivery work, but integral to it. The ‘complex adaptive’ part of that quote might be unnecessarily jargony but it refers to the inability of any linear plan to deliver this vital kind of change effectively (see my “Change in the 21st century” keynote).

Taking these together, Scrum working well means:

  1. Meaningful goals regularly met
  2. The system – the team and well beyond – evolving commensurately

That’s harder to achieve and even harder to sustain than it might sound, and the guide is honest about the level of challenge involved. What it leaves unsaid is that as soon as Scrum comes to mean ploughing through the backlog, these benefits become increasingly difficult to sustain. It’s why we find support in complementary tools such as Kanban, Lean Startup, and now Agendashift [1] when the returns from Scrum on its own begin to diminish.

2. The ugly: Things that should not be accepted at face value

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

There are so many better ways in which the Scrum Master role could have been introduced, and it beggars belief that this section could be edited (yet again) in the 2017 edition and left like this. After an ugly paragraph easily construed as ‘your first responsibility is towards Scrum’ we see a very carefully circumscribed kind of servant-leadership that will surely be read in the light of what precedes it. There are more charitable interpretations, but they depend on assumptions that aren’t made explicit.

To be a true servant leader, your responsibility is towards your colleagues, your organisation, your customers, other stakeholders, even towards society. Where by-the-book Scrum helps you in those responsibilities, fantastic. Where it gets in the way, it might be time to do something not by the book. A true master at Scrum might find these situations rare, but pity the conflicted rookie! Even if only in the context of these sentences, if it doesn’t bother you that Scrum Masters are certified after just a couple of days of training, it should.

If we want our industry to do better, we have to look at its systems, ready to challenge a status quo that tends to preserve itself. Scrum has been around long enough to qualify for that kind of scrutiny and whatever their true intent, these widely-read sentences are too open to a cynical, self-serving interpretation.

In response to my tweet yesterday morning, Neil Killick was quick with this much better alternative:

With all due respect to Neil, that wasn’t so hard, was it?

3. How I approach it

I start from the perspective that Scrum describes some pragmatic solutions to common problems. Do you have multiple customers, far removed from the team? Then you’ll find it helpful to have a highly available Product Owner. Do you need someone to model and facilitate appropriate practices and behaviors? Then bring in a Scrum Master. Are your feedback loops too slow relative to the rate of environmental change? Then plan your work to fill short timeboxes and meet daily.

Conversely, if you don’t have all of these problems, you might not need Scrum. At the very least, tread carefully:

  • Don’t place obstacles between a team and its customers if they’re already collaborating (yay, manifesto values!)
  • Don’t add layers of process and ceremony where teams are already self organising effectively
  • Don’t allow Scrum’s timeboxes get in the way of rapid flow and rapid change – they needn’t [2], which is why I don’t present this as a technical objection to Scrum

Nice problems to have, you might argue. And well you might, which why I am significantly more pro Scrum than anti. But I don’t check in my experience, knowledge, or curiosity at the door. Where I see conflict between approaches, I dig deeper, fully expect to find agreement, and am usually rewarded handsomely.

For the most part, you can leave the self-serving stuff behind (I’ve learned to filter it out). If you are helping to bring clarity and agreement around purpose and goals (things Agendashift and the guide fully agree on), and if you start with needs, seek agreement on outcomes, and so on [3], it’s likely that you’re approaching things in a good way. As time passes you might find that things look less and less like anything you heard in class, but don’t let anyone shame you for that. Expert or rookie (and yes, tread accordingly), you’re responsible. You’re a leader!

[1] About Agendashift
[2] Scrum and Kanban revisited
[3] Agendashift in 5 principles

I’m grateful to Olivier My, Neil Killick, Johan Nordin, and Karen Beck for their valuable feedback on earlier drafts of this post.

While we here

Lean-Agile Strategy Days London (II) – 22-23 Nov, London, UK is just over a week away and there’s still time to book your place. Interested in Lean-Agile change and its relationship to strategy? You should be there! In case you can’t make both days, we’ve just added a strictly limited number of single day tickets.

Outputs from yesterday’s Agendashift workshop

With the permission of its participants, this post is a quick tour through yesterday’s public Agendashift workshop in Cape Town, seen through the key artifacts produced by our two table groups. Sessions 1-5 are covered in detail in chapters 1-5 of the Agendashift book (all five chapters); see also the poster and about pages for a quick overview.

Picked up from the local printers the day before: cue cards for the 15-minute FOTO game (A6 & A5 sizes – the larger A5 size being the more popular); ‘original’ & ‘pathway’ survey reports, A3s. See resources.

2017-11-07 12.58.29-1

Session 1: Discovery

Two exercises here. The first is a getting-to-know-you “Celebration” exercise, ostensibly about a company celebration that is to take place some time in the future (it’s one of those time travel games), but in practice a nice way to make sure the workshop is grounded in organisational context and needs. To structure the output, we use the classic journalistic 5W questions: Who, What, When, Where, and Why, with the How coming later:

The second Discovery exercise involves:

  • Reflecting on our True North statement as an approach to the challenges of the first exercise, thinking about what that’s like, what’s different, and what obstacles stand in our way
  • Using our recently-open sourced coaching game 15-minute FOTO to turn that list of obstacles into outcomes
  • Organising the resulting outcomes to produce the outputs shown below

Session 2: Exploration

A few days prior to the workshop, the participants each completed an Agendashift values-based delivery assessment. The Exploration session starts with a survey debrief, the structure of which is now so well practised that the unbenchmarking report leads us through it step by step.

Then – guess what! – we generate outcomes:

  • Prioritise the survey prompts
  • Identify their respective obstacles
  • Generate outcomes using the 15-minute FOTO coaching game again (a lot easier second time round – one conversation stood out as one I’d wished I’d recorded!)

We finish the session with the exercise whose first rule is not to mention its name (see the first part of this writeup which breaks this rule, or chapter 2 of the book). The joint output of both table groups:

2017-11-08 14.29.46

Moments after this picture was taken we destroyed it (reusing the stickies) but not before identifying stickies setting towards the top left corner as being likely candidates for some hypothesis-driven change (session 4). Look out for stickies marked with asterisks in the next pic (session 3).

Session 3: Mapping

Next, the transformation map, like a user story map but where the items are outcomes rather than user stories:

2017-11-08 15.32.40

After some discussion, we concluded that the first column (Refine existing systems) was empty because the many small improvements that might have gone there were deemed insufficiently interesting on the day. Fair enough! Column 5, Address sources of dissatisfaction (etc) seems rather full; a review of the stickies shows significant scope for consolidation however.

The two stickies “above the line” were the subject of some debate. Are “Increased stability” and “Increased quality” to be treated as long-term objectives to which other yet-to-be-identified work aligns, or are they to be tackled head on? No right answers here, so long as we’re honest. Either way, I stressed that consider them to be actionable (“unactionable” and “aspirational” being trigger words of mine).

For reasons of time, we didn’t bother to prioritise within columns. There was plenty of past experience of that process in the room already.

Session 4: Elaboration

For a selected outcome per table, another generative process, that of creating options. Then:

  • Prioritisation, selected the option considered most capable of significant (“fantastic”) outperformance
  • A hypothesis, Lean Startup style
  • Further development, using our open sourced A3 template (a 20th century tool with a 21st century flavour)

It is not a mistake that both A3s have their Insights section filled in. No, we haven’t run these experiments yet, but imagining the learning we hope to capture allows us then to review our experiment design. Both tables identified gaps in their plans as a result of this tip. Result!

Session 5: Operation

As a practitioner workshop rather than a client workshop (same materials for both but different goals), we deliberately sacrificed much of this session in return for more time for reflection and discussion in sessions 1 & 2. Consequently there are no outputs to show here. With more time available, we would have added more outcomes to the transformation map, driven by an adaptability review. This process both recaps our outcome-oriented process and gets us thinking about how the decisions of the workshop will be carried forward. Our mantra here: “Treat change as real work”.

To wrap up, the Full Circle exercise, capturing outcomes using the house style of the assessment prompts – inclusive, present tense, non-prescriptive:

2017-11-08 17.00.09

The top one could almost be an advert for Agendashift (it’s not mine, honest):

We treat change as a type of work – owned, driven, and co-created by the team/s impacted

You, the outcome-oriented facilitator

If you could use some Agendashift-style outcome orientation in your coaching or consulting work, check out our partner programme. And there’s another opportunity very soon to try it all out, this time in London:

Finally, a massive thank you to all of yesterday’s participants, and also to the organisers of the Regional Scrum Gathering in South Africa who kindly invited me over for this morning’s opening keynote. Opportunities permitting, I hope to return to South Africa again soon – 6 years is too long!

Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events
): 22-23 Nov, London, UK

5 key plays and how to accelerate them

In the context of a discussion about a scaling framework (it doesn’t matter which one), I was asked yesterday in the Agendashift Slack about recurring patterns I’ve seen or applied in my work and whether/how they’ve been affected by Agendashift.

For the sake of minimum argument, let’s say we’re already using both Scrum and Kanban at team level. Basic (and improving) processes are in place, work is visible, and teams are not massively overburdened. It’s not necessarily how I’d start but let’s call that easily-understood baseline ‘play 0’.

After that, here are five key plays from my playbook:

  1. Smooth/speed work through dev – often through managing dependencies better, identifying them before work starts, making them more visible, greatly reducing the appetite for starting work that can’t be finished
  2. Make the post-dev process more visible – make any issues there too visible to ignore
  3. Smooth/speed work through the post-dev process – better conversations at the start of the process (even before dev), better automation, better management of environments, etc
  4. Validation – retain ownership of work well past delivery, validating that the impact on user behaviour is as expected and that needs are being met
  5. Work on the team/organisation interface – risk management, change management, service delivery reviews (a favourite of mine), team sustainability (funding, recruitment, skills transfer, etc)

In what order? When do you do these things?

Of course it depends, but notice:

  • The need for plays 1-3 should become increasingly apparent to the teams themselves once play 0 has taken effect. More experienced teams are likely to notice the need for them sooner; the most experienced ones will not only contain people who know not only that bottlenecks move, but can guess in which direction (and they’re listed in the most common order). These changes happen fastest when they are encouraged and supported by people who know what to expect. An explicit drive towards continuous delivery is helpful, especially with regard to plays 2 and 3.
  • Unlike plays 1-3, plays 4-5 are unlikely to appear spontaneously through a process of introspection. They involve some important attitude changes:
    • Work is only truly ‘done’ when needs have been met (and demonstrably so)
    • It is recognised that the host organisation has needs too, and that unless you want live forever in a small Agile bubble, a certain amount (and style) of mutual accountability is healthy, not a threat.

If I’m working mainly at team level, it’s likely that the five plays will happen in roughly the order presented. Play 4 may involve developing some skills that the dev team might not have in abundance initially (user research & testing, service design, service management, etc). Play 5 may come a lot sooner if the right kind of sponsorship is in place, and it helps immensely if there are managers who can also be considered part of the team for at least these purposes (service managers, delivery managers and project managers in GDS projects, for example).

How Agendashift changes things

Let’s recast these plays as outcomes to be achieved:

  1. Work flowing smoothly through dev, dependencies managed well
  2. Effective management of the process end-to-end
  3. Good collaboration end-to-end and an effective technical platform for rapid delivery
  4. Proactive alignment of team and customer, more ‘right thing’ than ‘wrong thing righter’
  5. Proactive engagement between team and organisation, setting the tone, metrics consistent with values, better alignment overall

As soon as you have agreement on outcomes like these, the opportunity is there for the taking. Of course there are right ways and wrong ways of going about things (and Agendashift provides some help here), but as per my previous post, Getting to Agendashift’s “Why”:

Because when you have agreement on outcomes, the rest is “just” the how…

Agendashift creates the opportunities for outcomes like these to be articulated and agreed upon, even before deep-seated pain points are fully exposed, thereby accelerating the process. They can be tackled in sequence or in parallel, via off-the-shelf practice or innovation, with or without reference to frameworks. The choice is between you and those that you work with and for, defined to some degree by your role already or left open. Where choices are open, make best use of that opportunity: consider a diverse range of options and make progress by testing assumptions relentlessly (advice that works for product development too).

While we’re here

November 8th (tomorrow) is a key day:

Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events
8th Nov, Cape Town, South Africa22-23 Nov, London, UK


Getting to Agendashift’s “Why”

[Updated 2017-11-04 following feedback]


Because when you have agreement on outcomes, the rest is “just” the how…

I’d be the first to admit it: clearly articulating Agendashift’s “Why” has taken more time and more iterations than perhaps it should. Or maybe that’s just how it goes – all part of the struggle!

Some of my past attempts at mission statements, taglines, and so on:

  • The new platform for positive change
    – I’m not that this early effort even made it to production but it’s there in my git logs
  • Leading change with less prescription, better conversations, lasting outcomes
     I was still searching for a tagline for the book at this stage
  • Transforming Lean-Agile transformation
    – I must admit that I still quite like this one, but how many people care about this goal?
  • Clean conversations, coherent collaboration, continuous transformation
    – borrowed from the book, but the book is only part of the product
  • Models, tools, & materials for enablers of outcome-oriented change
    – getting there (for reasons that I hope will become apparent in a bit), but this works only if you identify with the phrase “enablers of outcome-oriented change”

Early on, I described Agendashift as “values-based” but I’m not sure that anyone found that particularly helpful. The phrase lingers on in the name of the Agendashift values-based delivery assessment (whose six categories are indeed values – Transparency, Balance, Collaboration, Customer Focus, Flow, and Leadership) but even there the clock is surely ticking. Would “Agendashift delivery assessment” suffice? Probably.

Another description that I still apply to Agendashift is “non-prescriptive”. This resonates  with people who recognise that it’s a big issue for our industry that we rely far too heavily on lazy prescription in the absence of awareness of context or appreciation for how change works. On the flip side, it annoys those who want me to state clearly what Agendashift is, not what it is not. And they’re right of course.

Hence “outcome-oriented”. A useful alternative to non-prescriptive, but for the purposes of a tagline or mission statement it is both clunky and jargony. But ask the question “Why outcome-oriented?” and you’ll get an interesting answer:

Because when you have agreement on outcomes, the rest is “just” the how…

So there you have it: Agendashift’s “Why”, our proposition in a nutshell. It’s all you need to understand the intent and thrust of Agendashift’s tools and materials. For example:

  • The assessments help to identify possible areas of agreement for further work (eg with 15-minute FOTO)
  • The activity flow of Discovery, Exploration, Mapping, Elaboration, and Operation pivots around the central activity of Mapping (see slide below) . Mapping organises outcomes generated and agreed upon in the first two activities. Later, outcomes are reframed as actions in Elaboration; Operation treats change as “real work”.
  • Similarly, the principles:
    1. Start with needs
    2. Agree on outcomes
    3. Keep the agenda for change visible
    4. Manage options, testing assumptions
    5. Organise for speed, clarity, and mutual accountability

Screenshot 2017-11-04 14.12.45

The rest is “just” the how…

This isn’t meant to sound glib. I put the “just” in quotes because of course change is rarely easy. But to treat transformation as something to deploy over the resistance of others is to make it very much harder than it needs to be, and hardly congruent with Lean and Agile values either!

While we’re here

Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events
8th Nov, Cape Town, South Africa22-23 Nov, London, UK


Agendashift roundup, October 2017

In this edition: Workshops; 15-minute FOTO; Revision 4 of the book; Interviewed for the LAMP podcast (video); Because every framework needs a poster…; Speaking; Top posts


Last week I did a webinar hosted by Innovation Roots, a tour through the artifacts generated at the recent workshop in Bengaluru, India. Watch this space for a recording.

Next week’s workshop in Cape Town is nearly sold out – at the time of writing there is just 1 ticket remaining.

After that comes my joint 2-day workshop with Karl Scotland, London Lean-Agile Strategy Days (II) on the 22nd and 23rd. Early bird pricing expires on the 8th.

15-minute FOTO

Our Clean Language-inspired coaching game ‘15-minute FOTO’ is now open source. See:

For the uninitiated, FOTO stands for “From Obstacles to Outcomes”, and the game gives you 15 minutes in which to generate a decent number of them, using only the questions on the Clean Language cue card. An example of “generative over prescriptive” if you like. Described in chapter 1 of the book.

Many thanks to Andrea Chiou for her considerable support in this.

Revision 4 of the book

Talking of the book, it has now stabilised at revision 4. See:

Interviewed for the LAMP podcast (video)

A couple of weeks ago I spent a very enjoyable 45 minutes being interviewed by Dima Moroz at Kanbanize for the fifth episode of the LAMP podcast. See it here:

Because every framework needs a poster…

As featured in our new About page, there is now an Agendashift poster, and it’s downloadable via our Resources page.


UK, South Africa, and France:

Top posts

Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events
8th Nov, Cape Town, South Africa22-23 November, UK

We’ve open-sourced ‘15-minute FOTO’

For some time we’ve made available the PDF for the cue card for our Clean Language-inspired coaching game 15-minute FOTO. The game is an essential part of our workshops and also one of the most memorable, and we’re delighted to release it now under a Creative Commons with-attribution licence to enable its wider use and to encourage adaptations (very well demonstrated by Featureban since its creation in 2014).

What is it? FOTO stands for “From Obstacles to Outcomes”, and you have 15 minutes in which to generate a decent number of them, using only the questions on the cue card. An example of “generative over prescriptive” if you like.

Head over to its own landing page and you’ll find:

  • PDFs for the deck and the cue card for direct download
  • How to obtain the original .pptx source files
  • Facilitation tips
  • A link to a video that includes me facilitating the game for a meetup of about 80 people
  • Links to recommended reading on Clean Language and other Agendashift-related topics – not least the Agendashift book which introduces the game in chapter 1.

I’m indebted to Andrea Chiou for her help over the months in integrating Clean Language into Agendashift and for the work she has put in more recently to put this deck together. Thank you Andrea!

Screenshot 2017-04-03 18.09.15

Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events
8th Nov, Cape Town, South Africa22-23 November, UK