Beyond Agile Transformations: Embracing the Agile Product Operating Model

In this episode of the Scrum.org Community Podcast, Dave West and PST Andy Brandt explore the state of Agile transformations and the shift toward the Agile Product Operating Model (APOM) as featured in their recently written whitepaper. While Agile has been widely adopted, challenges like misalignment between business strategy and technical execution persist. Andy shares how focusing on products instead of work and starting small with one team can drive meaningful change. They discuss the role of AI in enhancing productivity, the importance of organizational alignment, and how executive commitment can lead to spectacular results. Tune in to learn how to move beyond Agile transformations and embrace a product-first mindset!

Referenced whitepaper: Moving Beyond Agile Transformations: Leveraging the Agile Product Operating Model
APOM: Agile Product Operating Model

Transcript

Lindsay Velecina  0:00  
Music. Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast, we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.

Dave West  0:20  
Hello and welcome to the scrum.org community podcast. I'm your host, Dave West, CEO here@scrum.org today's podcast is part of our agile product operating model series. Today, we're going to discuss the recently published paper moving beyond Agile transformations, leveraging the Agile product model. And I'm really lucky to have the author of the paper, Andy brand, PST and Organizational Change Guru to talk about his motivations in writing the paper, and really that to really lean into what is the state of Agile transformations. Welcome to the podcast, Andy,

Andy Brandt  1:04  
hi, hi, thanks for having me, Dave. Glad to be talking to you again, talking with you again, about this topic, because we talked a lot also when we were working on the paper. Yes,

Dave West  1:15  
we did talk a lot, and let's hope we don't bore our listeners, because I'm sure we did talk for hours and hours about this. And you know, your experiences in the Agile transformation world and and how you saw those transformations really, were really interesting, because very similar to what I'd seen in the US and the world with respect to that. So before we jump into the white paper, Andy, you know, let's start with the landscape or context of Agile transformations. So what's your take on the state of play on Agile transformations? What's happening?

Andy Brandt  1:56  
So I think that they are mostly a thing of the past. So whoever wanted to introduce agile into their organizations, into their company, they have already done that. And I would say that this big wave was around 2017 maybe till 2021 maybe 22 for some companies. So, but if I, if I encountered Agile transformations underway in 2022 it was mostly something like a second take. So is the second or third time we tried to do this because the first time didn't go as well. We didn't get the results we wanted. So we are trying it again. But I would say that the other transformations are largely done. And what do you

Dave West  2:45  
think in terms of the outcomes? You know, I've seen lots of these Agile transformations happen over the last 10 years, and I've got, I've got a feeling what the outcomes are on in in average, obviously, there's outliers on both ends. But what do you see in terms of, you know, the success, the value that they've got, that organizations have got out of Agile transformations.

Andy Brandt  3:09  
So I think that they got quite a lot of value, because in many places, these efforts succeeded in creating, for example, cross functional teams. And there is just one memory just just just plugged into my mind about that was, like, 15 years ago, or maybe, yeah, that was, I think, 2011 I was called to talk about agile. That was 2011 in a large bank and, and I don't remember much from that event. It was a very large event of large auditorium in the HQ with like 200 people there. And there were two departments present, largely the Department of software engineering and Department of quality assurance. And as part of my talk, I was responding to questions from the audience, which were coming on small slips of paper. And I remember just one of those questions, and it was like this, I understand that now, with agile, we'll have to work more closely with them, but we'll have to also sit together with them, okay, so, and this showed the depth of cultural divide between those two groups. Now it's unthinkable that divide is largely gone. We don't have totally separate departments of quality assurance and software development. That's one example of the change that happened so we have more cohesive teams. And also I feel that we we concentrate so much on processes, on Scrum, etc, but I think there is also lots of improvement when it comes to the craftsmanship of building software. A lot of that has improved over the past 15 years or so. But part of that is thanks to tooling, but much of that is again, thanks to efforts, and also thanks to agile. The sole thing that you have to have something done fairly often. And again, it's not so that all teams that say they do Scrum, they actually have something done every two weeks, which is the predominant splint length, by the way, but still, they have something done more often that they had in the past, and that kind of forced improvements in craftsmanship. So I think there's lots of lots of doubt. And also we have created quite a lot of Scrum Masters, adjunct coaches, whole departments of way of working and and, I mean, again, some, some are saying that they are not as valuable, or maybe they shouldn't be there as departments or whatever. But basically, what we created create a whole body of people who care about the process and about improvement and about getting better in the organizations, and they are, they are still there, in a sense, right? So those are those things that, on average, worked, yeah, yeah,

Dave West  6:11  
I would completely agree. I think the, you know, 20 years ago, 15 years ago, delivering product and predominantly software. But delivering software product was incredibly hard. Delivering the process was incredibly complicated. We were talking about things like CMMI. We were talking about, you know, Kokomo and things like that. And I think over this last 15 years, what I've seen is that delivery has definitely improved, cross functional teams, particularly with business analysis, testing, development, maybe UX have kind of come together. Maybe UX, that's a whole nother debate and a start, and are effectively doing, doing work together, which, which would have been, you know, I remember my first job, and you're a little bit younger than me, but you can probably attest to this, I built code. There was a whole different room where people tested it, and they weren't very nice people. Actually. They just kept finding problems with my code, which I didn't particularly like, at least now they're focused working together, which is a, which is a huge thing, but, but I still see, and maybe, maybe you don't see this, but, or maybe you do. In fact, I think this was the, the sort of premise of the paper, the that there's still a lot of these teams are still working on work. They're not working on value. They're not aligned to innovation. There's a massive gulf between business strategy and technical delivery. They they're sort of going in the they're going really effectively, but not necessarily in the right direction. They're building things that people don't want. They're taking an alternate amount of time to do that. That's that is has not changed because of Agile transformations. Do you agree?

Andy Brandt  8:13  
Yeah, I think it's slightly changed. It's slightly changed, but it changed. I wouldn't say it's not enough what has changed, because what I'm saying slightly changed. I have two things in mind. One is the companies, the organizations, or maybe parts of the larger organizations, that you call the outliers, where they change really deep around deep and was profound, but they are a minority. And I would like to make this I would digress a bit, but I think it's it's normal. It's something to be expected when we change and when we introduce change, and maybe that, that's another article that I have in on my mind. But when you change, when you introduce change in the way we were doing with Scrum and Agile, we were trying and we were looking at the best companies and best teams and most productive teams and hyper productive teams, etc. Well, average teams are average. They cannot ever be hyper, hyper. It was always a minority, so it couldn't hope. And no, no one can hope really, unless they take really drastic measures to really become from from becoming low average, they to jump suddenly to being one of the top performing outliers. I'm not sure that. I don't think it's even possible, but what is possible is moving from being a low performing average to higher performing average, what I call the 5% difference. But that 5% difference might be difference between going down and going. Slightly up, and that's a whole lot of difference. So that was to be to a certain degree to be expected, but the organizations did not get out, and I'm getting back to the main topic, they did not get out from the core problem that we all have, which is we are trying to do too much, much more than we are capable of. And I'm saying we all have it because it's a human problem. We have the same problem in our lives that we're trying to grasp too much, but in our lives, there are kind of hard limits that we can see or even feel. And in a large organization, if you are an executive, a CEO or someone of this kind, it's much easier to fall into that illusion that we can do everything, because almost no one will say no to you. And the end result of that is that you have an anti pattern that I see repeatedly in organization, is that they have like 100 initiatives open, and how many people are working on on those project well, 25 right? I'm exaggerating slightly, but, but this is this kind of relationship. We have many projects, initiatives, all kinds of names for different types of work, and that work usually cuts across different technologies, different systems and different teams. And one, one person that I talked to, one one manager and at the bank, he used this jar analogy. He said that our teams are like this jar that is full of sand, and there is no place to stick big stones, where in big stones, he meant products. And this leads to this, to this problem that so we have agile teams. We have we are delivering more often. We are better technically. We are better craftsmen. However, we don't have spectacular results. And how do you achieve spectacular results? Well, but by focusing, you cannot be spectacular in everything. You have to focus on something. So if you bowl that, if you kind of transfer that into an organization, I would say that teams have to be focused on products. And that's the biggest problem right now that we don't have. I mean that the whole work is not cut into products properly. And secondly, that those teams are not really focused on those products, and this is what we are trying to address with apon, I think

Dave West  12:27  
it's interesting. You sort of highlighted something that I don't think is obvious when you think about moving to a product model, but it's something that Dow Fernandez, ex CIO delivery lead of some large financial institutions, when he was introducing product operating model or a product model to those organizations, he said the most important and most powerful thing that it gave him and his organization, his delivery organization, was the ability to say no, and which sounds incredibly negative, and you're like, my god, the last thing you want is something that can say no. But he said because we said no, we said yes, so much more. I was like, Okay, now, now hang on. I'm now going around in circles. He goes because we actually had a road map for our for our products, and the teams were aligned to those products, and they weren't continuously changing focus, and they weren't continuously, you know, context switching and connecting and dealing with dependencies. And everybody knew it gave us the ability to do a lot more, but it gave us also the ability to not start a lot more at the time, you know. And I thought that was a really interesting perspective, that that that is something that his agile teams, and obviously he was at Fidelity, who were the what second or third company ever in the world to do, Scrum and, and I thought, you know, I thought that was a really, really interesting, interesting point of view. No, so, alright. So the alright. So we've got this challenge. You've got agile. Transformations have happened or been happening, and maybe they're still happening in your organizations. And sometimes these things are big and long, so we're not judging here. We don't do any of that, but the value that you're getting, which is significant, could be so much more with this idea of a palm. So talk a little bit about the Agile product operating model from your perspective, that's

Andy Brandt  14:40  
also well, so from my perspective, is mostly, maybe I wouldn't say mostly, because as we, as we worked on this model, and we are working on it right now, I see that there are different perspectives on that, but, but from my perspective, from where I see it, so to say, I would say that how to manage a product is an. Already solved problem. We already know how to do that by saying we I'm saying the community at large. There are books about it, there are people who have experience in it. There are training courses on how to be a product owner, product manager, or however you call it, on different levels of competence. So we know that. And I'm not saying that it's easy, but there is this body of knowledge. However, the key problem seems to be that there are no real product owners really managing the products. And you said about context switching, we are kind of forced to context switch, in a sense that we have to adjust our products to the changing market faster and faster and faster. So for example, strategy now is something two years off and not 10 years off, but still, it's done better when there is someone who makes decisions quickly, but they are within the context of the product that they actually really own and don't do that alone, then they own it with their team. And from time to time, that can change, in a sense that this whole team, and this whole team with the product owner, maybe gets another product or starts towards something else, if that product is not being developed anymore, or maybe it's not needed anymore, but, but still, it's a longer stretch, right? So we deal with instability, but being more stable, it's something like this, no, yes, problem that you you mentioned, or I will say that again. So yeah, we get stability, but we also deal with change better. And it's like this, yes, no, paradox that you mentioned, right? So, so I see it as a problem of how together, and how together is mostly how we convince people who are running those businesses, and they are running those businesses in the context of our socio economic system where they have to deliver profits and they have to be rising every year. How we convince them that the way to get there and to get those spectacular results they crave is to give more of the organizational power that they have in those teams to actually developing products, how to convince them that it's better to say no to many initiatives and say yes to some well strategically chosen product. And again, because we had those Agile transformations, because we have agile teams, this strategic commitment doesn't have to be long term. It can be, I don't know, for a quarter, and if, after a quarter they feel a product makes no sense, or investment in continuing investment makes no sense, it's easy to switch to something else. So how to get them to view the organization, not to the lens of ongoing work, projects initiatives, but through the lens of, okay, we have products, and we develop products. And of course, we have ongoing work as well, but at least some part of our power, which is manpower, which is capital, is devoted to developing products. And that's an organization, organizational change problem. And again, as we are talking right now, it just occurred to me that this all happens at a crucial moment, because right now we are in the midst of artificial intelligence revolution, and I'm also very deep into that. And when it comes to software development, it's a revolutionary technology. It increases the effectiveness of teams well from 30 to 70% depending on whom you ask. But having used those tools and using those tools myself, I see huge change over the last year, and it will just increase now. Why I'm mentioning that? Because this is another kind of temptation for the managers. Okay, why bother with that? AI will do everything that I want, and no, even AI won't do all the initiatives and all the work that you do that it is this, this, this problem of having the jar with stones and sand, it won't go away. Yes, the job will be bigger, but the problem itself won't go away. So while organizations will surely invest in this, in that technology, and then I'm very much for that, and I support that, and I will even be helping organizations do that, I still believe that they have to focus on well selected product portfolio, and that's the main challenge. I mean, the main challenge actually convincing the CEOs, CEOs and other executives, that this is the right way to go.

Dave West  19:58  
I think AI, it's really. Interesting. You brought up AI. I agree that AI and this technology is, I mean, it's, it's at the level of a print the printing press, you know, in terms of its potential impact in society. I actually was using it yesterday. I'm not very good at, you know, accountancy and planning and forecasting and all that stuff. And so I took it, I took my data, and I threw it in and asked it some questions. And I wouldn't say it was perfect, but it helped me make some decisions about, you know, where certain products are going, etc. But the key to it is that context and the problem that AI suffers from, and we've done a lot of experiments like you have, is, if you give it a much broader context, then the value of the answers that it gives you and the solutions that it provides are less valuable. The great thing about this boundary that we're calling product is it's customers, stakeholders, value. You know, it's a classical model right of a context that makes sense, which then providing that context and those boundaries allows AI to do some amazing things, to increase the power of the solutions it's it's creating. You know, I think that the the the alignment to product in an organization, coupled with the use of disruptive technology like AI will, I mean, potentially could do amazing things. Obviously, you have to pick the right products. That's a choice thing, and you've got to make some decisions about where value lies. But if you, if you do those two things, I think the sky's the the limit really. So I completely agree,

Andy Brandt  21:55  
okay, to you to use your printing press analogy. It is as hard now as it was then, to write a valuable, Wise Book, because it starts with with having something to share. And you can you back then you use, probably quail pen and stuff like that. And right now you can use open AI to draft it with you and polish your language, but still, you have to have some idea what you want to have to have something to say, basically, right? Because otherwise it will be low quality. So what the printing press changed is that it's much easier to then bring it to to the users of books or to the readers. And ebooks make that even easier right now. So going back to the core problem, the core problem will always remain, as long as we are in a limited reality is that you cannot do everything, and you have to concentrate your efforts in order. I mean, the question is, what do you want? Do you want to prolong the existence of your organization as it is now, or do you want spectacular results? And I'm kind of quoting this spectacular results is, is something that one board member demanded from his people and, and I think it's a fair demand. I mean, you are doing this extraordinary change, you have those motivated teams. Where are the results? It's a fair question. However spectacular results come from concentration and focus, and it has been so always, and I don't think any kind of technology can ever change that. Yeah, so, so this is the I mean, and I want to underline that the apom is something more than that, because we have been working on that and discussing amongst the PSDs that are working on this model. So there is, there are still those problems, how to manage products, how to organize cross product work, etc. But from maybe that's my main interest. That's why I'm so focused on this. It's okay, but how do you first get the company's management to actually realign much of their resources around certain specific products in a product portfolio that it's not too large for the resources to be spread to think to make any difference

Dave West  24:21  
and and that is the I want to say, $64,000 question. I guess when that saying came out, $64,000 was a lot of money. Now it's not, maybe as much. But that is the fundamental question. And from what I've observed, the best way of doing that is to start doing it and and start with one product, and then incrementally add another and then another and start doing that. The the message of this is the other thing that Agile transformations, I think, got wrong. And I you know this is going to sound very grandiose. And and please shoot me down. Andy, if I'm if I'm sounding like I'm preaching here is that they assumed, one that the implementation of agility would be done in a very sequential waterfall way. The other thing is they assumed that all teams would be agile, but they would all kind of do it the same way. They would have the same underlying agile operating model, and I don't believe that. And what I've observed is different products require different cultures, they require different organizational models, they require different incentives. They require now, they might not be grass drastically different from the other products, but, but the ability to own, I always thought there was an irony when we said that the people that own the scrum process that you implement, because it's a framework, are the teams, but we're going to tell you how to do it. And I thought there was some irony in these Agile transformations, telling people to become agile, you know, because of the you know, ownership, whereas I do believe, if you can empower the product teams and the leadership around the product to take ownership of how they work, how they're incentivized, how they're aligned, what, what the you know, the roadmap, the technology roadmap, the business roadmap, the operational roadmap, the value model, they take ownership of those things. I think I honestly you talk about spectacular results from my experience, having done a few startups, the most spectacular results we ever achieve is when everybody's aligned and owns the things that they're working on. And, you know, and obviously, AI and other technology can, really, can really, can really drive that. So I guess to answer your question, even though I meant to be asking the questions, I guess start one product at a time. So what? What you know, listeners, you know

Andy Brandt  26:59  
this is interesting, because when you talk to companies, when you talked about what were their experiences, quite a few companies have an experience of this kind that for some reason, usually that was CEOs pet project or something like that. They did really set these things upright. So they set aside a team and gave that team a product and let that team run with it. And quite often, that ended in a success, larger or smaller, depending on how big the market opportunity were and other factors. However, it kind of worked. What is interesting is that most often no one had the idea, okay, let's repeat that with three products, or maybe with five product next time, right? So I know at least one such project that ended and this team being spun off as a separate company, which is an okay business decision, but why not to try and repeat that again, right? So,

Dave West  28:05  
yeah, I've seen that so many times. It's like when I used to go into organizations and and I said, How long does it take you to deliver software? And they said, Oh, 12 weeks. And said, so when you have a production failure, it your products are out for 12 weeks. Oh no, no, we can deliver in minutes if there's a production problem. So you can deliver software in 12 minutes, or whatever they say. Oh yes, but normally we don't. I was like, Well, how do we make the norm not how do we make the norm the opposite. And there was, like, what, we can't do that. Why? Well, because, you know, obviously using the best people. So you're saying the other people aren't the best. How do we make them the best? Well, no, no. Well, we create an environment around them where they can make choices and make decisions. You're telling me you don't do that for your normal Well, we could do that. And it was, it's just always interesting as you unpack, you know, the the organizational bureaucracy that has there's evolved for good reason to make, you know, but at the end of the day, it's, it's about choices, and it's about trust, and it's about support, you know, and you get those three things in place, which I think are fundamentals to the to a POM to the Agile product operating model, using evidence to make those choices, using evidence to provide the support you know and and fix the problems and make those you know right choices. I think that at the end of the day, you can, you can do amazing things. So our listeners, you know, we have to keep this short, and I could talk to you Andy, as we've proven many very late nights for you, we have, we have burned the oil talking about this stuff. Our listeners, you know, maybe at many different levels in an organization, maybe. Some of them are practitioners working in Agile teams that have been through an Agile transformation. Maybe we've got some leaders listening. What would be the advice for them about a palm and the to leverage this Agile transformation and and to really take it to the next level? What? What can they do next?

Andy Brandt  30:21  
I would say, start with the first product. So define, well define a product. And this is, this can be hard in its own right, because by a well defined product is also has technological implications, which means creating a product that has as few hard dependencies as possible, and give that product to a team, or a group of teams, a formation, as we call it, with a product owner, and let them run with generic or general business goals, like a certain number of users, conversions, revenue, whatever, and see how that plays out. And obviously choose a product that that makes sense, right? So a product that really would appeal to your customer base, etc, and see how that plays out if you can get because it's much easier to get your executives, whoever, has the power to give green light to an experiment like that and keep that light, that green light on for long enough period for that to have any to bear any fruit. It's much easier to get such a commitment for one product than for creating a product portfolio of 40 products are 40, it's way too many. But like 20 products, and having quarterly reviews of those product portfolios, etc, it's much easier to get a commitment for one product, for, I don't know, a year and and, and then proving that this can work. And what is important that it can work here, not somewhere, somewhere else in another company, somewhere else in another country, not here. That's an important proof. And by the way, this is how Agile transformations got started. Is that somewhere some people established a few Scrum or agile teams, and they started to be in some aspects, better than the rest, and it got someone's attention. That's how it got started, before we had all the marketing going, before we before the large consulting company started talking about that to clients, etc. Before that, it started like this. So yeah, that's what I would recommend. Start

Dave West  32:41  
with a product, and it's a natural, you know, just to re echo the white paper, it's a natural evolution of your agile approach. It really is. What you're doing is you're basically changing the focus of the team from a work backlog into a product backlog, and really bring in the business, the people that are ultimately stakeholders of this, this product closer to that, and empowering some sort of product owner, Product Manager, to drive this product into the market and to deliver the results. Might be an internal product, might be an external product, but deliver the results that the vision and the dream and the plan are aspiring to. But I think it's a I think everybody has that ability to make this change. And that's the other great thing about a palm right, is that Agile transformations, particularly at scale, were like these huge things. What we're actually saying is get a team, or maybe a couple of teams, if it's a slightly bigger product, focus them on it. Get a road map, get a business map, get a ROI, build those, build those OKRs, or those goals, and then form that and then focus it on the problem at hand and let them go. And then review it continuously and see how it goes.

Andy Brandt  34:18  
Right. And if it's a new product I would highly recommend to start with one team and many.

Dave West  34:24  
Oh, yes, so would I there is a fallacy or a sort of, you know, if you the idea that if you throw 100 people at a problem, you get it, you know, 10 times faster than 10 people? No,

Andy Brandt  34:42  
it's worse. It's worse than that, because those people have to do something. So if there is not enough work coming from the product owner, they will invent their own work, which will basically mean developing something according to their vision. How the product will evolve in the future, which usually ends up, in all that, having to be reward or holding the teams back in the future. So it's so much better to start with one team if you are starting with a new product, small

Dave West  35:15  
is definitely the way to go. It is true that having lots of teams from day one, particularly on a new product, is a as a recipe for disaster, usually, unless there are actually multiple products and there's a clearly understood this, you know, separation between them, which is, which is really, really good. Andy, thank you for spending the time today. I've really enjoyed listening to your experiences around the Agile product operating model and talking about your white paper, moving beyond Agile transformations, leveraging the Agile product operating model.

Andy Brandt  35:57  
Thanks. Thanks for having me for this discussion in the scrum.org podcast. So first for me, so you know, oh, well,

Dave West  36:07  
that's always that's always good, that's always good. I'm glad. Finally we got, managed to get you on and listeners, thank you for listening today to the scrum.org community Podcast. Today, we're listening to Andy Brandt PST and organizational change expert talk about his motivations in writing the paper, moving beyond the Agile transformations, leveraging the Agile product operating model. Hopefully it's been as enjoyable for you listening as it has been for me, participating. I think the one message that came out was this is a great way of really taking those Agile transformations and the benefits you've got and aligning it to the problems of the future and to the outcomes that the company seeks the strategy is driving to, and really letting it go and and AI is just going to increase that leverage that you can that you can deliver the value from so I think that was a great message from today's podcast. And if you liked what you heard, please subscribe, share with friends, and of course, come back and listen to some more. I'm very lucky to have a variety of guests that talk about everything in the areas of professional, Scrum, product thinking, and, of course, agile, thanks everybody and Scrum on you.

Transcribed by https://otter.ai