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…

 

A True North for Lean-Agile?

You may have noticed that the blurb for our workshops and for the new book always starts with this:

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

It’s taken from one of our Discovery exercises (chapter 1), an early opportunity for participants to explore different ways of working not from the perspective of prescribed practices, but in terms of what it is like – how it feels, what’s different, and so on.

Some of the groups I’ve facilitated have found the exercise so cathartic that they ask repeatedly for more time. It’s not hard to see why:

  • If you feel that you’re rarely given the opportunity to work at your best, your team doesn’t work well, or you’re painfully aware that teams aren’t working work well together, it can come as a relief to be given the chance to imagine a different reality
  • Whether you’re a front line worker or a manager, conversations happening at the wrong time (or not at all) can be very frustrating
  • For most of us, knowing that we’re meeting needs is crucial to finding meaning in our work

The current text of the book doesn’t identify these words as a True North statement (a compass direction rather than a destination), but it probably should. A True North for Agendashift certainly, and I’d like to put it forward as a True North for Lean-Agile also. It’s consistent with the Lean pillars of respect for people and just in time. Consistent with the Agile manifesto, it elevates individuals and interactions, combining those with a sense of timeliness (I joke that Agile seems to imply lots of meetings, the beginning – one hopes– of true collaboration).

In its favour as a worthy True North:

  • It is easy to understand, worth striving for, and will remain always just out of reach. Transformation must be continuous, not a one-off project
  • It works at every scale – from individual to organisation, and at scales in between
  • In its last bullet, it conveys much-needed senses of proactive discovery (needs don’t get consistently anticipated by accident) and purpose (needs being met)

Also, it’s not specifically about software, or even about product development. That’s a departure from the Agile manifesto, but I have no doubt that this is in its favour too.

So… Does it work for you?

Related:

Screenshot 2017-05-22 13.42.56


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

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

Lean-Agile Strategy Days, London

June 8th is a special day: not just because the UK general election is (somewhat inconsiderately) being held on that day, but because I’m pairing up with Karl Scotland for a 2-day public workshop in London, Lean-Agile Strategy Days.

I like to think of it as “pure & applied” strategy deployment. On day 1, we’ll be experimenting with Lean approaches for engaging people in the development and implementation of strategy. On day 2, we’ll use Agendashift as a model for continuous Lean-Agile transformation, a serious question of organisational strategy if ever there was one.

This workshop is a first, and I’m proud to be doing it with Karl. We describe the workshop as an opportunity for collaboration, and this isn’t just hype. As a key collaborator in the development of Agendashift, Karl did much to push Agendashift upstream, suggesting (and bravely testing) ways to develop the Discovery tools, also to better integrate the Cynefin-related material. He has a gift for nudging me in productive directions, and I would be surprised if something new and exciting didn’t come out of this event.

You can be part of it! Book your place here.

Read Karl’s post: Lean-Agile Strategy Days: An X-Matrix and Agendashift Fusion

PS Did I mention I have a book coming out? May 11th!


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

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

Why Agile needs some 21st century Lean thinking

At least as far as the textbooks go, 21st century Lean is quite a different beast to its 20th century forebear. The best of the more modern Lean literature is now explicit in its recognition that you can’t just take the Lean tools out of one context, drop them into another, and expect the same results. Just because it works for Toyota, doesn’t mean it will work for you. Just because it works in a car factory… I hardly need to complete that sentence!

Not unmodified, that’s for sure. The kind of Kanban I described in Kanban from the Inside that works so well for people engaged in creative knowledge work is almost unrecognisable from the canonical kanban systems of the automotive factory. Many of the underlying principles are the same – for example visual management, controls on work-in-progress, the quest for flow – but their physical or electronic realisations are very different. In one, cards move left to right (downstream) on a kanban board to reflect the progress of work; in the other, cards are sent upstream when some downstream activity wishes to signal a need for some just-in-time replenishment.

But that’s just technical detail. The best of the 21st century Lean authors have been humble enough to make an even more important admission: even within the manufacturing domain you can’t (as the 20th century writers tried to suggest) transplant the tools whilst ignoring the management systems that guide, support, and sustain them, and still expect good results. An important case in point is continuous improvement (or kaizen, if you prefer). Don’t get me wrong: continuous improvement will always be a good idea. Unfortunately though, it is rarely sustained for long through goodwill alone. Asking your workforce for continuous improvement as a low-commitment way to achieve real transformation will almost certainly result in disappointment, even harm.

We in the Agile community know all this of course – how often do we see retrospectives fall into a state of neglect once the easy changes have been made? Unfortunately, we make it harder for ourselves, and by design! As an end-of-century reaction to 20th century top-down and plan-driven management styles wholly unsuited to the challenges of rapid product development in uncertain environments, Agile rightly sought to wrest control back to the teams doing the work. The unfortunate side-effect: blindness to the power of the kind of internal structures that create regular opportunities for mutual reflection, support, and accountability well beyond the team. How is the Agile team supposed to help the organisation become more Agile when it is determined to live inside its own protected bubble? This is how inspect-and-adapt (Agile’s continuous improvement) runs out of steam. Even at team level it’s hard enough to sustain; expecting it to drive broader change without support is, well, optimistic.

I’m not looking to throw the baby out with the bathwater. I’m not suggesting any backsliding on Agile values. I’m not making the case for 20th century top-down management (in fact quite the opposite). I’m asking that we look beyond the delivery-centric processes and tool (most especially beyond the determinedly team-centric ones) and start to think about what that cross-boundary support and accountability could look like.

In particular:

  • What will drive Agile teams and their host organisations to help each other to serve their customers’ and each other’s needs more effectively?
  • Where are the joint forums for reflection?
  • What mechanisms will provide support and ensure follow-through, even when the necessary changes become more challenging on both sides?
  • Where are the opportunities for people to engage seriously in the development and pursuit of organisational goals?
  • What skills will be  needed to make these things happen?

Outside the Agile mainstream, Kanban and Lean Startup have opinions (if not explicit guidance) on many of these questions. Helping people pay attention to concerns such as these is one Agendashift’s main motivations. Much of Agile however still seems to ignore them, sometimes recognising the need for end-to-end thinking but still wary of “at every level” thinking.

The good news is that these concerns are largely orthogonal to delivery. Agile delivery frameworks probably don’t need to be any bigger than they are today (let’s hope so). Some awareness of organisational context and its journey will be necessary though, and it may mean leaving aside the rhetoric of past battles. Welcome to the 21st century!


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

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

 

Lean-Agile transformation as Lean-Agile process

[Update: Section/chapter 2 previously named Analysis is now Exploration. Thanks to Mike Leber for the suggestion made at last week’s Agendashift facilitator day in London. 1. Discovery, 2. Exploration, 3. Mapping – that’s a nice progression! Some edits made to reflect this change.]

Did I mention that I’m writing another book? Writing begins in earnest next week, and the wait is killing me! Nearly three years after Kanban from the Inside, I again feel the compulsion. I have to do this!

The new book’s first five chapters mirror the five main sections of the Agendashift transformation mapping workshop:

  1. Discovery: Identifying strategic objectives, obstacles, outcomes, and change strategies
  2. Exploration: Debriefing your Agendashift values-based delivery assessment, prioritising opportunities, and agreeing scope
  3. Mapping: Building a transformation plan
  4. Elaboration: Generating, framing, and developing actions
  5. Operation: Organising for continuous transformation

If you’re anything like me, you might thinking “Plenty of plausible-sounding words there, but what makes the process Lean, Agile, or Lean-Agile?” It’s a fair question – there are enough linear, top down, cookie-cutter, imposed, consultant-knows-best, and resistance-trumping models out there and we surely don’t need another one! Can we instead demonstrate collaboration, iteration, flow, pull, feedback and the rest?

There’s an old Lean trick that I’ll be employing in chapter 5: review the process backwards, from finish to start, from life at the operational sharp end and back to the fuzzy front end. Here’s a preview, and it describes a process for organisational transformation that with just a few substitutions could easily describe a Lean-Agile process in the product or service space.

5. Operation

We meet frequently to review progress on the changes we have in progress and to share what insights we’ve gathered along the way. We’re validating the impact of our most advanced experiments to help us decide whether or not to adopt them formally. Some of our other experiments haven’t reached that stage yet – we’re still testing changes for their usability (there’s no point in endorsing changes that won’t stick). Still further upstream we keep a small backlog of prioritised and well-understood changes to work on as soon as capacity permits.

4. Elaboration

We’re careful not specify changes until we’re close to needing that level of detail – this isn’t big design up front (BDUF) but a just-in-time (JIT) process. Leaving it until the last responsible moment gives us the opportunity to incorporate feedback from previous experiments (successful changes or otherwise) and to take into account recent environmental changes outside our sphere of control.

Where appropriate (which is much of the time) we use the language of Lean Startup and A3 to frame and develop our actions. We take the outcomes that are the main units of currency of the transformation map and from them form hypotheses, identify who should to be involved in the change (to a significant extent we’re our own customers here, but therein lies a trap), design pilot experiments to test our assumptions, and so on.

3. Mapping

There’s much still be achieved, and it’s important to keep our ideas organised. Call it a planning tool if you like, we use a transformation map, highly analogous to a story map, except that the elements being organised aren’t features, user stories or job stories, but the outcomes we’d like to achieve through our transformation.

[Aside: The analogy is strong – the ‘so that…‘ elements of user stories and job stories are outcomes too of course.]

The categories under which outcomes are organised may describe the stages in a transformation journey or simply identify high level themes; sometimes one evolves into the other. This organisation comes under periodic review as we step back from the day-to-day and reflect on our overall progress.

We prioritise within categories before looking across categories and deciding on what we will work on next. In setting priorities overall, we may choose to give special emphasis to a particular category for a while, or decide instead that it’s better to choose a minimal set of complementary changes from across the board.

2. Exploration

Exploration keeps the transformation map both based in reality and connected with the vision, the output from Discovery. What do we know? What can we find out? What seems to be important? Who should we talk to? Where are the most promising opportunities? What’s our scope?

With Agendashift, exploration is a generative process. Informed by the results from the assessment tool, we collaborate on identifying opportunities and their respective obstacles, then ‘flipping’ those obstacles into the outcomes that will become either the work items or the organising themes on our transformation map.

We do enough of this up front to prime the pump and to get a good sense of what it is we’re really dealing with. We revisit it periodically; as our transformation progresses, so too does our understanding of what’s urgent, what’s possible, and where we think we’re headed.

1. Discovery

What would it be like if everyone were able to work at their best, individually, within teams, and across teams? What if we could have the right conversations between the right people always happening at just the right time? What if everyone always got what what we needed at just the right time too?

Why don’t we have that now? What obstacles lie in the way of achieving that? Can we go from all of that to a set of goals? What kinds of delivery approaches will be appropriate for the kinds of outcomes we seek? Who do we need to engage in the process?

This was the first of three related posts (post 3 coming soon):

  1. Lean-Agile transformation as Lean-Agile process
  2. Agendashift as coaching framework
  3. Agendashift as Good Strategy

If you’re a Lean-Agile practitioner and can see yourself using these tools, check out our partner programme. If you’re a sponsor of change and think this might work for you, check out our partner directory. In either case, check out our events calendar for a public workshop near you. If you don’t see one or you’d like one internally, get in touch.


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

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

A blocker waiting to happen (and it works both ways)

Dependency
A blocker waiting to happen

That’s a rather informal definition and it’s not strictly accurate (some blockers are unrelated to dependencies), but it will do! Certainly it’s more helpful than Wikipedia’s:

[A] dependency is a link amongst a project’s terminal elements.[citation needed]

In our consciously inclusive and non-prescriptive way, the full version of the Agendashift values-based delivery assessment implies two kinds of dependencies:

1.5 We identify dependencies between work items in good time and sequence them accordingly
1.6 We identify and manage dependencies on external teams or services

The first of those is usually straightforward to deal with: we take care not to start a work item (some kind of deliverable – a feature, say) until we know that its dependent work items (other features or required infrastructure) will be in place. In the simplest case, we just sequence work items into some natural order and deliver them one by one. We must be a little more careful if we want to take advantage of our capacity to work on items in parallel, but still the advice mostly boils down to the mantra “Don’t start what you can’t finish”.

That mantra applies to the second kind of dependency also. Here, we know (or really should know) that we can’t finish a work item without some external contribution. Even the best cross-functional team will find itself dependent on others from time to time! Under these circumstances, if our work is to flow smoothly we must be take active steps to ensure that things will come together at the right time.

That in turn means being in the habit of identifying our dependencies in good time, keeping them visible so that no-one makes the mistake of starting work prematurely, and engaging appropriately with the people on whom our work’s completion depends.

2015-02-25-08-01-42
A Story Map with external dependencies:  note the red flags bottom right

Just-in-time: It works both ways

Most people will read “appropriately” as “early enough” – early enough to ensure that our work won’t be delayed. This is a slightly selfish view however, and it’s worth looking at this from the perspective of the team on who we depend. From their side, a piece of work that is started too early is a piece of work that can’t be integrated, tested, deployed, validated, and so on. Ugh! This is the kind of work-in-progress (or inventory) that the organisation as a whole really doesn’t want. If we’re really serious about flow in the presence of dependencies, the Lean idea of just-in-time (JIT) implies some two way commitment!

This is one reason why the concept of service is so helpful. Whether customer-facing or internal, an effective service combines two things:

  1. A strong sense of what we’re delivering, to whom, and why
  2. The ability to manage expectations around performance

service-oriented organisation has both of these firmly established on both sides of all its dependencies, achieved through mainly bilateral coordination, not overly reliant on organisation-wide synchronisation. A very good thing to strive towards.

Do you find yourself continually struggling with dependencies or (the flip side of the same coin) excess organisational inventory? It’s a solvable problem. Get help!


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

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

Outcomes, alignment, and changes to our A3 template

Last week’s post Two new tools* and how I’m finding them useful has generated a lot of interest – after just six days it is already the 3rd most popular post of the year!

*Spoiler: Clean Language and the Cynefin Four Points Contextualisation exercise

One piece of detail I neglected to mention is a tweak I have made to the A3 template we use to guide people through the process of framing and developing their actions as hypothesis-driven changes. The header area at the top of the page has gained a new field: “Aligned to objective”.

It’s a chance to identify:

  1. a pre-existing high level objective to which this action aligns, or
  2. a summary outcome shared by this and other actions (a theme, if you like).

Better still, both at the same time – this is after all what alignment and strategy deployment [availagility.co.uk] are all about. Without alignment, so-called improvement can easily descend into just fixing stuff – interesting locally perhaps but unlikely to be important in the grand scheme of things.

Resources


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

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