Updated: Agendashift’s three meta strategies

[Updated March 10th: tweaked the headings, replaced the image]

Or if you prefer:

  • After Rumelt, three guiding policies – thank you Oren Golan for the reminder
  • Less grandly, three things to keep working at if you’re doing anything strategy-related (which, if you think about it, should be a lot of the time)

For now at least (this is a work in progress) I’ll go with meta strategies. They’re strategies for getting better at strategy, in particular the kinds of strategy that tends to motivate transformation. And forgive me if I drop the meta once in a while.

Meta strategy 1. Keep asking the “agreement on outcomes” question

Which is to say, keep asking this question and learn to really mean it:

What if we put agreement on outcomes ahead of solutions?

Authentic agreement on meaningful outcomes. “Authentic agreement” meaning the right people in the room, agreeing on things that matter, expressed in their own words. “Meaningful outcomes” meaning not just numbers, not just targets, but needs met, happy endings to stories, the world changed for people in meaningful ways.

Solutions second, outcomes leading the way – literally “leading with outcomes” [1] – solutions emerging from the people closest to the problem [2], people already motivated to find them.

All of that is a 180 degree turnaround from those 1990’s models of managed change, a different paradigm entirely. Instead of using outcomes to sell solutions (and very often solutions of the wrong kid of scale), we use outcomes to find solutions. Not just game-changing for engagement, a completely different game.

Meta strategy 2. Change the game’s objectives to keep outcomes in the foreground

The trick here is to change the meaning of ‘done’:

  • You’re ‘done’ only when needs have been met
  • You’re ‘really done’ only when you have fully accounted for all the learning

Outcomes don’t go away once we start thinking about solutions – quite the opposite. Outcomes change what ‘done’ and ‘really done’ mean. When we account properly for learning, it creates certain expections, helping to keep ‘done’, ‘really done’, and all the outcomes they represent in the foreground. Solutions are kept in their proper place, just a means to an end, held much more lightly.

We’re done when “someone’s need was met” [3], the outcome demonstrably achieved. This implies that we know whose need we’re trying to meet, what need, and how we’d know that we have indeed met it.

We’re really done when we’ve fully accounted for all the learning that goes with achieving the outcome. To be sure of not missing any, work is framed in the right way (as hypotheses and experiments, whenever that’s appropriate), the right things are monitored, and regular reviews are in place. The regular rhythm of review and the shared understanding of what each review entails creates containers for learning. If you know that the learning will need to be accounted for, it really changes how you work.

Meta strategy 3. Keep developing your understanding of where all this happens

Where rather than how, because the third meta strategy of the three is not about practice or process, but organisation [4]. It’s about working to eliminate a common organisational dysfunction, also working to develop a kind of organsational agility that’s about so much more than mere speed.

If instead of keeping outcomes in the foreground you allow yourself to be distracted by solutions and how you’re rolling them out, you are managing for progress (or worse, activity), not impact. Compounding the error, one group manages things that people closer to the work could easily be managing for themselves. And it works in the opposite direction too: one group second-guessing the needs, priorities, and strategies of another. In short: the wrong people managing for the wrong things. Totally dysfunctional, so common, and don’t be so sure that your branded process framework or your PMO will fix it for you either!

Often this dysfunction happens between levels of organisation (up and/or down), but the trick is to think less in terms of hierarchy or process and more in terms of identity and purpose. For an outcome, what’s the group of people most closely identified with it or that you would want to see organising around it? Conversely, for any group of people with an identity of its own and the apparent will to develop itself – team, team of teams, something bigger, something cross-cutting, whatever – what are the outcomes that it is pursuing? What, in other words, is its strategy, and has it been afforded the opportunity to develop it for itself and in its own words?

That way of looking at organisation has a dynamism that’s simply not there in the org chart or the process diagram. People participating in multiple circles, circles that overlap and rapidly share learning, insights, and intelligence because they also share people. For as long as they’re needed, circles that have lives of their own. Structures that by themselves and in their relationships support both the development of people and the development of the organisation. Structures rich and dynamic enough to meet the ever-changing complexities of the business environment.

With this third meta strategy, the preceding two don’t just have a home, they have many homes. Strategy becomes something fractal and emergent, living in the conversations not just within circles, but between them.

3 meta strategies

[1] This section drawn from the first video in Leading with Outcomes: Foundation (academy.agendashift.com)
[2] Thank you Karl Scotland for that wording
[3] See Done (agendashift.com/done)
[4] See the Deliberately Adaptive Organisation (deliberately-adaptive.org)

For further reading, my two most recent books:

  1. Agendashift: Outcome-oriented change and continuous transformation (2nd ed 2021)
  2. Right to Left: The digital leader’s guide to Lean and Agile (2019, audiobook 2020)

What if we put agreement on outcomes ahead of solutions?

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

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

The 1967 Manifesto for The Deliberately Adaptive Organisation

It may still too early to judge the 1990’s for its net contribution to organisational understanding. If much of what was published on the specific topic of change management had never been written, it might have been for the better! It’s not all bad though: I have recently enjoyed two books from that period, Karl Weick’s Sensemaking in Organizations (1995) and the 1994 first edition of Henry Mintzberg’s Rise and Fall of Strategic Planning. (Regarding the latter one, if you can tell me whether I should also read the 2000 second edition, do let me know.)

Reading Mintzberg, what stood out for me wasn’t so much his concept of emergent strategy (arguably not much more than a fancy name for what really happens to our best-laid plans) but these five things:

  1. The limits of rationalism and control, and the apparent disregard shown for them not just by the mid 20th-century strategic planners but by their champions in academia
  2. The idea, attributed to Edelman, of experts being those who avoid (or merely bemoan) the pitfalls but fail to notice the grand fallacy (see point 1 above, and I suspect I may never hear the words ‘expert’ and ‘pitfall’ in quite the same way again!)
  3. Primed by my prior reading of that Weick book on sensemaking, the idea of strategy as the means by which we make sense and meaning of our decisions; strategies don’t just help us to act in the present and project ourselves into the future, their role in helping us reinterpret how we got here is important too
  4. And before we get too comfortable with strategy as story, strategy as theory – something to be tested, lightly held
  5. Brian Loasby’s 1967 Manifesto for the Deliberately Adaptive Organisation

I’m having a bit of fun with that last one of course. I’ve no reason to think that Loasby (now Emeritus Professor in Economics at Stirling University) had anything manifesto-like in mind, and the Deliberately Adaptive Organisation didn’t exist back then. Not even its sources: the Viable System Model (Beer) was not yet fully formed; the Deliberately Developmental Organisation (Kegan & Lahey) was decades off; Agendashift’s main architect (yours truly) was just two years old.

But check this out:

if, instead of asking how they can more accurately foresee future events and thus make better decisions further ahead, firms were to ask first what they can do to avoid the need to decide so far ahead, they might be led to discover important ways of improving their performance.

Brian Loasby, 1967, via Mintzberg

Let me recast that in the “this over that” style of a notable document familiar to many readers, the Agile Manifesto. Adding some flourishes of my own:

In the pursuit of business performance, we are finding it useful to see plans and strategies more as theories to be tested quickly than as predictions and commitments for the longer term. Through this change of perspective, we are learning to value anticipating and meeting needs over setting and meeting deadlines, open options over past decisions, and rate of learning over closeness of control. Not that deadlines, decisions, and control have no value, rather that when valued against needs, flexibility, and adaptability, it is the latter group that drives our development forward.

I am not seriously advocating a new manifesto – for me, that ship sailed long ago – but Loasby was definitely onto something all those years ago. Rewriting history, there is already something Lean-like about his heuristic, and for anyone trying it, I’ve little doubt that Lean’s explicit attention to people and to flow would soon be required in any determined application of it. Invite the customer inside that way of thinking and you get something quite Agile-like. And compared to Agile as first framed, much more obviously relatable to business agility too. Interesting!


What if we put agreement on outcomes ahead of solutions?

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

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

What the (Lean-)Agile scaling frameworks don’t give you

[Minor edits 2020-12-11 and again 2021-01-08 with an updated title. It is now aligned to the final version of the manuscript that went to the publisher this week] 

Not a gratuitous provocation but putting it out there for review. The text below comes from the final chapter of the forthcoming 2nd edition of Agendashift; it’s a quick first draft (written today) and I want feedback! The chapter is new to the 2nd edition; it is titled Up and down the Deliberately Adaptive Organisation and the excerpt below comes at the end of a section called Scaling up.

For context, we have by this point reconciled Agendashift with a powerful diagnostic tool, the Viable System Model (VSM). Stafford Beer’s classic model has lessons for all organisations that have the desire to “meet the demands of surviving in the changing environment”.

What the (Lean-)Agile scaling frameworks don’t give you

I can’t help noting that not everything identified in this reconciliation exercise is addressed well by the scaling frameworks. If you’re looking to one of those as the basis of your Deliberately Adaptive Organisation or (somewhat equivalently) as a model of business agility, here are five things that you may need to attend to yourself:

1. Meaningful experimentation

A worthwhile proportion – perhaps even the majority – of your delivery capacity will need to be devoted to objective-aligned insight generation. There is nothing adaptive about ploughing through backlogs of requirements and hoping for a good outcome. Random experimentation isn’t adaptive either; whilst it flexes some important muscles and can be a useful source of innovation, unless the bulk of it is meaningfully aligned to shared objectives (and driven from them in a way that creates meaning for the people doing the work), it’s unlikely to take you very far.

2. Meaningful negotiation between levels based on trust and transparency

If you’re not careful, cascading hierarchies of objectives end up as backlogs of requirements to be ploughed through, and we know where that leads. Dressing up that hierarchy in Agile terms – saga, epic, feature, story, etc – doesn’t change that.

Remember that what’s asked for, what’s needed, what’s possible, and what’s sensible are four different things. Moreover, each level will have its own language, its own way of looking at things, and its own measures of success, and it’s not helpful when one level projects (or worse, imposes) theirs onto another. Instead: trust-building transparency, then mutual understanding, then alignment.

3. Containers for multi-level, multi-loop organisational learning

I’m referring of course to your framework’s equivalent of the Outside-in Service Delivery Review (OI-SDR) and VSM system 4 more generally. How does your framework help you build and evolve shared models of the system and the world outside? How strong are the expectations of learning that it creates? How does it challenge? How does it help you monitor progress towards objectives? How does it challenge? How does it ensure that intelligence and insights are shared quickly across the organisation?

4. Meaningful participation in strategy

Let me say it again: It’s a funny kind of autonomy when strategy is something that happens to you. Now let me add that it’s a funny kind of adaptive strategy if it doesn’t know how to listen. What we have here are two organisational antipatterns that Agile frameworks – scaled or otherwise – has done little to address. Perhaps it’s unreasonable to expect that they would, but when they’re sold as transformative models of organisation I believe that some scepticism is entirely appropriate.

5. Meaningful self-organisation at every scale

Not just who does what (better described as self-management), but self-organisation as the interplay between structure and spontaneity – who collaborates with whom, at whatever scale, and with what potential. How does your framework both encourage that to happen and ensure that when it happens it is done well?

How well does your scaled (Lean-)Agile implementation demonstrate those five things? The most likely answers are “not very” or “not at all”. If you’re thinking of embarking on a framework-based scaling initiative, I would suggest that it may pay to attend to these issues first. You’ll then be in a much better position both to understand what the frameworks still have to offer and to make whatever further changes now seem necessary.

To be clear, I’m not anti-framework. To understand how a scaling framework really works is to appreciate how its patterns have been integrated, and there’s definitely value in that. But anyone thinking that it’s cool to roll out a large framework waterfall-style is living in the 1990s! Expert-driven ‘tailoring’ doesn’t fundamentally change that. Much better to use your expertise to help people experiment with combining patterns from the full range of sources at their disposal.

Related:


Upcoming workshops

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

And if you’re thinking of becoming an Agendashift partner, it pays to sign up to that first (in fact it might even pay for itself).


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

How I choose my models

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

agendashift-inspiration-map-2020-06-29

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

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

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

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

What I do appreciate:

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

And supporting those:

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

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

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


What if we put agreement on outcomes ahead of solutions?

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

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

Still not a fan of the PDCA cycle or the continuous improvement initiative

I’ve just finished the first decent draft of chapter 3 of the Agendashift 2nd edition and its segue into the more operational part of the book. Choosing my words here quite carefully: you can take this post as warning that I won’t be praising the PDCA cycle or the continuous improvement initiative. There, I said it. Heresy?

Last week I posted this question on LinkedIn:

Ask LinkedIn: Why does Lean Startup’s build-measure-learn loop seem often to sustain itself but the continuous improvement loop (PDCA) that inspired it typically run out of steam quickly? I’ve written on the PDCA problem more than once before and I have plans to do so again but I’m curious to know what people think [source]

36 comments and several good answers later, the one that best gets to the issue is this from my friend Patrick Hoverstadt:

My suspicion Mike is that this is structural – PDCA works ON the process, whereas build-measure-learn IS the process. If you stop doing PDCA, the work still goes on, product still gets produced and shipped and paid for, but it just stops improving. If you stop doing build-measure-learn, then the build part stops, so no product, and the business stops. PDCA shouldn’t be, but often is seen as an extra. [source]

The Agendashift book’s strapline is Outcome oriented change and continuous transformation, so I do need to get beyond just identifying the issue. Here’s how the new chapter 3 begins to tackle it (and for context, here first is the patterns picture):

patterns

The […] myth is that change happens naturally in cycles. You plan an experiment. You do the work of the experiment. You check the results of the experiment. You act on those results. Rinse and repeat, one experiment leading to the next. The PDCA cycle (<figure>) in other words.

Replace PDCA with another improvement cycle and the brutal fact remains: one experiment does not inevitably launch another. Improvement cycles are not perpetual motion machines; they do not sustain themselves. If ever you have wondered why continuous improvement initiatives seem to run out of steam so quickly, perhaps instead you should be wondering how they last any time at all.

Let’s look at two places where experimentation does seem widespread:

  • At the high tech startup
  • At Toyota, the inspiration for Lean

Size-wise, they’re at opposite ends of the scale. So what do they have in common? It can’t be the technology – many of Toyota’s experiments are remarkably low-tech. Common (and I would say glib) answers such as “leadership”, “sponsorship”, or “culture” don’t help much because their respective cultures are so different. There is a grain of truth to them though, and I believe the lesson is this:

Experimentation is sustained where these two things are true:

  1. The learning that it generates matters to people
  2. When that learning isn’t happening, it gets noticed

If you’re not a startup it would be inauthentic to pretend that your situations are equivalent. Even if genuinely you’re in a fight for survival, your organisation most likely has (or at least had) some viable business at its core; the startup lacks even that anchor. And don’t expect to magic up Toyota’s kaizen culture overnight – it took them generations after all.

Agendashift’s answer:

  1. Experiments flow from meaningful outcomes and their measures of success (not rationalised the other way round), each experiment framed to ensure that learning will happen regardless of how it turns out
  2. Experimentation is conducted in the full knowledge that multiple levels of learning will be accounted for in forums that matter

My advice is to abandon the notion of the cycle and to keep separate the framing of individual experiments, the day-to-day management of your active experiments, and the harvesting of learning. Of the three, the last is by far the most important; with the right focus on it, the other two fall into line behind it.

Hence the pattern Right to left strategy deployment, the right to left part signifying the working backwards from meaningful outcomes, the strategy deployment part a reminder (among other things) of ­the importance and relevance of the work. Solving problems just because they are there will no longer do.

A reminder of those three aspects to keep separate:

  1. Framing experiments
  2. Managing your portfolio of active experiments
  3. Harvesting the learning

They’re covered across the final two chapters. The first two of those are well understood and the 1st edition covers them well. For the last one, which really means building a learning organisation, I’ll be pulling out all the stops, integrating (as Agendashift has done consistently for a long time) ideas and experience from Lean-Agile, organisation development, and strategy. Chapter 5 won’t be just the wrap-up chapter, it will be the climax, and I’m really excited about it. Happy to report that doing a 2nd edition is no drag 🙂

Before you go, a couple of dates for your diary:

Only a few places left for that first one. For the second, don’t hesitate to ask for a discount if you think you might qualify on grounds of country, non-profit, government, educational, etc. Also if you’d be a repeat participant, of which there have been a good number!

Related articles


What if we put agreement on outcomes ahead of solutions?

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

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

What I really think about Scrum

[Comments on this post on LinkedIn]

Let’s look at Scrum through the lens of last week’s inverse square law of framework scaling, its power as a framework being the product of:

  1. The incisiveness of its point of view – its core paradigms, principles, values, and so on
  2. The ease with which its key patterns combine – both with each other and with those from outside the framework

Being small, Scrum should do well on both counts; I’ll take them in reverse before returning to how it scales.

The ease with which its key patterns combine

Scrum scores really well here.

Look at Scrum merely as composition of smaller patterns (dangerous, but bear with me just for a moment) and you have to give it significant credit for normalising the practices of daily standup meetings, small-scale planning meetings, retrospectives and so on. Not for everyone an unalloyed good (“too many meetings” is an easy complaint to make if for whatever reason it’s not working), but certainly a mark of Scrum’s success.

And it gets better: Scrum as a whole is small enough that it combines easily with other things. Scrum+XP has been a thing for a long time. I’ve worked with Scrum and Lean Startup in combination (in the government sector, no less). Scrum+Kanban (Scrumban) isn’t just one thing, but several; in Right to Left I describe four common combinations and elsewhere I have counted more (it’s not hard: just consider the different ways in which their respective scopes might or might not overlap).

The incisiveness of its point of view

Here’s where it gets awkward. Scrum isn’t one thing, but two:

  1. Left-to-Right Scrum: the team working its way through a backlog that is determined for it, mostly in advance
  2. Right-to-Left Scrum: the team iterating goal by goal in the direction of its overall objectives

Left-to-Right Scrum is a process that’s mediocre (or worse) to experience, and doomed to deliver mediocre results at best. And it’s easy to see how it happens:

  • Little room in the project for learning about the customer’s real needs or for exploring different ways of meeting them
  • Thinking that the job of Sprint planning is to fill the Sprint to the maximum, a misconception amplified by story points and velocity (the problem not being that they’re nonsense metrics that cause otherwise intelligent people to bestow mystical properties on Fibonacci numbers, but that they reinforce a dysfunction)
  • Reviews not of what’s being learned about the team’s customers, its product, and the team itself, but of progress against the plan
  • Retrospectives that lack the authority to address strategic issues, and that fail to follow through even on the issues over which it does have influence

I’m convinced that Scrum would be considerably less prone to these failure modes if only it would maintain a clearer point of view. Scrum’s tragedy is that it’s presented as a backlog-driven process so often that its core paradigm as an iterative, outcome-oriented process gets lost in the noise. And from that failure, disengagement. All that hating on Agile? You don’t need to look far for causes.

Scaling it up

For the most part, disappointingly predictable and predictably disappointing:

  • Take Scrum and layer on hierarchies of organisation structure &/or work breakdown structure
  • Plug it into a project/programme structure that almost inevitably works in left-to-right terms and is given no reason to think otherwise
  • Compounding it all, the rollout project – failure after failure, but still we do it!

Again, the tragedy is that it doesn’t have to be that way. Instead of layering on so much process that you disconnect teams from strategy and organisation development, invite them in! Instead of losing faith with self-organisation, invest in it! Instead of solution-driven imposition, outcome-oriented engagement! Honestly, it’s not that hard.

We’re in the business of building wholehearted organisations. Need help reorienting your Scrum implementation so that it can work as it’s meant to? Want to put authentic engagement at the heart of your transformation? Get in touch – we’d love to help!

Further reading:

cover right to left audiobook.001

My thanks to Teddy Zetterlund and Steve Williams for feedback on this post, and to Agendashift’s Friday #community Zoom group (details in Slack) for the conversations that preceded it.


What if we put agreement on outcomes ahead of solutions?

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

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

Community: Slack | LinkedIn group | Twitter

#2MBM: Meaning before Metric, Measure before Method

In the models-sources-inspirations picture shared in the  June roundup earlier this week you may have noticed one or more less-than famous acronyms upper right. I did leave a breadcrumb or two, but as was my plan all along, let me spell them out.

agendashift-inspiration-map-2020-06-29

The newest acronym – just days old – is 2MBM. From the patterns page (the Right to Left link points to my book/audiobook of that name):

Right to Left: ends before means, outcomes before solutions, and the two MBMs – meaning before metric and measure before method (2MBM)

MBM 1: Meaning before metric

I’ve been using this one for a while. Some clues here in From Reverse STATIK to a ‘Pathway’ for continuous transformation (October 2019):

This [understanding fitness for purpose] is OK as far as it goes, but the faster it turns … into a conversation about metrics, the less time anyone spends actually exploring purpose. If I’m honest, this part leaves me a little cold … .

My real concern here is with a common behaviour: consultants and other practitioners leading too hard with a favourite metric. My advice: whether they’re pushing lead time, velocity, or NPS, if they’re not also demonstrating an interest in connecting deeply with your purpose, politely show them the door.

More reason to trust your instincts when you feel yourself go cold at the mention of metrics is when they’re imposed as targets. It’s when OKR (Objectives and Key Results) turns into MBO (Management by Objectives), and there’s a reason why the latter is discredited, disowned by its creator (Drucker). Particularly when they’re tied to compensation and advancement, imposed targets inspire creativity of the wrong kind, too-clever ways to meet the goal. In a word: dysfunction.

MBM 2: Measure before method

So…  metrics are bad? No! As we’ll see in a moment they can be a source of healthy creativity if explored at the right time. If the first MBM translates to “not too early”, then the second translates to “not too late”. In fact, there’s “too late”, and then there’s “way too late”:

  • “Too late”: having a solution idea and then coming up with the metrics that it is likely to impact, justifying it on that basis
  • “Way too late”: implementing a solution idea and looking for benefits afterwards

Not so much alignment as post hoc rationalisation, severely limiting the likelihood of any real learning taking place, and missing some vital input into the ideation process.

To illustrate that last point, here’s how we now teach it in Agendashift:

  1. Reacquaint ourselves with the outcome we’ve chosen to work on (remember that with us it’s “outcomes all the way down” and we haven’t even got to the bottom of that stack yet) with Challenge Mapping
  2. Having explored around it, identify a list of success indicators for that outcome
  3. With the conversations of steps 1 and 2 still in the air, generate solution ideas
  4. Select the fantastic option, the one most likely to significantly outperform – relative to the others and disproportionately (non-linearly) relative to its cost and risk

TASTE and ODIM

And finally to two more of the acronyms on my picture (plus a bonus).

Karl Scotland‘s TASTE stands for True north, Aspirations, Strategies, Tactics, and Evidence. What we’ve known for a while – in the Agendashift material we have deliberately made this a two-part exercise to emphasise this point – is to leave Tactics until last. Cross-referencing them in an X-Matrix, we’re asking this question:

  • Inspired by and aligning to our True north, what Tactics (collectively) will support our Strategies and deliver the Evidence of success we hope for? (Aspirations are already correlated with Strategies and Evidence at this point)

Larry Maccherone‘s ODIM stands for Objectives, Decisions, Insights, and Metrics. One creative way to think of it is in behavioural terms:

  • For this objective to be achieved, what will people need to do differently? If that involves them making different decisions, what in their immediate environment will guide those? What then do we need to measure?

In the latest iteration of the Wholehearted:OKR workshop we use TASTE when we’re exploring alignment between levels, a way to build coherence at scale. ODIM is introduced near ideation time (previously it came too early, reducing its impact – no pun intended).

One last credit: I took “Measure” and “Method” come from Salesforce’s management process V2MOM:

  1. Vision— what do you want to achieve?
  2. Values — what’s important to you?
  3. Methods — how do you get it?
  4. Obstacles — what is preventing you from being successful?
  5. Measures — how do you know you have it?

Type 1 MBM but not (as presented here) type 2. Still, it starts in the right kind of place, and for that I’m glad. Thank you Steve Pereira and Tom Kerwin for an interesting Twitter conversation.

Followup post:

Related posts:


What if we put agreement on outcomes ahead of solutions?

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

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

Revisiting ‘wholehearted’

agendashift-banner-2019-12-17

Agendashift’s strapline is “the wholehearted engagement model”, and I’ve been reflecting again on just what we mean by wholeheartedness. That in turns leads me to revisit how I introduce Agendashift – what it is, what differentiates it, and why we do what we do.

Wholehearted

Starting with my reflections on that word, I’m drawn to two clusters of qualities:

  1. Engagement, commitment, and purposefulness
  2. Alignment, integration, integrity, and wholeness

For an organisation to be wholehearted, both sets of qualities must apply. Crucial to developing and sustaining them are participation and outcomes:

  • Participation, because 1) people disengage when they’re denied the meaningful opportunity to influence on how their working environment operates, and 2) you can’t have integrity and wholeness – or for that matter self-organisation and other hallmarks of the modern organisation – when the organisation’s parts don’t relate both between and within themselves frequently and richly enough.
  • Outcomes, for the simple reason that they’re what people align on, and for the more subtle reason that it’s easy to destroy engagement when solutions are put ahead of outcomes. Keep outcomes in the foreground (and not a rationalisation or afterthought) and you create the opportunity for acceptable, effective, and often innovative solutions to emerge at the right time, no imposition needed.

With all of that in mind, Agendashift is best introduced as the wholehearted, outcome-oriented engagement model. Unpacking that backwards:

  • The term engagement model is our preferred shorthand for the kind of thing that Agendashift is, a framework for agents of participatory change and transformation. The framing there is deliberate; we find it necessary to keep a certain distance from the failed solution-driven change management models of the last century and don’t wish to be numbered among them! Neither is Agendashift a model only for continuous improvement, a process that while necessary is not a substitute for strategy.
  • Agendashift is outcome-oriented to such an extent that this is its defining feature. It’s “outcomes all the way down”, dealing coherently, humanely, and strategically with everything from the most aspirational of goals to the impact of the smallest experiment. With outcomes generated, organised, and developed through participation, agreement on outcomes follows naturally; solutions come as they should on a just-in-time basis, lightly held as hypotheses to be tested until some other approach is understood to be safe.
  • We – Agendashift’s founders, partners, and supporters – are wholehearted in our commitments to participation, to outcomes, and beyond those to the wholeheartedness of the organisations with which we work. We strive to develop all the qualities of wholeheartedness, building organisations that create meaning continuously, through both their discourse and their ability to anticipate and meet needs.

We’re in the business of building wholehearted organisations. Are you?

Related


Upcoming workshops

With yours truly unless otherwise indicated:

For some brief commentary:

And for the latest, check the Agendashift events calendar.


agendashift-banner-2019-12-17
Links: Home |
About | Our mission: Wholehearted | Become an Agendashift partner | Assessments | Books | Resources | Events | Contact | MikeSubscribe
Workshops: Transformation strategy | Transformation strategy | Short training
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

My kind of…

Two years ago almost to the day,  I was among a group invited by Pierre Neis to answer this question:

What kind of Agile is your Agile?

I was writing Right to Left at the time, and “my kind of Agile” was already a feature of chapter 2. Here it is (the short version at least):

People collaborating over working software that is already beginning to meet needs

That’s just a starting point. To put it into practice, we work backwards from there, keeping needs and outcomes always in the foreground as we go. Understand how that “right to left”, outcomes-first kind of Agile differs both philosophically and practically from a “left to right”, backlog-driven kind of Agile – a kind that too often involves imposing process on people for the sake of mediocre results (at best) – and you’ll understand why the book needed to be written.

If you appreciate that essential difference already, you’ll enjoy the book’s singular perspective. If you don’t, you’ll find it a highly accessible introduction to the Lean-Agile landscape, one that avoids the mistake of explaining Agile in the terms of the models it seeks to replace, a mistake that undermines it every time it is made.

I opened this post with Pierre’s question of 2 years ago because I was delighted this week to speak at his invitation on “My kind of Agile” at an online meetup he hosts. In preparation I put up a new page:

In the print and e-book editions, My kind of… is Right to Left’s Appendix B. It’s a glossary of sorts, a gathering together of some informal definitions that are especially characteristic of the book. It starts with two versions (shorter and longer) of “My kind of Agile” and continues in that same vein.

If you’re listening to the new audiobook edition – out just a few days ago – the appendices aren’t included, so here you go!

cover right to left audiobook.001

Upcoming workshops (all online of course)

With yours truly unless otherwise indicated:

For the latest workshop and speaking events check the Agendashift events calendar.


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

Agendashift as framework

So here it is, slowly revealing itself online over the past few weeks, and now ready for the formal announcement and some background. It’s the biggest update to Agendashift since the 2018 book and it prepares the ground for a second edition.

New &/or updated:

Previously announced, and updated again in line with the above:

The last of those is of course the basis of Agendashift’s recent rebranding:

Agendashift as framework

From the framework page:

These pages describe Agendashift – the wholehearted engagement model – as an open framework for continuous, outcome-oriented transformation.

Agendashift is primarily for use by agents of strategic change, with or without an explicit Lean-Agile agenda. It is not intended as a replacement for the likes of Scrum, Kanban, or SAFe; neither do we consider it a way to choose between them. Our clear opposition to the imposition of frameworks on the unwilling does not make us anti-framework; rather we’re pluralists, celebrating frameworks as exemplars and sources of patterns that combine in interesting ways.

We don’t however pretend to be neutral. Outcome-orientation is not a neutral stance. If these pages give you a fresh perspective on other frameworks and help you avoid yet another failed or mediocre implementation, that’s definitely for the better. Moreover, it’s not hard to see that whole system engagement and strategy deployment are useful models for delivery in complex environments.

In the past I’ve been a little reluctant to describe Agendashift as a framework, for reasons similar (I guess) to those of the Kanban community: compared to Scrum, SAFe etc, it’s not the same kind of thing at all! Then in Right to Left I made a point of always describing these as process frameworks, solving that problem. And from chapter 3, Frameworks and patterns:

 [The word ‘frameworks’] has multiple meanings. Some of them – Scrum and Lean Startup most especially – are frameworks in the sense that they provide some minimal structure into which specific practices can be introduced. Others – DevOps and Design Thinking for example – are frameworks in the different sense that they provide a particular perspective to an organisational problem and an array of techniques with which to approach it.

Within the context of change and transformation, both definitions apply to Agendashift. What makes the second one particularly interesting is that Agendashift’s needs-based and outcome-oriented perspective has an impact on how you think about and operate delivery too – certainly if you take it to the level of a resolute stance (which of course I do). You could say that this is how I went from Agendashift: Outcome-oriented change and continuous transformation (2018) to Right to Left: The digital leader’s guide to Lean and Agile (2019). Read that and you’ll never look at a process framework in quite the same way again.

Key changes

Principles

I’ve tweaked the wording of principles 1 & 5 (there’s a before & after comparison on the principles page):

principles-2020-04-04

This feels like a good place to start so I’ve made them a little more prominent.

Patterns

This is new. Agendashift can now be summarised as two generative patterns:

Understand those, how they relate to each other, and how they challenge the status quo, and you’re a long way towards understanding both how Agendashift works and why it exists.

I’m presenting the patterns ahead of the five core activities – Discovery, Exploration, Mapping, Elaboration, and Operation – a demotion for those if you like. Certainly I see this as a significant change. Although the patterns are an addition, it’s one that seems to crystallise and simplify; one of the reassuring things about Agendashift is that the more it develops, the easier it becomes.

You may have noticed that I sneaked IdOO into Monday’s post Doing Agendashift online (4 of n): Ideal, Obstacles, Outcomes (IdOO). Behind the scenes there was a flurry of activity making everything ready in time!

idoo-2020-03-25

No doubt I’ll be referencing the second pattern – Just-in-time Strategy Deployment – in a later installment of the Doing Agendashift online series and I’ll keep my powder dry for now. Give it a read meanwhile!

A new overview picture

Bringing it all together:

Agendashift overview 16x10 2020-04

Don’t worry: despite appearances my long-held caveats on the subject of cycles remain. I leave you with this post-workshop tweet from friend and workshop participant Allan Kelly:


Upcoming online workshops


Agendashift, the wholehearted engagement model
Links: Home |
About | Our mission: Wholehearted | Become an Agendashift partner | Assessments | Books | Resources | Events | Contact | MikeSubscribe
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter