In this episode, we check in with Mike Burrows, the Author of Agendashift: Outcome-oriented change and continuous transformation, and Kanban from the Inside. We learn from Mike how organizations can leverage agile approaches and collaboration methods to generate meaningful outcomes from digital initiatives.
Mike, welcome to the show. I'm thrilled to have you on the show and discuss how to leverage Agile concepts and tools to transform customer experience and bring more business outcome. To get us started, can you tell us a little more about yourself and what you've been doing lately?
Great to be here. Thank you very much. Yeah, I am the founder of Agendashift and the co-founder of the Agendashift Academy. I'm perhaps best known for my books, Kanban from the inside, already seven years old now, a Lean-Agile classic, then Agendashift came in 2018, and the second edition of that earlier this year, and also Right to Left: The digital leader's guide to Lean and Agile.
What we do, it's a big exercise in engagement and in meaningfulness. Making sure people understand what outcomes they are pursuing, outcomes articulated in their own words, the results of really productive conversations happening in the organization. All the things that need to happen before, during, and after anything significant happens; business initiatives, change initiatives, product ideas, services, all that kind of stuff.
We're trying to get away from the idea of Agile being just a process that's imposed. That's a dysfunction and it's unfortunately a dysfunction that a large part of the Agile community has fallen into. If you're familiar with the manifesto, you'll know it's ironic, people and interactions over processes and tools is one of the first lines of the manifesto, and yet we've become about rolling out process. We can do a lot better than that. We need to do a lot better than that, and that is what Agendashift is all about.
That's really exciting because I was particularly intrigued by how you're looking at it, I’d just call it Agile Plus, as a way to get into the engagement with stakeholders, which really, I believe, is a timely topic because of the situation the world is living in right now, where a lot of digital initiatives are getting a lot of pressure to be deployed quicker.
It does seem to require a new level of stakeholder collaboration. But first, when you say Agile, what you really mean by it, because it has a lot of history by now. I just want to quickly make sure we are on the same page in some of the evolution, the changes that you are seeing there.
Well, there're a few words around the Agile agility. Whenever I write Agile with a capital A, it's always obvious in the context, and often explicit in the context, that we can trace it back to the Agile manifesto. In 2001, [inaudible 00:03:36] a convergence of things like Scrum, and XP, and various other things, and a manifesto that really has made a difference.
I will always give that event huge amounts of credit for achieving something world-changing. Agile, for a lot of people, is becoming something a bit different; its Agile process. That's actually a problem.
It's perhaps inevitable, when something goes mainstream, that the principles that underpin it gets spread very thin. People forget why we're doing what we're doing, and people begin to resent the imposition of it, as well.
If your goal for your organization is to have an organization that's innovative, collaborative, and so on, then your means for changing the organization needs to be the same. You need to engage people, you need to involve people, they need to collaborate, they need to identify the right problems to solve, they need the opportunity to come up with some solutions that are really going to work fantastically for them.
The old change management industry, the idea of starting with big solutions, big frameworks, big whatever, and rolling them out, is just totally the wrong approach. It's backwards, unless you start taking resistance to change, not as something that's overcome, but as a sign that they're doing it wrong.
With Agendashift, we start with authentic agreement on meaningful outcomes. That's the results of the kind of conversations that you need to be having if you're trying to do anything significant, anything that changes the way people work, anything that changes the relationship between staff and the organization, or the organization with its customers, and so on.
That covers transformation work, it covers improvement work, it covers even product work, as well, and there's a really nice interchange between those different spaces.
I think sometimes a success can get messy…and it's really coming out of product-based, more saas companies, and that kind of a way of working is gaining business attention because it's working, and the world, to me, is getting even richer from it.
Business teams who are not used to work completely within that kind of a team methodology are really getting into it now. And it's more of a company-wide agenda at this point.
I am one of those people who are having problems with things not working fast enough, though. Looking at a lot of cases where there's a huge initiative that impacts most people in the company and customers…like, "Hey, we have a special situation, now. Digital initiatives needs to get going faster. And the things that we've been doing with our customers, basically a manual plus kind of way, is going to cost us big time, how do we get self-service rolling?" Or things in that nature.
I would love your thoughts on how Agile came about…and is changing now that it's being used by a broader user set and asked to solve probably even different types of problems. How should we be looking at it now versus what it was before?
It's interesting, you mentioned self-service, because I was delivery manager for two of the UK government digital Exemplar projects. These were flagship projects to demonstrate new Agile ways of working in government.
Just think about the problem we are solving. Government and digital, those words don't go together very comfortably for most people. You know, we all know what government is like. And we know what government IT projects are like. That's how digital used to be done in the UK. You spend a lot of money coming up with a design for a system. You may be paying another supplier to build the system. They then chuck it over the fence to maybe a third supplier who's going to support the system when the thing goes live. When it does, everybody hates it. What a stupid way of developing software, developing products of any kind.
Back in the David Cameron days, the government said enough is enough. We need to change this. They came up with a very actually brilliant strategy. Principle number one was, start with needs. It really was strategy. They were really serious about starting with needs. If you couldn't prove that you were serious about understanding user needs, and that you're going to keep on top of understanding using needs as users evolve, as systems evolve, as government policy evolves, as society evolves, and so on and so on, and evolve your services to suit, have the commitment to keep evolving your services to suit your better understanding of user needs, then you risk your project being stopped. Really, really serious about it.
Again, it's turning the whole process around. Instead of sort of starting with the requirements, in building things and releasing things, and so on, you start with, what need is it that we're trying to solve, and what would it look like when we solve that problem? How can we most quickly demonstrate that we get it? How can we test these ideas with potential users? How can we actually roll something out that we can test with real users, and develop the kernel of a system that, perhaps, is just [inaudible 00:09:07] to start with, but as quick as you possibly can, is the beginning of a new life system, and then the system grows around it?
You said things are messy. Well, yes, they are. The world is messy. The needs that we're responding to are messy. There's a saying it's Gall's law: any complex system that works, evolved from a simple simpler system that worked. Specifying hugely complicated systems, and rolling them out, is actually a recipe for pain, and disaster, and also for disappointment.
Chances are, you've not really understood your users properly. Only by interacting with them can you hope to do that. We need to start thinking backwards. The title of Right to Left is thinking backwards from needs met, outcomes realized, learning captured, and focus on that and work backwards. Work back through the technology of being able to deploy quickly. Work through the team dynamics, and the tooling, and the practice, and the development process.
You've got to have ways to organize the work that we are planning on doing soon; things like user story mapping jobs to be done, those kinds of things. There needs to be some strategy behind it all. We need to be clear about what we're trying to achieve. Clear about the constraints that we're operating under. Clear about the most significant obstacles that we need to overcome. Clear about the sources of uncertainty. Clear about the commitments that we're going to need to be able to make, and so on. With any of those elements missing, then you're set up for failure. Great organizations, great product teams, and when I say product team, I mean the whole thing, not just the product specialists, the product owners, product managers, but the whole thing. It's been a privilege for me several times in my career, but those government projects were great examples of it, to see all those elements in place.
It's exciting and motivating working towards clear goals. We had the right people in our teams with all the necessary skills. We evolved our process as we went along. Our Scrum-based process was actually very, very suitable to the early parts of the project, but it evolved into a [loss 00:11:29] of end to end flow based process as the systems and the process begins to mature.
I have never worked with British government, and my enterprise space sometimes looks complicated enough, but I can see when it involves governmental bureaucracy and those teams, how it can get really bigger.
There's good news, of course, if government can do it, anybody can do it. [crosstalk 00:11:56] If the most bureaucratic and top down organizations in the world, which governments are, can do something as exciting as this, then there's no excuse for commercial organizations.
I have to bring you back to reality, some of the day-to-day business and living with it, because we really are having this conversation where the topic is becoming relevant for companies of all sizes. When you are dealing with limited resources, some of the skillsets, and some of the traditional domains giving you input as necessary. The problems that any of these projects have to deal with, sometimes are similar in its complexity.
I give you an example. The other day, I was talking with consultants who are working on enabling self-service for insurance claims processing. Part of the difficulty is…everybody can agree to, say providing great service with new customer experience, right? And then, that leads to taking the experience to mobile communication interfaces like chat apps, WhatsApp in this particular case, and that triggers many changes…then the problem finds another stakeholder in the pricing department who has to get involved, and so on. The thing is, time is something that we don't have enough of, or is that just a mindset?...and if you start engaging these people at that stage as needed, it's taking a lot of time. It's becoming a blocker in a way.
Is there a smarter way...You don't want the team to be really big in the get-go, but is there a smarter way to engage these stakeholders to get this expedited?
You can approach the problem from both ends. So, first thing, starting at the user end of things, you need to know who your users are, and as soon as you know your users, and you know that some of them are going to be using mobile phones, then the early design work, the early user experience work, you're going to have to do that on mobile as well as on desktop.
You can't afford to leave mobile as a "day two" thing, if you know that's what most of your users are going to be doing. We've found in government digital, that actually they're surprisingly high in proportion, even several years ago, an amazing proportion of business was conducted over mobile; people applying for benefits, people applying for apprenticeships.
They might be in the classroom where they're hiding their phone under the desk, and you get to hear the stories and you get to learn how they use things. Just presenting stuff on the desktop would be a mistake, so, that's from that end. Get to know your users better, have some different personas and recognize there are different, multiple kinds of users and so on, and make sure they are well-represented in your thinking.
At the other end, at the beginning of anything big, it's important to get the right people in the room. You need to work through what the end-to-end process looks like, what all the touch points within the organization are, how all the behind-the-scenes things that the customer doesn't see, how all of those kinds will be worked, and who needs to be involved in making sure that they worked smoothly, their policy implications for an insurance company from a risk point of view, for example.
For government, there are legal implications to some of the things that we did, some wording was unacceptable, for example. There were times when I worked, we would get blocked on a policy decision, had to be made by someone from legal or something like that. We had to get a translation into Welsh, or whatever it might be.
You learn to get smart about it. You learn to recognize, you get a good smell for what's a piece of work that's likely to encounter one of these problems, and you make it extra visible. We use different colored cards, or different color stickies, to highlight things likely to have these different kinds of problems. You start to manage them proactively. You don't start development on them until you've already had some of those conversations. If you've had those conversations in advance, then things tend to flow, 9 times out of 10, will flow through development much more smoothly. You can't get all of these things right a hundred percent of the time, but if you keep making the same mistakes, that is stupid.
You have to learn. Learning hasn't happened until the process changes, until the way you manage your work, the way you visualize your work, the way you prioritize your work, until there's that kind of change happening, you haven't really learned anything. You're just waiting for it to happen again. This learning process needs to be built into the delivery process, as well.
Totally with you on that. The only definition of stupidity I wholeheartedly sign up to is doing the same thing, expecting different results. I have to keep telling myself that. Some of the ways Agile teams have dealt with problems…using visualization and such. Can you tell me about those more, things that came out of Agile that are really helpful for tackling such problems?
There are two strands of Agile going pretty mainstream now, but in the early part of the century were much newer. You have Scrum. Its key idea is around iteration using your two week sprints, or however long your sprint is, as a container for some innovative work to happen. At the end of those two weeks, out comes something amazing. That's a really simple, beautifully simple idea. For the early parts of a project, thinking government, at the end of two weeks, having something worth demonstrating, that's amazing. That works great. That works really well.
Kanban comes more from the idea of [inaudible 00:18:15] and flow, and things like that. Making work visible, using all that. There's no one way of doing it, but using every trick you can think of to make your pain points visible, in the short term, helps you manage those issues practically.
In our case, where we had policy decisions to be made or language translations to me made, two pain points for us, we made those extra visible. Every organization has different pain points, and you'll need different visual techniques to make your pain points visible. You get on top of them, and then you think, well, how can we change the process so these pain points don't bite us so often? All of their conversations, which should be happening earlier, which is a very common way of improving a process, all the conversation which should be happening earlier that will preempt these problems arriving later, are often very cheap solutions to what are quite painful and expensive problems if they occur late in the process.
Back to customer experience, and I mean by that, end users actually experiencing the outcome. Sometimes there's a huge distance between getting something to a test stage at the end of two weeks versus making it work in productive mode. Get us to where, at the end of the day, the end customer actually experiences it, how we ensure the learning from feedback to reiterate?
Yes. I'll go left to right in the more conventional way, just to explain this. You've got a feature idea that you want to develop, and you're clear about the business objective, the user objective, the customer need, that this feature is going to address. If we don't have that, then we shouldn't be doing the feature at all.
To make sure we all get all that, actually getting people into the room to actually make sure we understand the need, make sure this feature idea is the best way to meet that need, and then, quite often, it's the UX people that next take the lead on this. What would this look like from a visual point of view and from an interaction design point of view?
You start to, first of all on paper... When I say on paper, it might be on the screen, but it's not something that's functional, get an idea of what visually it will look like and the journey that you would take the user through as they are using this feature.
Then build a little prototype that you can actually test. Government Digital, we didn't just test it amongst ourselves, do a demo to each other, and say, "Doesn't this look cool?" We would actually drag people off the street and say, "Have a play. What do you think? Imagine you have this need. I'm going to give you this system. How would you try to meet that need using the system?" You're getting to see how usable your system is. You're getting to see how easily people can find the different things that your system offers, and so on. You can do all of that without actually having written any backend services, no integration with the rest of the organization, and so on. This is really quick and cheap to do.
If you've got a good UX developer, you can do multiple iterations even over the course of an evening, and I've seen this happen, and it's great fun to do this. Then from that prototype, you do it properly. You build out the service side things, the integration with the organization that needs to happen, the prototype gets integrated with the back end, or it gets rewritten, or whatever's appropriate given your technology constraints.
Then typically, we might be careful about how we release it. We might deploy the code to production, but someone might have to flip a switch before anyone can actually see it. You might make it available only to a small percentage of users, or to specific users, perhaps people you know that have this particular need and you ask them to try it out. It's a way, without incurring significant risks, of getting quick and early feedback on something you're not yet sure is ready for prime time.
With your ability to build quickly and deploy quickly, if any refinements are needed, you can quickly make them. That process end to end, doesn't have to take long; I'm talking days, sometimes faster. Sometimes with something super urgent, you can do it in hours. Those feedback bits might wait. Perhaps some things, for example, only release once per sprint. It might take a couple of weeks before the next iteration gets to production. Other teams can do multiple deployments in a day if they want, and that's great if they can do it.
Back to my digital days, I remember on one of our early releases, we deployed a bug and we were absolutely appalled. We were so embarrassed that we delivered a bug. We fixed it the next day and sort of thought, phew. And then the feedback came back. "This is amazing. He fixed the bug in a day, never seen this before." For us, normally to fix bugs, it takes months. Someone has to raise the bug. It has to go through a triage committee. It has to go through a prioritization committee. It has to get onto the project plan for the next quarter, and many months down the line the bug fix goes out. It doesn't have to be that way. As I said before, if government can get this right, then there's no excuse for your organization.
You're setting wrong expectations, too, at the same time.
I don't mean to dwell on this, but I think it's important as agile practices go "mainstream," because the traditional organizations are more used to having control mechanisms, and because it's coming from a different ethos, but we’re also learning that sometimes it's not a bad idea to have both together. How would you think about this "go with rapid piloting and testing" versus having it more tempered with controls?
Yeah, I certainly don't underestimate the level of challenge there. You said everything I said sounded obvious, would be obvious to most people. In fact, multiple generations of managers have been taught that the proper way to do something is to analyze, specify, build, release, and then see what happens.
When you're against a, probably, 40 year legacy of managers being taught that is what doing it properly looks like, to get them to commit to a more iterative way of working, it really is a challenge. I would never doubt it. Then the question is, well, if people can see logically that yes, this iterative way of working, yes, I can see that it makes some sense. I can understand that, yes in some ways, it's actually lower risk rather than higher risk.
In some ways the economics looks better, and so on. There is a logical case to make, but you still got to overcome the fear that if we haven't properly designed this thing, then we've lost control. Where to start is definitely an important thing. I think starting with something where you know innovation is going to be necessary, is probably the best place to do it.
If you're already an organization that's trying to do something digital, and that's not your comfort zone, then it's probably actually an ideal place to do it, but it does take some guts. You would love to say, "I'm going to spend this amount of money. It's going to take this amount of time," and introduce the supplier, and it's their problem. Welcome to the real world. To offload all of the risk is very, very expensive.
No supplier is going to guarantee perfection within the deadline without also a huge budget to go with it. Even then, there were no guarantees. A more iterative approach is the way that most good suppliers will want to work on that kind of project. That actually can help you. Again, that's how the digital things works.
We put together some great digital teams based from suppliers that knew how to do it already, and we integrated experts from suppliers, with people from the clients, from the government departments, for example. We built mixed teams, left our budgets at the door, and we just started doing it. Yes, it takes some trust. It takes a little bit of courage, if you've got the right strategic goals in mind, coming from the top.
If your senior leadership understands that we need to innovate faster, that we need to collaborate better, we need to integrate with our customers better, we need to learn faster; all of these different things. Then you can treat a project like that as actually a massive learning opportunity for the whole organization.
I fully appreciate the fear that people feel, but, they're going to have to do it some time, and they should go about it in the right way. The right way is to optimize it for learning, not just for the sake of the product, but for the sake of the organization as a whole. I think most of the success stories are where that has happened.
That is really... Sometimes it's just too obvious, but being able to think that and capture that is really beneficial. A lot of times, I see people looking at it as just a baby step, the low hanging fruit approach. You are, in fact, talking about the opposite…maybe you should just start where the innovation is needed the most.
Ten years ago, that's where I was as well; baby steps, small changes, don't do anything that's going to upset anybody. It will only take you so far. The piece for me that was always missing was, we need to have some serious conversations about what it is we want to achieve. We need to get the right people in the room to have those conversations. People that have the power to spend money, people of authority, people who are good at articulating what it is we eventually agreed to go for.
Also, we need people in the room that understand where the pain points are, where the obstacles are going to be, people that know their customers, people that know that the organization's technology, all of that. I always say at least three levels of seniority in the room, people with authority and people who have knowledge of what's really happening on the ground.
That is the piece that is so often missing. No, I'm just choosing a solution based on an article you've read somewhere, or based on the conversation with a salesman on the golf course, that's a terrible way of achieving anything significant in your organization.
By being open and honest about what's hard about it, but being open and honest about obstacles, not just the ones that you're aware of, but being open to listening to what other people's obstacles are, that's the way of building trust. So you build trust, and then you build some idea of where it is you'd like to get to, and some of the signs that you're winning along the way, and it's all articulated in your own words, it's organized coherently into something that's beginning to look like a strategy. Well, that's exciting.
Facilitating that is now what I'm about. I tell people I've dedicated the rest of my career to outcomes. It's actually about those conversations. It's not about 10% more for 5% less. It's about outcomes that mean something to people. It's outcomes that are realized when their own struggles are overcome, when their customer's struggles are overcome, and the organization is achieving something really great.
You can't do that just with process. We've got to do more than that. We've got to do better, as I keep saying.
That comes back to the whole notion of the North Star, in a way.
Yeah. One of the tricks we have in our toolbox is the idea pattern. It's the way of taking a true north, or a north star, whatever you'd like, that might actually be coming from the facilitator. What you're not doing is selling that to the organization. You just give them a chance to imagine what it would be like, and then put it into their own words.
The way we put it in their words is the idea pattern: ideal, obstacles, outcomes. What would it be like if we had this? What are the obstacles in the way? What outcomes would we achieve if we found a way to overcome those obstacles? Then what happens? Now every time we ask them what happens, we are articulating things that are of increasingly aspirational for the organization, and we're getting further away from the original thing that facilitator might have provided.
That works at a high level. We've got some various high-level statements that we use to start those conversations. You can work at a low level as well. You can use things like assessments. If it's a really well crafted assessment, each of the prompts in the assessment can itself be an inspiring statement that you can have these conversations around.
People prioritize themselves which assessment prompts they want to focus on, and then from there, what problem area is this highlighting? What would it look like if we did something really great here? It's such an easy pattern. When it's explained to you, it's obvious, and it's a really easy and great way to get away from just going with the first solution that you thought of, which is almost always a mistake, even if it's the right solution it's a mistake, but you need to have those conversations first.