Emergence, Fast and Slow

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:


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

Centered and T-shaped (sub)communities

On the evening of my arrival at Raleigh, NC from across the pond, I gave a new talk on my first book Kanban from the Inside. Here’s a slide I used to explain the philosophy behind Part II, Models, addressing in particular the question of how multiple (and some would say competing) models can be used together:

Screenshot 2018-04-04 15.28.37

I’m not going to expand on bullet 1 other than to point the curious in the direction of Gall’s Law.

Bullet 2 is much more up my street, and I’ve stuck to this line consistently – it’s pretty much the definition I use for the Lean-Agile community in the Agendashift book: a community that celebrates Lean and Agile, both separately and together.

That definition describes a very broad umbrella, and there’s a wide variety of things happening beneath it. Agendashift is one of them, a community centered [1] on outcome-oriented change. Around that theme we are:

  • Running with the idea, diving deep, developing it through use, making our more successful experiments more repeatable and more easily transferable to others
  • Taking a stance against imposed change (in which we stand shoulder-to-shoulder with our friends in the OpenSpace Agility community)
  • Bringing together a range of different experiences and areas of expertise, colliding a number of models old and new, from within Lean-Agile and without
  • Expecting exciting things to happen.

It’s interesting to note that among the Agendashift community’s closest collaborators we have both Certified Scrum Trainers and Accredited Kanban Trainers, knowledgeable and experienced representatives of two great communities whose relationship hasn’t always been easy. Along with vast majority of practitioners who would be comfortable sitting under a Lean-Agile umbrella, I think I can speak for all of them when I say that each of them understands and respects the special contributions of their erstwhile antagonists. And after that, not just “Why can’t we all just get along?”, but “What can we achieve together that were weren’t achieving on our own?”

Observing this, I wonder aloud if the concept of T-shaped people [2] might extend to T-shaped subcommunities. I’m suggesting that in order to stay healthy, an ecosystem as large as Lean-Agile needs groups of people that have:

  1. The persistence to run with ideas and to see just how far they can take them (so that you don’t have to, except where there’s a genuine passion to pursue)
  2. The diversity to ensure they stay vibrantly creative
  3. Broad enough representation that their learning will diffuse and cross-pollinate via the overlaps between communities

Sometimes this will happen by accident, but I suspect that the majority of successful examples are the product of deliberate attention. Can we make it more repeatable? I don’t know, but I would certainly be interested in comparing notes with others who are doing similar things. Could conversations such as these help make Lean-Agile simultaneously more cohesive, more diverse, more respectful, and more productive? I’d like to think so…

[1] BDD is a Centered Community Rather than a Bounded Community (thepaulrayner.com)
[2] T-shaped skills (en.wikipedia.org)


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 evolution 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 I read the Scrum Guide

Overview:

  1. The good: Things the Scrum Guide™ reinforces that would otherwise get lost
  2. The ugly: Things that should not be accepted at face value
  3. How I approach it

I’m going to assume that you have at least a passing acquaintance with Scrum, either as it’s generally taught and discussed, or as defined in the Scrum Guide. The guide itself has been updated in the past few days, there now being a 2017 edition:

The guide is ©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/.

I haven’t checked to see when this license model was applied, but nice move.

1. The good: Things the Scrum Guide reinforces that can easily get lost

My biggest “Aha!” moment for Scrum was when I realised that it wasn’t about story points, velocity, Fibonacci numbers, and the like. Although tools like these do seem to work effectively enough for some people, others find them a recipe for (i) busywork or (ii) setting teams up for regular disappointment. Small wonder that they’re a popular target for sniping. Rightly, there is no mention of them at all in the guide.

The guide instead talks of the sprint backlog as both a set of items selected for the sprint, and – crucially – a plan for delivering them. And get this: the sprint backlog is subordinate to something else, the sprint goal:

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Imagine you’re working in an organisation that typically takes months or even years to deliver anything of note (I exaggerate not). Now give people the chance to work together on achieving a meaningful goal in a matter of days. And again. And again. That’s powerful. Could that be done without Scrum? Does it happen without Scrum? Of course it could and of course it does, but Scrum is often the vehicle by which people experience this for the first time, and that’s something to celebrate.

I also have to give credit to Ken and Jeff for being explicit about Scrum’s applicability:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

I don’t highlight this quote as some kind of backhanded compliment, a way to put Scrum back into its box. The domain described here is huge! And it’s important for reasons explored in chapter 5 of the Agendashift book. To operate a Lean, Agile, or Lean-Agile process worthy of that name, you must embrace the idea that the often challenging, sometimes messy, and always necessary work of helping the organisation to change must be treated as real work, to be carried out not just alongside delivery work, but integral to it. The ‘complex adaptive’ part of that quote might be unnecessarily jargony but it refers to the inability of any linear plan to deliver this vital kind of change effectively (see my “Change in the 21st century” keynote).

Taking these together, Scrum working well means:

  1. Meaningful goals regularly met
  2. The system – the team and well beyond – evolving commensurately

That’s harder to achieve and even harder to sustain than it might sound, and the guide is honest about the level of challenge involved. What it leaves unsaid is that as soon as Scrum comes to mean ploughing through the backlog, these benefits become increasingly difficult to sustain. It’s why we find support in complementary tools such as Kanban, Lean Startup, and now Agendashift [1] when the returns from Scrum on its own begin to diminish.

2. The ugly: Things that should not be accepted at face value

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

There are so many better ways in which the Scrum Master role could have been introduced, and it beggars belief that this section could be edited (yet again) in the 2017 edition and left like this. After an ugly paragraph easily construed as ‘your first responsibility is towards Scrum’ we see a very carefully circumscribed kind of servant-leadership that will surely be read in the light of what precedes it. There are more charitable interpretations, but they depend on assumptions that aren’t made explicit.

To be a true servant leader, your responsibility is towards your colleagues, your organisation, your customers, other stakeholders, even towards society. Where by-the-book Scrum helps you in those responsibilities, fantastic. Where it gets in the way, it might be time to do something not by the book. A true master at Scrum might find these situations rare, but pity the conflicted rookie! Even if only in the context of these sentences, if it doesn’t bother you that Scrum Masters are certified after just a couple of days of training, it should.

If we want our industry to do better, we have to look at its systems, ready to challenge a status quo that tends to preserve itself. Scrum has been around long enough to qualify for that kind of scrutiny and whatever their true intent, these widely-read sentences are too open to a cynical, self-serving interpretation.

In response to my tweet yesterday morning, Neil Killick was quick with this much better alternative:

With all due respect to Neil, that wasn’t so hard, was it?

3. How I approach it

I start from the perspective that Scrum describes some pragmatic solutions to common problems. Do you have multiple customers, far removed from the team? Then you’ll find it helpful to have a highly available Product Owner. Do you need someone to model and facilitate appropriate practices and behaviors? Then bring in a Scrum Master. Are your feedback loops too slow relative to the rate of environmental change? Then plan your work to fill short timeboxes and meet daily.

Conversely, if you don’t have all of these problems, you might not need Scrum. At the very least, tread carefully:

  • Don’t place obstacles between a team and its customers if they’re already collaborating (yay, manifesto values!)
  • Don’t add layers of process and ceremony where teams are already self organising effectively
  • Don’t allow Scrum’s timeboxes get in the way of rapid flow and rapid change – they needn’t [2], which is why I don’t present this as a technical objection to Scrum

Nice problems to have, you might argue. And well you might, which why I am significantly more pro Scrum than anti. But I don’t check in my experience, knowledge, or curiosity at the door. Where I see conflict between approaches, I dig deeper, fully expect to find agreement, and am usually rewarded handsomely.

For the most part, you can leave the self-serving stuff behind (I’ve learned to filter it out). If you are helping to bring clarity and agreement around purpose and goals (things Agendashift and the guide fully agree on), and if you start with needs, seek agreement on outcomes, and so on [3], it’s likely that you’re approaching things in a good way. As time passes you might find that things look less and less like anything you heard in class, but don’t let anyone shame you for that. Expert or rookie (and yes, tread accordingly), you’re responsible. You’re a leader!

[1] About Agendashift
[2] Scrum and Kanban revisited
[3] Agendashift in 5 principles

I’m grateful to Olivier My, Neil Killick, Johan Nordin, and Karen Beck for their valuable feedback on earlier drafts of this post.

While we here

Lean-Agile Strategy Days London (II) – 22-23 Nov, London, UK is just over a week away and there’s still time to book your place. Interested in Lean-Agile change and its relationship to strategy? You should be there! In case you can’t make both days, we’ve just added a strictly limited number of single day tickets.

5 key plays and how to accelerate them

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:


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

 

Agile and Lean are just toolkits, right?

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:


Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: 
Home | AboutPartners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events
):
8th Nov, Cape Town, South Africa22-23 November, UK

Scrum and Kanban revisited

Update: See the August 30th webinar by Steve Porter and Dan Vacanti titled Scrum and Kanban: Make your teams better by busting common myths [scrum.org]. It’s great to see such a collaboration happening, and I’m happy to acknowledge that they are the original source of the six numbered headings below (not the content – that’s still mine). Apologies to Steve and Dan – honest mistake, I should have dug a little deeper.


Late last week I was invited by Fasih Sandhu to contribute my reactions to a LinkedIn post on the topic of Scrum and Kanban. My initial reaction was “Oh, here we go, 2012 just called”, but I ended up leaving a comment big enough that I had to edit it down for it to fit. Here then is the director’s cut! I don’t for a moment suppose it will resolve the issues once and for all, but it does at least give an opportunity to explain how someone committed to thoughtful integration approaches it.

Do you think that combining the #Kanban principles and practices with the #Scrum Framework will enhance the collaboration across your agile teams?

Space did not permit me to address this question on LinkedIn, but had it not contained the phrase “enhance the collaboration across your agile teams” I would likely have not have engaged at all.

To understand why this phrase was so crucial, here’s the Agendashift True North [1]:

Everyone able to work consistently at their best:
 • Individuals, teams, between teams, across the organisation
 • Right conversations, right people, best possible moment
 • Needs anticipated, met at just the right time

I’m interested in enhancing collaboration not just across agile teams (as per the question), but between teams (of all kinds) and across the organisation – the right conversations happening between the right people at the best possible moment, wherever in the organisation or outside of it they happen to reside.  Do I believe that a combination of Scrum and Kanban can help to deliver this? Yes I do, and I can point to multiple projects where I’ve witnessed it happen.

In a week or so, I will be attending an event on #Scrum versus #Kanban and I am interested to the reaction of my LinkedIn followers to any of the following statements that will be discussed in that event:

1) Scrum is for product teams; Kanban is for service teams
2) Scrum is for complex work; Kanban is for simple work
3) Our Scrum team has evolved to become a Kanban team
4) We do Scrumban
5) We do Kanban because we can’t plan out for an entire Sprint
6) Scrum is revolutionary; Kanban is evolutionary

Oh dear. “Scrum versus Kanban”. 2012 really is calling. Moving on:

1) Scrum is for product teams; Kanban is for service teams

Quick gut reaction: Ugh. Propaganda (at best based on an error of logic, more bluntly a lie based on a misdirection).

Longer answer, explaining the above but leading to a much less controversial conclusion:

Yes, Scrum is, by design, for product teams. Scrum.org describes it as “a management and control process that cuts through complexity to focus on building products that meet business needs”. No argument there, and in that context it is well understood and well resourced. For some it’s the framework of choice, for others it’s a good starting point or something you have to know.

Is Scrum designed for service teams? Not really. Can Kanban help there? In other words, can service teams benefit from Kanban’s visual management, controls on work in progress, collaborative, feedback-driven process improvement, etc, etc? Many can and many do!

What is also true (and it’s what makes this statement so frustrating) is that visual management, controls on work in progress, collaborative, feedback-driven process improvement, etc, etc are also highly useful to product teams, whether or not they are using Scrum.

So… Kanban is not only for service teams, and Scrum and Kanban are not mutually exclusive. Boring, but true! And can your product teams afford to ignore the service dimension anyway? Probably not, and some would even start there…

2) Scrum is for complex work; Kanban is for simple work

Quick gut reaction: Double ugh. Like question 1, but with a dose of Appeal to authority thrown in.

I could give an extended answer here, but suffice it to say that if you don’t understand that Scrum and Kanban both seek – in their quite different ways, both technically and philosophically – to help their organisations (not just their products) evolve in the presence of internal friction and external competitive pressure, then you don’t understand them, Agile, Lean, or Lean-Agile very well at all.

3) Our Scrum team has evolved to become a Kanban team

Positive, negative, and mixed reactions might be appropriate here – it’s hard to comment on this one without knowing the specifics of the scenario.

Unfortunately a statement like this could mean a whole range of things, ranging from “We stopped doing a bunch of Scrum-related stuff and we don’t really know what we’re doing” to “We’re now using a number of new techniques in a the pursuit of flow, leaving some older practices behind once we established that it was safe and effective to do so”.

Minor technicality: By the design of both, ‘Kanban team’ isn’t as well defined as ‘Scrum team’, but I can see how this arises.

4) We do Scrumban

As documented [2, 3, and elsewhere], my personal experience of Scrumban has been very positive.

To celebrate the Scrum part, the teams I worked with very much appreciated the focus of the sprint in the early days of each project; for organisations unused to achieving anything quickly, the experience can be amazing!

As to the Kanban part, this helped immensely in the pursuit of end-to-end flow (see my answer to question 3 above). This isn’t just better task management, this is integrating a process that starts well before development and finishes long after delivery into production.

I’m glad to be able to say that Scrumban is better resourced now than previously; see for example the book [4] by my friend Ajay Reddy and (from the same stable) some tools [5, 6].

5) We do Kanban because we can’t plan out for an entire Sprint

Quick gut reaction: I find it hard to see this as anything other than a feeble cop out.

Every team is subject to sources of unpredictability – in fact most teams seem to generate a fair amount of the stuff themselves! And yet there’s so much that remains under your control:

  • How often you plan is up to you (clue: choose an appropriate sprint size)
  • Whether or not you plan with zero wiggle room is up to you (clue: don’t)
  • The confidence you attach to your plans is up to you (clue: understand that this is crucial to the planning process, and that your choices here should be informed by both capability and need)

6) Scrum is revolutionary; Kanban is evolutionary

Quick gut reaction: Some truth there, exaggerated for effect, not on its own a useful value judgement.

Scrum is revolutionary if you’ve done nothing like it before. Over time and as there is more of it about, it will become less and less revolutionary, (a victim of its own success perhaps). And don’t forget that it has evolutionary goals (see question 2 above).

Kanban is often described as the easier of the two to introduce, but try introducing it in an organisation allergic to transparency!

Frankly though, discussions about what does or doesn’t constitute evolutionary change quickly get very dry, and in any case I don’t believe that this is a sensible basis for serious decisions about tool integration (and like it or not, every successful Agile adoption is an integration, not just a selection). Nowadays therefore, I prefer to take a more principles-based approach: Start with needs, Agree on outcomes, and so on [7, 8].

References

[1] A True North for Lean-Agile? (See also chapters 1 and 5 of [2])
[2] Agendashift: clean conversations, coherent collaboration, continuous transformation, Mike Burrows (yours truly) (2017, Leanpub)
[3] Kanban from the Inside (2014, Blue Hole Press)
[4] The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban, Ajay Reddy (2015, Addison-Wesley Professional)
[5] GetScrumban
[6] ScrumDo
[7] Agendashift in 5 principles
[8] (Non-)Prescription, frameworks, and expertise


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

(Non-)Prescription, frameworks, and expertise

Let’s look again at Agendashift in 5 principles, 5 principles for organisational adaptability and 21st century change leadership:

  1. Start with needs
  2. Agree on outcomes
  3. Keep the agenda for change visible
  4. Manage options, testing assumptions
  5. Organise for clarity, speed, and mutual accountability

Alongside those principles let’s consider also Agendashift’s description as “inclusive, non-prescriptive, and methodology-neutral”. Taking all of that together, what place is there here for skills and expertise in methods, frameworks, and so on? As it happens, quite a lot. It might seem counter-intuitive, but non-prescriptive is an excellent stance for the serious change agent to take.

Just one of the several cool things about starting with needs and outcomes instead of requirements and (pre-selected) solutions is that you give yourself the opportunity to generate and evaluate options (part of principle 4). That’s an interesting process in itself, and here are some of the ways in which a skilled facilitator can encourage diversity and innovation:

  • For every option that involves implementing a tool, we try to think of one that doesn’t (eg to “Implement Slack” we might add the alternative “Get out more”)
  • For every option that involves someone outside our circle providing more accurate inputs, we try to think of one where we we take the responsibility for better and timelier conversations (eg to “Better requirements documents” we might add the alternative “Spend time with customers”)

And some questions:

  • “What has worked elsewhere?”
  • “What would experts from different backgrounds recommend?”
  • “What’s the most radical option we could try?”

To people and teams already familiar with a framework (Scrum, for example), it makes total sense to try things that have worked for similar teams, so long as there’s a decent chance that it will help you achieve the outcome you’re currently focused on. For non-trivial problems, it also makes a lot of sense to understand how other people have solved similar problems outside your framework. For all but the most unusual problems, an expert worthy of that title will have ready access to a range of options and will be able to provide insight into when and why some options work better than others under different conditions.

Industry experience and framework expertise come into their own again with principle 5, organising for clarity, speed, and mutual accountability. Many frameworks have their own answers (technical answers, at least) to how communication and decision-making should work, but only a fool would pretend that it won’t be a challenge to change how organisations operate, especially at scale. Without a good understanding of i) what’s possible and ii) how to help make it happen, you’re stuffed.

The majority of Agendashift partners have deep expertise in at least one Lean-Agile method or framework and a working knowledge of others. No less valuable are the remaining partners that come from the organisation, facilitation, and change side as employees or external consultants, who are used to working respectfully with the technical experts (and vice versa).

If this inclusive (“it’s all great”), non-prescriptive, methodology-neutral thing sounds attractive to you, give Agendashift a closer look. Check out our partner directory, either to find some local expertise or to help you decide that you’d belong there yourself. If you’re a practitioner, check out the partner programme. If a potential sponsor, the unbenchmarking service and the transformation mapping workshop will give you a flavour of the services we and our partners can offer. And for depth, there’s the book: Agendashift: clean conversations, coherent collaboration, continuous transformation.


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter