My name is Lukasz Szyrmer. If you are new here, I am the author of the book Align Remotely. I help teams thrive and achieve more together when working remotely. In this episode of the Managing Remote Teams podcast, we speak with Mike Burrows. Mike created the AgendaShift framework to help companies implement change in a way that feels effortless and is based on outcomes everyone cares about. In fact, it’s designed to engage the entire company while implementing major changes.
I've been following Mike's work on the periphery for a while, but I got really interest recently in his pluralistic attempt at getting the best of 7 different operational models into a grand unified theory of agile in Right to Left. He's probably best known for his AgendaShift where he's come up with an approach for positive organizational change that minimizes internal resistance that people typically feel when such things are introduced.
Upon listening, you will discover:
- Why objectives are central to engaging everyone in organizational change initiatives
- What often goes wrong with particular attempts at Agile and scrum and how to fix it
- How to use outcomes to faciliate strategy and map it to delivery
- What right-to-left delivery means and why it really matters
About Mike Burrows
Agendashift founder Mike Burrows is the author of Agendashift: Outcome-oriented change and continuous transformation (2nd edition March 2021), Right to Left: The digital leader's guide to Lean and Agile (2019, audiobook 2020), and the Lean-Agile classic Kanban from the Inside (2104). Mike is recognised for his pioneering work in Lean, Agile, and Kanban and for his advocacy for participatory and outcome-oriented approaches to change, transformation, and strategy. Past leadership roles include global development manager and Executive Director at a top tier investment bank, CTO for an energy risk management startup, and interim delivery manager on two of the UK Government Digital Services ‘exemplar’ projects.
- agendashift.com/book redirects to the main page for the 2nd edition.
- Most other things would be under agendashift.com/resources.
- Mike Burrows on LinkedIn
Show Transcript
Mike Burrows, welcome to the podcast.
Great to be here, Luke. Thank you for having me.
Yeah, my pleasure. I wanted to ask a little bit about your backgrounds in terms of how you got into agenda shifting in the first place.
Oh, that's so that's the question right from the beginning. So
small talk,
I'm old enough to have had multiple careers, you could say. But I went from leading a global department at a top tier investment bank around the time of the credit crisis, which was to put it mildly an interesting place to be.
And interesting, not always in a good way to being a CTO of a energy, risk management startup. I was running a department of, a hundred odd people to running quite a small team within an organization that was actually smaller than the department that I used to run. At the time that it was gonna be the case study for Kanban from year. So it, my, my first book and in that process, I was already blogging, I was an active member of the I don't know if he was still going, but the campaign, the mailing list was was very active at the time. After I finished that, I went into consulting, wrote Kanban from the inside. And so for a while I was, a Kanban guy, it was very well received book. I'd come up with the values model for Kanban. That was really the trigger for writing the book.
There I am, identified as the Kanban guy but that's a little bit of a, but, and it's actually in a way I'm in the body is around something that actually is actually a strength that can by not another weakness, but I just wanted to take it a bit further.
So one of the things that's very interesting about CAMBA and is it the dividing line between what is the thing, the thing that you're implementing , and the process by which you implement it, that the noise in between those is very blurred.
But all the same, it does not start with the conversation. Why are we doing Kanban in the first place? I got very interested in how those upfront conversations go. I got very interested in how those improvement conversations go as well and try to understand how could you do it in a way that didn't prejudge the answer.
in a way you can think of agenda shifts being Kanban, where you take all the campaign out of it, and then turn the dial up to a level practical. But, if you know enough about Kanban in terms of change, you begin to get the idea. But then it took of means a strategy as well.
And so the why question turns out to we, it really interesting,
Having strategy conversations about transformation, having strategy conversations more generally. About, where do we want to be as an organization? What customers should we be providing our services and products to? How are we going to go about doing that? How are we going to become the organization? We want to be where we want to be and all the rest of it, all of those things are really fascinating conversations.
And I started to look at agile and the change process much more holistically, much more integrated, and start to get a vision of the organization where strategy, delivery, organization development. They are integrated in two, three participation integrated through and people talking to each other and where we have an idea of what some of, some important conversations need to happen and how to have some of those conversations in a good way.
So that's about where we got to by 2017 ish. And I started writing the first edition of the book. And that's what came out. First of all, public then properly on Amazon and everywhere else in 2018. And that was pretty well established by them. You had a part in the program going some very well developed , assessment tools templates , all the other things that you can get from the gender shift websites workshops pretty well developed.
And then in the, quite a lot of those happened in three years since I right to left that was published in 2019, and then we'll do a book in 2020, and that was taking what's now how very outcome oriented view of the world , we don't start with a solution. You wouldn't start with the agile framework. We start with the outcomes we want to achieve and the conversations that we have to work out what that looks like, how different outcomes relate to each other, strategically, all that kind of stuff. And right to left was taking that same perspective to the lean agile landscape.
So how can we describe all the things we know about agile frameworks? The challenges of scaling, how does bigger picture organization stuff, strategy, leadership, all those kind of things. How do those fit into a lean agile world where we put outcomes before solutions, and we'll be really to look forward to outcomes, look forward to delivering on those outcomes, to meeting people's needs, learning about our customers and ourselves in the process of doing that.
And let's think all the process stuff fall in behind. Plays outcomes. So what happens when you look at, from in that way, what happens when you look at Kanban in that way? And even the the scaled stuff, say from the Spotify. It turns out to be very interesting way of looking at the hall and the, and a very interesting way of integrating them as well.
Looking at things through a lens of outcomes is just it's that much more practical, up a notch or two in terms of practicality. That's what I, that's what I've been doing for the last five years. A bit less, identify with them, the Kanban community now, I still owe it's a adapt, I wouldn't be where I was without it.
But so much now is focused on issues like engagement and strategy and so on. And making sure that we compartmentalize change management in such a way that we don't get polluted by all the dysfunction that's associated with it. Calling ourselves as a gender shift as an example of an engagement model log and change management.
Really trying to establish that as a category really out outside of change management. So we're not sure if the ambition that's what we've been doing the past few years.
If it's not really a Kanban book, is there another approach that you favor?
It's a very, it's a very pluralistic book in its outlook which agenda shifters is as well. And we tried to promote ourselves as neutral, or agnostic. I think those those aren't the words, I think pluralistic is a much better word. We have to integrate things. And we put things together for fun to see what happens when you put them together and encourage other people to do that.
But also, realizing that when you look at things with a particular lens, and we look at things through the lens of outcomes that actually help. It gives you some pointers as to how how things can be integrated.
If I understand and remember it correctly, you start with discovering outcomes and not the underlying reasons. Why is it so helpful to do that?
Let's do this right to the left and who worked backwards. Is there someone that's going to come up with, if someone's going to implement a solution idea. It's so much easier if that solution idea is in their own words, the reason the motivation for that solution idea is in the, in their own words.
And they've had conversations with their colleagues about why they why there's a need for this solution before they, generated and evaluated multiple ways of achieving that outcome and so on. And you get completely away from this idea of selling solutions and resistance to change and all the rest of it instead to having conversations about what it is we want to achieve to the extent that it's necessary.
Breaking that down, thinking about what obstacles are in the way that thing we want to achieve, what outcomes are available. If we were to overcome some of those obstacles, understanding the relationship between those outcomes making smart decisions about which outcomes to focus on first.
And now that you can see this sort of strategic landscape of outcomes laid out. In front of you and it just it just bypasses a whole lot of the pain of change management and it deliberately forces you to defer decisions on solutions so that you're not forcing solutions on people you're expecting solutions to emerge at the right time.
I'll give you a little analogy. When we went continuum, we went when we were into iterative. And then when we went continuous, the kind of the iron triangle kind of went out the window. The time dimension of the iron triangle started to become less and less meaningful. And if transformation is going to be a continuous process near the idea of the solution is no longer, very helpful. And actually what's much more useful is to think about how can we set ourselves up. So always looking for the next thing, how can we set ourselves up so we can support people to find solutions that aligned to our overall objectives. And if you're familiar with OKR, this all fits very well.
It's not the kind of OKR that you wish need to be 10% better or something like that, not talking about, Oh, it gets coming from on the high, we're talking about a participatory process that, that models the landscape around us in terms of outcomes and helps us make some smart decisions that allow people to be creative and innovative and collaborative. And all those good things under every scale. It's not trying to be a replacement for the agile process frameworks or for this coding frameworks. But it actually creates some really essential infrastructure. If you want an organization that moves quickly, it's got to be able to understand where it's going
we articulate that and reaffirm that. If you build your delivery processes around that, they're always going to be working on the right kind of things. And the organization with them can then be so much more responsive, so much better at sharing intelligence and all these other things.
And we get away from this. What to me is a really miserable side of our child that their child has become plowing through backlogs. If you've read any of my books, I have very little time for that experience delivering mediocre products. And then we got ourselves into a stage where we, on the one side we're talking about autonomous teams and a minute later where we're giving them our strategy rather than letting them work it up for themselves. And it's a very funny kind of autonomy when strategy is something that happens to you yeah.
Performed upon you. Yeah. Going into that, I'd just start just to unpack some of the language that you use. That's quite interesting. What exactly does right to left mean in the context of all of this
RIght to left really just means always putting out comes before solutions. I illustrate it with a little metaphor for it, if you had to explain LEGO in a way that made it meaningful, where would you start? Would you start with truckloads of plastic granules arriving at the Lego factory? Would you start with boxes of LEGO leaving the factory, or would you start with children playing with the finished product? So would you start with the inputs to the manufacturing process, the output of the manufacturing process, or maybe even just the rate of boxes, leaving the manufacturing process? Some people like to start with the metric even or do we start with something meaningful? the need being met, the need for children to play and explore and discover and build them and all these other things that they do with LEGO. And then you mentioned Lego as a process focused on that moment, anticipating it, thinking about how it can be the best possible moments, thinking about how we can learn as much as possible, about that moment and about ourselves in that process and so on.
And use that as a metaphor for what's an agile delivery process looks like now, instead of thinking, that our job is to plow through a backlog of requirements our job is to keep focused on the next outcome that we want to achieve and keep focused on making sure that we're going to learn in that process.
That says something about how we're organized, how we plan, how we review the work that we've just done and so on. It also requires us to know what those outcomes are and probably what the next one is going to be and how they relate to each other.
So working backwards that employs some strategy conversations and things like that happening as well. Again, thinking about this continuously, it's not enough to say that there's a roadmap, it's not just a document, it's not just an artifact. There has to be a process that keeps that current. It keeps it informed by intelligence and insights and everything else. Scrum solves that by saying it's, the product team has responsibility. Yeah. That's not quite enough for me. Now you start to think of the big bit bigger picture about how organizations work and you realize how important it is that strategy and delivery and organization development are integrated.
I start to look to see how these things are supposed to happen and whether they're happening and so on.
I think it does a lot to explain what had been reported in the last couple of years. There's been some quite miserable experiences of agile people hating on agile and saying that agile is date and all the rest of it, it's gone from being something iterative. And something about learning to something that's about plowing through stuff. And I really regret that. And I think we even describe it wrong. If you look at many descriptions of scrum, their descriptions of a backlog driven process, I think that is really to be regretted that are, there are other ways of describing scrub. We were pursuing our shared goals, shared objectives, goal by goal that's describing iterative process. And each time we describe agile in a backlog driven way in a left to right sort of way, I think, slowly drip, we are undermining it, killing it, man. I think that's very sad.
I think a lot of the challenge usually lies in articulating these objectives in the first or discovering these objectives in the first place. What are the most common areas where organizations struggle in terms of doing that?
There's there's a couple other, firstly, I divide strategy into two main areas. So there's one around ways of working and there's one more genuinely about the organizational structure of your product strategy and so on.
So around ways of working, the problem is people go from, Oh, we want to be more agile to, we need to implement an agile framework and already we're in we're in left to right mode already starting with a solution, not starting with the outcomes and if you're going to do that with at scale, so say you're implementing safe and let's make sure we keep this new scale, that job framework plugged into our PMO that thinks in terms of planning through backlogs, thinks about what breakdown structures and all the rest of it.
And, making sure that we're getting through all our stuff, what hope is there that they will discover a properly right? For the left process that really is focused on the customer. Really want to focus on understanding what's really happening with customers, what their real needs are, how we're meeting them and continually adjusting adjusting ourselves, adjusting our strategy then to, to all of that it's very difficult, it doesn't mean that the frameworks don't work or can't work, but you started in that solution driven way. And you do nothing to change the prevailing left to right mindset, as you could call it, the backlog first. The problem is that we're using w why is she using the language of the old paradigm and using the language of project management. I should say that, and we're using that same language to describe the new thing. And that is a mistake. And if we seriously want an iterative process and learning process, let's describe it in those terms first. And then think about what are the processes that cheat that process just well, enough fed, not overfed so that you end up worrying about your backlogs are going, but just in a fed well enough informed and with, good quality work to do.
And how do you keep people participating in that process that people are properly motivated , and getting away from this heads down, let's plant the directs mentality.
Yeah. And what about the more strategic objectives what are the common challenges that you see in terms of that?
I'm simplifying a lot, but I see , two major schools and it's a bit analogous to left to and right to left, but it's not quite the same inside, out and outside in, inside out strategy. We have these capabilities and, these are the things that we can do.
And our performance on each of these areas is, X, X, Y, and said, how can we build on that? And how can you, how can we do more with what we have? So how can we be faster? How can we sell more, starting from where we are. And that is a way to find some incremental changes, but it is not very exciting.
And it doesn't actually tell you where you're going to get to.
And I think a much more interesting kind of strategy is outside in strategy. And you actually start from the customer first and work your way in. So what, in abstract terms, we're positioning ourselves relative to the customers that we want, and then working our way into what that means for the organization in terms of what kind of organization we want to be and how we want to present ourselves to the outside world what products and services we need to offer on what platform are those products and services built.
We're not just technology, all the capabilities of the organization. And what does that mean for us inside the organization, in your people, in teams and so on. And I've designed them outside in the strategy review, and there's a template. You can download it for it. It starts with the question of what's happening when we're reaching the right customers, meeting their strategic needs.
It's a simple generative question. It's one that doesn't in any way prescribed the answer, as long as reaching the right customers, meeting their strategic needs is a sensible thing to focus on, you're probably gonna have a good conversation out of it. We have some ways of unpacking that question, who's the, we, what does reaching for us mean what customers, where what are their strategic needs, the needs that are most relevant to our, our mission or our current objectives and so on.
So you can have a conversation about that and you can imagine what it's like when that's working really well, when it's working in its ideal best, you can think about what obstacles are in the way of that. And then you can look beyond those obstacles. So where will we get to quickly. When we've addressed address some of our near term obstacles, where will we get to when we've addressed some of our further obstacles from, we can go from outcomes to outcome as well, given one outcome, then what happens when you get another outcome?
And so on, this is a generative process again, then in fact, this is what they get the 15 minute photo games about knowing just 15 minutes from a list of a small list of obstacles, generating a potentially vast number of outcomes. And then you can look at how they relate to each other.
You can organize them very simply short term medium. So long-term, or you can use some fancier mapping tools that help you explore the relationships between them in a bit more depth.
So that's the idea. So for each layer customer organization, product platform teams there's an equivalent question, a generative question, and then a generative process that generates the obstacles and outcomes that you can then the range.
So that's the basic idea of the strategy interview. It's a great precursor to OKR. Meaning before metric is one of my sayings, start with a number don't start with net promoter score or lead time or velocity, whatever your framework's favorite metric is.
Instead, what is it we're trying to do? Who is it we're trying to be, where are we trying to be? And that's expressed that in ways that motivate people and then think about what's in the way that let's be real, be realistic about where we are, what constraints we're operating under, what challenges we're going to confront, , but competitive pressures we might face.
For example that's getting real, it's not just tree map a vision and coming up with a list of features, it's getting real about capability and opportunity and, matching one to the other and soon.
Yeah, and that's very good. I'm a big fan of zero-based thinking in terms of strategic planning. Speaking of strategy, why are you a big fan of a wholehearted approach to strategy?
So wholeheartedly, that kind of was an accident. So while I was writing right to left, I read Christopher Alexander's book, binders books on architecture. that the timeless way of building as the name of the book
And he talks about a building being wholehearted, for building to be wholehearted. You can't be, so they can't be torn apart by, in in conflict and contradiction and all the rest of it, and there was a sense of wholeness and health and wholeheartedness, I'm paraphrasing slightly, that's the way he was thinking about what is a good design, but like for a building.
And I was thinking what a great metaphor for those of us working with organizations. And it was almost a throw away line in the book. What if we saw ourselves as being in the business of building a whole hearted organizations this was even while I was still writing the book, I'd love to bounce it.
And I got quite an amazing response to it. And I was doing a workshop in London a couple of weeks later. And we decided we would have a whole hearted Curry. And we went out to the field on the the first evening of the workshop. And we were quite lucky. We were done in the basement, in the corner, where we had two walls around us and looked quite a bit space.
I think 15 of us, We were sticking stuff on the walls and people are bringing to literally bring it to the table. What whole heart had meant to them, which was exactly. This is how gender shit works. This is a generativity again, I was very insistent that we shouldn't prescribe what the whole hearted organization, most certainly not prescribed how they should work.
We say the barest minimum of what we mean by wholeheartedness. So I do quote, the Christopher Alexander quotes.
About the most concrete I want to get. Is this idea of strategy, organization development and delivery being integrated and integrated through participation? If there is any conflict and contradiction and so on that it's easily worked out because people are talking to each other.
There are certain styles of conversation that helped to do this, a certain styles or certain, certain, like the strategy review. We have a service delivery review as well that, designed to expose these contradictions and give you a way forward. That's about as prescriptive as I would like to get.
And in fact, sometimes when I do an exercise on a whole heart, if sometimes I just put up a sentence, we're in the business of building wholehearted organizations or we're in the business of building wholehearted and deliberately adaptive organizations and not even specify wholehearted and deliberately adaptive, and then let it mean to people, what they want it to me and be surprised at how constructive those conversations can be because you start to surface things that people really want.
And when you think about the obstacles in the way of those things, we'll identify some real organizational issues and I could have stopped there. I couldn't resist and I have dug more into what does it mean to integrate strategy, deliberate delivery and organization development.
And it led me almost negatively to the viable system model. But rather than say, wholehearted isn't implementation the viable system model and destroy the generativity of it. The deliberately adaptive is the more technical. Two sides of the same coin. So wholehearted is qualitative and generative and deliberately adaptive is more technical and diagnostic consultant that helps you understand the many of the dysfunctions of organizations, helps you understand why scaling is so hard.
conversation scales really well. So it's good to start with something that scales and of all the, technical models, the vulnerable system model is the one that all the models that I know that scope scales, the best is, a fractal model that works from the level of the individual person who was the original archetype for it. And up to teams, departments, divisions, organizations, economies, countries,
Back to wholehearted and just basically, are we doing those three things, strategy delivery, organization developments, are they talking to each other, how they're talking to each other? Are they in balance with each other and have a strategy running ahead of delivery? Or is the tower running the dog, delivery is doing what it wants to do and strategies catching up. How, how did we have conversations about who he wants to be and where we want to be? And all those kinds of things, this rule really crucial to the health of any organization from team level upwards, or arguably from individual level upwards, can be myself, where do I want to be?
What do I need to deliver ? How do I need to develop if I'm going to deliver what I want to deliver and so on. And there's how you calibrate things and how do you maintain integrity, trust building, all those kinds of things. This was stuff that we're actually known about for 50, 60 years. It's amazing. But so there's a bit mind bending.