Here’s the paradox: How do you reconcile “Individuals and interactions over processes and tools” with the ceremony and seeming process-heaviness of Agile frameworks?

I think you can resolve this constructively by digging beneath the values, bringing  an assumption or two to the surface. In my ‘6+1 strategies’ paper (more on this at the end) I make this statement:

Agile assumes that software development is best … delivered through … processes that respect, support, and amplify the effective, deliberate, and timely interactions of skilled people

Even after editing some out, there are multiple assumptions at work here (“skilled”, for example), but it will serve our current purpose. It’s a statement that supports much (if not all) the Agile Process Heaviness Spectrum™, from the big frameworks near one end and most of the way towards “get a bunch of smart people together in one room” at the other.

Success is heavily dependent on the right conversations happening at the right time. If they’re not happening, some more process might help. More process might not generate exactly the right conversations, but there will at least be some more regular ones!

So the thinking goes anyway, but there’s a balance to be struck. Here are five ways you can try to improve that balance:

1. Do you have a recurring frustration that might be addressed through the implementation of some extra ceremony? Find one that fits, and introduce it as an experiment.
2. Before experimenting with any new ceremony, make sure you understand the assumptions beneath it. Does it address a problem that you actually experience? Will the benefits outweigh the cost?
3. Do each of your existing ceremonies “respect, support, and amplify the effective, deliberate, and timely interactions of skilled people”? If not, more experimentation needed!
4. Do you have an existing ceremony that seems particularly painful, either a poor use of people’s time or revealing problems only late in the day? As the XP folks might advise, experiment with doing it sooner and more often. Examples: Plan a non-painful planning meeting with frequent “pre-planning”. Head off painful code reviews with regular design conversations. At the extreme: planning on demand and pair programming, hardly ceremonial at all, and more achievable than you might think!
5. Can you see when conversations are overdue? For example, if it’s not obvious when there is “unready” or “unreviewed” work for example, then make those states more visible, eg with columns on your board.

6+1 Effective strategies for successful Lean-Agile transformation

The second draft of this paper is now out for review. All being well, the final version should be out next week. Register here for your copy.

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

Who or what drives your agenda for change? From which direction? Two common and clear-cut answers to these questions are these:

• Bottom up – continuous improvement (coaching or otherwise enabling the ‘doers’ to find better ways of working), the sideways and upwards sharing of learning, and so on
• Top down – strategic direction, strategic initiatives, etc, including also some unattractive versions such as management by objectives

Top down and bottom up describe extremes that are often a poor fit for a reality that seems much messier. How about middle out? This is can refer to either or a combination of these:

• Change led by people who have (i) a foot in both the operational and strategic camps and (ii) networks that reach out across the organisation
• Change stimulated stimulated by ‘mid level’ feedback loops such as service delivery reviews that sit above the more operational feedback loops of replenishment meetings, delivery planning meetings, and daily standups

In larger organisations, these ‘foot in both camps’ people are middle managers. The service delivery review is a key tool of Enterprise Services Planning. As someone who remembers what it was like to be a middle manager and an enthusiastic support and implementer of feedback loops, I have sympathy with both definitions!

With the agenda [for change] sitting right at the centre of the Agendashift model (below), I could describe Agenadashift as incorporating elements of bottom up, top down, and middle out change. Would that be helpful? Not really. I could stick with middle out and use it to mean “neither entirely top down or bottom up” but that would be a cop-out. Let’s not use the term so carelessly!

Happily, my thinking around how to describe what sets the agenda for change has further crystalised recently, thanks in part to the happy coincidence of reading Schein [aside: this works surprisingly well as an audiobook] and a scheduled chat with Karl Scotland on the topic of strategy deployment.

I have concluded that the agenda for change is best described not in terms of source or direction, but more simply as ‘the result of a process’. It might be a deliberate process (perhaps including some those approaches already described), supported by tools (such as the strategy deployment tools Karl and I discussed), or something rather more implicit, perhaps neglected. The process and therefore the agenda can be fed through continuous improvement. They can be informed by purpose and strategy. They can be aligned to values. They can be kept on the straight and narrow by feedback loops. Their outward impact is in multiple directions too – changed performance, changed outcomes, changed ways of working, changed attitudes.

I have long been wary of throwing the culture word around too casually but I’m very encouraged to find parallels with the ‘agenda-setting as a process’ that lies at the heart of Agendashift and Schein’s very helpful description of culture as the result of a process of social learning, again a process that may or may not be deliberate. The model is holding up well 🙂

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

[Update: the A3 I refer to here is now available via our Resources page]

[Update: see also the Changeban game which can be used to introduce many of the concepts explored in this post]

I’ve had the pleasure of running my classes and workshops in the company of experienced Lean practitioners, and I’m always amused when I see that lightbulb moment. “I see what you’re doing – it’s PDCA!”. We exchange knowing smiles and carry on.

At risk of being burned at the stake for heresy, I will admit however that I no longer teach the canonical improvement cycle PDCA by name or in its original form.

Otherwise known as the Deming Cycle, PDCA (Plan-Do-Check-Act) and its close cousin PDSA (Plan-Do-Study-Act) describe an experimental approach to improvement.

Here’s part of the problem (and I’m quoting verbatim from my book): The words Plan, Do, Check, and Act don’t mean what you think they mean – they’re even a little misleading – until you use them with the word “experiment”:

• Plan an experiment (based on a hypothesis)
• Do (conduct) the experiment
• Check (or Study) the results (or outcome) of the experiment
• Act on the results, changing either the hypothesis or the system accordingly, sharing appropriately

Instead talking abstractly about experiments (with or without the health warning), I now dive straight into reframing our action ideas Lean Startup style (early 2010’s instead of early 1950’s):

We believe that <actionable change>
will result in <meaningful impact>.
We’ll know that we have succeeded when <measureable signals>.

We complete Plan in the form of an A3 (named after the paper size, and the vehicle for a coaching conversation). This includes various kinds of risk and stakeholder analysis and a list of pilot experiments that will (we hope) take us closer to our goal and tell whether our change is likely to fly (and we aim for it to fly high).

Another problem is that there’s nothing at all inevitable about the “cycle” part. So, having shown how to frame and develop an experiment, it’s important address how a portfolio of experiments (plural) will be managed.

Check, Do and Act can be addressed visually by a kanban board. This too is inspired by Lean Startup, adapted to change management purposes by Jeff Anderson (with a couple of David Anderson-inspired tweaks for the right-hand column):

There’s plenty to talk about here:

• How to encourage ideas to join the board (under New) and what happens next
• The various ways in which they can finish
• The key questions of the middle three columns – What are we agreeing and with whom? Can we do it?  Does it help?
• Feedback loops – the opportunities afforded by the organisation to review progress and thereby sustain the change process

In summary, we split PDCA into two:

1. a framing part, learned by doing, represented (if you wish) by an A3
2. a follow-through part, highlighting a common organisational weakness, represented by the kanban board and accompanying feedback loops (which I stress)

As a bonus, we observe in passing the applicability in a development context of what workshop attendees have just practised in a change context. Meanwhile, our debt to PDCA is acknowledged in our books (mine, Eric Ries’s, and many others). And here too of course 🙂

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