Mobius loop with Gabrielle Benefield

Join Murray Robinson and Shane Gibson as they as they chat with Gabrielle Benefield, the inventor of the Mobius loop, an outcome focused delivery framework. 

Gabrielle shares her journey in agile product development from Silicon valley to Yahoo.  And the importance of focusing on outcomes of outputs and improving decision speed.

We discuss why organisations don’t focus on outcomes, the problem with contracts and scaling an outcome based approach.

And finally, we talk about how you can use an experimental approach to bring an outcome driven, focus to your organisation.

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson.

Gabrielle: And I’m Gabrielle Benefield.

Murray: Hi Gabrielle, thanks for coming on. We wanted to talk to you about Mobius, which is, your product development approach. Could you start by giving us a bit of a introduction to who you are and what your experience is? 

Gabrielle: I’m a Kiwi by birth and did live in Australia for a while. Early on moved to Silicon Valley. There I was working in early open source, so a company collab net. In those days. No one knew what open source was, so it was trying to convince people they should open their stuff up and give it away for free. And at the time that was fairly radical and people really pushed back and said, that sounds crazy, but we did it. And of course that worked pretty well. And I think that’s where a lot of my thinking around modular architecture and how to really scale well came from.

Then I… worked at an early startup in San Francisco, and that was very traditional. They brought me into head up product and it was all sorts of waterfall. About 99, I came across pair programming and then early two thousands bought in agile. And that was pretty incredible. I had really the best people coming in. So we started off early doing a bit of Scrum, so Ken Schwaber came in disrupted rather dramatically the whole place where the CTO, who was fairly brilliant, but a little command control. Loved his product too much. They talk about passion for product. Sometimes I think you can love it so much. It’s your baby and it’s really hard to let other people give feedback. Then I brought in Tom and Mary Poppendick from Lean Software and by the time they came in, they said to this day, it was still the leanest lowest cycle time they’d ever seen.

So we managed to get everything from first concept up to market really fast and also had Rob Mee from Pivotal on the Pivotal team coming in. And Eric Evans from Domain Driven Engineering. So if you put all of this stuff together, it’s pretty phenomenal what will happen. Mixing that in with very agile user experience design. So doing guerrilla research out in the field, turning ideas around. Jeff Sutherland talks about 10 times productivity. That sounds made up, but we actually had over 10 times improvements.

So we’re talking about 2001, imagine that time where instead of talking about what features were delivered, story points, any of those things that early Agilists might be using I built a very simple PowerPoint for the board and what I showed them was here are the rough blocks of value, roughly about how long it would take. They don’t need the details. And then I said, this is what we’re expecting in terms of the outcomes. So here are the problems we’re trying to solve for our customers. Here are the outcomes we’re going after and we’re going to measure that progressively. 

Another person we were lucky to get in was Andreas Weigand, who was the ex chief scientist for Amazon. So when he came in, we set up really cool data analytics and we’re measuring all this stuff. So that was really what led to this 10 times improvement. It’s so stunning to see the difference when you focus on outcomes. 

The biggest problem we had, I remember going to a meeting with the bankers. So these are the people who take us public and they said, we’ve got a real problem. You can’t go out. And we said, why not? Everything’s amazing. Look at the numbers. And they said, that’s the problem. Your revenue goes up like going up a cliff. They said, no one can do that. That’s not real. It looks like you’ve been playing with the books. So I had the weird conversation with my development team to say hey guys, we’ve got to actually stop doing so much work. Let’s work on all the fun stuff because we’ve got to taper off the revenue to go public. So we went public, that was very successful. 

Then I got brought into Yahoo to… scale this agile way of working. I led the innovation group, and we ended up with, hundreds of teams globally. Our team was excellent, but they got very distributed, doing lots of little agile things. But you’re sitting there as I would be going hang on, Yahoo, was that really so successful? I remember one day I literally accosted one of the founders on the stairwell at Yahoo and said, look, we’ve got to stop doing so much stuff. We’re just got so much stuff going on. We’ve got to kill off some product lines, which is a big conversation when you’re talking about killing off product lines worth hundreds of millions. 

And I said, we’ve got to go towards outcomes. You’re doing this agile stuff, but it feels like you’re simply delivering more features faster. So early feature farming.

And what we’d done differently at the first startup is it was very outcome driven. at 2008 when I left my mission was to move towards outcomes over outputs.

Murray: Can you tell us a bit about Mobius loop? 

Gabrielle: Yeah. So even though outcomes was what I really wanted the term was very unknown. I remember at an early conference in Denmark, I gave a talk about outcomes over outputs and Henrik Nyberg came to me afterwards and he said, If you’re not a native speaker, this , word outcomes doesn’t make sense. Maybe it’s goal. What is it? And so this is the time when people were pushing against outcomes. They didn’t quite understand it. So while I got people excited on the idea of outcomes and why should really change, it was very difficult to make it stick. In parallel, I was working on a book about agile contracts . 

And then I had the epiphany right when we’d written quite a big book, a lawyer and I, that actually you don’t want your contracts to be agile at all. Agile is not the point. It doesn’t matter if people are working in an agile way. You don’t want to measure things like story points, et cetera. What you need is to measure these outcomes.

However, there was no good way to create the outcomes, not in a way that was easy for an organization to follow. So I spent a lot of time iterating with different models. So at the time I was reading John Boyd’s OODA loop, so the military strategist, and I was spending a lot of time with Tom Gilb, who’s the godfather of Agile. So this guy in the 60s is doing one week iterations and his stuff is all about outcomes. 

Murray: Yeah, we’ve interviewed Tom . 

Gabrielle: Tom’s stuff is brilliant, but as he always says, it’s probably other people who can easily get it out to the world. So anyway it was a concoction of these investigations that led to this idea of how do you take this into a simple enough model? Something that people can immediately grasp, but has more depth. So Mobius is meant to be a very simple model. Now, in essence, it is an outcome delivery framework, but what it does is it makes it very simple to get started. Where really you want to ask three major questions what’s the problem we’re trying to solve? Who are we solving it for? And if we solve it, how will we know? 

So that’s the left side of Mobius. Mobius is an infinity loop, and there’s three parts. Discover, decide, deliver. In discover, you go through the problem, understanding that you create your measurable outcomes, which create the direction. So now you say, okay, I know where I am now. I know what’s going on in my current environment. I have the situational awareness. I have an idea of where I want to head, and then you come up with your options. So instead of requirements, which I don’t like the idea that something’s required, everything’s optional. It’s a guess, this idea of hypotheses are really our best guess at the time, based on our current understanding. The idea is to get onto the right part of the loop very fast, which is delivery. So you want to try things out quickly. And when I say quickly, I run half day workshops where the whole idea is just to get some momentum , and the idea is by the next day, you’re actually doing something that has value. And that’s radically different for a lot of companies, even Agile teams.

They spend a lot of time creating elaborate back logs and, debating it but we want to get that feedback into the loop. So we create something, we measure, is it actually making an impact? Are the outcomes moving or not? Based on that, we adapt. So it’s that fast decision making. This is where John Boyd’s work, where he talks about being able to get inside of your enemy’s decision making cycles faster. As we’re going around, we’re both getting feedback on, is this the right thing that people want? Is this going to help them? If not, what do we do about it? And that ability to adapt fast, I think is what really helps companies meet the outcomes.

Murray: Yeah, I find with doing some of these sorts of things with clients in the past, when we’re talking about outcomes over outputs, that they’ve never measured the outcomes of what they’re trying to do or their measures are way off. For example I worked with a travel company and we discovered that when the leads went into their internal systems, they lost track of where they came from.

Gabrielle: So there’s two paths to that, and I’d like to talk about both of them. One is the somewhat political ramifications of it, so we might come back to that. The second is how do you actually track that? So do you know the term poke yoke? That idea from Japan about idiot proofing. It essentially, I always think boil it down to make it easy to do the right thing and hard to do the wrong thing. So plugs, you can only plug them in one way. 

I’m quite visual. So what I do is I build very engaging simple models to make it easy to make this information visible. A lot of the Kanban people call it the ultimate Kanban. So it’s these three maps. I call them maps because a map tells you where you are now, where you want to be, and you map progress along the way. So by putting up these three maps that link together, discover, decide, deliver, it gives you this simple dashboard.

And that’s what we need is to have that up so you can’t not see it. And we put things on that, and that becomes our central focus point. So as you’re moving, you can’t not see the outcome part. So while you’re going, oh, we’re getting busy, we’re delivering all these things. Should it be red? Should it be blue? You go into details. You keep coming back to, oh, hang on, how does that help the outcome? And I think that’s where the conversation changes. Then I put it everywhere. I put it all over the walls. So every time they start going down, oh, we’ve got to make it into these little details, it comes back to did we solve the outcome?

So I think that part of it, make things really visual, make it easy for people to do the right thing. Don’t make it complicated. But I’m going to touch on the second one, which is politics. 

People don’t want to be confronted with the truth. So incentives drive behavior. And, if you’re getting a bonus if you’re getting graded on how well your organization does, if you come barreling in and say, you have all these features. Let’s see which ones are actually being used. Let’s start tracking that. And it turns out that over 80 percent of the stuff doesn’t really get used. Then people are really confronted and you’d think they’d be like, Oh my goodness, thank you so much. Instead, they’re like, Oh no, that makes me look really bad. So you’ve got to be very politically sensitive in how you do this stuff and as you make the transition towards outcome models, you’ll find that a lot of the things you’re doing probably don’t make a lot of sense. It turns out a lot of that stuff isn’t that necessary. There’s much easier ways to get the outcomes. 

I do more of my work now in more the organizational design space where I’m working with the executives to create an outcome driven organization. So instead of focusing on just what the delivery teams are doing, how do outcomes affect everything. For example if you have people in HR, I always love it when they say things like, we have all these values. One of the values is collaboration. I went, Oh, that sounds good. Let’s go and put some outcomes in there and see how well we’re doing. So I took this whole user journey where I went from first trying to recruit people, onboard them all the way through to maybe they even leave the company. What are you measuring in the way of outcomes? So with the performance evaluations, how would this help versus hinder collaboration? And then you’ll find that of course, if people are doing individual gradings and bonuses, that’s going to break collaboration, but they haven’t thought about it from an outcome perspective. So when you start taking everything from the values of an organization, whatever it is anyone needs to measure, you start looking at the outcomes and track that through, that radically changes it, but it’s very confronting. Like anything, it’s easier to measure outputs over outcomes.

Now, I’ve actually almost found that people have gone towards things like OKRs and other ways of doing outcomes. But they build that into their measurement system and that can backfire where people start using outcomes as a micromanagement tool. So it’s not easy. When you do the stuff for organizations, you’ve got to really look at it holistically, like any system.

Murray: Okay, so let’s go into this a little bit more. 

For listeners, I have gone to mobius loop.com/toolkit and I’m having a look at the three pages that you do. So let’s talk through them. Could you just walk us through, discover what you are doing there? 

Gabrielle: Yeah, I’m doing this incredibly fast. Imagine the most high energy, fast paced collaboration game when you’ve only got three hours with an executive team, that’s the map I’ll focus on. 

For example, Teo, who’s from a Irish bank said, can we bring in Mobius because we need an innovation process. She said, I’ve got this new idea and I want to get it on the roadmap, but it can take years for things to get on there and we have to innovate faster. So she got some people from across the Org, one of the executives, some of the data analytics and business people. 

And we started off, I said, give us the context. Well, In the pandemic, finance is really difficult to get quickly for people. The bank needs to innovate or it’s going to be disrupted. So there’s all these big banks and what they call the neo banks, those really very innovative startup y banks. And so the market’s getting eaten alive and their market tended to be aging. So they did need to do something or over time they’d be out of business. 

So then we went into the customers who have this critical need for finance, including their current customers and then ones that they wanted to get, so ones that they may not have currently. Then for each of those customer segments, what are their problems? What are they struggling with? What are they trying to achieve? 

So I’m using that exact same Mobius model, whether I’m doing strategy for the organization, Or, for one customer. Now, when you go through that, you’ll find that comments come up. For example, Oh, we asked for so much information for this loan. Then it takes so long to get that. And it takes many weeks for it to get a decision. And if they get knocked back, it’s not always clear why, so that’s really painful for the customers. The banks losing a lot of revenue while they have that big gap of decision making. So we want to close that gap, make decision making faster. So when we go into it, I’d hear things such as, Oh, X big bank, ask for about half the information we do. I’m like, okay that’s interesting. That’s something we maybe could throw onto our right loop and get done. Because if it’s Giant Bank, who has pretty good legal teams, they know what’s required regulatorily. Go on there, find out all the things they don’t ask for. And let’s cut that out of the customer journey. We could immediately start cutting down that multi week decision gap dramatically, just simply by putting some quick things into action.

And then we say what are their outcomes? Obviously to get finance faster, to do things like reduce the complexity, reduce the time, all of those things we could put in for each of these customers. Then you look across all your different customer segments to see where do we have these common outcomes, because we’re looking for where do we get the most bang for our buck as it were. So we’re going to do that for each of our customers. And so it becomes very clear what everybody needs. Then that jumps us into decide. 

So in decide, we’re coming up with options. So we’re saying, okay, based on the problems these people have, the outcomes they want to achieve, what can we do about it? So it keeps you very focused on the why. Instead of just brainstorm random ideas. We’re saying okay. But what are we trying to solve here? Once we do that, there’s different ways to order and prioritize those outcomes for the different customers. And we choose those. And out of that, how do we now run very rapid experiments?

So I tend to break things into we’re doing simultaneously. The loop is not linear. So don’t think you have to do things in a certain pattern. You will be starting with the current situation. What’s the problem. But if you’re in a very complex, slightly chaotic world, sometimes you just have to do something, you just have to move on to the right loop because you don’t know enough to even make a decision. So sometimes we run these fast experiments just to get some feedback going. So we’ll be doing simultaneously some research, running some experiments and delivering. And that’s the idea. What can you do to move the needle on the outcome?

And it’s the constant question. When you’re in deliver, instead of just saying, oh, let’s get all these things out, the big elaborate build, how do we make a difference this week? How do we make a difference today? You’ll move through those and you’ll see these items just running across the board as we go.

And that feedback loop is where we’re building in both the knowledge about what we’re building, but how we’re doing it. So we’re building in, how can we make this loop go faster? How can we navigate around it and make decisions faster?

Murray: I’ve just finished reading the new Elon Musk biography, and we also talked to Joe Justice about Tesla, and this sounds very similar to the way Musk and his companies think about things. 

Gabrielle: So yeah, I think this is how modern companies have to work. If they’re not working this way, then they are going to get left behind. And that’s what we see is the divergence at the moment. Some groups are naturally doing this. When people who are extremely experienced in product and user experience design see it, they say, Oh, great. I’ve been trying to cobble together my own model. This is a lot more elegant. It makes it easier to plug these things in. And the other thing it does is it doesn’t tell you how to do it. So for each of these areas I have a set of cards that I created for myself, where I put all my favorite little tools and methods down, and I’ll pull those out.

So for example, if I’m in frame the problem, there’s some key things I’ll ask for. When I go into outcomes, there’s some different methods I’ll use to measure it. In ideation, there’ll be a whole stack of different ways you can do it. So it gives people autonomy to think, find their own way, because we all create our own journeys. And what we’re working on can be vastly different. If I’m doing this for backend infrastructure, I’m going to be using a more lean set of tools than if I’m doing, say, a whole new business strategy. So what you want to do is have something as simple as possible, but no simpler. That you can find the tools and you can reinvent it in different ways for your different needs. 

And I think that’s where, some of the big scaling frameworks, get overly prescriptive. So RUP Rational Unified Process out of IBM, was all about solve for every single question. As in have an answer if someone needs to do X, Oh, here’s how you do it. But actually you want to not give all the answers. You want to let people figure it out. So I like having simple things where you can recombine it, but not prescriptive. Otherwise it limits imagination and innovation. So if a company uses a very prescriptive model which stops people thinking they become less innovative. So what I do is I give people a very simple model. When they’re ready, I show them different ways to do things, but they have to use their imagination and their skills to pull it together. And I think that’s a better way for people to work and learn.

Murray: I noticed that there’s no time on this. It’s not like a two week design sprint or anything. So can you talk to us about the timing? Is It just as fast as possible? Is it continuous? 

Gabrielle: It is continuous and there’s a reason it’s a loop. It’s not that you have to stay on that same track. You can teleport to other areas, but time is one of those weird things. Time’s imposed, but the idea is to get those outcomes met as soon as possible. I’m not doing it within this two week window.

If you look at the right loop, that’s usually where I put in things like Kanban, Scrum, whatever. I stay neutral because there’s so many ways to do this stuff. I care about, are we solving people’s problems, making the world a better place? But you can measure, and you should measure, your decision making speed and latency. That’s important. So how quickly can we make decisions ? And that actually highlights where there are Friction points and impediments along the way. So the loop is about try to get that momentum, get it going and don’t lose momentum. Put energy into keeping that moving and keep experimenting. I think people get really bored with process. You’ve probably seen the big backlash against agile. All the agile coaches are getting cut and weird shifts towards delivery managers.

Wow. Okay. That’s been a while since we heard that. , I think people get a little fatigued with whatever the latest greatest process is. So I almost like to remove process or naming from it and keep it pretty simple. I’d rather focus on the questions of what do you people need. What are their problems and if we solve them, how do we know? I don’t even care if you don’t use the loop. It’s just giving you a reminder to keep asking those questions.

Murray: I’m wondering about when is it appropriate to use this Mobius approach. I’ll give you an example and you can tell me whether it’s appropriate. So a big company has an application. Like e commerce back end, fully integrated, where all of their business customers order billions of dollars of stuff. The application is quite complex, but it’s working pretty well, except it’s on very shaky outdated technology. So they’ve got to change it. So they decide, okay we’ll just write down ten thousand requirements for what we do now and another 5, 000 more for some things we’d like to do. And we’ll engage some vendors and in a couple of years, we’ll have a brand new system. How would you approach that with Mobius?

Gabrielle: I’ve actually, had a very similar circumstance to that. So I was working with a big healthcare provider, one of the big three in America. And companies understand that their own internal systems always become such a gate.

So there’s a few strategies. I’d be asking, okay, what’s the problem? What are the outcomes? But the problem fundamentally is that they know what will happen if they just try to rebuild this. You’ll end up in requirements nightmares where people say the outcome we want is to be simple, user friendly. We want to be like the competitors where they have a lot less stuff. 

This was the real case. And so they started building and the next minute people say, oh, but we’ve got to make sure we put this in it. Oh, we’re going to make sure we put this in it and all this new stuff. And again, years of hell, and I don’t even know if it launched. 

When you look at it, you have to step back and say, what’s the real problem? The real problem is we keep falling back on traditional patterns to come up with these requirements. So maybe there’s a different way we can do this. Now, what happened with this is I actually said to them, I think if you try to do this under the company umbrella. You’re going to get hit with all these other requirements, but you actually want to be like cool startup X that’s eating the market, that’s disrupting the entire healthcare market and they’re doing something that has 20 to 40 percent of the features that you do. So I said, if I was you, I would build a new brand, even try to do it outside of your current company. Build it based on what your customers really need right now.

Not looking at any of that past baggage. Create their problem set and all of their outcomes, now come up with something very simple. that does that and no more. Put in place your outcomes for the architecture, for scaling, how you want to conceptually do this, now let it loose. If it does really well, you can actually buy it. Make a big splash about your company, buying this amazing company back. And if it doesn’t no harm lost . 

The barrier for them is they perceived they have to do everything under the sun. So this is a very radical, different strategy from what you first think you’re going to do, but the thing is solving the problem at the right level, which is it was a systemic innovation problem. Sun Microsystems when I was working with them many years ago, the company recognized they could no longer innovate because they were so heavyweight with their processes. So they said, if anyone has a really great idea, , they would actually introduce them to investors, help them spin out the company. And if it worked, they would buy them back because they could no longer innovate internally. So when you say, can you use Mobius for this? Yeah, we solved the systemic problem, then we used it to build the new product. 

With a really big complex system, what I often do is turn on feature tracking, because it shouldn’t be that big and complex. It’ll turn out that there’s so much waste within it, you’ve got to actually remove it. And when I’ve actually had to build in parallel within the same company, we’ll build the new system, create bridges to the data from the old system and build the new pieces that we really need put back in the things that are essential and then slowly just remove the dependency. I’m still using that same model.

Murray: How am I going to go to tender with this model so I can eliminate all my risk, Gabrielle? 

Gabrielle: Oh, now you’re talking about a conversation I love. Something I’m booting back up again. I’ve got a couple of lawyers, one in the UK and one in Denmark. They’re really progressive lawyers, and we’re bringing out our outcome driven contract model. So I spend a lot of time in contract land because I find that contracts are made for worst case scenarios. They’re highly reactive, and they set up this combative standpoint to begin with. Instead, you’ve got a document that should be about clarifying what each group needs and that’s where outcomes are incredibly important. 

If you think about customers, you go out to tender something, you’re someone who says, I don’t know what I’m doing. I need help, I don’t have this technical expertise. I don’t have this domain expertise. I’m gonna find experts. The experts turn around and say, great. Now, can you package up all that ignorance, things that you say you don’t know? Put it into requirements document for us. You’re asking the person who’s come out and said, I don’t know what I’m doing, I need help. To write down everything they, don’t really know into a document for the experts to build. It’s a weird model. 

We actually run these outcome driven workshops for contracts where we get the supplier and the customer together. And it’s all about saying how are we going to get clear about these outcomes. They become the underpinnings of the contract. 

You have the umbrella agreement, but what we do to mitigate risk is small call offs of work, what we call the statements of target outcome instead of statements of work. Under that, you need a model that continues to evolve because you can’t lock the stuff down because you need to do customer discovery. The biggest risk is you’re not getting your problem solved and you’re not meeting your customer outcomes. Whether you get everything ticked off and the features that people said they’d deliver is less important than are the outcomes met. So we actually measure the outcomes progressively. You’ll find with most contracts there’ll be some percentage put aside towards the outcomes. The rest will be in some more traditional charging model. And you will measure and put in some mandatory things that need to be, let’s say it’s a new e commerce system, you might put in these, the mandatory must have type things that we’ll have. But the rest will be about, we’re going to discover the customer’s needs, meet these outcomes as we go. 

One of the first outcome based contracts I did actually with the Danish lawyer, Jesper, I work with was for a Danish healthcare company. What they did in their tender, is they said we want you to come back to us and tell us how you would create and measure the outcomes while you deliver this project. 

And they said, everybody for years have been saying, we want to do outcomes. They said, once we put that out, almost no one could respond. And we’re talking about the IBM’s, Accenture’s, all of that, trying to respond. There was only one company in Denmark, Systematic. And they had actually flown over to me on Monday, asked me to help them put together the language around how we measure outcomes. And they won the contract because they’re the only ones who could actually have a cohesive discussion about how they would do that. Now, it was still difficult, but the head of the whole program from Danish Healthcare said it was so much better because it was all about collaborating, thinking about their customers and how they meet the outcomes and measure that. 

When we run these workshops, especially when you’re doing government contracts for shortlisting, we have multi supplier bids. And you have to get them all working together. So you want common outcomes. Then you want to get them to actually show you how they would deliver key pieces rather than do it theoretically.

So there’s a lot of ways you can put this together, but at the end of the day, your biggest risk is not solving your customers problems and not delivering their outcomes.

Shane: So I can understand how you can define outcomes based on core business processes. So that example you said about the bank where the process to approve was too long, the outcome we want is a shortened cycle in that approval process, better customer experience of them not having to wait six weeks for that approval.

So I can often see when you look at a business process the outcomes can be relatively easy to determine. After that, it gets really murky. Defining those outcomes is incredibly difficult in my experience. So can you just give me some examples of other outcomes you’ve seen?

Gabrielle: Let me ask you two, this one. 

I went in to help Red cross about how their contracts with their suppliers. They were building a way of getting donations and being able to track that . And they wanted it to be very user friendly. Okay. So in that context, the two of you tell me, how would you measure the outcomes for user friendly. 

Shane: I could look at abandoned process. So how many of them didn’t get the end and finish the donation then, we can infer there was a problem. I could look at number of clicks of speed to finish. 

Murray: Abandonment’s A good one. Or you could ask people to answer a. question at the end of the process, like how user friendly was this on a score of one to 10. 

Gabrielle: You’re definitely on the right track. And this is exactly what I do with people, is lead them through it, make them think. Because I’m going to ask you to spoon feed it, but I’m trying to train them to think in outcomes. And you two you’ve been around this game. For a long time And you know what you’re doing. So you’re asking all the right questions. 

Now, what really happened is I went through and I said what is user friendly? Is it meant to be simple, but things like your search are in the right place? Is it meant to be consistent? There’s all these different ways that we could talk about it. We can measure abandonment, et cetera, et cetera. And then I said, can you describe what success really means, take me through it. What are you thinking? 

She said, Oh well, what I mean is when we look at the spreadsheet, we can see all the numbers of the donations and we want to make sure that it all adds up. So the data is correct. And I’m like, Whoa, Oh, that’s what, that’s not what I would have thought of as user friendly. So it was completely out there. And if I’d just be measuring Approval rates. Oh yeah, it’s user friendly. And I say to people, user friendly means I could have unicorns, rainbows. It could be pretty. What does that really mean? 

If you run this in class you’ll get 10 different answers, even when people are talking about exactly the same thing. They’ll look at it completely differently. So when I end up with the gnarly, difficult things, It’s this conversation. We have to probe, we go through stories, we talk about what we’d really measure, what happens if. I do have a huge library the coaches and I use where we have for every sector, very different things we measure. For example, a financial system for traders. And you get people saying we want 99. 9 uptime. And you’re like, if it’s up 99 percent of the time, but from say 9 to 10 a. m. it’s down, is that okay? Hell no. Okay. Whereas if it’s down at 3 a. m. when the traders aren’t around, that doesn’t matter. So we’re really explicit and clear.

Tom Gilb will be happy if he listens to this. Because Tom Gilb’s the master of getting down into what you precisely mean. Now I like making Tom’s stuff really fun and accessible and you get to the precision you really need, but don’t do it all the time because it drives people nuts. It’s really hard to go deep all the time, but that’s what you need to do. It’s have that conversation. We work in energy, healthcare very different sectors, and you end up with quite a big library of things that you want to measure and look for. it’s practice. You’ve got to have this conversation.

Murray: This is very tuned with where I’m at after interviewing thought leaders in our area. 

But what I see mostly is that these sort of digital products and services are being developed by IT people taking orders from product people. . Then the IT people are managing suppliers to get it all done. And the outcome for IT is you must deliver all of my requirements. And it must be on this date for this amount of money. And then when it goes in, everything has to work and it can’t fall over. That’s all they care about.

Gabrielle: Many years ago, I was in South Africa giving a talk and someone from the audience pretty much said what you just said. And he said, so what do we do with those? And I said you have to decide. 

Do you want to keep working in that space, which is fundamentally broken, or do you want to do something else? Maybe, you should be going out and talking about a different way of working because this clearly isn’t working for these companies. You have to choose. Do you want to work in that way? Follow those guidelines or do the right thing. 

Probably a year or two later, he came back to me and he said, I actually pivoted my entire business model after that talk. He said, I thought it would be really difficult to do, but I actually made that the feature that we work in a very different way. And he said, there’s a lot of appetite because people are fatigued and companies know. If they want to keep working these traditional ways, they’ll be left behind. They are disrupted for a reason and that’s why I go after things like legal, HR, finance, all those areas. I find them more interesting because they have a greater impact. 

So when you say when I’ve got a customer who wants to do it this way, I would be saying here’s all the risks. Are you sure you want to work that way? Or do we try an experiment? 

Maybe we try something small and work in a very different way.

Like the early days of Agile, you try pilots. That banking one we actually did some other smaller process things. Then this was actually far more innovative than I really talked about because it involved all of these backend systems communicating with other banks, et cetera. But you try and experiment and say, which one works better? Just prove it. I never try to sell, I never did try to sell Agile in the first place, let alone Mobius. 

I say, I don’t know if it’s going to work here because they ask, how do I know it’s going to work? Yeah, we don’t. That’s why we try it. Let’s compare how we do this compared to the way you’re doing it. Have a baseline, a control group and run this stuff and see, they can learn something and they might go, we don’t have the appetite. This is going to be a political nightmare with all the data showing outcomes, being more successful, whatever it is.

Some people honestly choose not to do this. They’d rather do the traditional way, but that’s our job. If we think we’re thought leaders and you have a voice in the community, then our job is to get some proper data. And at companies it’s easy because we can measure it because we have outcomes. So I can show, is this going to be. Better, and we choose what better means. Are we solving customers problems faster, better, getting their outcomes met? Are we solving organizational issues? Because we’re measuring the whole thing. So I always say prove it, don’t plea it, don’t try to sell people on the stuff, just do it and see. And if it doesn’t work, then you shouldn’t be there. Whatever you’re doing not going to work Measure and do the right stuff.

Murray: I’ve been reflecting recently on why people do this stupid stuff. This very traditional old fashioned way of working. 

And I think it’s because they have a very defensive mindset. 

Somehow they’ve risen higher up in the organization while going through a lot of failures because the traditional way of doing things generates lots and lots of failures, projects that are way over time, way over budget, never coming even close to delivering the outcomes expected in the business case.

That’s standard operating process. And yet people advance their careers in that situation. And I think the way they do it is that. The traditional ways of working actually allow you to defend yourself. So if you’re an architect, you can say, I did my bit and then I handed it on to these other people and they stuffed it up. Or if you’re the CIO, you can say we wrote down all of these requirements and architecture in thousands of words of details and we gave it to the vendor in the contract and they didn’t deliver it. So it’s their fault. So I felt like a lot of this bad ways of working is based on avoiding blame. What do you think about that?

Gabrielle: I 100 percent agree. Ezra Klein has a podcast from New York times and he’s interviewing the woman who wrote a book, about government contracts 

Murray: yes. Jennifer Palko on Recoding America You should listen to our podcast, Gabrielle, because we interviewed her. 

Gabrielle: Did you? Oh, okay. I will. I will. I will. But what I’m saying is that it really comes down to how you’re rewarded or punished back to incentives, driving behaviors. I was talking to Rob Mee from Pivotal and his new venture, Mechanical Orchard what they’re really doing is rebuilding these big government applications and running it for them. 

Governments are so paralyzed by their own processes, they have to find a different way of doing things. So when I said, this is a choice for all of us, you either, do things in the way that they’re always done. Or you see it as an opportunity and you create a different way of approaching it. So he’s created what’s probably going to be a fairly substantial company based around building the stuff because they’re so paralyzed, they can’t do it themselves.

So essentially they replace the building and maintaining, its service for these types of governments. And I think you will see that where these systems fail so dramatically, something else will rise. It’s just like politics you’ll have people holding on to dictatorships until something happens that revolution and a whole different political system comes in. I think we have to get really creative about how we approach this. 

I was at once at a Big All Hands. They got me to talk about wonderful, agile ways of working. And then all these people said it was so miserable. They didn’t know why they were working there. It was so horrible. And we kept trying to come up with ideas. Finally, I just said then it’s a choice. You stay or you go. And maybe you should go at this point. The manager at the back went white and wasn’t very happy with me. 

But there’s a point where you play that game or you don’t play that game. So this comes down to us. Do we support bad ways of working, or do we find really creative, innovative ways of doing it differently? And I’m trying to bridge the gap with the legal contracts and trying to find a way that you can actually still work within the guidance, but find a much better way of getting the groups to work together. Same with things like auditing. I did early Sarbanes Oxley auditing with Agile. And a lot of it is people just not understanding. They follow what they think of the rules, but it’s just not clear. So there are creative ways. As a somewhat of a middle ground, but we do have to look at whether what we’re doing should be supported and continued.

Murray: That’s really interesting, this idea of government as a service being provided by a service provider. Instead of saying we’re going to build all these things, we’re going to build a managed service for you that’s focused on outcomes .

Gabrielle: Yeah. I think that would be quite interesting. 

Murray: You’d have to get in before the tender was written, to have any prospect or something like that.

Gabrielle: Yeah. Well, you see Companies where they go after a certain sector, let’s say healthcare, they have their platform, which they can essentially modify and customize, and once you get in, do a good job, then you’ll find you can go after that whole government and maybe other countries. And that’s the model. Once you crack one piece of it, all these models are similar enough. So that’s how you can do it fairly well.

Murray: What would you say to a service provider building things for corporates.?

Gabrielle: It’s very hard to do yourself. For my own business, it’s really hard to remember to keep focusing on outcomes. Every time I do, I go, Oh, this works so well. So having a way that you can run the workshop almost neutrally with your customer and together come up with something.. Cause it’s too easy to jump into details. Let’s write it down. Oh, here’s how we could do it. Here’s your quote. So I think if you did more of a step back into the why, what do we ultimately measure and setting up analytics as you go. So you should make building in the analytics and the outcome tracking part of this. We go in and build out dashboards and we try to hook up the data and actually create that as part of the service when we do bigger organizational work.

Shane: So the loop goes discover why, decide how, and deliver what, and then we daisy chain back and people will naturally always focus on the deliver what. The list of things, the list of features, and I’m assuming we want to push them left. So if we say have a conversation where we were talking about a bunch of options and we haven’t already defined who’s it for, what’s the problem or their need, and how are we going to measure the outcome of the success? Do we stop discussing those options and move left? Do that first and then come back to them. you did say that you can start anywhere and go anywhere, and so how does it typically work?

Gabrielle: Yeah, people often, start in options. they’ve got their big requirements list or their product backlog, they’ve made these decisions somehow, and then we’re saying, okay we can deliver, but what are the outcomes? Oh, okay. We haven’t really understood the problem, or we don’t have the right outcomes. So you’re going to find that adapt, there’s a little chameleon. I love the little chameleon. And that’s the decision point where you’re having that conversation. Okay. Based on what we now know, based on what we’ve measured, can we deliver more?

So that experiment was awesome. Let’s do that. Let’s grow this fast, this is worth investing in. Oh, we know that people want it. It’s desirable, but we haven’t actually tested for business viability. Okay. We need to get that clear or we didn’t really understand the problem. Okay. Let’s flip back on to do a bit more discovery. Or those outcomes they’re not right. And this is normal. So the team’s having that discussion fluidly. You’re constantly having things move around. It’s like a race car track, there’s some things left, some things right. Where I think it helps at that decision point is. You get the conversation where people will often start saying, Oh, we’re getting stuck in the right loop. Hang on. I think we need to do a bit of a step back. Is what we’re delivering still the most important thing to be doing right now? Or has the world changed? So what you’re doing is optimizing for the current situation continuously. It’s not time based. Some people like doing this sort of weekly step back reflect. Some do that on a daily basis. It’s really up to the team, but it’s asking that question. Okay. Based on what we now know, what’s the next, best thing to do. And it keeps you adaptive. Otherwise you fall in love with your ideas and you want to deliver them no matter what, but when you’re confronted with. Okay. You know what? We’re not getting the same impact from these outcomes. Could we do something better? Okay, great.

Murray: how do I scale this? What if I have a hundred people working on something? 

Gabrielle: So during the pandemic, I was working with a big financial services company and we had six executive teams. It was such a big company that each one is essentially their own CEO. And so they came in with both organizational issues. So how do we improve competitive intelligence and distribute that to the organization? How do we innovate and be more agile? How do we follow these core values? How do you improve your investment optimization? So we created these loops with the executive team and what they can do is say here’s our problem.

So for example, we’re going after this market in Morocco for insurance and different segments. They come up with a set of options that becomes your options portfolio. So these are the things you want to invest in. Each of those can create essentially a child loop. 

Imagine you have your child loop, where you’re going after one key initiative to improve insurance for rural farmers in Morocco. So that loop will form cross functional outcome driven teams. Then that gets those measures we’ll create the impact at the strategic level. So you’ve got these strategic outcomes and then you’ve got these customer outcomes that are linked to them. So what you’re tracking as an executive is how well that portfolio starts packing together. Now I’m very careful. Not to make it hierarchical. I really hate a lot of the OKR models out there that impose down, they used for individual performance, all sorts of things. But when you scale it, you want the teams to align up. 

Back to mission command, when you talk about the military, you have this your purpose your strategic intent, and then the teams figure out how they’re going to move the needle on it. So while teams are running their own mobius loops, they’re actually using that to influence the strategic ones. So we create a dashboard and what I want to see is, are these outcomes moving?

Murray: Okay, good. Shane, what do you reckon? Should we go to summaries? 

Shane: All right, summaries. We started off by talking passion for product and then quickly talked about when people tell you your baby’s ugly you get upset and that resonated with me a lot. 

And then you talked about outcomes over outputs. And we all know that feature factories focusing on the effort, not the outcome is bad. And we should be focusing on those outcomes. But I think defining those outcomes is hard. You gave us some good examples, but I think it’s a skill to be able to help people distill their outcomes.

liked this idea of an attractor and then depth when needed. So start simple, get good at it, and then peel back the onion when you need more. And , re looping back into what is the problem, who are we solving it for, how do we know we’ve solved it?

We often talk about the problem, the customers and understanding the journey. How will we know we actually deliver value to them? That’s the bit that we tend to always not do, because it’s hard.

One of the other things you talked about is if you make it easy to do the right thing, then people will do it. Often we make things hard and then we wonder why somebody does something else. And your analogy about a plug You just push it in and just being to the UK and those stupid plugs. A number of times I had it around the wrong way, but it wouldn’t go in. I had to turn it upside down to make it go in. So that’s great. 

When I look at the maps. One of the things that interests me was in the deliver map. 

You talk about the usual to do, doing, done, but you’ve got measure and learn. And most of the teams I see don’t do that. We do the doing, we do done. But we don’t do that feedback loop of measure and learn. 

I like the idea of , it’s fractal. So because it’s not prescriptive, I can see how you can use it for big things, for small things. I like the idea that you just create a map. It’s at a certain grain. You create another map, it’s at a certain grain. There is probably a relationship and we can describe that’s good, but if not, the value of those maps as different fractal levels is enough. 

I think I got the idea that you always shift left. So if we start off and deliver, we’re always moving back to decide and back to discover because that helps us give the context of what we’re delivering. But it’s the speed we do it.

We can do it in small bits. We can take one thing we’re doing and deliver and we can just shift that completely left. We don’t have to shift all the work left. And that gives us the ability to experiment. We’re delivering this. Why are we doing it? This is the outcome. That sounds a bit hokey. OK, what experiment can we do to redefine the outcome? Or how do we move that small bit? So again, that fractal ability to move up and down the grain of the work, I think. 

It’s a very simple set of patterns. And the devil in the detail of a simple set of patterns is the expertise to execute it. And I think you’ve proved that a couple of times. So simple to understand, really hard to execute or coach. So the ability to ask those questions, ability to facilitate the answers, especially in the outcome box. I think that’s a skill a lot of people don’t have. So I think it’s a set of maps you can use to begin with, but to get really good at them is going to take a lot of experience, especially if you’re helping another team do it. 

The last one is that idea of political outcomes. 

I work in the data space, working about data teams that deliver and get no love. And it reminded me when I had my consulting company, we used to do managed services for customers software. 

They’d have a platform or a system that was constantly having problems, the current vendor wasn’t doing the job, we’d go in, we’d sell them an outcome. So we’d sell them a fixed monthly fee for the thing to be healthy. Really simple conversation. And what would happen is we’d go in there, everything’s crashing, so we’d bring in our patterns our automation, we’d remediate all the problems, we’d go and fix it.

And it became healthy. And then within about 12 months, they come back to us and they go what do you guys actually do? And we go we keep your system healthy. Has it crashed lately? And they’re like, no. Good. Doing our job. And they go, oh yeah, but what are you actually doing?

And going back to what the outcome is, there’s been no problems. And they come back and they’d say, oh cool, but can we see the timesheet for the team? And the answer was no, you can’t see the timesheet for the team because that’s not what you’re paying for. And we got into this loop because politically or as a human, this healthy outcome wasn’t enough anymore. And I think that’s part of the thing we’ve got to realize is that, the outcomes are difficult to define, they’re difficult to measure, and then humans just sometimes do weird shit that just doesn’t make sense from the outcome point of view. So good conversation.

Murray, what do you got?

Murray: Yeah, I really like this approach, Gabriel. It brings together a lot of things we’ve been talking about on the podcast. So we’ve interviewed Tom Gilb, Stephen Bungay on Mission Command Jennifer Palko on Recoding America, Mary and Tom Poppendick, and tons of product leaders and other people. And it’s sometimes quite hard to figure out how to put it all together. But what you’ve done here is a very nice, simple, easy to use way of bringing it all together for me. I really like it. I went to your website and I wanted to buy your toolkits, but they’re sold out, which I’m a bit disappointed about.

Gabrielle: Yeah I’m doing a whole redesign of everything at the moment, but , the book will be out soon and that one’s a really practical step by step. Here’s how to put up a map. Here’s what to put in it and just trying to make that outcome of getting someone up and running and their first workshop going. So that will be released in the next two months.

Murray: All right. So where’s the best place for people to go to read all about this? 

Gabrielle: Go to mobiusloop. com for now and stay posted. We’re going to be putting on some webinars. We’ll do some more introductory things coming up. 

Shane: And importantly, you’re going to be in , sunny Melbourne in February doing an in person workshop. 

Gabrielle: Exactly, plug for Red Hat innovation Labs. They run with Mobius and Donna Benjamin, who does the open practice library, which is a set of open source methods and tools. They use Mobius and they’re going to be hosting. So we’re doing some classes around the world. So we’ve got Melbourne, we’ve got Singapore, Berlin.

And they’re very pragmatic, but for anybody, because I end up with a lot of managers and people who are not technical, so they are very hands on. It’s got to be a great experience. People have to be able to work together and basically embody outcomes.

Cause you’re right, Shane, that it’s difficult to do outcomes, but once you make that mind shift, you almost can’t stop thinking about it. Your world becomes about outcomes. So you need that little nudge. Then I think it becomes a lot clearer.

Murray: All right. Love it. Thanks for coming on, Gabriel. All

Gabrielle: Yeah, it was a pleasure. Nice meeting you too.

Murray: That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d like help to create high value digital products and services, contact murray at evolve. co. That’s evolve with a zero. Thanks for listening.