My kind of Agile

Posted on November 16, 2018July 16, 2022 by Mike Burrows

I’ve alluded to my kind of Agile in previous posts, but let me spell it out. I’ve hinted at it for quite a while, most recently in my popular post Right to Left: a transcript of my Lean Agile Brighton talk, which helps to explain the necessity and urgency of a Right-to-Left treatment of Agile.

I’m in the process of reworking the second chapter of my 2019 book Right to Left: The digital leader’s guide to Lean and Agile. Verbatim, here’s a key passage from chapter 2, Right to left in the digital space:

In chapter 1, we saw some of the quite different ways in which Lean is understood. Before we get to Lean-Agile, let me describe my kind of Agile, a kind of Agile that should already sound familiar:

People collaborating over the rapid evolution of working software that is already beginning to meet needs, their teams placing high value on collaboration, continuous delivery, and adaptation

That’s my highly condensed and “from-the-right” summarisation of the Agile Manifesto (agilemanifesto.org), describing a sweet spot for digital, and widely applicable elsewhere[1].

If you want to know what Agile is, the manifesto is where you need to start. Agile isn’t a defined process, method, or framework; Agile means embracing manifesto values. To embrace them you must understand them, and to understand them you must catch something of how they reveal themselves in environments that have allowed them to flourish.

Clearly, the manifesto values resonate with many. Meaningful conversations, the opportunity to build things that actually work for people, and the ability to keep improving the working environment to the mutual benefit of developers, customers, and the organisation – who wouldn’t want that? In other words, these things are valued for their own sake (which is why we recognise them as values).

For a values system to be more than just wishful thinking, there must be a clear relationship between the values, the kinds of behaviours expected, and the assumptions that underpin these behaviours. In the case of Agile, these assumptions are well documented – not least by the manifesto itself – and they go a long way to describe the behaviours:

Assumption 1: Direct, ongoing collaboration with customers is necessary to develop and maintain a mutual understanding of needs and potential solutions

Assumption 2: Collaboration across the entire process is what makes the whole greater than the sum of its parts – not just multiple perspectives brought to bear on complex problems, but new ideas created in the interactions between people

Assumption 3: The most effective way to build anything complex is to start with something that works[2], and ensure that it still works as it evolves. This is true not just for products, but for the working environment in terms of its technical infrastructure, processes, practices, organisation, and culture (not to mention all the complex interactions between those all of those internal elements, the product, and the outside world).

Agile’s breakthrough comes from bringing these assumptions together to everyone’s attention in the form of a compelling values statement. The underlying message is clear: wherever those assumptions are likely to hold, you would be wise to behave accordingly!

[1] I would stand by this definition outside of the digital space too and would argue that it is far more achievable than some would admit. But that’s outside the scope of this book.

[2] See Gall’s law, en.wikipedia.org/wiki/John_Gall_(author)#Gall’s_law, and John Gall’s rather wonderful book Systemantics: How Systems Work and Especially How They Fail (Pocket Books, 1978).

How does this resonate with you? Is there anything there that you would challenge?

The book is due early next summer; if you’d like to stay on top of developments and perhaps even get involved:

Subscribe to updates via the book’s landing page here
Join the Agendashift Slack community and its #right-to-left channel, the place for book-related conversations
On Twitter, follow @Right2LeftGuide &/or hashtag #Right2LeftGuide
(Note: I’ve only just stopped using the more generic hashtag #RightToLeft, so don’t expect to find much at the new one just yet. I’ve renamed the account accordingly.)

What if we put agreement on outcomes ahead of solutions?

Dealing with internal contradictions – if they can’t both be true at the same time, then what?

Posted on October 23, 2018October 23, 2018 by Mike Burrows

From my post Towards the wholehearted organisation, outside in (May 2018):

It got me thinking that I would love to be known for being in the business of helping organisations to be more wholehearted – less at war with themselves, their contradictions identified and owned so that they can be resolved in some pleasing way. If squeezing out excess work-in-progress is a key strategy for improving our delivery processes, perhaps squeezing out the contradictions is the way to improve our organisations for the mutual benefit of all concerned.

In the draft of the Outside In chapter of Right to Left (2019) I’ve included a version of the above paragraph together with the Christopher Alexander quote that inspired it. However, it seems wrong for the book to raise the prospect of bringing contradictions out into the open without also suggesting some constructive ways of looking at them.

The key question in a nutshell: If X and Y can’t both be true at the same time, then what?

On the premise that it can often be helpful to make explicit the thought processes that lead to our decisions, (perhaps as an aid to creating an agreed precedent or policy for next time), I offer a breakdown of the main ways in which contradictions get resolved. If I’ve missed any important combinations or references, do please let me know!

X and not Y

X achieves our goals better (in some defined way) than Y
Y does not align with strategic objective, mission, or core purpose X
Y is incompatible with core value X

Caution: Whilst it may be good to exclude Y, it’s possible that this decision says little about the merits of X, which may not be better than other alternatives (including doing nothing).

X and not yet Y

X naturally precedes Y / Y depends on X
X is more urgent than Y / X has a higher opportunity cost than Y (see also Cost of Delay)
X has higher priority than Y (because reasons)
We choose X to precede Y (because reasons)

Similar cautions apply. Y’s deferral may not justify X starting. And might Y be deferred for so long that it ought to be taken off the table entirely?

An important variation on the first one that an outside-in review might generate: Not Y because we don’t have capability X, the X not previously identified. Begs the obvious question: should we make it a priority to build capability X?

Neither X nor Y, but Z

Some higher objective Z either delivers X and Y or renders them unimportant
Some prerequisite objective Z comes first, or in other words, Z and not yet X and Y
Z as an alternative to X and Y – superior in some way, a better use of our time

X and Y

Creative tension: contradiction as a motivation for innovation (see TRIZ)
Perhaps, after challenging the assumptions of the apparent contradiction, we can demonstrate that X and Y aren’t necessarily in conflict (see Evaporating Cloud, one of the six Thinking Processes in the Theory of Constraints)
Conflict felt at a personal level, needing mediation perhaps

Caution: Beware the cop out, dodging the difficult decision…

Upcoming public Agendashift workshops (Italy, Germany * 2):

9 November, Brescia, Italy: Pre-conference workshop: Facilitating Outcome-Oriented Change (Mike Burrows)
21-22 November, Berlin, Germany: 2-day Advanced Agendashift workshop: Coaching and Leading Continuous Transformation (Mike Burrows)
03 December, Munich, Germany: Core Agendashift: Facilitating Outcome-Oriented Change (Julia Wester)

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…

Right to Left: a transcript of my Lean Agile Brighton talk

Posted on October 15, 2018July 16, 2022 by Mike Burrows

Friday was Lean Agile Brighton, a chance to catch up with friends in the community after the 3-day Brighton workshop with Karl. Here, from memory, is a rough transcript of my talk, the last one of the day (giving me the opportunity to refer back to other speakers), and just 20 minutes long. I don’t often do talks this short, but it was fun!

PS Over the weekend, I knocked up a cover for Right to Left (the book). It’s in the first slide below, also at agendashift.com/right-to-left, where you’ll find an overview.

Like Sal [Freudenberg, @SalFreudenberg, the previous speaker] I’m getting all misty-eyed about coming back to Brighton. My wife’s a Brighton girl, and my first job out of uni was in Lancing, just just down the road from here. My wife’s first boss later became mine (though not at the same time), and he’s in the audience today. Hi Peter! Thirty years!

Another reason to be excited: so many collaborators and influencers here: Karl [Karl Scotland, @kjscotland, one of the conference organisers] Steven [Steven Mackenzie, @busywait], and Liz [Liz Keogh, @lunivore] to name just three.

And I get to meet Caitlin [Caitlin Walker, @caitlinwalkerTA, opening keynote speaker] face to face at last! Her book [From Contempt to Curiosity] was quite an influence on the Agendashift book.

As I talk with colleagues and as I write my third book [see agendashift.com/books and agendashift.com/right-to-left], I detect a convergence: things happening in the Agile world that have long frustrated us but were hard to pin down we now have names for. And that’s good – instead of just complaining, we can begin to find solutions! Look out for couple of those in my talk today.

Who here is a Lego fan?

Wow, that’s a lot of hands!

If you had to describe Lego, where would you start? On the left with truckloads of plastic granules arriving at the Lego factory, or with children playing with the finished product? Plastic feedstock, or children playing? From the left, or from the right?

From the right of course.

Let’s try that with Agile. Where would you start? On the left with backlog items in Jira* (*other tracking tools are available), or on the right with people collaborating over working software that’s already beginning to meet needs? Backlog items in Jira, or people collaborating over working software. Left or right?

Yes, from the right again. You have to wonder though… How often do you hear Agile explained from the left, starting with backlogs, item sizing, and stuff? Rather too often. That’s a problem! It’s very easy to completely miss the point when you start from the wrong perspective.

We can do this with Scrum too. On the left we have the two levels of backlog, planning events, and so on. On the right: shared objectives pursued goal by goal.

Here we have two very different descriptions of Scrum, yet both of them entirely compatible with the Scrum Guide. And there are two mindsets represented here. Which mindset is the one more likely to encourage self-organisation, engagement, and innovation? The one that thinks mainly from the left, or the one that thinks from the right?

Again right, no question. Why then do we mostly hear the “from the left” version? Why do goals seem to be treated as though they’re some kind of advanced concept?

Now to SAFe, and it’s almost identical: n levels of backlog (where n is a parameter determined by the height of your SAFe poster), planning events and so on (very much like Scrum), or shared objectives pursued goal by goal (the wording here is identical to the previous slide, and it’s 100% compatible with SAFe).

I ask again: Which mindset is the one more likely to encourage self-organisation, engagement, and innovation? The one where progress against plan is closely tracked by the PMO, or the one where teams are encouraged to self-organise around goals?

You’re with me: the one on the right.

I’m not a SAFe user myself, but friends of mine in the SAFe community whose opinions I respect tell me that this tension is already beginning to be acknowledged and discussed in the SAFe community. Some implementations are more one way than the other; sometimes different people on the same project take a different view. Awkward!

We’ve done Scrum and SAFe but I’m not quite finished with this pattern yet. Let’s try it with Agile adoption. What’s your kind:

Here on the left: Prescribe a solution (or have it sold to you), justify it (manufacturing an inauthentic sense of urgency), roll it out regardless of what people think, and deal with the consequences: the resentment, the cynicism, the disengagement (which is very hard to undo once it’s there), not to mention the realisation that much time has passed, the world has since moved on, and we’ve got to do it all over again! Maybe that sounds a bit like a caricature, but from the nods I’m seeing around the room, I know that this hits pretty close to home for some of you.
And here on the right: Agree on some outcomes (a process we’re well practiced now in facilitating), generate some options (based perhaps on expert advice, but perhaps you’re already capable of more than you initially realise), and start to test some assumptions. Who here has worked with Lean Startup? [A few hands go up]. At least somewhat familiar with it? [Several more]. You’ll know that the way we make progress is by relentlessly testing assumptions, and trying to do it in such a way that we often realise some business value in the process. It’s the main engine of progress in Lean Startup, and also a great model for change. Do that for a while and change becomes part of the day job, real work done by real people, not spare-time work, hobby work, or something to outsource.

So which is it? Left or right? I hardly need ask.

The brokenness of that left-to-right model is a serious issue. Here for example is Martin Fowler [@martinfowler], a signatory of the Agile Manifesto:

[See agendashift.com/engagement-model]

That’s quite recent, in a 2018 State of Agile Software keynote. But he’s been consistent about this over the years: teams must have choice in their process.

[Again: agendashift.com/engagement-model]

Let me highlight this term, Engagement Model. When Daniel Mezick used it in the foreword to my book, I knew right away it was an important term, one that I might perhaps have run with in the book if we weren’t just about to go to print! It’s something I also recognised in Caitlin’s work – in fact the way she deliberately went about discovering and iterating on her engagement model is one of her book’s main threads, even if the phrase itself isn’t there. Of course whether they’re explicit about it or not, every Agile supplier has some kind of engagement model; the question is whether their model does what Daniel’s definition seeks: promoting staff engagement rather than destroying it (creating the kind of disengagement we heard about earlier).

There is a third level to this engagement model thing, and it’s the focus of some of the excited conversations I’ve had with Liz and other collaborators like those I mentioned at the start. As I said, I think we’re converging on something. It’s about teams, as they transform, engaging constructively with their surrounding organisations, not saying “don’t bother us, we’re busy being Agile”. We want both sides to thrive! Hunkering down might make sense for a short while as teams are trying out radically new ways of doing things, but to normalise this attitude is a disaster! How is that going to encourage the organisation as a whole to develop? What we need – and it’s something that Liz said in her talk too – are collaborations and feedback loops that deliberately span organisational boundaries, and we have some great patterns for that. The opportunity is enormous – think just of the opportunities created by cross-boundary participation in strategy, for example.

We have only a few minutes left but I want to give you a taste of what an overtly right-to-left and outcome-oriented approach to change can look like. And based on what we’ve experienced over the course of the day, it’s going to feel surprisingly familiar.

We’ll start with this True North statement:

[See agendashift.com/true-north]

Let’s pause for a few moments pause to take that in.

You might remember “Working at your best” from Caitlin’s talk; in my book I give full credit to Caitlin for the inspiration.

Now, to get the conversation started, a question for your neighbour.

In pairs: What obstacles do you see in the way?

You’ll recognise question 2 – it was one of the Clean Language Language questions we heard in Caitlin’s keynote:

With your neighbour, and with respect to the obstacles you identified: What would you like to have happen?

We’re starting a process Caitlin described as “modelling a landscape”; here we’re modelling a particular kind of landscape, a landscape of obstacles and outcomes. We could dig into the obstacles, but instead we’re going to go deeper into outcome space – it turns out this is a much better use of our time (quick book plug: Solutions Focus):

In your pairs: Then what happens?

People sometimes say to me “Oh, this is the 5 Whys!”. In a way it is, but here we’re going forwards into outcome space, not backwards into obstacle space. But now that we’re on the subject, I have to tell the 5 Whys joke:

Q: Why are the 5 Whys called the 5 Whys
A: Because with the 6th Why you get a punch in the face

We could break a relentless line of questioning with a different choice of question, perhaps one of the questions Caitlin introduced to us this morning. But let’s risk it:

In your pairs: Then what happens?

[See agendashift.com/15-minute-foto]

What we’ve done here is a super-quick, stripped-down version of our Clean Language coaching game, 15-minute FOTO. We’ve open sourced it, so you can download everything you need to play the full version. We do it in table groups of around 4 people, and in just 15 minutes, each group can easily generate 15 or more outcomes. Across a few table groups it can generate loads – it’s really effective.

[See agendashift.com/overview]

In our workshops or as part of a longer engagement we actually use it twice: once as part of Discovery, to help explore our ambitions and aspirations, and for a second time in Exploration when we’re looking for the opportunities to take forward.

[See agendashift.com/done]

I’m done, at least in the sense that my 20 minutes are up. I hope that someone’s need was met. Thank you very much.

What if we put agreement on outcomes ahead of solutions?

Continuous Delivery demands Continuous Discovery

Posted on August 17, 2018August 17, 2018 by Mike Burrows

This is the second of an informal series of posts suggested in the July roundup, expanding on tweets that have sprung to mind while writing (or thinking about writing) my third book, working title Right to Left: The digital leader’s guide to Lean and Agile. In case you missed first one: You can’t deliver a task.

Tweet #2:

Sooner or later, Continuous Delivery will depend on Continuous Discovery. Better make it sooner. #agile #agendashift #RightToLeft

— Mike Burrows (@asplake) July 25, 2018

Do you recognise this pattern?

We get somewhat good at building stuff
Later, we get somewhat good at testing it
Later still, we get good at deployment, so good in fact that we can do it at will
As work starts to flow, deficiencies in development and testing become more apparent, and they get dealt with
All of a sudden, the real bottleneck turns out to be outside of development – a lack of high quality ideas in the pipeline and/or frustrating delays in getting decisions made
Now what???

There is something almost inevitable in this sequence – in fact anyone familiar with the Theory of Constraints (TOC) will expect it! If you’re unfamiliar with TOC, it’s the model behind Eli Goldratt’s classic business novel The Goal, and much more recently the DevOps novel The Phoenix Project; TOC teaches that once you’ve addressed enough of your internal constraints, your key constraint will be found outside.

Although there’s a lot to be celebrated in that progression, no team wants to get to the “Now what???” stage. Your choices:

Hope that it never happens (or not care, because teams are there to be disbanded)
Plan to deal with it when it does happen
Make Discovery (or “upstream” or whatever else you call it) a first class activity in your process

Option 3 implies some proactivity, but that doesn’t mean that it has to be difficult. Instead of dismantling that capability as your latest initiative gets off the ground, keep it going, even if at a reduced level. Instead of accepting requirements at face value, make sure that someone is taking the time to understand their authentic situations of need. Instead of fire-and-forget delivery, validate that needs are being met, expecting to feed some new learning back into the process. Simple changes, but as documented in my first book, the effect can be profound, even humbling!

You can of course go further. One of the most important moves made by the UK Government Digital Service (GDS) was to insist that every new service had a credible plan to sustain user research and ongoing service evolution – not just at the beginning but indefinitely into the future. “Start with needs” wasn’t just a slogan, it was a strategy, and a successful one! If government could do this in times of austerity, what excuse does your organisation have?

Public workshops (US, UK, IT, DE)

24th August, Seattle, WA, USA: Core Agendashift: Facilitating Outcome-Oriented Change (Julia Wester)
14th September, Chesterfield, UK: Agendashift Studio – SOLD OUT – see below
9th-11th October, Brighton, UK: Agendashift + X-Matrix Masterclass (Mike Burrows, Karl Scotland)
9th November, Brescia, Italy: Pre-conference workshop: Facilitating Outcome-Oriented Change (Mike Burrows)
3rd December, Munich, Germany: Core Agendashift: Facilitating Outcome-Oriented Change (Julia Wester)

Make yourself known the #agendashift-studio channel in Slack if interested in attending another cozy 1-day or 2-day workshop for 3-4 participants in my studio office in Chesterfield, Derbyshire (minutes away from the Peak District National Park).

You can’t deliver a task

Posted on August 1, 2018July 16, 2022 by Mike Burrows

As suggested in the July roundup, this is the first of a few posts expanding on tweets that have sprung to mind while writing (or thinking about writing) my third book, working title Right to Left: The digital leader’s guide to Lean and Agile.

You can't deliver a task. #agile

— Mike Burrows (@asplake) July 16, 2018

Years ago, in my past life as a manager (which I still re-enter from time to time as an interim), I learned that there was little value in me tracking tasks. What mattered to me was the deliverable. Interestingly, I noticed that when I visibly stopped taking an interest in tasks, most of my team members followed suit. I said “It’s completely fine by me to tasks on the board if that’s what works for you, but I’m not going to ask about them”, and soon the task stickies disappeared.

As a team, we made rare exceptions for features that failed our “2 day rule”, which is to say features that at a very rough guess would require more than a couple of days worth of development. Experience taught us that these were disproportionately risky, so it seemed justified to insist on some kind of plan. Of course what actually happened was that most of these big features got sliced into smaller features, and then everyone’s happy to go back to feature-level tracking.

Stop tracking tasks, and no longer does the tracking system drive the developer to work in a way that doesn’t seem natural. A bit over here, a bit over there, then back to the first bit… if the tests say it’s fine, it’s fine! Two people with different skills working together on the same feature? Go for it! And at a stroke it eliminates the anti-pattern of “tasks for quality” – ie separate tasks for unit tests, refactoring, and the like (in the global department I ran more than a decade ago, these tasks disappeared when I asked why these things weren’t happening as the code was being written; I guess my predecessor didn’t see things in quite the same way).

And then there’s the whole question of when a task can be said to be “done”. How do you that some low-level piece of work is really done if the feature as a whole isn’t yet working? Somehow I think that this may have come up before….

Public workshops (US, UK, IT, DE)

24th August, Seattle, WA, USA: Core Agendashift: Facilitating Outcome-Oriented Change (Julia Wester)
9th-11th October, Brighton, UK: Agendashift + X-Matrix Masterclass (Mike Burrows, Karl Scotland)
9th November, Brescia, Italy: Pre-conference workshop: Facilitating Outcome-Oriented Change (Mike Burrows) Note: the booking page is now up
3rd December, Munich, Germany: Core Agendashift: Facilitating Outcome-Oriented Change (Julia Wester)

What if we put agreement on outcomes ahead of solutions?

#Right2LeftGuide is #Agendashift (outcome-orientation) for delivery

Posted on July 20, 2018February 20, 2019 by Mike Burrows

Going by chapter counts, Agendashift [1] is 80% outcome-oriented change and 20% continuous transformation. It describes an approach to Lean-Agile transformation that rejects imposition, replacing it with meaningful agreement on outcomes, bringing together organisational ambitions and the needs of everyone who will help bring those ambitions to reality.

Can we do for delivery what Agendashift does for change? Of course we can. The only surprise it that it’s so necessary!

It has always been well understood in Lean circles that to make proper sense of a delivery process, you must start with how the thing that is being delivered creates value in the eyes of the customer, and work backwards from there. Somehow, that lesson gets forgotten in Agile circles; either Agile is all about teams (a view I can find some respect for, even if I don’t fully buy it), or we’re fed the ironically process-centric lie that teams start with backlogs and create value from there.

#Right2LeftGuide is about recovering a focus on customer outcomes for Lean-Agile delivery [2], and maintaining that perspective as we work backwards through the delivery process, understanding it better, managing it better, and finding ways to do it better.

It’s a simple but surprisingly radical change of perspective. With it, it’s surprisingly easy to see that there are two Scrums [3], the mechanistic, backlog-first left-to-right version and the ‘iterated goal-seeking’ right-to-left version. It turns out that there are two versions of SAFe too; expect to see more on that soon (and not just from me). I haven’t yet established whether there are left-to-right and right-to-left versions of the other leading scaling frameworks; it would be nice to identify some that are predominantly right-to-left, but we’ll see (if you can help or just want to stay in touch with this work, join us in the #right-to-left channel in the Agendashift Slack [4]).

The Right to Left book [5] will come out next summer. Meanwhile, Agendashift has plenty to offer. For example, how do you explain survey results [6] like these?

Screenshot 2018-07-20 10.59.11

When I see results like these (which I do a lot), it’s all I can do to resist sarcastic lines like “Great to see all that leadership put to such good use!”. There’s some good(ish) news –transparency, balance, and collaboration are doing somewhat ok, relatively speaking (even if the numbers aren’t great in absolute terms and they’re not having the impact on flow that we would hope for), but just look at customer focus! Fortunately, I see a great appetite for doing something about this, paying more attention to needs, embracing validation, and so on.

I’ve said a few times now that I would be happy to see the rest of my career (I’m 53) being devoted to outcomes. When I first started saying it, I didn’t have #Right2LeftGuide in mind, but that’s 100% ok. Perhaps one day we’ll be describing #Agendashift as the #Right2LeftGuide for change!

[1] Agendashift (www.agendashift.com)
[2] Understanding Lean-Agile, right to left (blog.agendashift.com)
[3] #Right2LeftGuide works for Scrum too (blog.agendashift.com)
[4] Agendashift on Slack (www.agendashift.com)
[5] Right to Left: The digital leader’s guide to Lean and Agile (www.agendashift.com)
[6] Agendashift™ Assessments, also chapter 2 of the book (www.agendashift.com)

Upcoming workshops

9-11 October, Brighton, UK: 3-day Agendashift + X-matrix Masterclass
(myself and Karl Scotland)

An outside-in strategy review, Agendashift style

Posted on July 12, 2018July 16, 2022 by Mike Burrows

I’ve just about finished an initial draft of the second chapter of Right to Left: The digital leader’s guide to Lean-Agile (which now has a landing page). Its three-part structure is firming up nicely as follows:

Right to left (four chapters): Lean; Agile; Fundamental Lean-Agile patterns and how they combine; Scaling frameworks
Outside in (one to three chapters): Strategy reviews (and related tools); Capability reviews; Feedback loops and other organisational patterns
Upside down (one to two chapters): Designing for leadership and change: Servant leadership, Leader-Leader, the inverted pyramid, engagement models (of which Agendashift is an example) and so on

The shape works, and I’m thrilled with how the well the right-to-left thing is working out – see for example last week’s post #RightToLeft works for Scrum too which is already a top 5 post for the year and is helping me find collaborators interested in giving the scaling frameworks a similar treatment.

I’ve not just been writing. Let me share four questions I posed (one at a time) at a outside-in strategy review (a private workshop):

Customer: What’s happening when we’re reaching the right customers, meeting their strategic needs? (‘Strategic needs’ being the customer needs that best define our mission)
Organisation: When we’re meeting those strategic needs, what kind of organisation are we?
Product: Through what products and services are we meeting those strategic needs?
Platform: When we’re that kind of organisation, meeting those strategic needs, delivering those products and services, what are the defining/critical capabilities that make it all possible?

(Admission: I got two of these the wrong way round in my prep last week, which changes the wording slightly. This exercise still worked great though!)

If you’re familiar with the model, you may be wondering what happened to the fifth and innermost layer, Team. This we covered not by a question, but via the Agendashift True North, focussing not on the work that teams are doing but on ways of working.

As we considered each layer, we captured some vision, then obstacles. After exploring the five layers individually, 15-minute FOTO to turn obstacles into outcomes.

Precede all of that with some forward-looking context-setting and segue into hypothesis driven change and A3 (all of which are standard features of our transformation strategy workshops) and you have an outcome-oriented strategy review, done Agendashift style.

Want to explore these and other complementary strategy-related tools with us? Join myself and Karl Scotland at our Agendashift + X-Matrix Masterclass, 9th-11th October, Brighton, UK. Or drop us a line about private workshops. You might even facilitate one yourself – the tools and materials aren’t expensive!

What if we put agreement on outcomes ahead of solutions?

‘Right to Left’ works for Scrum too

Posted on July 4, 2018August 6, 2024 by Mike Burrows

Update: See the landing page for the ~~forthcoming~~ book Right to Left: The digital leader’s guide to Lean and Agile (published summer 2019, audiobook 2020)

Here’s a conventional, left-to-right [1] description of Scrum:

A Product Backlog (all the stuff we’d like to do), a Sprint Backlog (the stuff we plan to do this sprint), then a Sprint (a timebox) that culminates in a potentially shippable increment, a review, and a retrospective. Rinse and repeat.

To me, this is how NOT to describe Scrum. Is it a straw man, put up just so that I can knock it down? Hardly! Not all descriptions of Scrum follow this narrative, but it’s common enough. Complete with a video, here’s a nicely-produced example from a reliable source, the Scrum Alliance: Learn about Scrum (web.archive.org). It’s one of the first pages returned by Google in response to the question “What is Scrum?”.

The bullet points below are the first few from that page’s 30-second summary, and they’re very close to the commentary on the video:

A product owner creates a prioritized wish list called a product backlog.

During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.

The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).

Along the way, the ScrumMaster keeps the team focused on its goal.

If you wanted to describe Waterscrumfall, would you describe it any differently? Perhaps “the team is arm-twisted into pulling an implausibly large amount of work into the sprint (or the project manager helpfully does it for them)”, but little else changes. Would it help if the process description were prefaced with mentions of agility, complexity, and so on? That must depend on the reader’s frame of reference; if they don’t share our understanding of those words, they’re just noise.

Let’s try a right-to-left description, Scrum as a pattern of iterated self-organisation around goals:

A Scrum Team moves towards its Product Vision goal by goal, the team collaborating around a shared goal for a timeboxed interval called the Sprint, at the end of which the team reflects on how well the Sprint Goal was achieved before it prepares for the next one, organising around a new goal. The team’s best understanding of the work required to achieve the Sprint Goal is represented by a Sprint Backlog; options for future sprints are maintained in a Product Backlog.

The same process, yet so different, and with much less room for misinterpretation. This – I think – is much more like the Scrum that people love. Do you agree? Would you describe it differently?

Thanks to Steve Porter and Thorbjørn Sigberg for their feedback on earlier drafts of this post.

[1] Understanding Lean-Agile, right to left

Suppose you had to understand Lego – and I mean really understand it. Where do you start? With children playing, or with plastic feedstock?

Source: pixabay.com/en/plastic-polymer-granules-1061731/

Source: http://www.flickr.com/photos/aukirk/8171237624

Upcoming events

February

18 February, Online, 16:00 GMT, 17:00 CET, 11am ET, Agile Strategy Meetup Group:
Meet Mike Burrows on strategy
24-27 February, four 4-hour sessions online, afternoons UK time:
Leading with Outcomes: Train-the-Trainer / Facilitator (TTT/F)*

March

06 March, London, UK:
Kanban Edge 2025

*TTT/F and (where shown) LIKE events include free one-year membership of the Leading with Outcomes Authorised Facilitator programme, upgradeable to Authorised Trainer at any time. Both of those include access to the video-based Leading with Outcomes training and the full range of Agendashift assessment tools.

Leading with Outcomes from the Agendashift Academy
“Leadership and strategy in the transforming organisation”

Leading with Outcomes is our modular curriculum in leadership and organisation development. Each module is available as self-paced online training or as private, instructor-led training (online or in-person). Certificates of completion or participation according to format. Its modules in the recommended order:

Foundation module:
- Leading with Outcomes: Foundation
Inside-out Strategy:
- Part I: On the same page, with purpose
- Part II: Fit for maximum impact
Adaptive Organisation:
- Part I: Business agility at every scale
- Part II: Between spaces, scopes, and scales
Outside-in Strategy:
- Part I: Positioned for success
- Part II: A platform for performance

Individual subscriptions from ~~£24.50~~ £18.40 per month after a 7-day free trial, with discounts available for employees and employers in the government, healthcare, education, and non-profit sectors. For bulk subscriptions, ask for our Agendashift for Business brochure.

To deliver Leading with Outcomes training or workshops yourself, see our Authorised Trainer and Authorised Facilitator programmes. See our events calendar for Train-the-Trainer / Facilitator (TTT/F) and Leading in a Transforming Organisation trainings.

At every scope and scale, developing strategy together, pursuing strategy together, outcomes before solutions, working backwards (“right to left”) from key moments of impact and learning.

Agendashift roundup, June 2018

Posted on June 29, 2018June 29, 2018 by Mike Burrows

In this edition: Agendashift as…; A new joint 3-day workshop; Happy birthday!; Progress on Right to Left; Out and about; Top posts

Agendashift as…

In recent weeks and in weeks to come we’re pushing boundaries, getting into new areas:

Agendashift as an enhancement to Kanban training – using the assessment and some lightly structured “obstacles to outcomes” conversations to organise the day and help participants focus their work on things that really matter. I don’t actively seek out this kind of training opportunity but am happy to deliver an outcome-oriented experience when the call comes!
Agendashift as leadership development – another private workshop, helping leaders make the shift away from command and control, getting comfortable with (i) outcomes as the focus for self-organisation, and (ii) experiments as a powerful way to frame and develop actions.
Agendashift as business strategy development – “outcome-oriented” meets “outside-in”, the latter just a minor theme of the Agendashift book but one that will see greater prominence in the next one. Expect to hear more in the meantime as we pursue this on the ground, taking our tools of transformation strategy and adapting them for application in more general strategy work.

This October: 3-day Advanced Agendashift + X-Matrix workshop

One of my key collaborators is already very active in the strategy deployment space, and I’m delighted to announce another joint workshop with Karl Scotland. For the first time we’re bringing together the Advanced Agendashift workshop (already at least 2 days worth) and Karl’s X-Matrix workshop. You can be part of that collaboration, joining us for 3 days in Brighton ahead of the Lean Agile Brighton conference. More here:

Why a 3-day workshop?

Happy birthday!

On June 14th our Slack community celebrated its second birthday. Of all the things I’ve helped create, this is definitely one of the coolest. If you’re not participating, you’re missing out! More here about the kinds of channels on offer and how to join:

The Agendashift community on Slack is 2 today 🎉🎉

Progress on Right to Left

A quick monthly update on the third book: 7,164 words, nearing the end of chapter 2, still aiming for early summer next year. I have a ton of other people’s stuff to read and re-read; I’ll put together a new reading list soon.

A reminder meanwhile that the references for the Agendashift book make an excellent reading list:

Recommended reading

Out and about

Next week I’m at Agile Cymru in Newport, Wales, where no fewer than 5 Agendashift partners (Jose Casal, Karl Scotland, Matt Turner, Cat Swetel, and myself) will be speaking! Hope to see you there. A couple of private workshops aside, the summer period will provide some space for writing and development (I don’t mind admitting that I miss programming when I haven’t done it seriously for a while).

Have a great summer (or winter, if you’re south of the equator). There probably will be July and August updates but I will allow myself at least the option of a break!

How the Leader-Leader model turns Commander’s Intent upside down

Posted on June 4, 2018July 16, 2022 by Mike Burrows

If you’ve heard me speak in recent months, it won’t come as a surprise when I say that L. David Marquet’s Turn the ship around! [1] has become a favourite book. It’s the story of how Marquet, a US Navy captain, turned around a poor-performing nuclear submarine with its crew, taking it from “worst in fleet” to “first”. I can also recommend the audiobook, which is narrated by the author himself.

Commander’s Intent [2] is an important model from the military which (rightly) receives attention in business circles. In this model, leaders make a habit of expressing objectives and the rationale for them, controlling the urge to specify in detail how that objective should be achieved. In short, the what and why, not the how. As explained in Stephen Bungay’s The Art of Action [3], it was developed in the 19th century by Carl von Clausewitz, a general in the Prussian army, and has since become firmly established in military doctrine around the world.

Marquet turns Commander’s Intent upside down, but in so doing proves its point!

Suppose now the intent is expressed not by the leader to a subordinate, but by someone under their command and in the other direction. That person is showing initiative, might even be attempting something innovative. The commander has a choice: to trust them to get on with it, to provide support, or to suggest alternative course of action. Either way, they are mutually accountable, the one for his or her actions, the other for providing an appropriate level of support (in a context in which safety is paramount). If you can establish these leader-to-leader conversations as a new habit, then through countless such encounters and through essentially unlimited opportunities for people at every level of the organisation to show leadership, the organisation grows.

Marquet’s ultimate intention was no different to Clausewitz’s – to turn an organisation stuck in the ways of the past and barely fit for the present into one capable of thinking for itself and innovating its way into the future. Understand Commander’s Intent in those terms and Marquet’s Leader-Leader makes perfect sense.

How frequent are the opportunities for statements of intent in your organisation? Do colleagues (whether seniors, peers, or otherwise) both offer appropriate support and hold each other to account when intent has been expressed? It’s a great way for people and teams alike to grow in capability and for leadership to develop.

This post is the third in a series of three, introducing three core themes to be developed in my next book (my third, out I hope about a year from now in early summer ’19) :

Right to left: the effective organisation – see Understanding Lean-Agile, right to left
Outside in: the wholehearted organisation – see Towards the wholehearted organisation, outside in
Upside down: the supportive organisation – this post

Working title (as of this week!): Right to left: A leader’s guide to Lean-Agile.

Meanwhile, the Agendashift book [4] is a book not about Lean-Agile but about outcome-oriented change. It is steeped in those themes, but by design it assumes them more than it explains them (though they begin to become explicit in the final chapter). If you like, Right to left is Agendashift’s prequel. Join us in the #right-to-left channel in the Agendashift Slack to monitor progress and to discuss any of these three themes.

[1] L. David Marquet, Turn the ship around!: : A True Story of Building Leaders by Breaking the Rules (Portfolio Penguin, 2015)
[2] Commander’s Intent (en.wikipedia.org)
[3] Stephen Bungay, The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results (Nicholas Brealey Publishing, 2010)
[4] Mike Burrows, Agendashift: Outcome-oriented change and continuous transformation (New Generation Publishing, 2018)

What if we put agreement on outcomes ahead of solutions?