Tag: business-agility

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 Flow to Business Agility

Posted on by Mike Burrows

Preamble: You may have noticed that I don’t use words like ‘waste’, ‘improvement’, or ‘flow’ nearly as much as my history in Lean-Agile [1, 2] might suggest. Recently [3] I expressed what could be interpreted as a lack of enthusiasm for a more recent term, ‘cognitive load’. Not to put fuel on the fire but to put those and similar terms into what I think is their proper context, here’s where I’m coming from.

Pick a scope, any scope. Bigger is better perhaps – your whole organisation even – but what I’m about to share works for small scopes too, your team, say.

Now picture its sweet spot, a metaphor for the set of its most desirable states or configurations: the right people working on the right things, the right conversations happening at the best possible moment, needs anticipated, met at just the right time [4].

Enjoy that for a moment.

What stops that? What gets in the way? Well, here’s how it often plays out.

Decisions on what work to start aren’t always optimal, and to correct past decisions, new work may need to be started. Already, and despite good intentions, we’re out of that sweet spot.

As a consequence perhaps of those earlier decisions, some of what is in progress can’t be finished, so yet more things get started. Inevitably, before this increasing pile of work finishes, new work arrives, and some of that gets started too.

Those “right conversations”? Can’t you see that we’re busy? Now there’s work being done by people who don’t have all the customer or business context they need. This results in yet more work – rework. With all of that going on, little thought can be spared for the question of how the organisation itself impedes those conversations. 

“Needs anticipated, met at just the right time?” You’re kidding me! People overburdened, work lying around not getting finished, staff and customers alike frustrated by delays, the business having to finance not only the productive, value-adding work, but the delays and the rework too. That sweet spot turned out to be a tiny island in an ocean of other, far less desirable states.

The improvement story runs in the opposite direction. Focusing on finishing. Learning to be more careful about what gets started when. Reducing overburden. Testing assumptions sooner [5]. Improving quality. Reducing rework. These are measures that promote flow – better for the people doing the work, better for the customer, better for the business – a triple win!

So far, so conventional. Is that all there is to it? Of course not. If it were enough simply to manage the process more efficiently, why not just outsource it or sell off the offending product line? Let others find the efficiencies! That can’t be the right answer for most teams, most product lines, or most organisations – those with any kind of future ahead of them at least – but if the logical conclusion of that kind of thinking is a race to the bottom, there must be something that we are missing. Clearly, there’s a trap here.

With some justification, the missing piece is often assumed to be purpose. But the issue is even more basic than that. It is viability. Excluding perhaps project organisations whose mission and timescale are bounded, most organisations would not wish to pursue purpose in ways incompatible with survival, and efficiency is only part of that challenge.

John Boyd (of OODA loop fame) [6], described the challenge as one of “developing our capacity for independent action in a changing environment”. If there is a better definition of the pursuit of viability than that, I haven’t found it. Understand (as Boyd did) the competitive nature of that challenge, and it describes business agility very well too. Without going too deeply here into the study of viable systems [7] (fascinating, but outside the scope of this article), let’s try to make that actionable.

First of all, let’s see all that waste (including other forms of waste not identified above) not only as impediments to flow (as measured by things like lead time, flow efficiency, etc), but as drains on the organisation’s decision-making capacity. All that extra workload, the constant context switching, the quality issues, the dependencies, the frustration, the untested assumptions, the rework, and so on and so on – all of that needs to be dealt with, consuming the decision-making capacity of every participant in the system.

Conversely, improving the system releases decision-making capacity. A good thing no doubt, but improve the system enough it might seem to someone obsessed with efficiency that we now have excess capacity. That’s people we no longer need, right? It’s that trap again!

To understand why that decision-making capacity is so vital, we must understand that sweet spot not as the ultimate goal, but as a local optimum. Adjacent to it are other possibilities – possibilities that people now have the capacity to explore. And what lies beyond those? Not just optimisations to the end-to-end process, but new communication channels that might one day lead to new organisational structures. Not just changes in practice, but innovations and understandings that might lead to radically new solution ideas. Not just improved performance, but the organisation reaching a different understanding of itself and its position in the world.

That is what “developing our capacity for independent action in a changing environment” looks like. Turning that around, if you’re not developing your capacity for independent action, sooner or later you run out of options, and it’s game over. That applies at every level: to the organisation, to its larger structures (teams-of-teams, value streams, cross-cutting structures, and so on) down even to its teams and their team members. It applies to you. At none of these levels do you want your capacity for independent action to be so constrained that effectively you’re out of options. You don’t want to be out of options, and you don’t want that happening around you either.

You thought business agility was only about speed? Think again. Business agility comes from the capacity to keep creating options (ie to strategise), to select and test the best of them at the right time and with sufficient pace (I hesitate to call that execution), and to keep learning from the experience. To sustain it, the organisation must keep striking the right balances between delivering to existing commitments, discovering new opportunities, and developing the capacities they will need. At any level of organisation, some of those activities may (rightly) bring into challenge its structure, its purpose, even its identity. All of that demands decision-making capacity at every level [7, 8].

Decision-making capacity is a fundamental constraint on organisations. Without it, needs and challenges go unrecognised. Opportunities go unexplored. Options don’t get generated. Good options don’t get exercised at the right time or with the right priority. It is provisioned not only by reducing wasteful drains on it (reducing what is popularly known as cognitive load), but by enabling it to be exercised effectively. Therein lies the organisational challenge, because it depends on the availability of opportunities to participate and on situational awareness, both of which are constrained by far more than workload [9].

Ask yourself this: what is stopping people from deciding for themselves to do the right thing, to deviate where necessary from accepted practice, to seek to understand their work more contextually, to empathise more deeply with the customer, to interact with different people, to enter into new collaborations, to self-organise around new challenges – ie to innovate process-wise, product-wise, or organisationally? This is the organisation exercising and developing its capacity for independent action, but if the cost is too high or the capacity simply isn’t there, it won’t happen. Or perhaps at some level it is happening, but the surrounding organisation is too focused on other things for it to make a difference.

The truth is that no formal process or organisational structure can guarantee you the decision-making capacity to deal with every situation that your organisation will face. In a changing environment, they may hinder as much as they help. Whether for reasons material or psychological, the people closest to the challenge may feel constrained from acting. Lacking context, others around them may fail to lend their support. The wider organisation may be impeded structurally from recognising that the problem or opportunity even exists.

Yes, it’s important to seek efficiencies, to reduce waste, to pursue flow, to iterate and learn faster. But don’t see it only as a productivity play. If you aren’t quickly seeing the improvements spill over into a more profound kind of capacity [10], it could be that you aren’t helping your organisation half as much as you think. Your organisation’s reserves are enormous. Is it time you released them?

(Comment on LinkedIn | Hacker News)

References

[1] Kanban from the Inside (2014)

[2] Right to Left: The digital leader’s guide to Lean and Agile (2019, audiobook 2020)

[3] I may be on my own here but… (linkedin.com)

[4] Borrowing from Agendashift True North (agendashift.com/resources/true-north)

[5] Cockburn, Alistair, Elements to a Theory of Software Development (HaT Technical Report, 2016)

[6] Boyd, John R., Destruction and Creation (U.S. Army Comand and General Staff College, 1976)

[7] Everywhere all at once: Introducing the Deliberately Adaptive Organisation (agendashift.com/resources/everywhere-all-at-once)

[8] Adaptive Organisation (I): Business agility at every scale (academy.agendashift.com/c/adaptive-organisation-i)

[9] Between spaces, scopes, and scales: What the scaling frameworks don’t tell you (agendashift.com/keynotes#between)

[10] Explaining the “unreasonable effectiveness” of Agile (blog.agendashift.com)

Acknowledgements

For their encouragement, feedback, and comments as this post developed over the holiday period I am grateful to the following: Andrea Place, Badre Srinivasan, Cat Hicks, Craig Lucia, Daniel Walters, David Michel, Dickson Alves de Souza, Dustin Parham, Elizabeth Jones, John Obelenus, Karl Scotland, Kyle Byrd, Leif Hanack, Matt Mitchell, Matthew White, Michael Cicotti, Nader Talai, Nariman Dorafshan, Ricardo Alvarez, Robert Howes, Sarah Whitely, and Shern Tee. Thank you all.

1

It’s 10 years since the post that changed my career

Posted on by Mike Burrows

Happy New Year! For me it’s a big anniversary: this time in 2013 I had spent the New Year’s break taking the principles and practices of the Kanban Method, and from them abstracting a system of nine values. Then on January 3rd, I published Introducing Kanban through its values. Kanban’s values model was born.

Nine values are quite a lot to hold in one’s head at once, so I soon learned to present them in groups:

  • An initial six, or two groups of three: transparency, balance, and collaboration, then customer focus, flow, and leadership
  • Then understanding, agreement, and respect, which for reasons of brevity are often subsumed under leadership

In most of the decade since, it has been my most-read post each year. And it led to my first book, Kanban from the Inside (2014), which remains a Lean-Agile classic. Great! Now what?

I had no interest in making Kanban any more technical than it already was; if anything, the values model would always draw me in the opposite direction. Neither was I drawn to the emerging Kanban Maturity Model (or any other such model). What I did instead was to allow a common problem to bother me: why do so many people arrive at the training class not knowing why they are there? Tempting as it might have been to see that as a failure of administration or marketing, I saw it instead as a symptom that there were important organisational conversations that simply weren’t happening.

I realised quickly that this problem was far from unique to Kanban. To those that resent having had Scrum or (later) SAFe thrust upon them, the Agile manifesto’s “People and interactions over processes and tools” must ring rather hollow.

That took me away from Kanban into the realms of organisation, leadership, and strategy, to the development of Agendashift, and then sort of full circle, not back to Kanban and Lean-Agile specifically, but to business agility. Ten years on, as practice gets refined through use, as its message gets refined through the telling, and as we dig ever-deeper roots into the available theory, three main topic areas co-evolve together:

  1. As described now in two editions of the Agendashift book (2nd ed 2021), Agendashift the engagement model (thank you Daniel Mezick for describing Agendashift as such) and dialogic/generative organisation development approach (thank you Gervase Bushe & Bob Marshak), a way for practitioners to approach organisations without prejudging what solutions they will employ(/impose/inflict) and instead to help them have those missing conversations – engaging in participatory strategy, as it turns out
  2. The wholehearted organisation, a deliberately minimalistic values-based model of organisation and leadership, a spinoff from my third book, Right to Left: The digital leader’s guide to Lean and Agile (2019, audiobook 2020) that unexpectedly gained a life of its own
  3. The leadership development curriculum Leading with Outcomes, which compared to Agendashift minimises detail relevant mainly to practitioners, and instead distils some easily-learned patterns, strategies, and organisational models relevant to leaders at all levels, leaders in transforming organisations most especially

Explicitly in both Agendashift and Leading with Outcomes and implicitly in wholehearted, we have doubled down on the eighth value of that initial nine-value model, namely agreement. What if we put agreement on outcomes before solutions? One way or another, I’ve been asking that question for most of the past ten years, and I have no doubt that it will keep me going for a good while yet.

I no longer identify as a Kanban guy. That separation was necessary to what followed, but all these years later I remain proud of the work I did there, of that first book, and of the blog post that started it all. Not that I’m planning on retiring anytime soon, but I have long seen it as marking the beginning of the rest of my career.

[Comment on this post on LinkedIn]

Related:

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.

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.

The 1967 Manifesto for The Deliberately Adaptive Organisation

Posted on by Mike Burrows

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

What’s new in the February Deep Dive workshop

Posted on by Mike Burrows

February’s Agendashift Deep Dive isn’t just the first of the year, it’s the first since I delivered the manuscript for the 2nd edition (publication is due in March). The revision process has helped me identify a number of improvements to the workshop materials. More significantly – and as I mentioned in my previous post on strategy [1] – we have been digging some deep foundations in systems, organisation, and personal development over the past 18 months or so, work of a kind that takes its time to feed through.

There are two main elements coming now to the foreground. One is pre-existing, familiar to followers of this blog, and receiving an upgrade; the other is new. But before I introduce them, a reminder of what Agendashift is: it’s an engagement model. And what does an engagement model do? My definition [2] states that they have three jobs to do:

  1. To structure and support the work of those that would encourage innovation, change, and transformation
  2. To help the organisation engage its staff meaningfully in change-related work
  3. To keep the the organisation’s parts engaged with each other as they change

Visualised:

2021-01-18-engagment-model

The upgraded and new elements in Agendashift speak to the Organisation box in that picture:

  1. Wholehearted, our mission [3]
  2. The Deliberately Adaptive Organisation, a non-prescriptive but still powerfully diagnostic model of business agility

In the 2nd edition you will see Wholehearted reconciled to two foundational models, Bushe & Marshak’s Generative Change Model [4] and Stafford Beer’s classic Viable System Model (VSM) [5]. Out of that reconciliation come a number of base assumptions [6] that Deep Dive participants will have the opportunity to validate, reject, or reflect on. (I’ll share them here once the book’s out.)

Book-wise I nearly left it there, but after sketching out an appendix with more detail on how that reconciliation worked, I felt compelled to add a whole new final chapter, Up and down the Deliberately Adaptive Organisation, a title inspired by Robert Kegan & Lisa Laskow Lahey’s Deliberately Developmental Organisation [6]. My model plugs theirs, Agendashift, Sociocracy [7], and OKR [8] into VSM. Thanks to the way that VSM scales – fractally – the combination is able not only to describe team-level, organisational-level, and people-level agility in one self-similar model, it reveals some of the organisational issues that Agile delivery frameworks either ignore or exacerbate [9].

For the Deep Dive, the Deliberately Adaptive Organisation helps to put several of our tools into better perspective, including:

I may also add an exercise on those scaling issues.

Details of that February Deep Dive:

And before that:

For all three 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. Many of those considerations apply to private workshops also.

For the Deep Dive especially, if you think that you might become an Agendashift partner, partner discounts make it well worthwhile to get on board before you sign up to the workshop.

References

[1] If you are not already engaging on strategy, the time to get serious is now (January)
[2] agendashift.com/about
[3] agendashift.com/wholehearted
[4] The Dynamics of Generative Change, Gervase Bushe, Gervase R. Bushe, (BMI Publishing, 2020)
[5] The Fractal Organization: Creating Sustainable Organizations with the Viable System Model, Patrick Hoverstadt, (John Wiley & Sons, 2008)
[6] Organizational Culture and Leadership, Edgar H. Schein, (Jossey Bass, 5th edition, 2016)
[7] An Everyone Culture: Becoming a Deliberately Developmental Organization, Robert Kegan & Lisa Laskow Lahey, (Harvard Business Review, 2016)
[8] We the people: Consenting to a Deeper Democracy, John Jr. Buck & Sharon Villenes, (Sociocracy.info Press, second edition, 2019)
[9] What the (Lean-)Agile scaling frameworks don’t give you (December)

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

0