Q&A on the Book Right to Left: The Digital Leader's Guide to Lean and Agile

The book Right to Left: The Digital Leader's Guide to Lean and Agile by Mike Burrows explains why we should focus on the outcomes, and how working backwards (right to left) from those can help us keep this focus so that the needs of customers are better served. It takes a right-to-left view on existing Agile and Lean methods, bringing a needs-based and outcome-oriented perspective to digital delivery.

InfoQ readers can download a sample of Right to Left.

InfoQ interviewed Burrows about why right-to-left matters, what Lean-Agile is, dealing with impediments to flow, applying Agile and Lean frameworks, how outside-in service delivery reviews look, and what can be done to support participation at scale.

InfoQ: What made you decide to write this book?

Mike Burrows: Writing Agendashift, my book on outcome-oriented change, I came to realise that there was a need for a book that in an accessible way both developed the underlying Lean-Agile philosophy that was mostly implicit in Agendashift, and helped people navigate the Lean-Agile landscape. Turning that realisation into a decision made Agendashift easier to write, and the prospect of writing another book excited me rather than daunted me!

InfoQ: For whom is this book intended?

Burrows: Much as I have always tried to write both for practitioners and a more general audience, Right to Left is the first of my three books really to put the ‘digital leader’ first. Whilst there should be plenty for the expert practitioner to enjoy, I want leaders (current and aspiring, technical or otherwise) who have any kind of digital remit to understand Lean and Agile as something radically different from traditional models. For the practitioner audience, its value will be in its breadth, its integration, and most especially the helpful provocation of its strongly needs-based and outcome-oriented stance.

InfoQ: What is "right to left" and why does it matter?

Burrows: "Right to left" is intended to encapsulate two things:

1. A sense of ‘pulling’ from the customer side, a concept fundamental to Lean and made highly tangible for knowledge work in the right-to-left review of the kanban board
2. A whole-process focus on needs and outcomes, in which "done" means that needs have been met, and demonstrably so (an approach that has a strong track record in the digital space)

This focus on needs and outcomes turns out to be a great way to integrate the key frameworks and models of the Lean-Agile landscape. This is a worthwhile goal; it’s worth noting that Agile is often introduced not right-to-left, but left-to-right – not needs-first, but backlog-first or solution-first. When the focus is on ploughing through backlogs of requirements, the likely result is mediocrity (or worse), hardly a great advertisement for Agile. And the dissonance of imposing solutions on teams rather than seeking to meet their and the wider organisation’s needs is potentially fatal to Agile adoptions.

Right to Left should not be understood as an attack on branded process frameworks; neither does it elevate any one framework over the others. However, as well as calling into question how they are often rolled out, I do voice the regret that they are so often described in left-to-right terms, leading me to wonder how Agile is then supposed to be understood as a departure from 20th century ways of thinking and working. I demonstrate that Scrum and even SAFe are readily described in right-to-left terms – "iterated self organisation around goals" is the five-word summary – and I wish that these and other frameworks did more to promote themselves in this kind of way.

InfoQ: How do you define Lean-Agile?

Burrows: In Agendashift, I define Lean-Agile as "celebrating Lean and Agile, both separately and together". I mention this again in Right to Left, as it describes very well I how I approach it, not just cherry picking, but honouring the journey that each community has gone through and the synergies and cross-fertilisation that continue to exist between them as they evolve. I go on to give the following values-based definition (integrating similar definitions of Lean and Agile suggested earlier in the text):

"Lean-Agile: The strategic pursuit of flow in complex environments, the organisation placing high value on collaboration, continuous delivery, adaptation, and learning."

As I explain in chapter 1, "the strategic pursuit of flow is inspired by Modig & Åhlström’s This is Lean (a modern treatment of Lean which I highly recommend). "Collaboration, continuous delivery, and adaptation" are intended to echo Agile manifesto values (I use continuous delivery here, but refer frequently to working software also). As for "learning", the pursuit of flow is a learning process; learning is made highly visible in frameworks such as Lean Startup, and there is clearly a relationship between adaptability and learning.

InfoQ: What kinds of impediments to flow have you encountered?

Burrows: Most flow problems can be classified under at least one of these broad headings:

• Blocked – some problem with the work itself
• Stalled – a problem that’s less about the work itself, but rather that the system’s attention is elsewhere
• Overburdening – people and systems overloaded
• Starvation – meaningful work being in short supply
• Defects – the triple and sometimes quadruple whammy: effort wasted producing defective work, then identifying it, fixing it, and dealing with any consequential impact
• Failure demand – additional demand generated by a failure to meet needs adequately the first time round
• Unrealised opportunity – high value work delayed behind low value work, caused by poor choices in sizing (oversized chunks or batches of work), poor prioritisation, or a failure to anticipate

When you see one of these, you will often find others if you look closely enough. For example, overburdened systems will have stalled work items and very likely suffer from quality problems too.

First as a manager and then as a coach and consultant, I have found it useful to train myself into the default assumption that failures of flow are rooted in failures of collaboration – certainly less judgmental and more empathetic than the assumption that every failure must be someone’s fault! This new assumption translates into a strategy for improving flow: do everything you can to increase the likelihood that the right conversations happen between the right people at the right time. When you have that, you have come a long way towards truly Agile working!

InfoQ: What can be done to reduce the chance of having unrealized opportunities?

Burrows: Let’s start with sizing work items appropriately, dealing with overburdening, having the flexibility to allow high value but underdeveloped ideas enter the system so that more people can collaborate over them (conversely, minimising distractions from low value ideas until – if ever – they’re ready), developing a sense of value that is both economically sensible and empathetic to users, and developing a good technical infrastructure so that work quickly gets into the hands of those who need it.

That’s already quite a long list, but it’s not exhaustive. It’s long because it gives a sense of the range of measures that need to be employed in the pursuit of flow, both reactively and proactively. Realistically, the pursuit of flow never ends.

InfoQ: What's your main suggestion for applying Agile and Lean frameworks?

Burrows: Change is much easier if you are in agreement on outcomes (Agendashift principle #2 ), because now everyone is ready to look for solutions. Working backwards from outcomes, you want an "in their own words" articulation, both of the business context and the needs of the organisation and its people. There’s a diagnostic element there, and the values and principles of the framework in question may help with that (the Agendashift assessments are organised around the values of transparency, balance, collaboration, customer focus, flow, and leadership). Our games Celebration-5W and 15-minute FOTO (available from our resources page) support the "in their own words" part; the former in relation to business context and the latter in relation to obstacles and outcomes.

With the right kinds of conversations, you’ll quickly generate enough outcomes that they will need organising and prioritising in some way. Working forwards from there, the role of the framework is as a source of inspiration as you seek contextually appropriate ways to realise those desired outcomes. You have an ideal opportunity to model an Agile process by selecting a manageably small number of outcomes to work on, collaborating on how they will be achieved, and reflecting periodically on how well they are performing. Just as they would in an effective product development process, those early articulations of context, challenge, and aspiration help to keep things aligned on meaningful goals – goals that will need refreshing and reaffirming from time to time through strategy and other similarly long-running review processes.

InfoQ: How does an outside-in service delivery review look?

Burrows: Over the years I’ve experimented with outside-in reviews in various forms, a concept borrowed from the strategy world. The premise is that it’s not enough just to monitor the development of internal capabilities; that would be pointless (or worse) if they don’t take us in the direction of where we need to be with respect to other participants in our business or organisational environment.

The outside-in agenda I describe in Right to Left goes like this:

1. Customer
2. Organisation
3. Product
4. Platform
5. Team(s)

To apply this generic structure to the service delivery review, we start by identifying the people best able to represent each of the five ‘layers’, looking for people (sometimes more than one person per layer) who have both relevant expertise and situational knowledge. They are then responsible for presenting not just news or issues, but relevant metrics and progress on experiments (the latter presented right to left, recently-completed first) on behalf of their respective area.

The power of this outside-in structure is that it makes it very obvious whenever there is a contradiction between our aspirations for one layer, and our actions and priorities in another. Analogous to impediments to flow, these contradictions are impediments to alignment. Adapting a metaphor from the renowned architect Christopher Alexander (of patterns fame), we can’t have a wholehearted organisation if its contradictions make it at war with itself, and I love the idea that as leaders and practitioners we can choose to be in the business of building wholehearted organisations. I choose that!

InfoQ: What can be done to support participation at scale?

Burrows: Anyone wanting to encourage participation at scale should study and practice the patterns of participation. To name two important sources:

1. Liberating Structures provides a good library of facilitation patterns (eg for workshops)
2. Open Space Technology (OST) scales very well when facilitated properly (sadly, it’s often facilitated poorly or not at all; a lonely flipchart in a spare meeting room at an Agile conference is not Open Space, but we can hardly blame the model for that)

I have also been inspired by Sociocracy, finding it a very useful lens on strategy deployment, governance, and organisation generally. Take for example my Rule of Three, a rule of thumb for workshops and other meetings:

"Design your strategy and governance meetings so that they invite the active participation of at least three levels of seniority."

Inside organisations, I make a point of blurring hierarchical reporting lines by increasing the diversity of representation in key feedback loops. Not only do you get more authentic intelligence from the ground, you get more authentic conversations because you remove the translations that take place when conversations travel up and down formal reporting lines. More crudely, there are witnesses!

With Sociocracy as my lens and the service delivery review meeting as the governance meeting in question, I take the customer, organisation, product, and platform layers of the outside-in review agenda and use them to label ‘circles’ of people, each of them also intersecting a circle that represents the meeting itself. Re-labelling those circles to use names that would be recognised in their context, here’s a real example from the government digital space:

[Click on the image to enlarge it]

Wherever the intersections have two (or more) people, who between them both represent one circle to another and lead it on the other circle’s behalf, you have what Sociocracy calls double linking. It’s not hard to achieve, and when you have it, you immediately get the kind of diversity of representation I mentioned. Combined with Sociocracy’s deep commitment to consent, it’s a powerful model indeed.

About the Author

Mike Burrows is known to the Agile and Lean-Agile communities as the author of Kanban from the Inside (Blue Hole Press, 2014) and Agendashift (New Generation Publishing, 2018), the creator of the Featureban and Changeban simulation games, a keynote speaker at conferences around the world, and as a consultant, coach, and trainer. Prior to founding Agendashift, he was an executive director and global development manager for a top-tier investment bank, CTO for a late-stage startup, and (as an associate of Valtech UK) the interim delivery manager for two UK government digital ‘exemplar’ projects. Before and sometimes during those, he was a software developer (programming remains a passion).