Generally speaking, you've probably heard it said to you that iterative planning is the right way to do software development.
And the justification for this is that iteration is agile, that it allows you to respond to change.
And we're not gonna get into the specifics of whatever process you're running at your team level, but I do wanna talk about this idea.
The dichotomy between iterative planning or exploratory engineering, exploratory development, where you may not have more than a sprint or two worth of work planned out versus something like target state planning.
Target state planning in some ways may look like a waterfall plan.
because target state is essentially laying out where you think things should go.
And this in some ways constrains the direction that your sprints might take, especially the initial direction.
And these two things may seem at odds with each other.
And in some purely doing iteration, then target state is a premature planning step in some ways.
However, they are not necessarily at two ends of a philosophy.
It is possible, for example, to update your target state as you learn things through your sprint.
But then you may ask, why would we need a target state to begin with?
The best answer for that question is that it allows you to set a general direction.
Think about your target state as more of a directional state in this kind of situation.
But I want to kind of go through the types of kind of decision factors that you might care about when you're trying to think through, okay, how do we want to plan our work?
And I wanna give you kind of a practical example of this.
Let's say that you have some software that you've already developed, a handful of services maybe, and they all talk to each other, and maybe you have downstream consumers, you're receiving data from an upstream source possibly, and you have a handful of problems, right?
Maybe your upstream data source is difficult to deal with, or intermittent for example, or maybe your API has performance issues.
The way that most teams approach this, this set of problems is as atomic kind of issues.
So we have the data problem and we have the API performance problem and we have X, Y, and Z.
And so we may take time to fix each of these problems as we believe they are high enough priority, for example, and this is kind of an iterative addressing of the issues that we have. And this is a valid way of working.
There's nothing necessarily wrong with it, but there's also other ways of thinking about this kind of portfolio of issues.
For example, take a metaphor.
Let's say you own a home and you're wanting to make an improvement, to the home.
You want to replace your windows, let's say.
This is kind of a crazy improvement to make, right?
Cut all of the windows out and replace them with casement windows.
So you make a plan to go through that process and then you get to the end of it and you realize, I'd like to make another improvement.
I think I'm going to change the siding on my house, I want to go from wood to a composite material.
And so you have the workers who finish the job and gave you the invoice, they have to write up a new invoice.
They have to come out and do a whole new set of work.
And then you say, you know what?
I actually think I'd like to do some interior work as well.
I want to upgrade my shower.
I want to go from a tub and shower to tile, right?
And so you keep on having these one off upgrades.
And maybe even you have different people doing each of these upgrades.
And at the end of it, it's very likely if you have enough of these jobs and certainly if you have jobs that look kind of similar to each other that may have, you know, finishing work that overlaps with each other, it's possible that you have different looking outcomes, That the finish on one job is a little different than the finish on another job.
And this kind of piecing together of improvements over time, the comparative version of this or the alternative that you might instead choose is to evaluate, okay, what are all of the things that I would like to do?
are there multiple improvements I wanna make all at the same time?
Given the idea that you could actually save money, setting aside that it's more efficient probably to contract with a single set of contractors that are all kind of coordinating, working together, you know, if they have all of the tools or the materials to do two or three jobs in the same uh kind of uh trip then they can coordinate and reduce the cost in that way right they also are likely to plan the features that you're looking for the improvements that you're looking for plan them to work better together right so if you're using white paint in one room and you want white paint in another room
they're going to match the type of white, they might match the the finish type better than you would if you were to do those rooms separately.
So the idea is that some upfront planning about that kind of job may be useful.
All right there may there may be a useful case for this so let's talk about some of the decision factors and that story should give you some idea of what the decision factors are.
are. When you might favor iteration planning, when there is high uncertainty, right?
If there's high uncertainty about the problem or about what the users need, then you might lean towards iteration.
And the reason for this is that you're going to be looking for what the users need through feedback.
And you're going to do that in either case.
But if you try to make a guess, a large guess about what users need or what the problem really is, then it's a more expensive guess.
It's a more expensive endeavor.
If you do have a lot of clarity on the problem, then that investment is more likely to make sense.
It's more likely to be correct.
So what's another decision factor?
The nature of the work.
The nature of the work.
if you are doing learning focused work, right?
If you're doing things like discovery, if you're building prototypes, proofs of concept, those kinds of, that kind of work is obviously more suited for iterative planning, for iterative and discovery type planning.
On the other hand, you might prefer target state planning if it is directly in production, right?
Or if you're already working on something in production, And something that has a lot of coupling would be another reason to favor target state planning because the decisions in one area have a strong impact and they constrain other areas.
So as you begin to iterate, you recognize that the dependency between those things is causing a larger design effort anyway, right?
You're taking on more risk if you do that without designing at a larger scale.
Regulatory safety risk sensitive contexts like aviation, healthcare, financial payment type systems, these are situations where you can't get half of the requirements in place.
There's regulatory requirements and you can't go halfway on that without incurring potentially even legal risks, right?
If you have fast feedback loops already in place, then you might favor iteration planning.
If you have good observability, if you have users that are that already are providing you feedback, then iteration may be a useful direction to go.
As a general rule, the more certainty or the more kind of stability that you have, The higher the cost of mistakes that you have, these are all things that would lend to target state, target state planning.
Higher costs of mistakes in this case means, you know, in your iterative planning, you may take a swing that is not super well thought out.
You didn't do a ton of discovery on it.
Instead of doing that discovery, you are learning through the process of shipping something and getting feedback and the cost of failure being very low in that situation is beneficial because you want to be able to fail in iterative planning.
So you're gonna ask a series of questions.
You're gonna ask, what type of problem are you solving?
Is it a discovery kind of problem?
Is it a POC? Are we scaling an existing system?
Are we building something that has a lot of clarity?
Are you gonna look at the cost of mistakes, right?
how painful is it to turn in the wrong direction?
You know, can we learn cheaply by shipping something and testing it right away, or is that, you know, is that cost much higher than we expect?
What is the scope of the impact?
Are you doing this work only within a single team, right?
The more people who are involved, the more likely it is that iterative planning is going to stall out, and you're gonna need to do a little bit more upfront design.
Feedback mechanisms, how fast can you learn, right?
How quickly do you get feedback?
For example, if your business operates with very long business cycles, if your customers have very long business cycles and you're not really gonna get a very high signal on whether your new features are very good or not, except at that year long scale.
and it's very likely that the feedback timing is a critical factor and you might want to lean more towards target state planning rather than iterative planning.
And then what is the coordination cost?
If the coordination cost is low, if it's all within a team, like we mentioned before, if you have your stakeholders that are local to you, if your ability to make these changes and test them and when we say this alignment cost, this coordination cost, it's not just about coordinating with your team, it's also coordinating with your users, it's coordinating with the resources that you're using, so if you have an external API that takes a long time to get some kind of change made on that API for example, these are all reasons why you may want to lean more towards a target state planning, whereas if the coordination costs
are very low, right, if you're, like I said, if your team is more local to you, there's not a lot of external dependencies, then you may lean more towards iterative planning.
Ultimately, it's a red flag, or at least a yellow flag, a warning sign, if you are choosing one of these by default, right?
It makes sense to consider how much upfront planning is useful.
And to not be afraid of that through some kind of dogma, that upfront planning is somehow going to limit you, right?
It's very possible that upfront planning is actually going to enable you.
And in either case, you should set yourself up so that as you learn things, you can adapt your plans.
Just following a plan because it's a big plan, because it's a target state is not a rational choice.
The reason why those upfront plans have received so much negative feedback is because the cost of building the plan itself, in many cases, the plan, the likelihood that the plan was correct was very low and it was costly to generate.
So changing that plan, there was a lot of friction to changing it because there's a lot of sunk cost in building the plan in the first place.
So a lot of the negative perceptions and perspectives of something like waterfall, in this case we're not really talking about waterfall per se, we're just talking about planning a little bit more upfront, the negative perception of that is driven primarily off of those early stage projects that would have benefited more from iterative approaches, that's not always true.
All right, that's not always true and it is a spectrum.
You shouldn't necessarily think that a target state has to be six months or six years down the road.
This is more of a spectrum than it is a pure dichotomy.
Thank you so much for listening to today's episode of DeveloperT.
I hope this was insightful.
I hope you will be able to think about your team and the way that you're planning these projects out, whether that's in your work, in your life, how much upfront design should you take on.
Consider these questions that we talked about today, and you're likely to make a better choice.
Thanks so much for listening.
Until next time, enjoy your tea.
