A new template for Celebration-5W

Nicely following on from my post a few days ago on ‘Open‘, here’s a community-driven enhancement to our Creative Commons-licensed workshop kickoff exercise, Celebration-5W, in which participants capture the ‘Who, What, When, Where, and Why’ (the journalistic 5Ws) of a celebration that will take place some months from now. I use it to capture or create some shared context not just for classic Agendashift workshops, but also for my ‘outside-in’ strategy workshops (more on those coming soon in Right to Left), where a sense of timescale is very helpful.

Mike Haber took my “Clean sheet of A3, portrait mode, big bold headings down the page” and came up with something significantly better:

This is great, and not just because it looks good – it’s really clever!

The original guidance as described in the deck and in chapter 1 of the book suggests that you start with ‘When’ (How long will we need to achieve something meaningful?) and work backwards through the ‘What’ and the ‘Who’ before finishing up with the ‘Where’ (a venue that makes some kind of statement) and the ‘Why’ (the importance of not just the celebration but the whole endeavour). With Mike’s layout, this translates to “Start with the When (bottom right) and work anticlockwise” – much more elegant! For presentation purposes, it’s natural to start either top left with the ‘Who’ and work clockwise or left-right, or in the visually impactful middle with the ‘Why’.

The Celebration-5W Dropbox now includes an updated facilitation deck with instructions for both old and new layouts, also a printable template (I just bought myself an A3 printer with very much this kind of thing in mind). Request access here.

I will of course be using this new template in my upcoming workshops; Julia might too. Check out details of events in Seattle, London, Boston, Berlin, Stockholm, and Oslo below.


Upcoming Agendashift workshops

See also the recent blog post: Agendashift workshops in Seattle, London, Boston, and Berlin, which includes a detailed description of the 2-day workshop. Workshops facilitated by Mike Burrows (yours truly) unless otherwise indicated:


Blog: 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…

 

On the quality and nature of backlogs

From the Agendashift and Agile and Lean Software Development LinkedIn groups (the second by request):

If you’re building systems for use by humans, ploughing through backlogs of requirements  – however well they might be written – rarely delivers anything better than mediocrity. Conversely, in a high feedback environment (where ideas get tested very quickly), even apparently low-quality inputs can deliver great results, if the inputs do at least focus collaboration and innovation on the right challenges.

Not that the “upstream” folks get a free ride from me – it’s their job to ensure a ready supply of those right challenges to work on, options developed to an appropriate level of detail just-in-time. What’s “appropriate” here is highly contextual, depending as it does on the degree of uncertainty involved and the skillset of the team. Focussing on the quality of the backlog as a whole would be a mistake and not a metric I would want anyone to take seriously.

That’s taken a little out of context and there is no doubt a risk that I’ll be misunderstood, but the comment stands alone well enough I think. One thing is for sure: I completely stand by the idea that ploughing through backlogs is a recipe for mediocrity, particularly when the system under construction is mainly for use by real people. I said it before in Agendashift and I’ll be saying it again (albeit for a different audience) it in Right to Left.

As to the idea that focussing too much on the quality of the backlog can be a trap for the unwary, let me quote from the draft of Right to Left. Here we’re describing close collaboration between development and its ‘upstream’ process in a digital context where this kind of working is now very well proven:

[They] learned to stop thinking of [their ‘upstream’ process] as a phase broken down into stages with gates in between; now they understand it as managing a portfolio of options for the best possible return. The best ideas will be released quickly, perhaps even before they are fully formed – the opportunity being great enough that more eyes and hands should be involved sooner. Some ideas take longer to mature, the cost/benefit equation being sufficiently marginal that a few rounds of prototyping and user testing might save the team some wasted effort later. The least promising ideas will languish for a while before a positive decision is made to reject them. No-one mourns a rejected option; each one is a bullet dodged, waste avoided.

Focus less on the backlog itself and more on the job that it has to do!


Upcoming Agendashift workshops

See recent blog post: Agendashift workshops in Seattle, London, Boston, and Berlin

Facilitated by Mike Burrows unless otherwise indicated:

open_leadership_symposium_speaker_burrows


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…

Agendashift roundup, January 2019

A shorter and less structured roundup this month – there are a number of additions and changes to the events calendar in the pipeline and I’ll begin to announce these separately in the coming weeks. Watch out for details of 2-day Advanced workshops in the UK, the Netherlands, in Germany, Scandinavia, Greece, and the US. The last of those will be announced as a masterclass linked to an exciting new event, The Open Leadership Symposium, which takes place in Boston in May.

Right to Left

Before things get crazy again I have a quietish February in prospect and there’s every chance that I’ll have a decent draft of Right to Left done by the end of the month. I’ve been aiming for early summer for publication; dare I say late spring now? We’ll see!

To whet your appetite, the first few paragraphs of the introduction now appear on the Right to Left landing page. If you’d like to read the whole introduction, drop me a line or visit channel #right-to-left in Slack.

Changeban and Featureban

My recent trip to India plus a private workshop back in the UK has given me three more opportunities to run Changeban sessions, two of them for 50+ people at a time. Based on the experience of those larger sessions (both of which were recorded; fingers crossed we’ll be able to share at least one of them) I’ve switched around some of the introductory slides – in the ‘endgame’ part, if you’re familiar with it. If you’ve signed up to the Changeban Dropbox, look for a version 1.1 deck. Nothing fundamental, it just flows better.

I’ve still not had the chance to test Featureban with Changeban-style rules and it seems likely that others will beat me to it. When that does finally happen (and I’ll be grateful), watch out for Featureban 3.0. Until then it remains at version 2.3.

Questions? #changeban and #featureban in Slack.

Top posts

  1. My favourite Clean Language question
  2. A Grand Unification Theory for Lean-Agile?
  3. How the Leader-Leader model turns Commander’s Intent upside down (June)
  4. Right to Left: a transcript of my Lean Agile Brighton talk (October)
  5. My kind of Agile (November)

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 Grand Unification Theory for Lean-Agile?

The job of chapter 3 of the forthcoming book Right to Left: The digital leader’s guide to Lean and Agile is to introduce a number of important Agile, Lean-Agile, and associated frameworks. I have taken care to describe them not as alternative solutions that must be chosen between, but as patterns to be combined in interesting ways. That’s not a new idea, but what does seem remarkable is how helpful a right-to-left perspective is in explaining how they work together and complement each other. When I say right-to-left, we’re talking not just collaborative, continuous, pull-based, and so on (concepts conventionally associated with Lean-Agile) but something very explicitly outcome-oriented.

Almost verbatim from the manuscript:

  1. Scrum (and Scrum-based scaling frameworks, if that’s your bag): continuously iterating on and self-organising around goals (short term outcomes) in the pursuit of longer term outcomes – product vision, the team’s mission, broader organisational objectives, and so on
  2. Kanban, making progress on outcomes visible, concentrating effort on the ones that matter most, fostering a focus on completion
  3. XP and DevOps, right across development and production, providing the infrastructure of process, practice, and technology necessary to accelerate feedback on the delivery of outcomes
  4. Service Design Thinking (along with user research, user experience and so on), continuously discovering which outcomes are important
  5. Lean Startup, pursuing business viability through continuous deliberate experimentation, managing for impact (outcomes again), finding and continuously refining a business model that enables customer outcomes to be sustained

Here it really is outcomes that holds everything together, not (as you might expect) flow, collaboration, or some other shared value or technical principle. This way, we avoid saying “if you dig deep enough, they’re the same” (which I hear from time to time and strongly reject, believing that it does each framework’s creators and communities a huge disservice).

Neither are we saying “don’t use frameworks”, if (and it’s quite a big if) this means that you must always start from first principles. A sensible way to start is again outcome-oriented and has a measured and pragmatic attitude towards frameworks (quoting this time from chapter 4, Viable scaling):

  • Identify needs – looking at what kind of organisation you’re trying to be and at what you’re trying to achieve  – and the obstacles that currently prevent those needs from being met
  • Agree on outcomes, not just goals plucked out of the air, but the kind of outcomes that might be achieved when these obstacles are removed, overcome, or bypassed
  • On a just-in-time basis, prioritise outcomes and generate a range of options to realise them, using your favourite frameworks as sources of ideas (not excluding other sources, but valuing coherence nevertheless)
  • In manageably small chunks of change and through a combination of direct action and experimentation (choosing between those approaches on a case-by-case basis according to the level of uncertainty and risk involved), begin to treat change as real work: tracking it, validating its impact, and reflecting on it just as we would for product work

In a nutshell, I’ve described Agendashift, which is of course a right-to-left approach to change and transformation. Other engagement models exist – see OpenSpace Agility (OSA) for another excellent, well-documented, and highly complementary example. Whichever approach you choose, take care to choose one that models Lean and Agile values, lest the dissonance proves too great and you fatally undermine your work, a very real risk. To sow disengagement would be a truly bad outcome!

Related:


Subscribe here for monthly roundups and very occasional mid-month announcements

Upcoming public Agendashift workshops (India*2, US*2, UK, Netherlands):

Also: Channel #agendashift-studio in the Agendashift Slack if interested in a cozy workshop with me at Agendashift HQ (Derbyshire, England).


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…

 

Rejection, insight, and learning

Two questions:

  • When did you last reject an idea as a result of deliberate testing?
  • What did you learn in the process?

And a followup question:

  • How does your process encourage that kind of rejection and learning to happen?

If your process doesn’t keep asking the right questions, you can be pretty sure you’re over-investing either in stuff no-one needs, or in changes that won’t deliver the organisational benefits you expect. But if you program in the time to reflect on your rejected ideas (however sporadically they’re currently happening), the rest might just follow.

Here’s how at the end of the Changeban [1, 2] game we model that reflection and introduce two key concepts: the hypothesis and double-loop learning [2] (notice the two levels of learning identified by the red callouts):

changeban-retrospect-on-experiments-2018-12-03

In theory, if you have an organisational design that encourages double-loop learning, the rest of your process will soon catch up. In my experience however, it’s rare to see it outside of those organisations that haven’t already chosen to pursue a hypothesis-driven, outcome-oriented, ‘right-to-left’ kind of delivery process.

For example, heavily ‘projectised’ organisations typically learn painfully slowly. This is only partly explained by the fact that they do everything in large batches that take a very long time to process. There are deeper issues:

  • Once the scope of a project has been decided, the mere thought that there might be more needs to discover and respond to is often actively discouraged. If discovery happens at all, it is done by people outside the delivery team in preparation for future projects, greatly limiting the opportunity to integrate new learning into current work.
  • Similarly, when the ironically-named ‘lessons learned’ meeting finally arrives, it is already too late for the project in question to test any proposed process changes, and it’s unlikely that other projects will be ready to do much with the insights generated either.

Not that Agile has this stuff completely sorted either:

  • Backlog-driven Agile projects (four words that will never gladden my heart) remain susceptible to the scope problem, and typically they don’t make a habit of framing individual pieces of work in ways designed to invite challenge
  • Even where the delivery process is a good generator of insights, team-centric Agile tends to limit the organisational scope of any learning

In Right to Left [4] (due summer 2019) I will describe a style of delivery organisation that has i) managed to let go of that old left-to-right kind of thinking, and ii) explicitly created not just opportunities for organisational learning to happen but the clear expectation that it will will be happening all of the time, a natural part of the process, and ‘real work’.

Fortunately, there are enough real-world examples of right-to-left thinking out there that I know that it is no idealistic fantasy. Neither is it a doomed attempt to shoehorn diverse experiences into a single and over-complicated delivery framework or to extrapolate from the experiences of just a few. Rather, the right-to-left concept represents a concentrated essence of Lean, Agile, and Lean-Agile working at their best, a helpful metaphor, and a unifying theme, one that allows me to celebrate a wide range of models, tools, and examples. Each of those is unique and special, but a commitment to learning connects all of them.

In the meantime, don’t forget Agendashift [5, 6]! This is no stopgap, but rather an approach to change and transformation through which that same right-to-left philosophy runs very deep. If you’re in the business of change in what could broadly be described as the Lean-Agile space and are hungry for alternatives to 20th century change management, the book and the tools it describes could be just what you’re looking for.

[1] Changeban (www.agendashift.com)
[2] Changeban has reached version 1.0 (blog.agendashift,com)
[3] Double-loop learning (en.wikipedia.org)
[4] Right to Left (www.agendashift.com)
[5] Agendashift: Outcome-oriented change and continuous transformation (www.agendashift.com)
[6] Agendashift (www.agendashift.com)


Subscribe here for monthly roundups and very occasional mid-month announcements

Upcoming public Agendashift workshops (India*2, Netherlands):


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…

My kind of Agile

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

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

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

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

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

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

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

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

  • Assumption 1: Direct, ongoing collaboration with customers is necessary to develop and maintain a mutual understanding of needs and potential solutions
  • Assumption 2: Collaboration across the entire process is what makes the whole greater than the sum of its parts – not just multiple perspectives brought to bear on complex problems, but new ideas created in the interactions between people
  • Assumption 3: The most effective way to build anything complex is to start with something that works[2], and ensure that it still works as it evolves. This is true not just for products, but for the working environment in terms of its technical infrastructure, processes, practices, organisation, and culture (not to mention all the complex interactions between those all of those internal elements, the product, and the outside world).
  • Agile’s breakthrough comes from bringing these assumptions together to everyone’s attention in the form of a compelling values statement. The underlying message is clear: wherever those assumptions are likely to hold, you would be wise to behave accordingly!

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

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

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

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

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

Screenshot 2018-11-16 10.40.57


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


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…

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

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

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

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

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

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

X and not Y

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

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

X and not yet Y

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

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

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

Neither X nor Y, but Z

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

X and Y

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

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


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


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…