Engagement: more than a two-way street

September 14th, 2018 is the second anniversary of Agendashift’s public launch. I’m marking the occasion with a post that describes a key motivation and gives some clues about where we’re headed. And while we’re here, if you haven’t recently checked our programme of upcoming workshops, there are four listed at the bottom. Enjoy!

We all know what employee disengagement looks like, how it saps energy and creativity, and not just in the unengaged. I won’t go into all the causes and symptoms here, but briefly, if you take away people’s agency – their perceived ability to make choices for themselves – a stress response is provoked, and not the kind of stress that you would want to find in an organisation that hopes to see people working at their best [1].

Just as anywhere else, disengagement is a very bad sign in the context of [Lean-]Agile transformation. It’s a sign that the change agents (managers, consultants, coaches, etc) don’t know what they’re doing! If people are disengaging because there’s the perception that they have no say in how things are going to work inside their teams, it strongly suggests that they have been denied the opportunity to participate meaningfully in the transformation process. This represents an inexcusable failure to engage on the part of the change agents responsible. It would seem that engagement is a two-way street (actually it’s more four-way intersection than two-way street, but we’ll come to that).

In short, 20th century-style rollout projects and managed change programmes run the risk of destroying engagement. Not only do the ends not justify the means, the means don’t work if the goal is an engaged and creative workforce. That it keeps happening is “an absolute travesty”, as Martin Fowler (an Agile Manifesto signatory) recently put it [2].

So ‘Big Agile’ bad, ‘Small Agile’ good? Not so fast. Agilists lamenting a lack of Agility in the organisation is not engagement. Tweeting false dichotomies about management vs leadership is not likely to engage many managers. Praying for viral adoption is not much of a growth strategy. And don’t get me started on the passive aggression (“We’re so Agile, we only let our stakeholders talk to us in the Sprint review” [3]).

A plague on both their houses then? No! The arguments between the two sides keep missing the crucial point that success depends on engagement. It’s a phony war, fought on the wrong battleground, few shots landed. The apparently less exciting good news: the more that they do engage, the less obviously top-down or bottom-up they become and the more that they have in common. Funny that.

It should now be clear why engagement models [4] such as Agendashift [5], OpenSpace Agility (OSA) [6], Systemic Modelling [7], BOSSA nova [8], and TASTE [9] are so necessary. Non-prescriptive by design, they work happily with frameworks big or small, branded or home-brewed, and with each other. In their various and complementary ways, they bring people together from multiple levels of the organisation, help the organisation collectively to reveal to itself what needs to change, and come to agreement on what needs to change.

But we can go further. In a transformation of any reasonable size, it is inevitable that different parts of the organisation will move forward at different speeds, and this will keep on throwing up new challenges. If we want the ‘new’ to survive and then thrive, then its surrounding organisation must too. If the new is to grow, then the old must adapt. Both have needs, those needs will evolve over time, and attending to them is key to the viability [10] of not just the transformation, but the organisation itself.

What’s needed then is another kind of engagement: not person-to-person but system-to-system. It raises questions like these:

  • How does strategy work going forward? How will ‘old’ and ‘new’ participate in the processes of strategy development and deployment?
  • On the day-to-day stuff of delivery, how will old and new coordinate with each other effectively?
  • How might this play out over time, and what implications will that have for the easily-forgotten, slower-changing, but still critical parts of the organisation? (For example, what role do HR and Finance play in the staffing, skilling, and funding of a very different-looking organisation?)
  • How will we know that it’s working? How will we know to intervene when it is not?
  • How will we know that we’re winning? Then what?

These questions could easily be re-framed so that Agendashift-style tools can be used to explore this evolving landscape. For example:

  • What obstacles will prevent ‘old’ and ‘new’ participating in the processes of strategy development and deployment as we move forward?

(Then from obstacles to outcomes (FOTO) [11] – you know the drill)

Whether we’re talking about Agile process frameworks or engagement models, I don’t honestly think it’s sensible to expect off-the-shelf products to have answers to these questions. What’s important is that they’re asked and answered, then re-asked and re-answered as the transformation progresses. Instead of glossing over them, how about embracing them? Does this not invite management from both sides of any old/new divide to become more engaged, to take more responsibility for the process, and for new kinds of leadership to develop as a result?

Screenshot 2018-09-14 05.50.14
No shortage of opportunities for both kinds of engagement [12]
I believe this represents a massive opportunity for the engagement models. It’s not that we didn’t already kinda know this, but we’re going to make it more explicit, both because it’s important in its own right and because it further exposes the bankruptcy of approaches based on imposition and other negligent forms of non-engagement. A concerted effort is gathering a head of steam here in Agendashift-land [13], and we collaborate with our friends in our peer communities too. No lack of choice there!

Notes & references

[1] I credit the phrase “working at your best” to Caitlin Walker’s From Contempt to Curiosity: Creating the Conditions for Groups to Collaborate Using Clean Language and Systemic Modelling, Caitlin Walker (2014, Clean Publishing). You can see its influence in the Agendashift True North (agendashift.com/true-north).

[2] The State of Agile Software in 2018 (martinfowler.com). Key quote:

The Agile Industrial Complex imposing methods on people is an absolute travesty

[3] A sensible enough short-term policy designed to protect the newly-forming team becomes dogma, to the long-term detriment of all.

[4] Engagement model: For Daniel Mezick’s quick introduction to the concept, see Engagement (openspaceagility.com). Key quotes:

Engagement Model (noun) : Any pattern, or set of patterns, reducible to practice, which results in more employee engagement, during the implementation of an organizational-change initiative.

If you cannot name your Engagement Model, you don’t have one.

[5] Agendashift™: agendashift.com, and of course the book, with communities on Slack and LinkedIn. Twitter: @agendashift

[6] OpenSpace Agility™: openspaceagility.com, with communities on Facebook and LinkedIn.

[7] Systemic Modelling™: See Clean For Teams: An Introduction to Systemic Modelling (cleanlearning.co.uk) and Caitlin Walker’s book above [1].

[8] BOSSA nova: See the website and the book by Jutta Eckstein and John Buck. Twitter: @AgileBossaNova

[9] TASTE: Karl Scotland’s take on Lean strategy deployment, with the X-Matrix as a key artefact. See the blog posts TASTE Impacts, Outcomes and Outputs and TASTE Success with an X-Matrix Template. Karl is also a leading collaborator on Agendashift; the upcoming Brighton workshop (see Upcoming Agendashift workshops below) includes both.

[10] My choice of the word ‘viability’ is deliberate. Its conventional meaning works fine, but I’m also alluding to Stafford Beer’s Viable System Model (VSM). Rather than the somewhat impenetrable Wikipedia page I would wholeheartedly recommend Patrick Hoverstadt’s excellent book The Fractal Organisation.

[11] 15-minute FOTO (agendashift.com/15-minute-foto), our Clean Language-inspired coaching game, Creative Commons licensed, available now in several translations.

[12] Figure based on Agendashift chapter 5 and my keynote Inverting the pyramid.

[13] Channels #right-to-left and #systhink-complexity in the Agendashift Slack. Note the title of the pivotal fourth chapter of Right to Left (due 2019). Twitter: @RightToLeft3

Acknowledgements: I’m grateful to Allan Kelly, Daniel Mezick, Philippe Guenet*, Karl Scotland*, Mike Haber, Thorbjørn Sigberg*, Andrea Chiou*, and Jutta Eckstein for their feedback on earlier drafts of this post. Asterisks indicate Agendashift partners.


Upcoming Agendashift workshops (UK, IT, DE)


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

A small departure from the book

Slightly technical, but if you’re interested in what we know to be a remarkably effective combination of Clean Language, Cynefin, and Story Mapping as practiced in most Agendashift workshops, read on…

One of the notable highlights of an Agendashift workshop comes when we take the list of outcomes generated by the 15-minute FOTO game [1], transcribe them onto stickies, and organise them 4-points style [2]:

cynefin-finished-2017-12-16

Through the experience of the ‘4 points contextualisation exercise’ (to give it almost its full name), participants are slowly introduced to the Cynefin framework [3], the facilitator trying all the while to avoid naming the model or using Cynefin terminology such as ‘obvious’, ‘complicated’, ‘complex’, or ‘chaos’ (trust me, it’s hard!). For participants familiar with the model, it’s always a funny moment when the penny finally drops and the realisation dawns that Cynefin can be so much more than just a conceptual model, especially when there’s a good supply of ‘narrative fragments’ – outcomes, in our case – to play with. For those that haven’t come across it before, it’s a great opportunity to explore why different kinds of outcomes need different kinds of approaches, a lesson that’s much more meaningful when it’s learned through interacting with your own data (‘sensemaking’) than it would be as a lecture.

Up to now – and as described in the book [4] – the translation from the Cynefin representation to one based on a story map has been a 2-stage process. First, a few minutes of organised chaos as stickies are moved to under their respective headings:

Second, as much time as we want to spend – anything from a few moments to an hour or more – prioritising stickies within columns, and through that process making sure that there is a shared understanding of what each of them means and their possible dependencies on other stickies. Anyone who has done story mapping before will recognise that this can provide an important opportunity for some valuable conversations; we’ve found this to be the case even in public workshops, with ‘teachable moments’ aplenty.

A refinement

Instead of the ‘organised chaos’ followed by prioritisation, work clockwise from bottom right, prioritising as we go:

  • Starting with the ‘obviously obvious’: Sticky by sticky, check that they really are obvious (ie we can all quickly agree what needs to be done and can be pretty sure of the likely outcome), put them in their correct columns, and prioritise. Prioritisation will be easy, as there’ll be at most a few per column, a mixture of quick wins and less important items.
  • The ‘borderline complicated’: For the items on the border between obvious and complicated, explore why they were placed there, and discuss what should be done about their non-obvious aspects (perhaps there’s some important detail that someone will need to get to grips with). Prioritise them relative to the already-prioritised ‘obviously obvious’ items in their respective columns (again, this should be easy)
  • The complicated, one sticky at a time: who might be delegated to run with this item? Should we get some external help? In its appropriate column, how does it prioritise relative to the items already there?

I could at this point say “and so on through the complex and chaos” but the facilitator will flag up here that anything in or bordering on complex is likely to be a good candidate for hypothesis-based change (a session later in the day, see also [5]), and so it’s a good idea to mark each item in some way so that they can be identified easily later. And for the borderline cases:

  • ‘Borderline complex’: Are the complicated and complex parts easily separable? How will we organise this, mainly linear with some room for refinement along the way, or mainly through iteration with some expert input or planned work at the appropriate time?
  • ‘Borderline chaos’: Is it urgent to address symptoms or or attempt some diagnosis now, or can we afford to wait until we see what’s thrown up in the course of other work?

I’ll be honest: it’s still early days for this change and there’s no slideware [6] for it yet – if any is needed we’ll learn that through practice and by partner demand. That’s usually the best way!

[1] 15-minute FOTO, our Clean Language-inspired coaching game
[2] Cynefin Review Part 7 – Finding Your Place on the Framework (adventureswithagile.com)
[3] The Cynefin framework (wikipedia.org)
[4] Agendashift: Outcome-oriented change and continuous transformation, Mike Burrows (New Generation Press, 2018), chapters 2 and 3 in particular
[5] The Agendashift A3 template (and chapter 4)
[6] The Agendashift partner programme

Finally, some opportunities to experience it for yourself:


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

You can’t deliver a task

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

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

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

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

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

Screenshot 2018-05-05 06.23.15Our handy, referenceable, Definition of Done

Public workshops (US, UK, IT, DE)


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

‘Right to Left’ works for Scrum too

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

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

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

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

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

  • A product owner creates a prioritized wish list called a product backlog.
  • During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
  • The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
  • Along the way, the ScrumMaster keeps the team focused on its goal.

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

Let’s try a right-to-left description:

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

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

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

[1] Understanding Lean-Agile, right to left

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


Upcoming workshops


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

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

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

51inQ8o4t9L

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

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

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

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

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

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

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

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

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

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


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: 
Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

Towards the wholehearted organisation, outside in

It’s one of those often-cited, non-enough-read books, Christopher Alexander’s The Timeless Way of Building, the classic book on architecture and the built environment that inspired the patterns movement in software (think Gang of Four Design Patterns, PLoP, etc).

It’s a rewarding read – philosophical in a way that is both surprising and delightful, and (whether intended by the author or not) full of ideas that are just asking to be carried over to other domains. I read it with organisation design in mind.

This favourite quote isn’t specific to building but it is loaded with metaphor:

Screenshot 2018-05-26 11.52.59

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

In my keynote talk Inverting the pyramid, I use this quote to introduce a section on outside-in reviews – for example the strategy reviews and service delivery reviews that follow the kind of outside-in agenda as described in chapter 5 of the Agendashift book:

  1. Customer
  2. Organisation
  3. Platform
  4. Product
  5. Team

Juxtaposing these different perspectives – each one presented by the people who are best equipped represent them – increases our chances of not only bringing our inner contradictions and misalignments to the surface, but of finding better ways to meet external needs too. Within each agenda item, a right-to-left [1] structure: what we’ve recently learned about how things are, what we’re beginning to learn through experimentation, and what experiments we plan to conduct as capacity permits.

Some context and an invitation: As mentioned a few days ago, I have just begun work on my third book: a no-nonsense, leader’s guide to Lean-Agile, organised around the three themes of right to leftoutside in, and upside down. Join us in the #right-to-left channel in the Agendashift Slack to monitor progress and to discuss any of these three themes.

Related posts:

[1] Understanding Lean-Agile, right to left


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: 
Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

Understanding Lean-Agile, right to left

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

 


Now suppose you had to understand Lean-Agile. Where do you start? With people collaborating over software that is already beginning to work for its customers, or with backlogs and projects? Working software, or JIRA?

With the Agendashift book [1] only just out of the door, I’ve begun work on the prequel, a no-nonsense guide to Lean-Agile, the kind of book you’ll give to your manager and hope that they’ll pass on to theirs. And yes, we’ll start right to left, beginning at the point where needs are met [2] and working our way upstream. We’ll describe what it’s like to have Lean and Agile already working well, and demonstrate powerful ways to understand, manage, and improve almost any kind of delivery process.

There’ll be two more themes: outside in and upside down; more on those soon. Join us meanwhile in the #right-to-left channel in the Agendashift Slack [3] if any of these themes are of interest to you. Perhaps you have relevant examples or models that support these themes, or are already beginning to wonder about how they might be applied in your current situation and have questions.

[1] Agendashift: Outcome-oriented change and continuous transformation
[2] My handy, referenceable Definition of Done
[3] Agendashift on Slack


Upcoming Agendashift workshops:


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: 
Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…