One word that came up a few times in last week’s workshop (which got a 12 out of 10 by the way) was emergence. It’s a funny kind of word, one that gets some people excited and leaves others completely cold. That’s due in part to its scientific overtones, but there’s more to it than that.

In its slow form, emergence – as in emergent architecture for example – is regarded as a close cousin of evolution, a process whose results (structures, phenomena, properties) emerge from the repeated application of certain rules and constraints. Done deliberately, it looks something like this:

1. We start where we are, with what we do now, or with a simple but probably inadequate design
2. We wait until we’re dissatisfied somehow with the status quo
3. Following some defined rules and keeping within certain constraints, we make what we hope turns out to be a step forward
4. Rinse and repeat (starting with a new what we do now)

To its fans, it’s reliable way to cause a design to become increasingly fit for purpose – even when the environment around it is continually changing. Two things come with experience of the process:

• Confidence in the outcome – the details of which aren’t planned in advance but familiar patterns and consistent properties do tend to repeat themselves
• The realisation that the process can be guided and accelerated, for example using transparency to promote the activations of steps 2 and 4

Unfortunately, to those that haven’t experienced it, emergence and evolution can be a tough sell (which is why I don’t talk about them much). To some ears, these words evoke a process that’s highly wasteful and almost geologically slow, involving speculation, dead ends, and highly unpredictable outcomes. To others, it looks passive and directionless, change happening only in response to external pressures. No-one wants their organisation to go the way of the way of the dinosaur, and when proactivity is called for, it seems safer to stick to planned approaches with their up-front commitments and rigidly defined outputs – never mind that outputs and outcomes are two very different things!

I’ve hinted that in expert hands, emergence can be speeded up. Sometimes it can be very rapid indeed. Take for example the process we facilitate in Agendashift’s Discovery and Exploration activities through our 15-minute FOTO game:

• Seed the process with a list of obstacles – things that block our path toward our generic True North (for Discovery), impede progress towards specific prompts prioritised from one of our assessments (for Exploration), or some other list
• Identify the outcomes that lie immediately behind those obstacles
• Identify the outcomes behind those outcomes, repeating through several layers, searching deeper and wider into outcome space

At Friday’s workshop we calculated that we were generating outcomes at a rate of nearly 2 per minute per table group. Two table groups were able to produce nearly 60 in just 15 minutes! As facilitator, I can’t predict what specific outcomes will be generated (I’ve stopped trying), but I’ve done it enough times to know that it’s a highly productive process, and that what emerges with the detail is a shared sense of both agreement and ambition. That’s gold!

Agendashift’s tagline is “Outcome-oriented change and continuous transformation”. With apologies to Daniel Kahneman, this is “Emergence, Fast and Slow” – the rapid emergence of agreement on outcomes and the emergence of a fitter, more adaptable organisation in the focussed follow-through. Agreement without the follow-through would of course mean the waste of a few hours or days of work. A much greater waste would be to implement change in the absence of agreed goals, the committed support of the host organisation, and the meaningful engagement of the people affected. They need each other!

Upcoming Agendashift workshops:

• 14-15 May, Munich, Germany – Mike Burrows, Mike Leber
• 22-23 May, Cardiff, UK – Mike Burrows

Blog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

There seem to be two schools of thought on how best to explain iterative and incremental delivery. In the interests of clarity, the “incremental versus iterative” school, represented excellently by Alistair Cockburn, seeks to keep technical definitions separate as far as possible. The “incremental and iterative” school deliberately emphasises the intertwingliness of it all (in fairness both schools I’m not including people who blur the line unthinkingly).

Just for the purposes of this post I’m in the second school. Here’s a cute, mutually recursive definition that describes a healthy delivery process:

Incremental: new goals agreed and achieved with each short iteration, building on previous work

Iterative: seeking to be objectively better with each small increment, learning from previous work

If that’s healthy, what would unhealthy look like?

• Incremental only: big backlog up front (BBUF?), backlog-driven development (the BDD acronym is already taken), no time for learning
• Iterative only: constant tinkering, chasing metrics, busywork, no meaningful alignment on goals

Ugh – you really do need both! If you’re big on planning, break the big rocks down into smaller rocks, and make sure you leave enough gaps between them in every iteration for learning. If you’re big on flexibility (at the extreme, on-demand scheduling), don’t settle for ad-hoc; step back regularly from your individual work items and agree on which goals you’re (self-)organising around.

Related concepts: refinement and fidelity (see this by Karl Scotland). It’s smart to start with crude solutions that kinda work, then refine them incrementally and iteratively (both at the same time):

• Incremental refinement: make refinements you had the good sense to defer
• Iterative refinement: make refinements based on feedback

Credits: Thanks to everyone who commented on my crude, kinda-working prototype micro posts on Slack, Twitter, LinkedIn (and LinkedIn group), also privately on Facebook. In particular: Steven Mackenzie, Roy Marriott, Karl Scotland, Sean Blezard, Ray Edgar, Graham Berrisford, Rob Ferguson, David Daly, Becky Hartman, and Lowell Lindstrom.

Related:

• How I read the Scrum Guide
• Scrum and Kanban revisited

Upcoming workshops:

• 6 April, Raleigh, NC, USA – Mike Burrows, Kert Peterson
• 14-15 May, Munich, Germany – Mike Burrows, Mike Leber
• 22-23 May, Cardiff, UK – Mike Burrows

Blog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

In the context of a discussion about a scaling framework (it doesn’t matter which one), I was asked yesterday in the Agendashift Slack about recurring patterns I’ve seen or applied in my work and whether/how they’ve been affected by Agendashift.

For the sake of minimum argument, let’s say we’re already using both Scrum and Kanban at team level. Basic (and improving) processes are in place, work is visible, and teams are not massively overburdened. It’s not necessarily how I’d start but let’s call that easily-understood baseline ‘play 0’.

After that, here are five key plays from my playbook:

1. Smooth/speed work through dev – often through managing dependencies better, identifying them before work starts, making them more visible, greatly reducing the appetite for starting work that can’t be finished
2. Make the post-dev process more visible – make any issues there too visible to ignore
3. Smooth/speed work through the post-dev process – better conversations at the start of the process (even before dev), better automation, better management of environments, etc
4. Validation – retain ownership of work well past delivery, validating that the impact on user behaviour is as expected and that needs are being met
5. Work on the team/organisation interface – risk management, change management, service delivery reviews (a favourite of mine), team sustainability (funding, recruitment, skills transfer, etc)

In what order? When do you do these things?

Of course it depends, but notice:

• The need for plays 1-3 should become increasingly apparent to the teams themselves once play 0 has taken effect. More experienced teams are likely to notice the need for them sooner; the most experienced ones will not only contain people who know not only that bottlenecks move, but can guess in which direction (and they’re listed in the most common order). These changes happen fastest when they are encouraged and supported by people who know what to expect. An explicit drive towards continuous delivery is helpful, especially with regard to plays 2 and 3.
• Unlike plays 1-3, plays 4-5 are unlikely to appear spontaneously through a process of introspection. They involve some important attitude changes:
  • Work is only truly ‘done’ when needs have been met (and demonstrably so)
  • It is recognised that the host organisation has needs too, and that unless you want live forever in a small Agile bubble, a certain amount (and style) of mutual accountability is healthy, not a threat.

If I’m working mainly at team level, it’s likely that the five plays will happen in roughly the order presented. Play 4 may involve developing some skills that the dev team might not have in abundance initially (user research & testing, service design, service management, etc). Play 5 may come a lot sooner if the right kind of sponsorship is in place, and it helps immensely if there are managers who can also be considered part of the team for at least these purposes (service managers, delivery managers and project managers in GDS projects, for example).

How Agendashift changes things

Let’s recast these plays as outcomes to be achieved:

1. Work flowing smoothly through dev, dependencies managed well
2. Effective management of the process end-to-end
3. Good collaboration end-to-end and an effective technical platform for rapid delivery
4. Proactive alignment of team and customer, more ‘right thing’ than ‘wrong thing righter’
5. Proactive engagement between team and organisation, setting the tone, metrics consistent with values, better alignment overall

As soon as you have agreement on outcomes like these, the opportunity is there for the taking. Of course there are right ways and wrong ways of going about things (and Agendashift provides some help here), but as per my previous post, Getting to Agendashift’s “Why”:

Because when you have agreement on outcomes, the rest is “just” the how…

Agendashift creates the opportunities for outcomes like these to be articulated and agreed upon, even before deep-seated pain points are fully exposed, thereby accelerating the process. They can be tackled in sequence or in parallel, via off-the-shelf practice or innovation, with or without reference to frameworks. The choice is between you and those that you work with and for, defined to some degree by your role already or left open. Where choices are open, make best use of that opportunity: consider a diverse range of options and make progress by testing assumptions relentlessly (advice that works for product development too).

While we’re here

November 8th (tomorrow) is a key day:

• There’s still one place remaining at tomorrow’s workshop in Cape Town
• Early bird pricing for the London workshop on the 22nd and 23rd expires tomorrow

Blog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events):
8th Nov, Cape Town, South Africa; 22-23 Nov, London, UK

Agile, Lean, Kanban, Scrum, SAFe, … plenty of tools to choose from, so why does ‘toolkit’ set my teeth on edge? Perhaps it puts me in mind of the journeyman worker who knows his tools but never really excels at anything.

To be more than a mere journeyman and to progress towards mastery, you need to know more than just the distinguishing features of each tool or body of knowledge. If I were looking for expert advice or inspiration I’d want to see:

1. Some respect for how these different schools came into being, the conditions prevailing at the time, the problems being solved
2. An understanding of the values and principles that explain their design choices and implementation strategies (and I don’t mean just being able to parrot them; values in isolation of practice are meaningless)
3. An ability to describe their ‘lessons’ – key takeaways that you can apply non-prescriptively, perhaps using alternative tools

Some examples of these lessons:

1. From Agile: the power of working collaboratively in carefully controlled chunks goes way beyond what you’d learn from studying psychology or queuing theory separately. It’s not magic (it’s easy enough to explain technically and it’s not hard to bring about) and there’s a positive reinforcement feedback loop there, one in which success breeds greater success.
2. From Lean Startup and Kanban (bedfellows almost from their respective beginnings): make the processes by which you learn about your customers, your product, and yourselves as visible as you can make them. You make rapid progress by continually testing your assumptions about all three.
3. From Scrum: don’t underestimate the value of rhythm. It’s not just the ritual and the predictability, it’s also the opportunities to achieve something meaningful in between (see lessons 1 and 2)

I’d love to see more of these. Can you describe a ‘lesson’ non-prescriptively?

Related:

• Scrum and Kanban revisited
• (Non-)Prescription, frameworks, and expertise

Blog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events):
8th Nov, Cape Town, South Africa; 22-23 November, UK