The Agile CoE

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome. And here we are again for the Definitely Maybe Agile podcast. And my good friend Dave here is uh my good friend Dave is here as well to enlighten us. And today we're going to be talking about the Agile PMO. So, so Dave, what what have you got to say to open us up on this one?

Great to talk to you again, Peter. I'm looking forward to a bit of a conversation here. So let me just start by trying to understand when you say agile PMO, and we often talk about agile COEs, so project management offices or agile COEs, centers of excellence, what do you see in organizations? Do you see Agile PMOs or Agile Center for Excellences popping up with a very clear focus or overlap between those? How do you see that?

I've seen it uh occur, especially in large organizations, in a variety of ways. If if there is already a PMO, very often that continues to exist while uh a center of excellence for agile gets stood up under some transformation mandate of some kind, reporting up through the organization in some other manner. Um and and I've seen the variety of one taking over the other at various points in the evolution of that um and where that particularly goes because they tend to be tackling different things. Uh I I I could comment too on uh, but I think it'll take us in a slightly different direction with this conversation than we were talking before about um uh coming from an infrastructure space. One of the big problems I've always had with PMOs is that they really do not understand how to deliver infrastructure projects. Uh they're no good at delivering software projects either, but they're terrible at delivering infrastructure projects because infrastructure projects don't really fit very well into the traditional PMO that exists within organizations either.

It's but but I I mean this is always an interesting conversation because I don't think either of us have ever planted ourselves in a PMO, in a project management office, with an idea of saying this is this is really important, we need to do this, how do we go about putting this in place? I think uh first of all, we have to recognize the purpose behind a project management office, which is primarily governance. And to your point about infrastructure projects, it's not about can they run the projects, but are the projects running on time, on budget, to within plan or whatever the particular parameters are that people care about. And I think the same is true for you know software. We're all very familiar with um gated funding models and having to design a piece of software up front before the team comes on that's going to build it, and knowing that that design and the final design that gets built are going to be out of sync for many different reasons. And so if we understand the project management office as a governance body, that's actually a starting point where we can have more constructive conversations than understanding it as a definition process definition.

I think that's fair. And then a lot of the time when we see in agile adoption, we see there's still a PM being assigned oversight very often of the purse strings and how those are being distributed, because it's not uncommon for the PMO from a governance perspective to be the ones who are charged with making sure the money's going to the right places. Or when I say right places in quotes there.

Well, but I think it's also difficult because you know, in a small organization, quite frankly, you shouldn't have a PMO. It should be something that's a little bit more fluid, and you know, there's a hundred people or there's fifty people or there's a few hundred people, you should be able to govern where you spend money appropriately without the weight of a governance role or responsibility in a PMO. But in larger organizations, to be fair, they need to control that. There's a lot going on. There is there's a lot of activity. So, how do uh large organizations make sure the activity is going on in the right places? And not only that, but is the that activity uh going in the right direction? Is the money being well spent? And I think the biggest conflict we have with project management offices in the governance space, uh in that governance role, and agile project management offices or governance, if you like, is fundamentally they're governing in different ways. And if my head is in one space, it's really difficult to get my head into the other space to look at it from that perspective. So in the agile context, we focus on rapid delivery of value. So if we're releasing shipping something valuable in short uh increments, we actually don't care what happens inside there. We just accept the cost of that short increment, a sprint, let's say, and measure that and say, did we get enough value to say that was uh a good uh sprint of activity? Or did we not get enough value, in which case that wasn't a good sprint of activity and we need to modify it and change it? That mindset is very, very different to one where the increments are long, it's multiple months or even years because there are these project plans and they're trying to do everything, kind of boil the ocean and get the whole thing shifted. And in those situations, I can't wait to the end of the increment, the end of that deliverable phase, because we've burned too much of our resources getting there. So now I have to worry about the activity that's going on, and what I always refer to is illusions of progress, those milestones or the sort of ticking the boxes to think, okay, I feel like we are moving in the right direction. Therefore, we should be successful.

And we and we I think the other one we commonly see is uh where you've got the hey, we've still got a project, but it's gonna be run exactly as it was, except here in the middle we've got a bunch of boxes which are marked sprint, sprint, sprint, sprint, sprint, sprint, sprint, which lead into each other, and then a whole bunch of tidy-up stuff at the end to release it, but we haven't really actually changed very much in the process. That's uh another common model that I've seen.

Well, I mean, that's iterative delivery, right? But it's iterative without the increment. And the increment is the magic that makes agile delivery work, coupled with short iterations, whatever short is in your context. Yeah. So it we talked a little at the beginning about agile COEs, centers of excellence, and and um agile pro um project management offices, and of course, they often overlap, but not always. There is a distinct role between the two. And um it's I find it quite uh peculiar that as an agile, like involved in agility, business agility, and transforming organizations to this sort of iterative and continually learning way of working, we will very quickly talk about communities of practice or guilds from the whole world of Spotify or whatever we but we're going to talk about those communities of practice and we encourage them right up until someone says, and we've got an agile community of practice slash coe, and then we sort of recoil back from that. From your experience, what why do you think that is? Why are we so keen on communities of practice on the one hand, but struggle with communities of excellence around agile in many cases?

Well, well, I I see those as two slightly different things, and and it's it's partly nomenclature, but it's also partly how they're set up and treated. Because theoretically, a a COE could be a COP, but we we when we often when we talk about it, we differentiate between the two. And we see the COE as the center of excellence being, hey, all of the people who know how to do this are over there. If I want to know how to do this, I've got to go over there and be with them because they're the ones who know. Versus a center of practice, which is looking at, well, we're all involved in understanding how it is we work, and if we set this up, we can start to look at how can our practices improve? What practices can we evolve? We all have we have a common, we have something in common in the practice that we're doing. We all work with with data, we all work in testing, we all work in some area. So if we bring that across and look at it, then what are those practices that we can work together to get better at improving? So that becomes our community built around looking at that particular practice versus excellence being a sort of almost the ivory tower over in one corner that uh is being held responsible for being the experts in this that you can only go and consult if uh you're wearing the right robes.

So, in in your description there, Peter, do you see any role for a center of excellence in terms of that almost feels like it's a definition process definition piece, or it's a um it's where all the experts sit and proclaim what agile or whatever your center of excellence is across an organization?

Peter Peter Peter.

Yeah, that's how I I often uh see it being both defined and interpreted. And I don't think it has to be that. I think if it's done well, then it's really less about what the name is and more about how it behaves. I mean, if you're if it's acting more as what I would call um what I might call a flow enablement team or a ways of working team where they're they're actively um helping uh the organization develop and understand new ways of working and set up communities of practice and helping put new ways into place versus the accumulation of knowledge and then telling people how to do things and saying here here is your here is your set of practices that thou must follow. Uh, and if you wish to be agile, here's a rubber stamp to say that you are agile now because you did the right things to be so. And I and I have seen that in organizations, and that that's typically something I associate with the group that's been labeled as the COE.

But do you see um any point at which a definition, you know, a organization-wide, clear-cut definition, this is what Agile is, or this is what Fred is, whatever the the particular topic is, this is our shared understanding of what that means in this organization.

I think that I think there's value in in somewhere having made that available so that it's in the context of the organization, that the organization understands that, but it has to be done in a way that it's open, that you can come and you can use that, and the resources are there for you to consume, and we will help you with the consumption of those. But if you wish to change them, then because there you there's parts of your context that you understand that you're far closer to, that we can't we can't dictate how you should do this. We're not going to inflict this onto you. We're gonna invite you to come and learn about this, and you can take that away and apply it to your context and however you work, and we'll we're happy to help you in that. I I actually came up with a with uh five sort of layers of interaction models for this the other day as a part of uh a book I'm writing, and uh sort of along this lines of it's it's all about that um how you enable the engagement to help people have something they can take with them versus saying, hey, we we're gonna dictate exactly how you will do Scrum. And if you don't follow this, you're not agile and you don't get the stamp to say that you're right.

And I I think I mean we're on the same page here. I I love where this conversation's going because I I think there's a recognition that that there should be standards, and I certainly don't think removing standards makes any sense at all, especially if you're in a large organization. And one of my continual frustrations is walking into organizations where every every team interprets what they're the way they are working in their own way. So there are common uh phrases, terms, stand-ups, or uh definitions of done used across the organization, which it is so simple to standardize that, and yet they're not standardized, so everybody interprets it and adds colouring, which which then brings us back to okay, if you're going to define those standards, and this is the challenge, right? How do you stand how do you standardize the uh the practices or that description of a process which is uh a big part a cultural change and uh and situational? And I think that's the bit that we really have a struggle with because if I go in with a mindset of I'm going to write down all of the different steps in a step one, step two, step three sequential process and the inputs and the outputs, and we define all of that as some sort of product or software delivery lifecycle, uh that's not what's going to happen in an agile context for two reasons. One, we're continually iterating to change that. So if we don't want to make that uh life cycle description be continually modified, we need to think of it in a different way. And secondly, there's a big chunk of it is cultural change and is is situational. And those two things mean uh cultural change is rarely achieved because somebody writes down what's going on and shares the leaflet out. Cultural change comes with a much more organic process behind it.

Yeah, for sure. And it's and it I think that is where we trip up in trying to marry those two different worlds and ensuring that there's this piece of I I will I will start to bring together the understanding. That there's another area where you I can see um there's an area in which I see the Center of Excellence also having some things that it could do that uh might not exist otherwise, which is around um the awareness piece, around both both internally and out externally to the organization. So going outside the organization, looking for other ways of doing things and bringing that back to the organization and radiating the successes so that there's an understanding of what's happening and what we're achieving, which adds an awful lot of value too. And I can see that there's there's a lot of value in that, the the radiation of these ideas. And here's here's something that uh may or may not work in your counter. We've seen this somewhere else, this has helped this team over here. Is this what sort of challenges are you running into? Um, and here's something that somebody else tried, if you want to try it yourself, kind of thing. So it's uh that opening things up to provide the options, the understanding. But I do completely agree. There needs to be at least that standard of common uh nomenclature, how do we describe things, how do we understand each other when we talk to each other? Because if we're all talking about something completely different in different languages, it becomes very hard to communicate. Um it's uh I I talk about that a lot and when I talk about like the Rosetta Stone of how different parts of an organization need to be able to translate um to each other. And and this is not a technology thing, this is this exists across the organization. It's uh if sales needs to talk to marketing, if say if uh if your finance department needs to talk to your marketing department, that there's different languages and different areas where we need to be able to work out how to translate what all these different things mean. And if everybody's referring to things in different words, uh I ran a value stream mapping exercise earlier this week, and across that organization they used three different words to describe uh the uh who one of the parties was in that value stream. So different people in the organization referring to the the same role with a different language in different places, um, which is true.

So so uh sorry, um I really like the two things that are coming out from that description there, Peter. One of them is um uh a common vocabulary, so that commonality, so that when I talk about something and you talk about something, we use the same language, it's defined, we understand it, and it's the way this organization refers to those key things. And I think that's classic COE territory um and absolutely essential for people to be able to dig into the details behind it and have a really good conversation. Um and then uh the second thing that you you talked about radiators, and I thought of that as the narration of how you share the good practices both inside the organization that you see, so you can sit down and say, over here this is what's been achieved. There's a there's a narrative over here, or equally outside the organization, what these narratives are. And I I think the only the the third thing, just sort of in that COE slash PMO overlap, might be a conversation of governance in terms of uh recognizing uh how we measure a good uh investment of time, energy, effort, money, whatever it might be, versus how we look at something and say, Yeah, this isn't working, we need to pull the plug on it, so we need to invest and be curious and understanding what's going on here to um to kind of turn it around a little bit. So that governance aspect, if you add that to the terminology vocabulary piece, the narrative piece, and then the governance. And the governance is probably a harder one because it's distinctly different to traditional project management. Um but that governance piece then it feels to me like you've got some power there.

Yeah, the uh and as as the so power is an interesting word in this case. There's value, maybe might be a better word for me. I think it's it's uh it's the some usefulness almost. There are things that well I did so.

Let me just because as I said the word power, I thought, oh no, that's not really the right word. But there's it's a catalyst, there's something there that will accelerate adoption, good practice, uh curiosity in an organization with those three things there. And so I think it's a it's not it's definitely like I said, power is probably the wrong word, but it's it's catalytic in some way, it's an accelerator, which is exactly what you want to see from a uh a project management office or a COE that's really worth its salt.

It's an enabler, it allows the the organization to function at a higher level than it would do without that body being and uh and I think of that more as this um this way of ways of working team, as that's from the Sooner Safer, Happier World, or the or what um we call um the flow enablement team, or or whatever you the this enablement team that's uh helping the organization in that manner, um versus quite often what we see in that COE category, which can sometimes uh end up being the um dictorial um where thou shalt operate this way in order to be called this, and if you're not then you're not doing it right type uh behavior, which is um uh quite I find uh quite counterproductive.

So looking at the time, maybe, Peter, what are the what are the kind of takeaways you want people to think about as we leave this conversation?

Well, I I think uh and I think we've gone through quite a number of really really good points. And the and the three that we had here, I think are still really worth talking about um around the first one being that uh you can't control the cultural change from a COE. Uh that they can help enable it in the organization, they can help guide it, they can help bring new ways of working, and if they behave and uh and operate in the right world, they can be a very powerful force to help accelerate as a catalyst that change in the organization. Uh the second one was around uh you can't put control on a changing, constantly changing process. So, this idea that the COA is going to sit there and write down exactly how you will do these things and that everybody will do those things that way, it doesn't uh that is not how agile works, and that's not how uh uh change works. And just simply in terms of how do we deliver value to our customers and accelerate our ability to do that, that's just not how um these you can change these systems. And then the last one was uh the a traditional PMO being very much at right angles in terms of the the governance structure. Uh there's a lot of value in what a a PMO can potentially do, in that they they need to be involved in that change. Um, but their their role is very much at right angles to what that transformation, uh the the COE, as we're describing it here, the way of working uh team is actually operating uh in terms of uh Accelerating value delivery. So with that, would you like to wrap us up for today, Dave?

Well, let me just um say thank you again for the conversation. As always, we'll welcome comments or ideas of topics insights. And until next time.

Thank you very much. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital, agile, and DevOps at scale.