Building An Agile Operating Model That Accelerates ROI 

Accelerating your time to ROI isn’t about delivering more lines of code faster. And it isn’t about delivering working tested product faster.

To accelerate ROI, we must reliably put the right combination of working tested product in front of customers so that it can drive revenue, self-fund further product development, and create opportunities to get critical feedback.

So how do you get all of this? By designing your operating model in a way that makes it all possible.

This clip is from Mike’s series on the 6 Key Business Drivers of Agility. You can check out the full ROI webinar on-demand here: https://go.leadingagile.com/gj1

Or to learn more about how we think about and approach Agile Transformation, you can download our Agile Transformation white paper here: www.leadingagile.com/whitepaper

Transcript

So early ROI, this often gets expressed differently. What it often gets expressed as is I want to be able to do things faster. They will say things like, “I’m a hint Jeff Sutherland wrote a book.” There was something like twice the work and half the time, right? That kind of a thing.

So 2X the work, one half the time, right? And that’s valid, right? Because people are looking for efficiencies, they’re looking for ways to get things into market faster. But you know, we have the physics of project management, right? It’s always kind of like, looking us in the face, right? You have scope, you have time, and you have cost, right?

So you kind of like pick two, and then you have to kind of float the third, or you have to figure out how to bring all of these different variables into balance. And so if you’re going to say something like, I’m going to do 2X the scope And I’m going to do it in half the time. Like, is custom save same as custom drop? Like, I don’t know, right? So like, what I want to explore with you guys a little bit is what are our options around doing things faster? And what does it actually mean, to do things faster, or to get things in the market faster.

And the reason why I categorize it as early ROI is because what the executives want is they don’t want to just deliver faster, right? It’s not just about like lines of code as fast as you can deliver them, right? It’s not even about working tested software as fast as you can deliver it, it’s really about what is that combination of working tested software that we can put reliably in front of a customer, so that we can start charging money for it. And we can start, you know, obviously getting revenue to fund further development. But we can also start to get that product in the hands of paying customers faster, so that they can start to give us feedback around it.

Okay. So a lot of it is how you might think about it, is we need to start thinking about optionality to release. Okay. And so I think an option is a lot, right? So I’m creating options to release things and to be able to get them into market faster, so we can start charging money for them and we can start getting feedback. So like a lot of things, we’re gonna build from kind of the atomics of this.

And then we’re going to start talking about how do you like dealing with it at scale and different things? So let’s talk a little bit about what the system of delivery looks like that gives us that optionality to release. Right? So I’m going to talk about the idea of the system of delivery. But then the other thing that we’re gonna have to figure out how to do is how do we educate the business to exploit that optionality to their economic advantage? Okay, and so it’s a tension between kind of the system of delivery and the business’s ability to exploit that. Okay. And we find that both of these can kind of become a problem.

And like, let me give you a for example, like, let’s just at the simplest level, let’s say, we had a really well functioning agile team that knew how to operate off of a well defined backlog that could produce a working tested incremental product at the end of the sprint, right? And life is good. But then we have the business that is approving big giant projects that are long, cost a lot of money and they aren’t willing to do anything with it until the team is totally done. You kind of go like, well, “how am I gonna be faster? Like what things are going to contribute to being able to do that, right?” So let’s go back to the teams backlogs to working tested software thing, right?

So what gives me optionality to release at the team level is, you know, again, things we’ve talked about, right? So there’s not a whole lot new when you get under the mechanics system, right? So I want a complete cross functional team that owns a technology stack that has very few dependencies highly encapsulated. You know, has everything and everyone necessary to be able to deliver the product. And I want that team to be able to establish a stable velocity. I want a product ownership capability, that enables me to break big things down into small things. So that, you know, I can pull a piece of the backlog off, feed it into the team and then have the team on two weeks cycles, be able to produce that piece of the software, right?

So if I’ve got the size of the backlog, I got the velocity, then I can start to think about duration, and scope. Right? That’s our basic like law, to me of team level agility. It’s like the three things that have to be in place. And you notice that’s like the anchor for almost everything that like, I like to talk about. So like, how does that get us into an early release situation? Well, you think about, like, what has to happen for that, right? So the idea is mechanically, whatever I pull off the backlog has to be built and tested, and accepted by the product owner.

And then we talk about this idea of potentially shapable, right? In an ideal world at a minimum of about every two weeks, I would like to be able to take this bit of backlog, run it through the team, deploy it into production, and to be able to actually put it into the product and have like a real person pay me for it and use it. Okay. Sounds like pretty simple. Okay.

So again, mechanically, right? You think about, I’ve got to have these things broken up into small pieces. I have to have the team, have some ownership, there can’t be a whole bunch of external dependencies. I have to be able to continuously test the product, I have to be able to have some sort of maybe CI/CD pipeline here, I have to be able to push something into production really safely, I might have to be able to roll it back if there’s a problem, right? So there’s this whole like, execution pipeline that has to be in place in order to be able to give something, actually to a client and to be able to use it, right?

So that’s kind of like the mechanical side of early ROI, right?

You have to have the ability to do that. But here’s the other side of that, what goes into the backlog, right? What the product owner puts into that backlog, there has to be a hypothesis there about what a customer might actually use. Okay, and so what we want is, we want stuff at the top of the backlog, that there’s some person out here that might actually find it useful, and maybe even pay you money for it, right? That’s the goal. So we can have the ability to deliver this way all day long, Right? But if we’re not feeding the backlog with the right stuff, then we don’t have the opportunity to be able to get it in front of a customer and potentially charge for it or to get feedback or to learn or to do any of the other things. Right? So I’m sure you guys have heard of the idea of like, a minimally viable product. You know, at this level, right? So we’re still just like single team level Scrum level execution, right? All that kind of stuff, right? Single backlog, right?

So the idea is that I’ve got this, I have to understand what is the smallest thing that I think is valuable to put in front of a customer. Like I’ll give you an example within LeadingAgile. I like to give LeadingAgile examples, we’re building into another small internal dev team, and we are building a product that we call ELM Cooperstown. Whole reason why I call it ELM Cooperstown, but it’s employee Lifecycle Management. And eventually this is gonna be an iPhone app that is going to be able to will be able to pull up somebody in the database. I’ll be able to see like their location, I’ll be able to see their salary, I’ll be able to see like who their leader pod leader is, what account they’re on, we do a lot of personality profiling assessments in LeadingAgile. So I’ve got the ability to see their personality profiles, eventually I’ll be able to see things like what learning LMS modules they’ve been through, what onboarding things they’ve been through, what core skills are? And then the holy grail, right?

Somewhere down the road from now on, we’re going to have the ability to say, okay. We had this consultant it was operating in this way, with this client, they were really successful, we’ve got a similar engagement. Okay, show me all the consultants that are available that profile like Melissa, or show me all the consultants that are based in Atlanta, that profile like town, something like that, right? Because what I wanna be able to do is I wanna be able to really dynamically look up people, because we’re getting pretty big now. We have over 100 consultants, right? I wanna be able to look up people and understand kind of what their strengths and weaknesses are. Okay, so the instruction that I gave to our lead software guy, a guy named Donald, is I said, really fast, I want the ability to show me an employee database. And I put some constraints on it. Because it’s an iPhone app, I said, I want like some weird hacky iPhone app, like I want it to be like a beautiful, can’t spell beautiful iOS app. Okay. And I want to it beautifully display a list of people. I want to be able to search. And I want to be able to have just up on a name. And I want to be able to see some basic information. And I want to be able to see those one assessment we use called color code that I think is really super valuable. We could do a whole talk on that, that would actually be a pretty interesting talk. This whole thing called color code, I wanna be able to see somebody’s color code. So within like, a matter of weeks, it wasn’t like a super long time, I had this bit of stuff on my iPhone and I am telling you one of the most valuable things, right? I use on any given day, I use it by five times a day, because I’m constantly doing one on ones with people and talking to people and we’re making decisions about staffing.

And you know, why maybe somebody struggling here and not struggling there, we’re not getting the performance we want or behavior we want or something like that. I use this thing five times a day, every single day. And it was delivered in something like four weeks. Okay, in his spare time, right? Super, super valuable. Not nearly the vision that I anticipate having in this product a year from now. But what it does today, it does beautifully. And it does it with incredibly high quality. And it’s super, super valuable. Right? And that’s the kind of thing I’m talking about. Right?

So if I had this delivery capacity on my team in my organization that could be, you know, dedicated team, dedicated technology, really clear backlog, the ability to produce a working tested software, every sprint like whatever. But I was sitting here as the product owner going, ” You know what, Donald, this is never… I don’t wanna release anything until we can get everything.” Then I don’t get anything actually early and I don’t get any value from it.

So the tension on that dimension potential mentioned kind of run the tension in that dimension is that the product people have to orchestrate and sequence the backlog in such a way that everything is like getting to like an MVP or incrementing the MVP.

Okay, so you create the conditions for delivery. And then you have to teach the business, how to exploit those conditions. So that you can actually get the return.

I imagine you guys see this quite a bit. It’s like what starts to happen sometimes and this is really the core of the elevate agile conversation that we’re starting to have we’ve really learned a lot trying to talk about this over the last year is that there’s a lot of people out there that have built these really sophisticated agile delivery models. But the reality is that the business doesn’t really know how to exploit it, to get things in market early. So while we can do agile, because we’re still kind of dealing with project based funding models, we’re still dealing with large batches, annual cycles, right? All these different things. Nobody’s thinking through, how do I decompose this work and put it in front of customers as fast as we possibly can. Then this really great agile delivery capability that we built goes really underutilized.

So the promise of agile as a team level, or even an enterprise class delivery model doesn’t really realize the promise until the business understands how to exploit it. Okay. And so that example that I just gave you guys is like really simple, right?

This is single team, it’s really actually non-revenue generating piece of technology, right? Very little pressure on that team to perform it any kind of RAID. I’m the product owner, I’m the guy that’s funding it, right? Really super simple. But because of that relationship between me and my expectations, and delivery capability built, it’s working really well. And every single time there’s a release every couple days now. I get something new to play with. That is that is like really cool. Other examples in market that I imagine being like this, when I talk to kids at university, I talk about Snapchat a lot, because that’s obviously one of the latest and greatest, if anybody, social platforms, or maybe that’s even getting old news, I guess, TikTok, or whatever’s new. But I remember when Snapchat hit the scene, it was effectively just kind of like private video messaging that like just deleted a message, like right away.

As I recall, I was not an early adopter of Snapchat, because at the time, as a parent, right, everybody’s like, “Oh, no Snapchat, right? That’s how kids are sending inappropriate pictures to each other right? So where nobody gets busted, right?” And when my first adult friend ever landed on Snapchat, I was like teasing her that she was Snapchatting her kids and how weird that was. But apparently, by that time, Snapchat has actually evolved into how to add a more mature user base. But that’s where it started, it was this little thread of functionality that was like, “I’m gonna send you a message or picture and it’s gonna go away.” Right?

As that product is evolved right now, it’s got a more wide, more diverse user base, stories, and all kinds of different things, and filters, and all kinds of fun stuff, right? That people are using and you know, kind of a fun factor on that, my kids literally will not text me, like, they’ll ignore my text. But they’ll reply to Snapchat, which I find incredibly annoying. But point being is that, that was like an example of like an MVP, that got into market using agile delivery capabilities. And the business understood how to put something into that team really quickly, to bring something in market, and then grow it based upon user feedback, right? That is the absolute definition of early ROI.

Okay, so now let’s scale that concept. Right? So now let’s look into like a multi-tiered kind of enterprise agile kind of thing. Let’s talk about like, how that’s working. Right? So now we have like, we probably have like Shared Services teams, right? Service one, service two, service three, service four. We might have product teams or feature teams, that might be a better way of saying, like, feature teams, right? That kind of a thing, right? And then we have some sort of program layer. Right? If we’re thinking safe, we’re doing like release trains, we’re doing PI planning, right? All that kind of a thing. That’s probably subordinate to some sort of portfolio layer.

Okay, now, the trick when you start to get to this level of scale, right? And there’s kind of typically two ways you can manage this, I tend to like to model this as a kanban based queue, up here you could also manage it as in more like a kind of a release planning. Planning kind of PI planning kind of model, right? If you prefer Safe, right? What have you, right? So I tend to like Flowbase, Batch-and-Queue, Fun, right? Whatever. But the trick is when you start to scale this kind of stuff, let’s say you want to have a 12 week release. Okay? The trick is that you have to sequence the features that go into this release in such a way that enough of the user stories at the team level and at the feature level, product level, right? Get done, such that at the end of the 12 week release, you have something to actually put in the market, right? And then kind of like all this kind of same rules apply, right? What is the smallest set of features that is going to add value? How are those features going through decomposed into team level backlogs, right? How are those backlogs going to get rolled up into the program level? How are the features of user stories roll up into? How are they going to get validated? How are they going to get tested? How are they going to get deployed? How are they going to be put into market? How are they going to be rolled back if there’s like a crisis or a problem, right? That whole chain, that whole release management chain has to be like leaned out and tightened up so that you can put these bigger things into market. Right? What often is necessary there is you need a portfolio level that is dealing with projects that are way smaller investments than how we’re thinking about it now. Right?

So I told an executive of a company, we probably did like a year two, year three transformation for, you’d be halfway there, if you would just never approve a project that was greater than three months, right? It’s all about smaller bets.

David Spann introduced that language to me at one point in time. Right? If we could get the organization to not put anything not 30 months, type that out, three months, right? So if we could get the organization not to put anything into the system that was greater than three months. And everything that we put into the system broke down into features that were maybe a week or two big that broke down into user stories that were a few days. And we could sequence all of this work here in such a way that it rolled up and flowed through the product here. And then as features got done, we were actually able to release projects into market every couple of months. Right? Then we have the ability to know these big top level things that have big level ROI. Right? Now we can start to have that kind of a conversation around how this works.

Okay, so you start to think about it, so we got the delivery capacity here at the team level execution teams, teams, backlogs, working tested software, making sure that we’re running the smallest set of stuff through getting it to a really clear definition of done working tested software. Everything’s potentially shapable. Everything’s deployable. These things roll up into larger increments that were maybe continuously releasing or maybe batch and queuing, right? But they have a testing and integration cycle that’s fast and continuous. And then the organization has the ability to release things in market in a more fast and convenient way.