The right amount of planning

Welcome to Definitely Maybe Agile, the podcast where Peter Madison and David Sherrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your hosts Peter Madison and David Shurik.

I was gonna say, Peter, it's obvious you've not looked out of the window here because it's grey and gloomy over here where you're clearly seeing lots of sunshine. Great to be back, great to be talking about uh well, planning this week, right? Talking about how to plan or when to plan uh within the context of agile delivery.

Yeah, and then like I'm how much? I mean, it's quite clear in the manifesto what they they like to say about this, but it's uh part this came out of uh partly as well sitting through a PMP boot camp. I was helping my uh my wife was doing the PMP boot camp and uh I was uh helping support her and bouncing ideas around and uh uh I I got some insights out of it. Uh but it uh was actually kind of surprising how many insights I got out of it.

So what when you say you got some insights, I mean the agile community as a whole is quite um uh they're not very friendly, if you like, towards project management. And I'm not sure that's quite the case. In fact, many of us have come through project management as a career choice or a training background. That's where we come from in the in terms of learning how to deal with complex IT programs. You're going to learn how to deal with projects and the the steps that go into that. So, what is it that you picked out, the kind of the hooks that you walked away from the PMP training for?

So there was there were some pieces there that um I hadn't thought about in quite some time that I think are actually valuable, um especially when they were talking about uh the more structured, quantifiable ways of looking at things like risk management and looking at uh uh procurement and other activities like that, where there's the there's much more structured modeling of those types of processes and practices, which I can see situations where applying that uh makes an awful lot of sense. Uh and it's I I usually think about um project management in the sense of uh bringing the right amount of planning to the problem that you're trying to solve. And this was actually something that they they had there. It's that the uh the lower your certainty, the uh less amount of planning you do. The higher your certainty about what's going to happen, the more planning you can do. It's uh kind of a direct correlation.

Well, and and the reason we do the planning is because the higher level of certainty that plan reduces the risk of mistakes, of being trapped in running after a particular shiny object, whatever it might be. It keeps people, the organization, the teams working on things on track. Uh so I think that's sometimes forgotten that the need is there for um for for to to make it as cost-effective as possible by eliminating distractions and making sure the organization is focused at the right place at the right time in order to deliver something which is inherently predictable.

Yes, and uh as uh as Eisenhower said, plans are nothing, but the planning is everything. Uh because uh this is and if we look at this from when we see faults occur in uh in in Agile, sometimes it's the taking it too far into what we don't need to plan, we're just going to do. Uh, and the complete lack of any kind of planning uh is also generally quite detrimental. We need we need some idea of what it is, what's the approach we're gonna take, like what's the general structure of how we're gonna work together, and which is kind of key, really.

Well, I I'd push it a little bit even further than that, Peter. So something that I'm uh we're seeing when we step into organizations, and we're seeing it in a number of different areas, is it's almost like that skill of planning has been forgotten. And uh I think we want to be very careful that we need to understand how to plan, how to consider what the objectives are, what are the resources, the the things that we can bring to the table, how we can sequence different events. There's a skill set around planning, which there are a lot of um organizations and a lot of individuals in in planning roles, in roles where there needs to be an appreciation and an understanding for a plan, who for whatever reason have locked the door on the skills they had around those plans. And you know, even if I look at something like sprint planning and the breakdown of tasks, it's it relates very closely to the work breakdown structure, which is obviously a key piece of the project plan. It isn't as formal as that, but there is a reason for a work breakdown structure, and there's a reason for that sprint planning uh conversations and what gets pulled out of it. And what sometimes happens then is it's almost a random way of getting the work done that follows from that without an appreciation that there is an order that would make more sense versus an order that maybe doesn't make more sense. And those conversations about, you know, how do you deal with things? If you're taking a half day on a Thursday, how do we work around that? That just that simple level of even planning on just availability and what gets done first, second, third is often missing. If you then factor it up to, but we've got a dozen teams and they're all coming together, we still need that ability to be able to look at the big picture and understand those connections and start talking about planning behaviors and activities and deliverables in a way that's going to optimize delivery. And yet that word plan or planning or project management or whatever is often shied away from, unfortunately.

Yeah, runaway and terror, we don't want to do any of that because that means we're we're setting things in stone, which isn't necessarily the case either. It's uh uh it's really having enough of a plan to be able to do the next things that you need to be able to do. And uh which is really what we're where we started there with like the what is the what is the amount of certainty? What how much do we need to plan to be able to do the next pieces? Uh do we have a good enough understanding of what the interdependencies are going to be? Have we taken into account those pieces? Are we sufficiently uh are we sufficiently managing the upcoming risks that we might see uh with the plan that we have, or are we uh in a state where more planning might actually add benefits? Because I mean there's there's also uh this level of the diminishing returns. You uh you get to the point where any further planning isn't really actually helping you reduce the risk, you're just uh um sitting there moving boxes around on a page.

Yeah, well I I always like referring now to the the um uh my sporting metaphors are coming in again and my Canadian sporting metaphors, which I have to be careful with, because I've not played either of these sports in any meaningful way at all. But if you look at something like curling, where I can plan my next move and I can take the time and analyze and understand what things are because it's predictable, because it's stable, even static in terms of the situation and where I'm going to to what the move will be and what we're trying to achieve. Uh, planning is obvious there. The conversation around what we're going to do with the next stone, how we're going to play that is very obvious. What's less obvious is the planning that goes into a game like hockey. In hockey, once I put my skates on the ice rink, the plan that I had as I was putting my feet onto the ice rink changes almost immediately because somebody somewhere is trying to knock me off balance. The puck is nowhere close to where we thought it was, and you've got a couple of minutes before you run out of puff and you have to come back off the ice. So there's a lot of things there that make the idea of stepping on with a gant chart and a plan quite ridiculous. However, and and and I think this is, you know, I use that metaphor because it's so very different to an agile mindset and a planning mindset. But if you talk to the coaches behind the game, if you talk to the professionals in the game, there is a coherence, there is a plan. You don't just have coaches wing the game and come in and just go, just do the best you can. There is definitely a game plan behind this. So that brings us to that sort of appropriate level of planning. What level of planning is too much, and what level of planning is the right amount, but it doesn't say don't do any planning. Again, Agile Manifesto does not say don't plan. It says respond to change over following a plan. So have a plan, but don't get trapped into following that plan. Use the plan as a backbone from which you're going to adjust as you learn more, as you get feedback, as we make our way towards our end goal.

Yeah. And uh things like uh options are quite good. The real options is another nice way of looking at this too. Look for the points at which I can make a decision. Do I have enough information now to be able to uh decide what direction I'm gonna go in? And and then I can plan from there where I'm gonna go. And it as long as I've got sufficient confidence in where I'm going. And how do we measure that? Yeah.

I I I I hadn't thought about options, but I think that that's a really great way of looking at it because the again, as an agile mindset, there's a couple of things that really come to the why you know we like the idea of that real options in terms of what's going on. One of them is uh you can have multiple options in your hand. You don't have to have one. And I think from a planning process, too often we end up saying there is this one single plan, and this is the single plan we need to follow. What I like about the you know, looking at things from a view of options is now we can look at a range of different scenarios. And so we can have multiple plans. Brilliant. We've got more options there, more things that we can do. But then also the thought about when do we let go of that option? When do we when do we let go and say this is no longer an option, this is not anything we should keep on the table, put more effort into, whatever it might be. And I think that those sort of define that mindset. Many different paths forward and a continual focus on removing options from the table and probably bringing new options on the table as we learn more and explore.

Yeah, and that's and that's very much in that real options uh method around like you want to get, you want to create options, you want to meet so that you've got different paths you can potentially follow, and now you can decide which way should I go. So I've got so you're wanting to create those opportunities, and then that then gives you ways of moving forward and different ways of addressing. And so, yeah, th that was uh some of the things I I would say that I I got from it. Uh the I I'm I'm also uh I really believe that you've got to apply the right practices to the right spaces and the right types of problems that you're looking to solve. Um, and uh some of this comes from uh having a uh an infrastructure background and where if I'm I'm looking at if I'm looking at something like a data center move or building out a data center, I I mean I I I know I have to plan out certain things because things have to happen in a particular order, and uh, there are certain activities that will need to uh occur before others, and there is a point at which I'm going to have to flip the switch and turn one of these off and one of them on, and it's like there's kind of no going back typically at that point. So I've got so I can do what I can to try and make that as flexible as possible, to create options in that. And I so but the planning itself, I need a plan. I've got to have some form of plan to understand whether or not I can hit the targets or the constraints that I have. Uh but underneath that I can use um agile thinking and agile methodologies to help um adapt as things occur within that. So I'm not sticking to the plan. I'm creating options for how can I move forward. Uh, but I need the plan. I need to have some idea of the of the sequence and the dependencies and what things do I need to do in what order.

Yeah, and I I think uh it's um I think in many ways our as an if if you're trying to drive things from an agile context, we tend to look at individual teams and there are there is you know the planning around that. But there's a broader piece of how many teams working together are going to go forward. And there's a level of I mean, planning that any you know multi-million or multi-billion dollar business has to have in order to be able to function and go forward and spend its shareholders' um capital in the right way. There better be some sort of thought as to where it's going and and some paths that that allow us to go in those directions. So I think when we're looking at the plan piece of it, the tendency of ignoring the planning is unfortunate. We we definitely want to bring that more to the fore. What comes out more and more is this need for situational context and being appropriate with the level of planning that's there. And and I think it we talked, I think, last week about this sort of pendulum going backwards and forwards, and we need the right level of planning and we need the right level of options and agile mindset and thinking about flexibility and being adaptable to what we might be finding there. And of course, like any of these things, these are difficult places to get the pendulum in the right place.

Yes, because if uh well part of it is that the the environment and everything that that exists in is also changing at the same time. So you it's not set in stone, it's uh it's very much on a bed of shifting sand, it's gonna move uh all over the place, right? As the uh as the environment that you're operating changes, and especially the the larger, the more complex, the more dependencies, the more interactions, uh, then the the more uh different moving parts there are that are going to derail any kind of uh of planning or even planning methodology, like how much planning do I need? If if my situation suddenly gets much more complex for some reasons, then I'm probably better not planning as far ahead and starting to react more to the change as uh I encounter it.

Now, what about areas or things that you noticed where you go, oh, we've got to be careful there. Too much of that might be detrimental. Was there anything that jumped out in your observations?

Uh there was definitely some there were some interesting pieces where the the project manager was the the authority to end all authorities and he had uh he was almost dictorial in uh in their in the way they described it across the uh across the execution of the uh project, and they didn't w which all good project managers that um that I've ever worked with don't typically behave that way. But uh there was a lot of that in there which I I didn't think made a lot of sense. Uh things that uh according to the the what's in there on PMBOC, for example, the word breakdown structure is entirely generated by the project manager, whereas in an agile sense, something like a user story map would be a more collaborative exercise where the team comes together to map out what is the sequence independencies between the different pieces. So there's there's areas like that that I thought were kind of interesting. Um there is there is a lot of documentation, like everything is documented. Uh horrendous amount of documentation there. I think there's a there's a need to make sure that you're only doing as much as you you need to to communicate ideas and uh not necessarily the the huge um sort of masses of documentation that were required if you did every single little piece that was asked for there. Uh so those are the couple of the major pieces, I think.

Yeah, it's um I I couldn't agree more on the documentation. I think uh this is a really challenging piece because there's a safety in documentation in that project planning mindset, um, which which is uh often misleading if your environment is continually changing, of course. That's part of it. There are two other areas when I look at uh the sort of project planning mindset and and how that can negatively can conflict or or or um bounce against an agile mindset. And I think one of them is where I see a project management mindset trying to be agile. And so the one example that I come across all the time is uh rolling wave planning or or iterative delivery. And I I mean, great, these are great practices, but then they're not agile. The mindset around iterative and incremental delivery is significantly different to the idea of rolling wave planning or iterative delivery. Um, and I think uh it in instead of the Me Too piece of trying to say one is a little bit more of the other or less of the other, I think what we want to recognize is that project management, that mind that that context is for a very specific type of problem, predictive problems, which are stable and we have a lot of control over what's going on. Agile works in a different scenario, a different arena of problem spaces. And it just happens that complex problems are dramatically growing in the number of uh places that you see complex problems. So agile is dominating in those areas, but project management or project waterfall delivery is for a different context. And then the other bit that maybe is slightly related to that, but which can lead to huge amounts of misunderstanding is around estimation and committing to you know, this is going to take four hours or you're going to deliver on this date. And that is again an area that becomes very contentious, contentious because there are different expectations of how estimates are used in those different worlds.

Yeah, and that that uh thingy right now, that there was a piece where they did Agile at the end of the uh boot camp uh that had me shaking my head in a couple of pieces. One one was where they equated velocity into time bounds and used that to track teams' performance against each other, uh which I was like, no god, no.

Maybe that's a topic for a deeper conversation, I think, because because numbers matter, right? People need to be able to look at things and assess what's going on. It's just we're using estimates in a very, very different way when we have an agile mindset. Maybe in summary, I mean we're just coming up to our time box. What are the two or three things that you'd pull out from our conversation this week?

So I'd say that um project management is still valuable and key, and we've got to be careful that we don't like throw the baby out with the bathwater. Say that there are there's still a lot of value in those practices, and in fact, and for the for those predictor stable practices, it's the right way to do it. It's like this is these sort of there's a reason that all of this body of knowledge is being brought up. It worked very, very well for tackling those types of problems. Uh so that's definitely one of them. Um the making sure that planning is appropriate to the problem that you're solving, that you're doing the right amount of planning and don't over-plan, and that uh you're so you're applying the right practices in the right context in the right space. Uh, but planning itself is important. Uh the plans aren't necessarily valuable, but the the planning, the activity of coming together and understanding what is the work that we're going to do is absolutely essential. Um so anything you would add to that?

Uh no, I think so I think we we touched on a few things just to watch out for, and that's really where the two worlds try and cross over and intersect. And I thought your example of the misuse of velocity to try and create those team performance transparency into team performance is a good example. Don't try and use um waterfall project management methodologies in a space which isn't really appropriate because it's unpredictable, inherently rapidly changing or volatile. And equally don't use agile because it's a very costly way of doing things in a world which is predictable and much more under your own, it's stable and under control. So there's that piece as well, the overlap we've got to watch for.

Awesome. So thank you as always, Dave. I always enjoy these conversations. Um, if anybody would like to reach out to us, they can get us at feedback at definitely maybeagile.com, and we'll uh see you again next time. See you again next time. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Madison and David Sharrock, focus on the art and science of digital, agile, and DevOps at scale.