0:12

Generally speaking, you've probably

0:14

heard it said to you

0:17

that iterative planning is

0:19

the right way to do

0:21

software development. And the justification

0:24

for this is that iteration

0:26

is agile, that it allows you

0:29

to respond to change. And we're

0:31

not going to get into the

0:33

specifics of whatever

0:35

process you're running at your

0:38

team level. But I do

0:40

want to talk about this idea.

0:42

The dichotomy between

0:44

iterative planning or

0:46

exploratory engineering,

0:49

exploratory development, where you

0:51

may not have more

0:53

than a sprint or

0:55

two worth of work

0:58

planned out, versus something

1:00

like target state planning.

1:03

Target state planning in

1:05

some ways may look like...

1:07

a waterfall plan. Target

1:10

State is essentially

1:12

laying out where you think

1:14

things should go. And this

1:16

in some ways constrains

1:19

the direction that your

1:21

sprints might take,

1:23

especially the initial

1:25

direction. These two things

1:28

may seem at odds with each

1:30

other and in some ways they

1:32

are. Of course, if you're

1:34

purely doing iteration,

1:37

then target state is a

1:40

premature planning step in some

1:42

ways. However, they are not

1:44

necessarily at two ends of

1:46

a philosophy. It is possible,

1:49

for example, to update your

1:51

target state as you learn

1:53

things through your sprint. But

1:55

then you may ask why would

1:57

we need a target state to

1:59

be... with, the best answer for

2:02

that question is that it

2:04

allows you to set a

2:06

general direction. Think about your

2:08

target state as more of

2:10

a directional state in this

2:12

kind of situation. But I

2:15

want to kind of go

2:17

through the types of kind

2:19

of decision factors that you

2:21

might care about. When you're

2:23

trying to think through, okay,

2:25

how do we want to

2:27

plan our work? And I

2:30

want to give you kind

2:32

of a practical example of

2:34

this. Let's say that you

2:36

have some software that you've

2:38

already developed, a handful of

2:40

services maybe, and they all

2:43

talk to each other, and

2:45

maybe you have downstream consumers,

2:47

you're receiving data from an

2:49

upstream source possibly, and you

2:51

have a handful of problems.

2:53

Maybe your upstream data source

2:55

is difficult to deal with.

2:58

intermittent, for example, or maybe

3:00

your API has performance issues.

3:02

The way that most teams

3:04

approach this, this set of

3:06

problems is as atomic kind

3:08

of issues, right? So we

3:10

have the data problem and

3:13

we have the API performance

3:15

problem and we have X,

3:17

Y, and Z. And so

3:19

we may take, you know,

3:21

time to fix each of

3:23

these problems. as we believe

3:26

they are high enough priority,

3:28

for example. And this is

3:30

kind of an iterative addressing

3:32

of the issues that we

3:34

have. And this is a

3:36

valid way of working. There's

3:38

nothing necessarily wrong with it.

3:41

But there's also other ways

3:43

of thinking about this kind

3:45

of portfolio of issues. For

3:47

example, take a metaphor. Let's

3:49

say you own a home

3:51

and you are wanting to

3:54

make an improvement. to the

3:56

home. You want to replace

3:58

your windows. Let's say, this

4:00

is kind of a crazy

4:02

improvement to make, right? You know,

4:04

cut all of the windows out

4:07

and replace them with casement windows.

4:09

And so you make a plan to

4:11

go through that process and then you

4:13

get to the end of it and

4:15

you realize, you know, I'd like

4:17

to make another improvement. I think

4:20

I'm going to change the siding

4:22

on my house. I want to

4:24

go from wood to a composite

4:26

material. And so you have the workers

4:28

who... finish the job and gave

4:30

you the invoice, they have to write

4:32

up a new invoice, they have to come

4:34

out and do a whole new set

4:36

of work. And then you say, you

4:39

know what, I actually think, I think

4:41

I'd like to do some interior

4:43

work as well. I want to upgrade

4:45

my shower. I want to go from

4:48

a tub and shower to tile, right?

4:50

And so you keep on having

4:52

these one-off upgrades. And

4:54

maybe even... You have different people

4:57

doing each of these upgrades

4:59

and At the end of it

5:01

It's very likely If you have enough

5:03

of these jobs and certainly if

5:05

you have jobs that look kind

5:07

of similar to each other that

5:09

may have you know finishing work

5:11

that overlaps with each other It's

5:14

possible that you have different looking

5:16

outcomes right that that you're that you

5:18

know the the finish on one job

5:20

is a little different than

5:23

the finish on another job And

5:25

this kind of piecing

5:27

together, right, of improvements

5:30

over time, the comparative

5:33

version of this, or the

5:35

alternative that you might instead

5:37

choose, is to evaluate, okay,

5:39

what are all of the

5:42

things that I would like

5:44

to do? Are there

5:46

multiple improvements I

5:48

wanna make all the same time?

5:50

Given the idea that you

5:52

could actually... you know, save

5:55

money, setting aside that it's

5:57

more efficient probably to contract.

6:00

with a single set of contractors

6:02

that are all kind of coordinating,

6:04

working together, you know, if they

6:07

have all of the tools or

6:09

the materials to do two or

6:11

three jobs in the same kind

6:14

of trip, then they can coordinate

6:16

and reduce the cost in that

6:19

way, right? They also are likely

6:21

to plan the features that you're

6:23

looking for, the improvements that you're

6:26

looking for, plan them to work

6:28

better together. So if you're using

6:31

white paint in one room and

6:33

you want white paint in another

6:35

room, they're going to match the

6:38

type of white. They might match

6:40

the finish type better than you

6:43

would if you were to do

6:45

those rooms separately. So the idea

6:47

is that some up front planning

6:50

about that kind of job may

6:52

be useful. There may be a

6:55

useful case for that. So let's

6:57

talk about some of the decision

6:59

factors. story should give you some

7:02

idea of what the decision factors

7:04

are. When you might favor iteration

7:07

planning, when there is high uncertainty,

7:09

if there's high uncertainty about the

7:11

problem or about what the users

7:14

need, then you might lean towards

7:16

iteration. And the reason for this

7:18

is that you're going to be

7:21

looking for what the users need

7:23

through feedback. You're going to do

7:26

that in either case, but... If

7:28

you try to make a guess,

7:30

a large guess, about what users

7:33

need or what the problem really

7:35

is, then it's a more expensive

7:38

guess, right? It's a more expensive

7:40

endeavor. If you do have a

7:42

lot of clarity on the problem,

7:45

then that investment is more likely

7:47

to make sense, right? It's more

7:50

likely to be correct. uh... so

7:52

uh... what what another another decision

7:54

factor the nature of the work

7:57

the nature of the work if

7:59

you are doing learning focused work,

8:02

right? If you're doing things

8:04

like discovery, if you're

8:06

building prototypes, proofs of

8:08

concept, those kinds of,

8:10

that kind of work

8:12

is obviously more suited

8:14

for iterative planning, for

8:17

iterative and discovery type

8:19

planning. On the other hand, you

8:21

might prefer Target state planning

8:23

if it is directly in production

8:26

right or if you're already working

8:28

on something in production Something that

8:30

has a lot of coupling would

8:33

be another reason to favor target

8:35

state planning Because the the decisions

8:37

in one area have you know strong

8:39

impact and and they constrain other

8:41

areas so as you begin to

8:44

iterate you recognize that you know,

8:46

the dependency between those things

8:48

is causing a larger design

8:51

effort anyway, right? You're taking

8:53

on more risk if you

8:56

do that without designing at

8:58

a larger at a larger

9:00

scale. Regulatory, safety, risk-sensitive contexts

9:03

like aviation, health care,

9:06

you know, financial payment

9:08

type systems. These are

9:10

situations where you can't get

9:12

half of the requirements.

9:14

in place. There's regulatory requirements

9:17

and you can't go

9:19

halfway on that without incurring

9:22

potentially even legal

9:24

risks, right? If you have fast

9:26

feedback loops already in place,

9:28

then you might favor iteration

9:30

planning. If you have

9:33

good observability, if you have

9:35

users that are that already

9:37

are providing you feedback, then

9:39

iteration may be a useful

9:41

direction go. As a general

9:44

rule, the more certainty

9:46

or the more kind

9:48

of stability that you have,

9:50

the higher the cost of

9:53

mistakes that you have, these

9:55

are all things that would

9:57

lend to target state.

10:00

All right, target state planning, higher

10:02

cost of mistakes in this

10:04

case means, you know, in your

10:06

iterative planning, you may take

10:08

a swing that is not super

10:10

well thought out, right? You

10:12

didn't do a ton of discovery

10:14

on it. Instead of doing

10:16

that discovery, you are learning through

10:18

the process of shipping something

10:20

and getting feedback and the cost

10:22

of failure being very low

10:24

in that situation is beneficial because

10:26

you want to be able

10:28

to fail in iterative planning. So

10:30

you're going to ask a

10:33

series of questions. You're going to

10:35

ask what type of problem

10:37

are you solving? Is it a

10:39

discovery kind of problem? Is

10:41

it a POC? Are we scaling

10:43

an existing system? Are we

10:45

building something that has a lot

10:47

of clarity? You're going to

10:49

look at the cost of mistakes,

10:51

right? How painful is it

10:53

to turn in the wrong direction?

10:55

You know, can we learn

10:57

cheaply by shipping something and testing

10:59

it right away? Or is

11:01

that cost much higher than we

11:03

expect? What is the scope

11:06

of the impact? Are you doing

11:08

this work only within a

11:10

single team, right? The more people

11:12

who are involved, the more

11:14

likely it is that iterative planning

11:16

is going to stall out.

11:18

You're going to need to do

11:20

a little bit more upfront

11:22

design. Feedback mechanisms. How fast can

11:24

you learn? How quickly do

11:26

you get feedback? For example, if

11:28

your business operates with very

11:30

long business cycles, if your customers

11:32

have very long business cycles

11:34

and you're not really going to

11:37

get a very high signal

11:39

on whether your new features are

11:41

very good or not, except

11:43

at that year -long scale, it's

11:45

very likely that the feedback timing

11:47

is a critical factor and

11:49

you might want to lean more

11:51

towards target state planning rather

11:53

than iterative planning. And then what

11:55

is the coordination cost? If

11:58

the coordination cost is low, if

12:01

it's all within a team, like

12:03

we mentioned before, if you have

12:05

your stakeholders that are local to

12:07

you, if your ability to make

12:09

these changes and test them, and

12:12

when we say this alignment

12:14

cost, this coordination cost, it's

12:16

not just about coordinating with

12:18

your team, it's also coordinating

12:21

with your users, it's

12:23

coordinating, you know, with

12:25

the resources that you're

12:27

using. if you have an external

12:29

API that takes a long time to

12:31

get some kind of change made

12:33

on that API, for example, these

12:35

are all reasons why you may

12:37

want to lean more towards a

12:40

target state planning, whereas if

12:42

the coordination costs are

12:44

very low, right, if you're, like

12:46

I said, if your team is

12:48

more local to you, there's not

12:50

a lot of external dependencies, then

12:53

you may lean more towards iterative

12:55

planning. Ultimately... It's a

12:57

red flag, or at least a

12:59

yellow flag, a warning sign, if

13:01

you are choosing one of these by

13:04

default, right? It makes sense

13:06

to consider how much upfront

13:09

planning is useful, and to

13:11

not be afraid of that

13:13

through some kind of dogma,

13:15

that upfront planning is somehow

13:17

going to limit you, right? It's

13:20

very possible that upfront

13:22

planning is actually going

13:24

to enable you. In

13:26

either case, you should set yourself

13:29

up so that as you learn

13:31

things, you can adapt your

13:33

plans. Just following a plan

13:35

because it's a big plan,

13:37

because it's a target state,

13:39

is not a rational choice,

13:41

right? The reason why those

13:43

upfront plans have received

13:46

so much negative feedback is

13:48

because the cost of building

13:50

the plan itself, in many

13:53

cases, The plan, the likelihood

13:55

that the plan was correct

13:57

was very low and it was.

13:59

to generate. So changing that plan,

14:02

there's a lot of friction to

14:04

changing it because there's a lot

14:06

of sunk cost in building the

14:08

plan in the first place. So

14:10

a lot of this, you know,

14:12

a lot of the ideas that

14:15

you hear are the negative perceptions

14:17

and perspectives of something like waterfall.

14:19

In this case, we're not really

14:21

talking about waterfall per se, we're

14:23

just talking about planning a little

14:25

bit more up front. The negative

14:28

perception of that is driven primarily

14:30

off of those. You know, there's

14:32

early stage projects that would have

14:34

benefited more from iterative approaches. That's

14:36

not always true. All right, there's

14:38

not always true. And it is

14:41

a spectrum, right? You shouldn't necessarily

14:43

think that a target state has

14:45

to be, you know, six months

14:47

or six years down the road.

14:49

This is more of a spectrum

14:51

than it is, you know, a

14:54

pure dichotomy. Thank you so much

14:56

for listening to today's episode of

14:58

Developity. I hope this was insightful.

15:00

I hope you will be able

15:02

to think about your team and

15:04

the way that you're planning these

15:07

projects out, whether that's in your

15:09

work, in your life, you know,

15:11

how much up front design should

15:13

you take on? Consider these questions

15:15

that we talked about today, and

15:17

you're likely to make a better

15:20

choice. Thanks so much for listening,

15:22

and until next time, enjoy your

15:24

team.