Ep. 109: Fixed vs. Flexible Processes

Peter: 0:05

Welcome to Definitely, Maybe Agile the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you today?

‍Dave: 0:15

A really great start to the day. I'm doing very well, by the way, just fantastic. I hope you're doing well. I was just thinking we're doing exactly what we're going to be talking about, which is we've had a process for kicking off these conversations. We've thrown that process away, and so now both of us are staring at the screen wondering what on earth are we supposed to do in order to start a conversation.

Peter: 0:35

Exactly. That's because we're dealing with our fixed process, the way that we always start this. We haven't gone back, even after all of these episodes, to actually refresh that and look at hey, how might we do this differently? What's changed?

Dave: 0:49

What I'm realizing is we've just shot ourselves in the foot. What we wanted to talk about today is fixed process and what impact that has on organizations, and when do you need fixed process, when do you nod, and what some of the risks are. As I was thinking about it, I was thinking about the best agile teams are really, really strong at navigating around processes. I just think we've proved we're not at the best agile teams by totally getting flummoxed by the fact that we've removed a process and we don't know what the next step is.

Peter: 1:18

Yeah, there are good moments for that, and this was something we were talking about. When you're looking to be creative, as we are in this podcast, then it can be good not to have a process, because it allows you to explore and see what's happening, like where do we go, what do we want to say and where might the conversation go next.

Dave: 1:36

Yeah, I think one of the realizations that I was making thinking about this topic is so this comes from both of us. We bump into organizations where they've got fixed processes. I just had a conversation around finance and budgeting just prior to coming into this, and how the wrong process can really hinder you being able to get things done. Because these financial processes are in place, the people in finance want to see them followed, but the process does not evolve to reflect the current needs of the organization. There's this speaking about agile and change. If I can just add to the other side of it, you've got, on the one hand, these fixed processes. This is what we need to be accountable, to be credible, to be good at what we do. On the other side, you have a lot of agile coaches, maybe in the coaching community, but also agile teams where they view processes, individuals and interactions over processes and tools. They throw out all the process and that generates a whole bunch of dysfunction as well.

Peter: 2:37

Yeah, at that point you are generating risk. You still need aspects of process in place in most organizations to ensure that the right things are happening at the right times, especially if you're in an organization that has some kind of regulatory needs that it has to meet, some external bodies or other places where there's something you need to do. Even if you don't, you're typically beholden to what the organization needs and where it's going, unless you're really really really small. If you're in a like a start-up and you have no external dependencies whatsoever, then you can perhaps get away with sort of just flying by the seat of your pants, but at some point you need to have something to create some kind of consistency in what you're doing.

Dave: 3:26

Well, what I was just going to say is I think we're actually not talking about there being no process. If I just take something daft like getting your expenses, if you're in a large organization, there is a process. If you want the finance department to give you any money back, you're going to follow the process or it doesn't happen. An explicit process that we can all use and we understand how that works In a smaller organization. It isn't that there's no process. There's still a process to get your expenses returned. It's probably a implicit. It's informal. I can walk in, go talk to the finance manager, or I am and I dip my. Whatever it is, there's some informal process and, crucially, it's not repeatable. It's maybe repeatable because somebody says hey, peter, if you want to claim that back, throw the receipt. This way we'll give you the money out of petty cash. Whatever it is, it's an informal process, but as you scale, that cannot, it doesn't scale. So it's not that there's no process. It's more that there's an implicit, informal process, or maybe there's an explicit process, but not that there's no process necessarily.

Peter: 4:28

Yeah, I agree, it's the. There is some way that something is done. There's a sequence of activities that occur and that sequence of activities has to occur. It may not always occur in the same order, as you say, because it's informal, but the but there is a sequence of things that need to happen. I, I asked somebody for the money. They give me it back. See, that type of thing Now.

Dave: 4:52

What's interesting then is okay. So because what we, where we started our conversation, is okay. Those fixed processes, how do they handle change? And I'm just reminding you to stay on finance. It feels like that safe place that we're not tripping over. But I'm just thinking. We're in the condo, which I'm living in, but they're currently doing a big chunk of construction and payment to the contractors is still done by Czech which I still. I scratch my head about this one. I mean, Europe got rid of Czechs whatever 20 years ago and yet still there's this part of work that gets done, where Czechs go backwards and forwards in a day when everything can be done through electronic transfer of some form.

Peter: 5:32

Yeah, and it's been that way because all of the different parts of the system that would necessarily need to change just haven't updated themselves to make this possible. So you've still got this process because that's the way that it's always been done and nobody's gone to make the change. Now, in some of these cases, it's because it's why make that change, like sometimes you get into situations where a process is fixed because the cost of changing it is higher than the cost of maintaining it, or at least the perception that the cost of changing it is too high.

Dave: 6:06

Although the benefit you get with a new process is just not there, right? Yes, yeah.

Peter: 6:12

So the people with the Czechs don't see the cost of all of the trees are getting chopped down or all the rest of the pieces, or the damage to the planet from all the pollution, if we want to be environmentalists about it. But there could be all sorts of like if you looked at the entire end-to-end value stream, is it really for the same cost you think it is?

Dave: 6:34

But I wonder, because this brings us on to risk. Let's just stay on this topic around the Czechs, because the reality is that the contractor in the case that I'm describing, the contractor is the one that carries the risk. If the Czech is delayed in the mail, they're the ones that don't get paid, and they're the ones. So this is about how do you manage the risk? Are you shoving the risk off to somebody else and they're now having to handle it, but it doesn't impact you? In which case, why would you change your process? Doesn't worry you, right, yeah?

Peter: 7:00

exactly and we were talking about this before is that if there isn't anything sort of driving that change, if there isn't any or there isn't anything that has to happen for a particular reason, then that reason to change the fixed process doesn't occur. You need some kind of driving force. So, even though all of the world and all the industry around has changed, we still end up with the same process in place and it stays with where it has always been. Because until there's something that, for example, where no longer allowed to chop down trees, nobody's allowed to print checks anymore, we have to change.

Dave: 7:37

Or the risk is somehow transferred back to us for some where we're held accountable for, let's say, the Czech not reaching its end point. So now we carry the risk for that. Therefore, we're going to make some changes to our processes to make sure that we're not carrying that risk.

Peter: 7:51

Yeah, that's, extensive.

Dave: 7:53

Well, I really think it's important for us to think, because where we came into this conversation is trying to understand why don't processes stay up to date and we were thinking in digital, in particular, there's well in operations that there are some very well-defined processes. Whatever it might be, if I make a change to the system from an operations manual perspective, I need to update the operations manual and make sure you say you in operations know what changes I've made. Now most people we can talk to about that would agree that sounds like a very sensible thing and yet decades of experience writing software and working in the technology industry tells me that just because we all recognize it's a sensible thing, we don't do it in many, many cases or it's difficult to be consistent about.

Peter: 8:33

Yeah, and part of it's where that accountability lies and part of it's like where is the value? Who sees the value in that? And the operation manuals, especially in organizations that still operate in a very sort of development and operations, are separate entities where the operations manual is valuable to the operations folks but it's development folks that need to update it and so it's not as valuable to the development folks in those situations so they don't update it.

Dave: 9:05

Risk transference again right.

Peter: 9:07

We're at risk transference.

Dave: 9:08

We're at risk of operations Now and I still think in a DevOps environment you've still got that headache, because I think a lot of risk transference is sort of human nature as well.

Peter: 9:17

right, I mean yeah, well, in a more DevOps environment you mitigate that because the delivery team, end to end, owns the systems that they're deploying. So as a part of that, for their own sanity, they now have accountability, they own the risk and you put the systems in place to ensure that they understand what are the consequences of the failure. So there's by having those feedback loops in place, by creating the telemetry, by creating the visibility into that when it's done well.

Dave: 9:53

But it's not just telemetry, is it? I know so many organizations have separated out, you know, defect resolution enhancements from feature development. And so now again, it doesn't matter how good my telemetry is, I still have a transference of risk away from the feature development team to the enhancement and defect fixing team?

Peter: 10:12

Yeah, well, but yeah, I had this conversation on Friday with a mentee of mine and, yeah, I said well, that was your first mistake. The delivery team needs to own their defects. Simple as that. If you like, separating it out into a separate team is is again risk transference, you're, and it creates exactly that same problem. And not to mention that that team that's solely working on doing all that defect stuff, yeah, good luck keeping them. Well, exactly, yes, yeah, yeah, because that is just soul destroying work.

Dave: 10:43

So if we turn his, if we just can kind of continue this conversation, we're definitely comfortable having a well defined process, for example, but now there's another aspect to it, which is that well defined process that is now no longer fit for purpose. Yeah, so talked a little bit about the check and finance and financial process, but there's a lot of examples where there are roles within organizations whose job is to keep you aligned to a well defined process and yet, invariably, those conversations are incredibly frustrating. And you know, in some ways, something that I'm thinking of development teams and so on, where they try actively to I mean honestly to ignore or avoid those conversations because they find them frustrating. Why is that?

Peter: 11:30

Well, there's a perception of the very least. I think it comes down to risk transference. Again, it's that that there where's the value and who's that valuable to, and if the delivery team is focused on. I've got to get this next feature out the door and you're. But you're asking me to stop and do all of this extraneous work which doesn't actually appear to have any value to what I'm delivering and I don't see why I should do this. So the the they may not see that value in creating, even like updating threat models, for example, is a common, so part of your delivery system, especially in a large, more complex system. If I'm making a change to integration into activity or moving parts of my system into, I'm like, an on premise environment, into the cloud, what, going through a threat modeling exercise, should be a standard practice at that point, like what are the various threat avenues? Because I've changed very much the nature of the system as I'm deploying it, so I should be looking at what is the impact of that causes, what are the potential new risks that I've raised and have I probably mitigated those?

Dave: 12:36

But it's interesting. So the threat modeling kind of idea there's something very dynamic about that in the sense that if I model a threat, you know, in February of 2023, and we've made the changes there the assumption in you know at the end of 2023, that that threat model is still relevant is probably in the world we're living in, where things are changing so rapidly and you've no dependencies outside of your control, is almost certainly not true. So that brings us to that. It isn't a fixed process but a continuously evolving, better and better and better process somehow. And I think that's where we start seeing challenges, because we think of processes as fixed or permanent and we want to think of the validation and continuous and approval of process to be the fixed and permanent bit, not the process.

Peter: 13:21

Yeah, it's the. We should focus on change itself. We need to get good at change, not at right it's for the cat person. Cat post diversion of this right.

Dave: 13:32

Well, and what I'm just thinking of, like there's so many of the organizations that we've stepped into I'm sure we've both experienced this where this individuals and interactions of a processes and tools meant basically ignoring process or at least very much downplaying it, instead of, to your point, changing process. And I think there's that element of being aware enough to know that the process doesn't have to go away. As we said, it becomes explicit, moves from explicit to implicit or informal. It's more that we take that explicit process and evolve it based on new circumstance, whatever that might be.

Peter: 14:11

And this isn't easy, especially on scale, because it can be very easy to make blanket statements that we believe to be true but that can become very, very difficult to implement. My favorite example of this, coming out of the DevOps space, is the idea of code scanning on every change that you put through, which in a, especially in an organization that's been around for a while or in an organization that's been encouraging people to be able to use whatever languages they want, just isn't feasible. There's no code scanning tool in the world that can scan every single type of code I have in the environment just doesn't exist, and it certainly won't work well with third party applications or configuration based systems or batch based systems.

Dave: 14:57

So there's I just. I get the impression you wait three months and then chat. Gpt will be doing that over his lunch break.

Peter: 15:06

Yeah well, again you run into a problem. even yeah, it's got a little bit more to it than that I was not wanting to derail things but that was just too easy of a shot to take, yeah well, that's a whole other conversation, because it I mean chapter DT might be able to come up with the various tests that you need to be able to execute, but it doesn't necessarily have understanding of all of the other tests that exist in the system that also need to be done and included. So, chat GPT on its own maybe not, but if you tie chat GPT into some kind of modeling system that would give it insight into what exists already, then yeah, potentially.

Dave: 15:43

Right, let me just pull that threat back in and we'll throw that?

Peter: 15:48

How far do you want to go down the rat?

Dave: 15:49

No, I don't want to go, not in this conversation, but what I wanted to say is I think what's important around for us to take away from that, if you like, is on the process itself. Is you need that dash of common sense in there as well, or experience or thoughtful application? So the idea I guess we're coming to is the idea that a process can cover all cases. Let's probably not go that way, at least in most of the spaces we work in but equally the idea that a process can be static and not continuously up for review and change as the environment around it changes. So I think the best example I mean the best scenarios, examples I can think of has been where there was sort of informed conversation about whether that process was still serving its purpose or whether it needed modification. There's a well understood way of making changes to that that valid. You know that had expertise looking over it to say, yeah, you're not throwing, throwing out something that's going to be critical.

Peter: 16:48

Yes, yeah, exactly, and, having been involved in a lot of these types of conversations, they typically there's everybody's got a point of view and getting everybody aligned to oh that's, that's a whole other thing. Right, yes, but yeah, there's there's a point at which processes get in the way, especially with where, if we're trying to be creative, we're trying something new. So creating avenues for people to be able to do that is essential. There are places where we need consistency and way things are done, or we we know that there are particular elements of execution that have to be in place, either because we have some external need or because, if we're in a and we were talking a bit about this you're in a system which has got more sort of life or death or has more severe consequences of there being a bad decision being made, then you may need to have to make sure that certain things occur so that you know that it's safe. And so there are these. There's definitely these elements that you need to include, but having sufficient flexibility and to be able, within the processes that you have, but also that, as we've been talking about like they need to continually go back and look at them and say, okay, is this still serving us? Is this doing what we need it to? Is there? How do we improve from here, like if what's the next iteration of this that's going to get us to where we need to be? And cycling back to the finance piece, the obvious one. There is moving from project to product and thinking of, like our fixed annual budget versus continual incremental funding of value streams, for example, or what are we doing.

Dave: 18:32

I mean your point about innovation and creativity is it's?

Peter: 18:35

really important.

Dave: 18:35

You know, in a culture which is heavily process oriented and effectively, therefore, control oriented, that just it just really makes creativity difficult and innovation difficult. But equally, when you go into a culture or an organization that needs to innovate or be creative, it doesn't mean there's no process there. Again, there's processes that allow you to innovate and be creative, some of which is strip away some of the controlling processes, for sure, but not. I mean, we're currently working with clients, helping them with innovation, and one of the things that's really interesting is there is well-established practices, processes around innovation. It's just different to the ones we use to build consistent features of a certain level of quality that meet the expectations of customers. There's a, there's another element to it, so there's a subtly different kind of environment within which they're working, but there's still constraints, there's still containers within which the innovation can happen.

Peter: 19:33

Yeah, yeah, and things like service design and design thinking and human-centered design and all of these spaces where there's a there's a. There's actually a fast array of processes and different methods and ways of doing that, to like from generating ideas to turning those ideas into actions, into experimenting, like how would you test this for a hundred dollars? Well, like that kind of thing.

Dave: 19:57

Yeah, it's. I mean just to kind of close the loop on a couple of things. I think, as we've jumped around around process us know that's in the background is I'm realizing the human behavior and how we interact with people. Because in innovation and creativity that's where it really becomes very obvious, because if we do things in the wrong order or we would kind of come in with the wrong mindset, we're really going to blow up the ability to get innovation and creativity. But the same is true and if I want a repeated behavior there is also I have to understand that there are certain things I cannot do, because nature is going to get bored, is going to be distracted by whatever's going on. So trying to get repeated behavior becomes challenging.

Peter: 20:44

Yeah, any process that has a base assumption that some human being is going to do the same thing in the same way every single time is obviously that you're not looking for consistency.

Dave: 20:59

Yes, yeah, Maybe just to sort of wrap things up, Can you talk a little bit about? So we've talked about lots of process, but if we talked about practices good practices, best practices- how does that? Fit in with the process conversation. So, without delving into the Well, trying to avoid a deep dive into Kinevin, but I think part of it is of course a practice and a process can be very aligned, or not, I guess.

Peter: 21:29

Yeah, well, and what you find, especially in larger organizations and heavily regulated ones, is they followed a particular set of industry standards and ways of doing things, and those have helped define what the processes are that are in place. And it can and this is one of the other things that often gets forgotten about is that will people change? People retire, people leave the company, new people come in, they look at the process and they go. Well, that doesn't make any sense. It's like why were things done that way? And a lot of it might have just been that somebody took another process and they brought it in, and that's what created that set of processes. And when we look at where some of that best practice comes from and where it gets applied, if we're operating with a complicated system, something that we know wants to do in a certain way, we want to do expenses. We know that to get expenses for the tax term, we need people to put in who it is that they met with and things like that. So there's a process that has to be in place for that, so that they're not allowed to enter it without entering that information, and then you can have review processes around it, for example, like we were talking about expenses earlier, so so there's a known best practice for that process. There's a set of things that need to exist, and if you buy a tool off the shelf, it'll probably already have that base version of that built in that you can tweak or tailor for your company and integrate into whatever other systems you need it to talk to, which is probably where it needs to start to operate. So there are, for a lot of things that we do, there are no ways to do things and no practices and best ways of doing it that we take and we adopt, and as long as we don't find that they're restricting us, we don't find that there might be a better way of doing this. Maybe if I just took a picture of everybody else having dinner with an, identified them all, took them out of my contact book and added them to the expense receipt, then I wouldn't have to fill in that field.

Dave: 23:38

I don't know what you're saying. There is basically, is best practice automated?

Peter: 23:43

Yeah, that's just what it is.

Dave: 23:44

I mean, it's just like how do I get this off my plate so I don't have to think about it? What I always find interesting here is you get into the good practice and then emergent practice. As you sort of get into either more volatile or dynamic areas or just unknown areas, is we're now it's almost like the dash of common sense and human, like thoughtful cognitive interaction and thought increases. So you're basically going like you know, best practice, don't have to think too much about it, just get it done. Good practice, we probably maybe it's 50, 50 or 40, 60 or something in terms of I need to be thoughtful about it and we were saying there are edge cases.

Peter: 24:20

Yes.

Dave: 24:21

And there are often, you know there's always something there that's not maybe fully, you know, included in this practice or process. And then, of course, emergent practice are the ones that we're always refreshing and apply different experience and understanding to, and I think that thinking of processes in that same way, of best to good, to emergent practices, all of a sudden gives a little bit of a tool to start thinking is this practice, is this process fixed because it's best practice? It should not be modified? Or is it fixed because it's good practice and we just think it's good and we should keep it, in which case maybe it's got to change or not?

Peter: 24:57

Or is it an emergent?

Dave: 24:58

practice that we need to continuously monitor and change and update as we learn more through telemetry, through whatever it might be right.

Peter: 25:05

Yeah, and I would say technical change of software would be an example of that. Yeah, exactly.

Dave: 25:12

So it brings us a nicely full circle. How do we sum this up, dave? We better keep going. So how you know what? For all of that conversation going backwards and forwards, I think one of my key takeaways and I really enjoyed this conversation one of my key takeaways is this idea of processes, first of all, always being there, whether it's explicit or implicit and formal or formal, and then, secondly, that there are processes that you really don't need to change or should be held firm. There are processes that you want to continuously challenge, you know. And then, somewhere in the middle of the processes that you want to review and update or think about on a regular basis, and I think where the challenge comes is when we treat, you know, processes always being firm or permanent, when they should actually be up for discussion or continuously reviewed or whatever. It might be something that's a little bit more flexible for for not a flexible process, but flexibly reviewed, you know.

Peter: 26:08

Yeah, it's the. I think it's the balance between creativity and risk. Right, that's where do we, where do we fit on that scale and where are we? What are we looking to do?

Dave: 26:21

And and problem space, right, so yeah, awesome.

Peter: 26:24

Well, with that, I think we can wrap up for the day and anybody wishes to subscribe, hit that subscribe button. And as as always at feedback@ definitely maybe agile. com, and wonderful conversations always, Dave, until next time.

‍