Tag: scaling

Agile’s Great Rebalancing: My next book’s take on the Agile manifesto

Posted on by Mike Burrows

Some context: Measured in chapters (not time, alas) I’ve reached the halfway mark in the writing of my fifth book, Wholehearted: Engaging with Complexity in the Deliberately Adaptive Organisation, completing the first three of six chapters and with those, part I (Business agility at every scale) of two parts. I’ve adapted the article below from a passage in Chapter 1 in which we’re exploring a space I call Delivery-Discovery-Renewal (Figure 1). That space encompasses the productive activity of a team or other organisational scope at any scale of organisation – everything that’s done in the “here and now”, as opposed to, say, planning or retrospecting.

Figure 1. The Delivery-Discovery-Renewal Space

The Delivery-Discovery-Renewal Space comprises the following:

  1. The value-creating work – delivery-related work (obviously), discovery-related work (making sure that we will be delivering the right things, scouting for new opportunities), and renewal-related work (working on the organisation itself, building and improving the capabilities needed)
  2. How that work is coordinated – understood very broadly as all the constraints on that work that have any kind of coordinating effect
  3. How that work is organised – organising around commitments and managing towards goals, another set of constraints on the work

…and their relationships:

  1. Mutual relationships between systems 1, 2, and 3 above, i.e. between the value-creating work, how its is coordinated, and how it is organised – how they constrain each other, how they inform each other, the effects they have on each other, and so on
  2. The relationship with the external environment – for the purposes of this article, relationships with customers and users most especially
  3. Relationships inside system 1 above (the value-creating work) – collaborations, process-defined interactions, structures, and so on

You may recognise there a good chunk of Stafford Beer’s Viable System Model (VSM), and with the mention of constraints, hints of something complexity-related also. The Deliberately Adaptive Organisation model and the forthcoming book cover three such spaces (Delivery-Discovery-Renewal, Adaptive Strategising, and Mutual Trust Building), the relationships between them, relationships internal to them, and the much-neglected relationships between different scales of organisation.

It is very much a relational model, i.e. not a process model but complementary to those, providing them with some sorely-needed theory, particularly on matters of scale. It is easy to engage with, it provides a fresh perspective on familiar things, it translates straightforwardly to a complexity-based perspective, and it can be the basis of a participatory strategy process – all very different from the more analytical ways in which such models are typically used.

In the lightly-adapted excerpt below, we are mid-chapter. You might find it worth giving the above introduction a second read therefore (I’ll refer to Figure 1 more than once). Somewhat in the vein of my January post From Flow to Business Agility (by a huge margin my most-read post of the year so far), we are exploring a key question for the Delivery-Discovery-Renewal space and for the other two spaces:

How might we increase our decision-making capacity?

The Great Rebalancing

One important way to increase decision-making capacity in this Delivery-Discovery-Renewal space is to move away from people serving the process and toward the process serving those who do the work. Some clear signs of success:

  • Routine work can be done with negligible overhead
  • Coordination problems – contention, overburdening, starvation, and the rest – are seen not as facts of life that people must simply endure, but as symptoms of something systemic that can and should be addressed
  • In non-routine situations, appropriate courses of action are made no harder than necessary by, for example, bureaucracy or overly restrictive policies
  • Those doing the work have appropriate control over their working environments, and that agency is seen as a potential source of innovation

Each of those reflects some change in the balance between the elements I identified in the introduction to this article, most especially between the value-creating work and how it is coordinated (systems 1 and 2 respectively in Figure 1 above). Taken together, they remind me of the Agile manifesto [1] and, in particular, the first and most famous of its four “this over that” declarations: “Individuals and interactions over processes and tools”. The remaining three declarations can be understood in a similar way, i.e. as representing a sometimes radical rebalancing of relationships inside the Delivery-Discovery-Renewal space.

“Working software over comprehensive documentation”: If we’re staying strictly within the Delivery-Discovery-Renewal space and focusing on the work rather than the thinking behind it, this declaration impacts mostly the balance between upstream and downstream activities. This idea has consequences in many spheres outside of technology development and the book will develop it further. Here though, let’s understand it in manifesto terms.

The 1990s, the context in which Agile arose, saw the peak of the linear project model. Technology projects proceeded in a sequence of phases (see Figure 2 below for an example), and because activities were separated in time, those upstream-downstream relationships barely existed. And at such a cost! As projects moved from one documentation-heavy phase to the next, the emphasis was on demonstrating that the latest work conformed to expectations set in preceding stages, not on establishing whether those expectations were based on accurate assumptions. When those assumptions were about the behaviours of users and people-based systems, they would often prove unsafe, but by the time they were invalidated it was already too late.

Figure 2. A linear project model

The remedy: upstream and downstream activities no longer in separate phases but tightly integrated in an iterative or continuous process. With people from different disciplines working closely together, feedback could come in days or less, not the weeks, months, or longer that it took previously. In support of those collaborations, documentation would become much more granular, produced no earlier or later than needed (i.e. just in time), taking perhaps the minimalistic form of user stories [2] or job stories [3], describing not whole projects but very thin slices of functionality – specific usages of individual features. Given an appropriate sequencing of these small but still individually useful deliverables, an incomplete but still meaningfully useful product could emerge quickly. With more time, and perhaps over an indefinite period (funded not as a project but as a product line), it could evolve into something fitting.

The genuine documentation needs of developers, customers, and end-users never completely went away, and there remains the responsibility of the Delivery-Discovery-Renewal space towards its future self. Pity the poor person who, a year from now, has to understand the design decision you made today or debug the code that you’re writing. Perhaps you owe it to them to leave at least some clues, not to mention that this poor person might turn out to be you! Working in the here and now, when the creation of those usually very small pieces of documentation is an integral part of the development process, a more maintainable system results. There remains a need, however, to keep that effort proportionate to its value, an issue outside the “here and now” and the province of the Adaptive Strategising space.

“Customer collaboration over contract negotiation”: The obvious rebalancing here is away from an adversarial relationship that makes change difficult and increasingly costly as it is delayed, and towards a partnership relationship in which risks and benefits are shared equitably and managed cooperatively. The benefits in terms of decision-making capacity alone are enormous, and I have first-hand experience of it working wonderfully in surprising settings.

Before the launch of the UK’s Government Digital Service in 2011, who would have thought that working on a government project as part of a mixed team of staff and consultants could be a truly special experience? As the interim delivery manager on two of GDS’s ‘exemplar’ projects, I experienced exactly that. There were two customer relationships there: the supplier/government relationship and the government/citizen relationship. By far the more important relationship there was the second, and the abiding principle was “Start with needs: user needs not government needs”. That was more than a slogan. We lived by it, and projects that couldn’t demonstrate it would find themselves in trouble.

Of course, beyond the neglect of user needs there are other ways in which the customer relationship can become dysfunctional. The rapid growth of the attention economy, the asymmetries involved in the handling of personal data, and the rise of AI have combined to create a new issue: the technology/user relationship becoming exploitative to the extent of causing real harm. Unlike the Agile revolution, I don’t see the technology industry solving this issue itself; it has become a matter for governments.

One cause of these problems is that the customer and the user are often not the same person. A sponsor paying for a system they will never use isn’t as troubling as an advertiser paying for access to data the user regards as private, but their product teams ignore the user at their peril. Users have untapped expertise, and how they interact with the product has a lot to teach the product team. Even the bad guys know that they need to make their products usable! Again: software cannot be said to be “working” if it fails to meet user needs, and if that needs to be expressed contractually, so be it. Better still, get users as close to the team as you can manage, even part of the team where that’s possible.

“Responding to change over following a plan”: This is the last of the Agile manifesto’s four “this over that” declarations. For the most part this one belongs with the Adaptive Strategising space, but – spoiler alert – the relationship between that space and Delivery-Discovery-Renewal works through what the two spaces share, the scope’s ability to organise (labelled 3 in Figure 1 above). In the “here and now” of this chapter, the relevant capacity-sapping dysfunction is over-commitment.

Overcommitment is closely related to overburdening and one may contribute to the other, but they should not be confused. Overburdening, a coordination dysfunction (system 2 in Figure 1), leaves a team, activity, process, or other organisational scope in an unhealthy and poorly performing condition because it is trying to work on too many things at once. This multi-tasking incurs costs in context switching, quality issues, delays, and frustration. Compounding all of that, additional work in the form of rework. Overcommitment, a dysfunction in organising (system 3 in Figure 1), means that new commitments can’t be made without breaking commitments previously made. Whether that’s the result of taking on too much work, working to a planning horizon that’s too long, working in chunks too large, or working to plans that leave insufficient room for manoeuvre, that’s a different but similarly serious problem. The scope’s capacity for independent action – John Boyd’s definition of viability – is compromised.

Taking those last three “this over that” declarations together, an Agile process matches its commitments to the short length of time it takes to generate useful information. Progress is made hypothesis by hypothesis, goal by goal. Out of an Agile process, products aren’t built fully formed to a design fixed in advance; they emerge.

When I use ‘Agile’ capitalised like that, I’m describing things that can be traced back to the Agile manifesto. In that sense, the forthcoming book is an Agile book per se; its roots are elsewhere. You can see in the above discussion, however, both what’s at stake and what’s possible. This is not to say that all is rosy in the Agile world: my previous books all address the issue of the Agile industry imposing process and practice on people, to the extent that “Individuals and interactions over processes and tools” can seem cruelly ironic at times. Nevertheless, I make the bold suggestion that Agile has been more successful – unreasonably successful – than perhaps its own community realises.

Consider the effect of this Great Rebalancing (or if you prefer, a great shift in organisational constraints) not only on the decision-making and communication capacities of the teams involved but also on those around it. Capacity that previously was consumed by the need to manage teams from the outside has been relieved of much of that burden. Capacity thus freed can be applied to more interesting things. That improves the experience of leadership, increases the quality of leadership, and greatly increases the chances that self-organised innovation will occur not only within teams but at larger scales too. That is what the book will be about: identifying and dealing with dysfunctions at every scale, enabling other great rebalancings, and unleashing thereby other kinds of “unreasonable effectiveness”.

Ping me if interested in tracking progress on the book; some have early access to the manuscript already, and with a view to getting multiple perspectives on it I will be setting up multiple review circles in the coming weeks covering tech, healthcare, education (i.e. universities), faith communities and other voluntary or not-for-profit organisations, and the systems and complexity communities.

See also Leading in a Transforming Organisation in Berlin, London, and Southampton in the list below of upcoming events. Highly relevant! Days 2 and 3 have much the same structure as the book. Likewise, under the heading of Leading with Outcomes, the self-paced Adaptive Organisation parts I & II further down the page below.

[1] More properly the Manifesto for Agile Software Development (2001), agilemanifesto.org

[2] See my favourite Agile book: Jeff Patton and Peter Economy, User Story Mapping: Discover the Whole Story, Build the Right Product (2014, O’Reilly Media)

[3] Another book that I recommend frequently: If interested in job stories and the jobs-to-be-done (JTBD) framework, start here: Bob Moesta & Greg Engle, Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress (2020, Lioncrest Publishing)

Upcoming events

February

March

*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:

  1. Foundation module:
  2. Inside-out Strategy:
  3. Adaptive Organisation:
  4. Outside-in Strategy:

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.

Agendashift™: Serving the transforming organisation
Links: Home | Subscribe | Events | Media | Contact | Mike
Agendashift  Academy: Leading with Outcomes | Trainer and Facilitator Programmes | Store

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.

From “What did you do yesterday?” to something better

Posted on by Mike Burrows

Go for it! If the main purpose of your standup is to make sure that everyone is keeping themselves properly busy, then the questions “What did you do yesterday?” and “What will you do today?” are without doubt the basis of a great meeting format.

But be careful what you wish for. If your goals involve 1) the team meeting needs, and 2) learning from the process, those questions can hurt a lot more than they help. Honestly, I’m not a fan at all.

You could try these instead. Understand the pattern, and with practice, it runs itself:

  1. What are we learning from what we recently completed? And is it staying completed? Whose needs did we meet, and how do we know we met them?
  2. What can we get over the line?
  3. What is and isn’t making the expected progress? Are we clear about whose needs we’re meeting, what needs, how we’ll know, and what’s our approach?
  4. Do we have the capacity to look at what’s next, or is that enough until we next meet?

You probably won’t get to that overnight, so some things to try:

  • Instead of reviewing activities (what you did, what you’re doing, etc), try to focus the things that you as a team are trying to produce, in the context of the goals you’re pursuing
  • All else being equal (in bigger meetings, this pattern can work within other interesting ways to structure the work), try reviewing your work most-complete work first, not forgetting to start with celebrating and enquiring into work recently completed
  • Make a point of noticing how the conversations change as you work backwards, and develop your repertoire accordingly – by this stage you’ll likely be noticing not only a performance difference but a language change and changes to people’s expectations and behaviour, and you can build on that until they become habits
  • In all of the above, try keep in your mind and everyone else’s what you’re working backwards from: “someone’s need met” and “all the available learning fully accounted for” (my definitions of done and really done)

I’ve used this “right to left” technique in a range of settings, often supercharging something that really wasn’t working before – standup meetings, risk & issue review meetings, service delivery review meetings to name just three. Right to left is named after Kanban’s board review pattern (you start on the right-hand side of the board with work at or nearest completion) but it’s not hard to apply in other settings.

And it’s more than just a productivity hack. In my third book Right to Left (2019, audiobook 2020), I take that philosophy of working backwards from impact and learning and use it as a lens on the whole Lean-Agile landscape (and more). Further to it not being just a Kanban thing, the book shows how right to left fits very well with the best of Scrum. Contrast that with an all too prevalent left to right kind of Scrum that does the reputations of Scrum and Agile no favours at all, and that scales up in the worst possible way. Fortunately it’s fixable.

This post started out as a LinkedIn post, then a second:

  1. Go for it! (linkedin.com)
  2. Building on that last one… (linkedin.com)

And now a third:

    Like, comment, share!

    You can also take any questions you may have to one of the upcoming webinars – the first three (December 8th, January 12th, February 2nd) all finish with an AMA (Ask Mike Anything) session. Series link: The questions that drive us (eventbrite.co.uk).

    Related:

    Upcoming:

    Agendashift™: Serving the transforming organisation
    Agendashift  Academy: Leading with Outcomes | Facilitator and Trainer Programmes
    Links: Subscribe | Events | Contact | Mike

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

    If you want to understand scaling… (part 2 of 2)

    Posted on by Mike Burrows

    If you want to understand scaling:

    1. Start with what must be true at each scale of organisation (part 1)
    2. Then with what happens between scales (this post)

    Where we got to last time (and from there to what a healthy relationship with the process frameworks looks like):

    • A structure that makes sense – not just tidy on paper, but purposeful at every scale – allowing each unit at every scale to self-manage effectively (structuring itself to minimise dependencies, for example)
    • Each unit at every scale able to express its own strategy in its own words, in terms appropriate to its domain and its customers, aligning it with other units and other scales according to both structure and opportunity
    • Each unit at every scale able to identify what it must manage at that scale – no more and no less – with protocols to deal with what should be managed elsewhere

    We reached those conclusions via a route that made it very obvious that each of them apply at every scale, and that the consequences can be serious if there’s a problem with any of them. But it doesn’t stop there. Whilst it’s possible for a scale to be badly designed in its own right – awkward structure, missing capabilities, or poor coordination to name but a few – it’s not hard to see that the relationships between scales are no less important. If anything, they’re more troubling.

    Consider these:

    • One unit doing the coordination work of another – micromanaging, or interfering in other ways
    • One unit doing the strategy work of another – imposing it downwards (directly, via an overly-top-down or centralised plan), second-guessing upwards, etc
    • Units taking on responsibility for outcomes over which they have insufficient control
    • Units providing insufficient transparency about strategy, progress, or risks for related others to make good decisions
    • Units failing to share useful intelligence
    • Or conversely, units not listening (or worse, punishing unwelcome news)

    These describe dysfunctional relationships even when they’re between peers, but when there’s any kind of power imbalance involved, those at the receiving end may feel powerless to fix them.

    The Deliberately Adaptive Organisation

    Let’s recast those challenging but still fixable problems more positively, as principles. These are table stakes I believe for any serious approach to scaling. With minor caveats they apply to every identifiable scope or scale:

    1. Each responsible for its own strategy and accountable for its own performance
    2. Respectful of the autonomy of others, each responsible for its next level of internal structure and its self-management across it
    3. Each committed to building mutual trust in every direction

    Choosing its models carefully to maintain that “at every scope or scale” vibe, the Deliberately Adaptive Organisation (deliberately-adaptive.org) integrates the following:

    • From Agendashift: rapid strategy development and alignment between scopes and scales through generative conversations, multi-level participation, and outcome-orientation
    • From Lean and Agile, patterns for collaboration and coordination, and the deep integration of delivery and learning
    • From Sociocracy (known to some as dynamic governance and to Akoff fans as circular hierarchy), consent and purpose as the basis for effective self-organisation and governance
    • From the Deliberately Developmental Organisation (as described in An Everyone Culture by developmental psychologists Robert Kegan and Lisa Laskow-Lahey), attention to the human side of development

    What holds it all together is one of the crowning achievements of Systems Thinking, Stafford Beer’s Viable System Model (VSM), perhaps the most powerfully “at every scale” organisational model in existence. We take the management consultant’s Swiss Army knife and give it some 21st-century attitude in an innovative and accessible presentation.

    Given that most of the popular approaches to scaling focus mainly on process, it is important for me to stress that the Deliberately Adaptive Organisation is not a process framework. Neither is it prescriptive. Instead, it is two kinds of model in one:

    1. Diagnostic, but only in the everyday sense that it helps with the identification of dysfunctions and opportunities (building on strengths as well as mitigating weaknesses), not in the sense that those dysfunctions become the excuse for heavy-handed prescription
    2. Generative in the sense that it helps organisations engage constructively with themselves, generate a wealth of ideas, and find their own way forward

    If you know Agendashift (mostly generative, with the diagnostic part done generatively), you will recognise that winning combination. In fact, the Deliberately Adaptive Organisation is introduced in the closing chapters of the Agendashift 2nd edition (2021), my previous book Right to Left (2020) doing some of the setup.

    And development continues. After I release this month the final instalment of Outside-in Strategy: Positioned for success, production work begins on Adaptive Organisation: Business agility at every scale, the fourth and last module in the Agendashift Academy’s Leading with Outcomes curriculum. Then sometime next year I hope, a book (my fifth – I have a fourth book close to completion, more on that another time).

    As that roadmap indicates, the earliest access to the next iteration of the Deliberately Adaptive Organisation will be via the Academy, and you can be part of it. Join one of our regular Ask Me Anything sessions and even before the content is released I’ll be only too happy to explore it with you. Subscribe now:

    Take me to Leading with Outcomes

    If you want to understand scaling:

    1. Start with what must be true at each scale of organisation (part 1)
    2. Then with what happens between scales (this post)

    Agendashift™: Serving the transforming organisation
    Agendashift  Academy: Home | 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

    If you want to understand scaling… (part 1 of 2)

    Posted on by Mike Burrows

    If you want to understand scaling:

    1. Start with what must be true at each scale of organisation (this post)
    2. Then with what happens between scales (part 2)

    Let’s begin with teams, or more specifically with its members, people. Even allowing for diversity, there are a number of near-universal things you can say about the members of any well-established team:

    • They each know who they are; many will also have a sense of who they’d like to be
    • They each know what they want to contribute; many will also have identified capabilities they’d like to develop
    • They each have a sense of what they can manage on their own and what should be managed more collectively

    There are some boundaries there. They may be fuzzy and there may be room for negotiation in the short term and for development in the longer term, but cross them – insist that people do things that “aren’t them”, aren’t what they signed up for, or take away their ability to self-manage to the level they expect – and you have unhappy people in an unhappy team. For example, most people don’t like to be micro-managed; neither do they want to see important things left unattended.

    Now to the team itself. You’d be hard-pressed to find a high-performing team for which these aren’t true:

    • There are collective senses of identity, purpose, and of what it aspires to
    • It knows what it’s there to do, what it is capable of, and ways in which those capabilities might be developed
    • It knows what it can manage for itself as a team, and (conversely) what needs to be managed more collectively, ie with (and perhaps by) other teams – potentially even with others outside the organisation

    Again, there are some boundaries there. Fuzzy and negotiable no doubt, but only a fool would think they could cross them without negative consequences.

    Jump now to the organisation as a whole. I almost don’t need to write these points down, but I will:

    • It has a sense of identity, a sense of purpose, and a sense of what it aspires to
    • It knows what it’s there to do, what it is capable of, and ways in which those capabilities might be developed
    • It knows what it can manage for itself as an organisation, and (conversely) what needs to be managed with others – suppliers, customers, industry groups, and so on

    You can be pretty sure that if there are significant issues with any of those points, you’re looking at an organisation that has problems – big problems. At the extreme: identity crises, or working catastrophically beyond its capabilities or its remit.

    Starting again at the level of the individual, on the topic of what makes the work meaningful, the answers may vary hugely. Moreover, you never know until you ask, and perhaps not even then until you get to know them well enough. At higher levels, diversity of purpose and capability is essential to meeting the complexities of the business environment. The successful organisation has them distributed effectively whilst maintaining some coherence of its own, not an easy balance to maintain when the environment is changing.

    What does all that mean for teams-of-teams? Does this repeating pattern – a pattern that already works at three levels – the levels of individuals, teams, and the whole organisation – apply at other scales? Pretty much!

    If your team-of-teams doesn’t have its own sense of identity and purpose – meaningful to the people in it, not just its designers – it is unlikely to amount to anything more than an aggregation of its parts. What is it for? What is it capable of? What does it add, other than overhead? If this problem is widespread, you have a structure that is hard to navigate, a direct cost to the organisation and potentially a problem for customers too.

    What if it has those senses of identity and purpose but not a sense of where it would like to get to, what it would like to become, and so on? In that case, what holds it all together as its component parts continue to develop?

    And what does it manage? If it’s trying to manage what its constituent parts are capable of managing on their own – interfering, in other words – it does both them and itself a serious disservice.

    All that said, what does good look like?

    • A structure that makes sense – not just tidy on paper, but purposeful at every scale – allowing each unit at every scale to self-manage effectively (structuring itself to minimise dependencies, for example)
    • Each unit at every scale able to express its own strategy in its own words, in terms appropriate to its domain and its customers, aligning it with other units and other scales according to both structure and opportunity
    • Each unit at every scale able to identify what it must manage at that scale – no more and no less – with protocols to deal with what should be managed elsewhere

    Any problems here I would characterise as organisational problems first (the organisation getting in the way of doing the right thing), problems of the strategy process second, and problems of the delivery process third – a distant third if the first two are in any way significant. And as leadership problems? It is hard work for leaders when these problems aren’t dealt with, so let’s be careful not to personalise problems that may not be of their own making. Neither should we underestimate the power of participation, self-management, and self-organisation. But if as a leader you’re getting in the way of the organisation fixing its problems or are complacent about them, well that’s on you.

    Neither should you expect your problems of organisation, strategy, and leadership to go away by rolling out a process framework. Why would they? I don’t know if we have got to “peak process framework” yet – I don’t suppose we can know until some time afterwards and I’m not ready to call it – but in the meantime let’s be realistic about what they can and can’t do. And while we’re at it, let’s not pretend that a framework rollout is an easy and risk-free thing.

    Much as I detest the rollout, this is not an anti-framework rant. If you find the opportunity to borrow from a framework as you address those more fundamental problems, that’s totally sensible – there’s no point in reinventing the wheel. You are still are in control of your own destiny, free to pursue what really matters.

    Before part 2, more on the topic of maintaining healthy relationships with frameworks in these two articles:

    On some of the leading frameworks themselves:

    And to those bigger themes:

    Watch those last two come together in the coming months. At the Agendashift Academy, the final Leading with Outcomes module, Adaptive Organisation: Business agility at every scale is due in the autumn. You can get ready meanwhile with the first three modules:

    1. Leading with Outcomes: Foundation
    2. Inside-out strategy: Fit for maximum impact
    3. Outside-in strategy: Positioned for success
    Take me to Leading with Outcomes

    If you want to understand scaling:

    1. Start with what must be true at each scale of organisation (this post)
    2. Then with what happens between scales (part 2)

    Agendashift™: Serving the transforming organisation
    Agendashift  Academy: Home | 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

    Updated: Agendashift’s three meta strategies

    Posted on by Mike Burrows

    [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 Outcomes | Home | 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

    Agendashift’s three meta strategies

    Posted on by Mike Burrows

    Or less grandly, three things to keep doing if you’re doing anything strategy-related (which, if you think about it, should be a lot of the time).

    Meta strategy 1. Keep asking this question: “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. Keep outcomes in the foreground; you’re ‘done’ when needs have been met, ‘really done’ 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 manage for progress, 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 levels or hierarchy and more in terms of identity. 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 (and more powerfully), 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 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.

    deliberately-adaptive-image

    Summary

    Agendashift’s three meta strategies, things to keep doing if you’re doing anything strategy-related:

    1. Keep asking this question:
      • What if we put agreement on outcomes ahead of solutions?
    2. Keep outcomes in the foreground:
      • You’re ‘done’ only when needs have been met
      • You’re ‘really done’ only when you have fully accounted for all the learning
    3. Keep developing your understanding of where all this happens:
      • Less in terms of hierarchy
      • More in terms of identity

    [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, audibook 2020)

    What if we put authentic agreement on meaningful outcomes ahead of solutions?

    Welcome to Agendashift™, the wholehearted engagement model

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

    What if we put agreement on outcomes ahead of solutions?

    Agendashift™: Serving the transforming organisation
    Agendashift  Academy: Leading with Outcomes | Home | 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