S3:E03 - Timeboxing

Péter (2): Hello everyone.

Welcome back to The Retrospective.

As you know, this is an engineering leadership podcast where we give

advices and share our experience, on engineering management and

engineering leadership topics.

With me here is our regular host, Jeremy.

And I'm Peter , the co-host, and for new listeners, we have a format where

we are focusing every episode on one single topic targeted at engineering

managers and technical leaders who are interested in generic leadership topics.

This time, it was on Jeremy, on you to bring a topic.

So I'm curious, what did you bring to us?

Jeremy (2): Yeah.

it's great to be here with you, Peter.

the topic I wanted to talk about is, something near and dear to my

heart, which relates to delivery.

delivery is one of the key things that, engineering managers are

responsible for, the topic I wanted to talk about was really.

focusing on time boxing and using time boxing as your main

method to manage, delivery.

Péter (2): Awesome.

What is time boxing?

Jeremy (2): Well, it's not time blocking... fundamentally.

Time boxing is a principle, that you then apply.

the principle of time boxing, basically, is that you block a period of time

to do a task or a project, and you stick to that timeframe basically.

In a project, normally you have what you're gonna do, and you have the timeline

and you have maybe the people as well.

And so what you actually do is you fix the number of people.

ideally you fix the time, but you allow the scope to change in time boxing.

in traditional project management, you are actually, Usually having variable, scope.

'cause as you build you do more and you may also try and add

more people or do other things.

So time boxing is really trying to limit, and then still deliver something.

the principle of time boxing is really well known to most people because,

when people say they're working in agile and they're often using

sprints, one week sprints, two week sprints, whatever, and time boxing is

a fundamental principle of sprints.

Péter (2): so this is basically like scrum sprints rebranded in a different way.

Jeremy (2): Important thing is to understand that this is the

principle behind sprints then, to understand the power of that.

And then, all I'm saying is, when you're doing projects, I would suggest

that you apply this principle to your projects as well, even if you're using

sprints as part of your delivery.

or you could be using Kanban or whatever.

the idea that I'm proposing is that you apply time boxing to the bigger level

projects and not just to your sprint or whatever that you're already doing.

Péter (2): Okay.

maybe we can get into a little bit deeper about the problems this is solving.

Like, how do you diagnose traditional project management and how time

boxing is solving those problems, or what are the problems it's solving?

Jeremy (2): Yeah.

so I think what I see a lot of companies doing, and a lot of places

I've worked in, is some element of, been called water scrum fall.

So kind of like, high level.

planning process and project planning process that's kind of waterfall.

a lot of high level requirements, documents, design documents,

pre-plan out, big project.

And then you do, scrum, as a kind of approach to each

your way through that project

Péter (2): like a way to manage the work that was predetermined.

Jeremy (2): Exactly.

And then we just see how much of that we pull into this sprint.

We plan it out.

maybe we allow some time in the sprint for run activities that are regular stuff that

comes up, people's holidays, et cetera.

But you are, you're basically.

biting your way through the project backlog that you already pre-planned.

And then

Péter (2): Mm-hmm.

Jeremy (2): on your release process, you may also have a waterfall release.

you may be hopefully deploying regularly or on demand.

But, there can often be even a waterfall release approach to.

the actual project going out.

I think the problem with that approach that when you do a

project, when you do some work.

discover I need to make another decision here As I encounter something,

I learn something as I do the work.

And what you discover is, oh wow, there's this five more things

I need to do or this extra edge case that I need to take care of.

so as you do the project, your backlog of the project is expanding.

It's not getting smaller, it's getting bigger.

And there's all these new ideas that you have.

And then you go down this rabbit hole and you build this extra thing.

And, um.

Your project exploded.

And what happens is that business is saying, why is this taking so long?

You're not delivering any results.

Um, and, and like, we all get fixated on, oh.

You know what?

I learned all these new things and I can't release this now

because it's not perfect anymore.

I have a fear based on, oh, I wish I could just polish this thing

a bit more before I release it.

we get dragged into all of these perfectionist tendencies as well.

And then we try and do lots of crazy things in organizations.

Like we have even more detailed estimation.

Let's estimate out the whole project with story points.

do super advanced, capacity planning for the quarter where you take all of your

projects highly detailed estimates I keep getting challenged on why is that a

large, so I need to go to a super detailed estimate to explain why this is large.

I spend so much time planning and building the infrastructure around

my delivery and I'm actually spending less time on the value delivery part,

the thing that makes a difference for the customer or for the business.

Péter (2): Yeah.

. software development is a creative work, by nature.

If you want a hundred percent precise estimates, you need to do the wall work.

you need to face those hard problems.

it's just absurd because, you have a six weeks project and the

first four weeks you estimate if you can fix into it or, or, or.

Fit into it or not.

that's a typical problem and the solutions we come up with sometimes

are also typical, like, delay the project, delay the release, increase

the headcount, to try to fit into the deadline or wrong solutions.

Jeremy (2): Add another person.

This is like a super, I think I've got it right next to me

on the shelf, but you know, the mythical man month, you know, let's

Péter (2): Yeah.

Jeremy (2): some more people at it.

It'll go faster.

The reality is throw more people at it.

They have to have more context.

There's more communication needed in the project.

We go slower, so.

Péter (2): Yeah, yeah, yeah.

Exactly.

Exactly.

Jeremy (2): Yeah.

Yeah.

Péter (2): Yeah.

Jeremy (2): this is why

Péter (2): Why I, I,

Jeremy (2): I really prefer,

Péter (2): prefer.

Jeremy (2): as an approach because, it's based on this other idea,

from what's called a Parkinson's law, which is basically that work.

Expands, to fill the time allotted to it.

and time boxing inherently acknowledges that.

And it works with the fact that that's what happens.

so I think it's a way to, Reduce the amount of things that you have to do and

get to, more of an incremental shipping value and learning, in smaller chunks.

In a, in a, in a lighter weight way, I would say.

You, you can potentially, and, and maybe controversially, you

could get rid of story points.

You could, I mean, potentially it, I think it's an enabler for

Kanban, potentially as well.

I mean, you choose the method that works for you in the end.

I don't really think it matters if it works for the team, but it definitely

Péter (2): They're definitely around.

Jeremy (2): Force yourself to get something out the door and,

I think it's a forcing, I think that that's the main thing.

It's a forcing function, a lighter weight forcing function to get stuff done.

Yeah.

Péter (2): I would like to make this very explicit, like you have these three

variables, the time, the scope, and the resources, like how many people you have,

and you make a very conscious decision that you're just gonna put a pin on

the time, like that's gonna be fixed.

Everything else.

I mean, resources don't change, I guess so.

Jeremy (2): yeah, you

Péter (2): 'cause.

Jeremy (2): re the people as well.

I would definitely say you try and fix two variables out of the three.

Péter (2): Okay, so, but this means that there is a lot of flexibility

on the third because projects are changing, we have new information.

so I guess this is what time boxing is like, let's put aside resources

now and consider fixed teams because, a lot of organizations don't change

teams around, in the short term.

you have two variables, the time and the scope, and you say.

I'm gonna fix the time and let's see what happens, right?

So this is time boxing essentially,

Jeremy (2): That's exactly it.

Péter (2): and I.

Jeremy (2): like a couple rules related to this to make this work.

which is that whatever time box you set, you need to ship something.

You don't expand the time box.

Like our initial feeling is always, oh, so close to this time box.

Péter (2): I just had one more day, like I even saw people working on weekends.

Just to finish the Friday stuff during the weekend because

it's such a strong pressure.

Yeah.

Jeremy (2): Weeks are kind of an inherent time box that we've

created as humans for ourselves.

Uh, we, we don't always recognize that.

And the day is a time box that, you know,

Péter (2): Yeah.

Jeremy (2): time box that nature imposes on us.

Péter (2): Hmm.

Jeremy (2): the moments in between meals are time boxes that nature imposes on us.

what I like about this rule is it's a forcing function for the

conversation about what scope do we cut and, ideally as early as

possible to still make the time box.

so I think that's like the first rule.

Péter (2): Quick question on this.

yeah, really something before the time box ends.

That's, that's the first rule.

Why is there so much emphasis on releases?

, Cannot we say that, okay, we are done with this task, this is ready for release, but

maybe we have some, regulatory reasons.

Maybe there are training materials that needs to be done.

not every organization can just quickly release something, to the wide.

Maybe there are on-prem clients and, and so why is this emphasis on release?

Jeremy (2): I think I'll answer this by giving you the second rule of the

Péter (2): Sorry for interrupting.

Jeremy (2): it's okay.

No, no, it's really, it's valid, right?

so the second rule is you get to the end of the time box no matter what.

You stop working and you review your progress and you look back and you

retrospect and you say, what did we learn?

The reality is that,

can mean lots of different things depending on what you're doing.

It could be, that we put the dock out for a review.

it could be that we have a prototype, that we can do some user testing with it.

It could mean that we have it.

And it's not ready to be turned on in under feature flag

with users, but it's there.

the really important part is you reflect at the end of the

time box of what you learn.

And then there's another part of it, which is, you ask yourself,

do we spend more time on this?

Is this worth still spending more time on?

And then you allocate another time box, towards the activity

if you feel like that is because.

The reality is that most projects, require multiple time

boxes, to get the end result.

But, from an engineering perspective, I would say maybe there's a third

rule I could add, which is no.

project Time box should be bigger than six weeks.

Péter (2): Mm.

Jeremy (2): which means

Péter (2): That's more like a practical implementation thing, right?

Jeremy (2): yeah, but I think a lot of projects like that we do,

they take a quarter, you know?

Péter (2): Yeah.

Jeremy (2): want people to work in smaller, time boxes within that.

Even though we all say, yeah, we want to keep working on this.

it makes us reflect back and say, well, okay.

gonna need to do another six weeks on this.

What is the outcome that we want at the end of that six weeks?

And rather than just running for 12 weeks for something, uh, and then thinking

about it, it's really having that kind of like, that, that reflective moment.

and this goes back to the other part that I think on a high level part

of, of time boxing, which is that you use time boxes like this, of.

what are we going to do, for the quarter, and then doing this heavy

capacity planning and saying, okay, I can do this Tetris of these projects,

and then this combination of projects so I can commit to these goals.

You can say priority one is this.

Priority two Is this priority three?

Is this priority one?

I'm gonna spend two six week.

Time boxes on it with, two people of, of, or three people of the team in it.

Priority two, I'm going to do, a six week project with two other people and priority

three, I'm gonna do a spike of two weeks time box to learn something about it.

your planning becomes appetite and priority based upfront, and is so much

simpler your scope is gonna change.

And you have some ambitions in the goals and so on.

, But, , you don't have to do all this complex Tetris

planning, which is all in a way.

Anyway, it's all finger in the air stuff.

Right.

You never really, I mean, no.

Estimates are really, I don't like, I think as an industry

we're moving away from estimates.

so yeah.

Péter (2): Okay.

I really like two aspects of what you were saying.

one is that, to answer my question, why is there an emphasis on releasing something?

And it really ties to the second rule about, stopping when the

time sends and reviewing progress.

and the key insight for me is that.

In order to efficiently review the progress and learn from what you

did, you need outside feedback.

you need to get something from the outside, from your users, your

colleagues, your sales team, whatever.

And this is why releasing something, getting something out

of the scope of the team and, to increase, the value of feedback.

And, and the second thing I really liked is you were talking about outcomes.

it's, I think it's really, like I had an experience earlier when I was

leading platform teams and, we wanted to try, cloud development, tools.

But we called the whole initiative improving the local developer experience.

And one of the spikes was only to figure out, if cloud development is

mature, mature enough for our goals.

And it was really good because we found out that no, it's not, and

actually the problems are in different areas in the development pipeline,

and we could focus on that without having to change the project or go

into a rabbit hole of implementing something that was not needed.

So because the outcome was improving the local developer experience.

We had the freedom to experiment with various stuff.

Jeremy (2): Exactly.

And, I think if we move on to like, what are the practical kind of ways

Péter (2): Yeah, yeah.

Yeah.

Jeremy (2): I think this is a really good segue into that because, I would give some

very high level guidance on this, which is you have a project or an initiative.

Divided into six week chunks.

So maximum six weeks, Why six weeks?

I think six weeks is just about long enough to really build something

relatively significant and ship it.

it's interesting because that kind of time box has emerged from multiple places.

it's actually interesting 'cause it's part of the Shape Up approach where they

work in these six week cycles and then a cool down Shape Up really focuses on the

whole org working on a rhythm like that.

and that can work.

but there's other companies as well, I think have blogged about

this kind of six week time box,

I can't remember.

I think it might be Intercom and a couple others that have put it out there.

It seems to have emerged as something that that's reasonable.

you can fit a few of those into a quarter, and so on.

So I think it works, well as like your upper time bound

for an increment of a project.

It is kinda like turtles all the way down.

it's kind of like a time box.

We talked about setting an outcome for what am I trying to achieve?

a guidance for what you should have as an outcome is a change in human

behavior that impacts business results.

Péter (2): Unplug that a bit.

'cause there, like, I feel like this is those kind of sentences where

every word has a reason to be there.

So just briefly, it's a short rabbit hole, but I'm curious

Jeremy (2): Changing human behavior.

So human behavior is measurable.

It's something that you can measure, you know, users are able to do this

thing or users do this thing, and you can measure, like ship a feature

Péter (2): before,

Jeremy (2): the

Péter (2): but it's the feature, it's gonna

Jeremy (2): a behavior

Péter (2): behavior.

Jeremy (2): a behavior.

So you should be able to measure that at some point afterwards, right?

linking it to business results.

So it has to have an impact, right?

It's not just a random thing.

now.

Engineers can get really hung up on this, especially on technical things,

but I think that human can be internal.

can be, , the, the going faster, giving feedback.

It can be, we spend less time investigating flaky tests.

Péter (2): Yeah.

Jeremy (2): can

Péter (2): Yeah.

Jeremy (2): so, you know, like I, I do think this, this, this kind of outcome

approach, it's really important.

It's not ship a feature or ship this much of a feature.

so I think it's important.

Then the second part.

Breaking this down is you don't just have the six week time box if

that's your max or, or whatever.

You need to chop that up into some time boxes.

I like to say maximum two weeks of, and those are milestones, right?

but if you can do one week this outcome, and again, those are

outcome, outcome, outcome, right?

so that's why I say

Péter (2): And shipping, shipping, shipping.

Also like you want teams to ship something at the end of a milestone also.

Jeremy (2): Do a demo.

Ideally, you should be merging your code every day, and it should be going into

production, but maybe you're under a feature flag, some of those milestones we

can actually, turn something on for users or, we can, enable in beta or we can do a

user test with the mocks that we've done.

But like, those are all shipping that we can do.

But yeah, those one, two week milestones really important also.

So you're, you're not just doing the forcing function at the

top, you're doing it all the way through, because what happens is.

If you don't do that, as you do work, oh, there's this other really interesting

thing that I need to do, you get diverted and you do this really interesting,

important thing, but you lose sight of the outcome I was trying to achieve,

which didn't need this thing to happen.

And I could have either stuck it in the backlog, I could document that we

should really look at this or whatever.

But like, if you can get from A to B. And maybe that's, you'd have

this conversation, the project.

Wow.

I'm only gonna be able to do Happy Path.

the scope, right?

That's a scope conversation.

You're having a conversation about the scope, but you're

obsessively focused on trying to hit the outcome of the milestone.

so that's, that's really important.

I do think then the other practical guidance I'd give is

names of your milestones and your your time box need to have.

Clear kind of outcome based naming.

So they don't just call it like technical things or A B, C, D or 1, 2,

3, 4, milestone 1, 2, 3, or whatever.

No.

Make it meaningful for someone looking at your project plan to understand and

like, what are you trying to achieve?

and then this goes to the final part, I would say, which is, visualize, create

the visualization of your progress.

that means like showing like on a high level your project plan, the

milestones, your progress, that, that can be Kanban, like a board

that you have in the team and so on.

But like visualizing, the project, projects together,

the time boxes together.

and

Péter (2): Yeah.

Jeremy (2): earlier, the really important thing in this is having a

conversation when scope starts to creep, D

Péter (2): Yeah.

Jeremy (2): Aggressively on the milestone that you're trying to

achieve, put it into the next time box for the project, as like, okay, this

is the extra things we need to do.

We got to the end of the time box.

We, over the project, six weeks, we realized actually we only

were able to build happy path.

We learned all these other things.

We definitely need to be able to do a second time box of two weeks

to make this something that can actually be turned on for users.

Great.

We learned a lot.

we still have an aggressive time box, which means that we need to get over

perfectionism and, the fear of shipping.

Péter (2): Yeah.

I really like this, I feel like this technique addresses the

inevitable, that scope is changing.

Things happen.

There's an incident in the middle of your sprint that takes a week

to resolve all kind of things, and acknowledging that these diversions

and unplanned things will happen.

It creates a recipe for how to handle those, and the recipe is

don't push the deadline, don't push the end of the time box out.

Because that's just gonna have verse implications.

Focus on the scoping and releasing something and get those learnings,

get those feedbacks so your next time books can be more valuable and

Jeremy (2): Yeah,

Péter (2): and deliver results more aligned with business goals.

Jeremy (2): exactly.

And I think that the thing I would add to that is the other thing that

comes up when you're working is new stuff, new project, new thing.

And what time boxing allows you to do is to say we could do that when

this time box ends in two weeks.

Instead of pausing projects halfway and coming back to them, you say, let's,

okay, uh, is it okay if we start that in two weeks when this time box ends?

We have a natural point that we've forced our project to

end we can insert a new thing.

Péter (2): Perfect.

Jeremy (2): doesn't, it's less, I feel like it's less disruptive.

'cause you took your project to a natural.

Point that you aimed for from the beginning rather than a

pause at 80% done or 60% done and come back to it in two months.

so it allows you to do reality of engineering is I

had to do this extra thing.

yeah, and like in your example where you have an incident that took a week out

of the project, have to just slip of the outcomes that you're able to achieve.

Oh, we didn't work on that milestone for a week because of this instant.

Um.

re, we pushed stuff out.

The time box achieved less, but Okay.

You know?

Péter (2): I, I really like the aspect also that you mentioned with ShapeUp, that

it creates a predictable rhythm that can be extended to other departments also,

like if marketing knows that there is this six week cycle, if sales support, no.

Product management very important.

like product managers can reliably expect that after the end of six weeks, I can

rely on getting some kind of learnings that I can use in my next planning or

next, steps of coming up with features.

Yeah.

I like this predictable organization wide rhythm that this creates.

Jeremy (2): yeah, what I'm not arguing for here, 'cause ShapeUp has.

This kind of company rhythm, which is six weeks, two weeks, cool.

Down and, and then you have like, what are the things that we work

on in that six week time box?

I'm not arguing for that to be honest.

I think one of the issues with Shape Up that some companies have found

that engineering is too locked in that six week period and we need other

Péter (2): Yeah.

Jeremy (2): In a specific con context of Basecamp, the company their products

Péter (2): is like the Spotify model,

Jeremy (2): yeah.

Péter (2): right, the old famous model like that worked for them in those times.

Jeremy (2): I think the things that you need to learn from shape Up.

Extract the principles.

This principle of maybe six weeks

Péter (2): Technically

Jeremy (2): time bound for your project

Péter (2): you don't have to follow it all.

Jeremy (2): definitely don't force my teams to work in all six weeks.

Some projects are two weeks with a two week time box, and it's more about

Péter (2): more about,

Jeremy (2): might have three projects in flight or two projects in flight.

with different timelines,

Péter (2): mm-hmm.

Jeremy (2): and they may have different periods of cool down and so on in between.

I think it's very hard to

Péter (2): Very hard to.

Jeremy (2): whole engineering or whole company rhythm like that.

if it works for you, it works for you.

Péter (2): Yeah, I guess it's a secondary benefit.

Like if it works great, it's a nice to have, like, okay.

I'm trying to be mindful of time.

I have a quick question and then we should move on to how this goes wrong

and what are the pitfalls to avoid.

So my question is that, that, you seem to be downplaying the

importance of estimations, agreeably.

Like, we all know that they are never right.

But in order to figure out what you can fit into a time box, you need some kind

of estimations, you need some story points or t-shirt sizes or something.

So how do you resolve this conflict of estimations?

Nah, they, it's a waste of time, but on the other hand, I need to figure

out what to fit into the time box.

Jeremy (2): I think it's

Péter (2): I think it's much easier.

Jeremy (2): to say, these are my priorities, stack ranked.

Péter (2): Mm.

Jeremy (2): think it's much easier to say priority number one.

In my opinion, I would spend this much time and this many people

during that time box on it.

and to work with your planning on an appetite based approach,

based on priorities, and say, no.

Number three, we need to do something on it.

We can't just have number one take over everything, I only want

you to spend two weeks on it.

Péter (2): Mm-hmm.

Jeremy (2): And I just

Péter (2): Mm-hmm.

Jeremy (2): spike and learn this thing.

Maybe it's going to inform the next quarter, right?

But we need to be able to have done that to go into the next quarter.

if you're working in this way, you need to have, some basics, like

being able to ship really quickly.

Time boxing goes all the way down to the tasks that you plan, like

planning tasks breaking down.

You should be able to break down the tasks that you're going to do

in the current week or whatever into A task that takes a day max.

basically you are, decomposing your work.

um, ultimately this goes more to the kind of idea of counting the number of tickets

to see your, velocity and you plan and break down your work into small enough.

tasks.

You break everything down into one story point size whatever, like small

size, whatever that is for you and you.

And then you just count those and, and in a way you still can calculate your

velocity, uh, or you can predict it.

But, um, the whole point of time boxing is that you're more saying, okay.

first time box in this, uh, the first milestone time box in this project, of six

weeks is um, we're gonna have a kickoff.

We're going to have a, a planning session together.

We're going to align with the stakeholders.

We're going to have a draft a design document and a PRD.

That, or whatever it is that you're going to do.

then in the second milestone, we're gonna finalize that and finalize the plan.

And we'll also have done these two spikes that we know we need to do.

And actually, your milestones might evolve.

You might have only planned the first two milestones of the six weeks,

and then milestone three might be two weeks because you have to build.

And this thing and happy path and you are a CI or whatever

it is that you need to do.

And then the final, bit might be to just get to the ship, a final outcome of that.

Right?

So the whole process is very different.

Péter (2): Yeah, I like that.

what I'm hearing also is that this process acknowledges the time

needed to do proper estimations.

And actually puts it into the first phase of a time box.

it's not expecting you to come up with estimations, off the top of your head.

It involves the whole team to do the spikes, as you said.

do some design documents, planning, validating, and not focusing on this

simple question of how long does it take to build a newsletter for my site.

Jeremy (2): Yeah, exactly.

the whole planning process becomes so much easier.

Péter (2): Every engineer has been there, I think, who was asked to make an

estimation that this very uncomfortable feeling that I'm just bullshitting here.

Like, I have no idea to know exactly how long will it take, because there

are just so many unknowns and it would be easier to just do the damn

thing and measure how much time it took than trying to estimate it.

Jeremy (2): process is, oh, we need to do quarterly planning right now, and

we have these things that we could do.

Let's really quickly estimate out the size of these different things that we need to

do, which we know then the stakeholders are gonna challenge in the, in

Péter (2): Yeah.

Jeremy (2): quarterly planning meeting.

And then, uh, we're gonna do Tetris.

With those based on what we argue of the actual site, what

we think, and the stakeholders.

Now that's easy.

Why are, why is that so big?

You know, I and so on.

And uh, then you have this kind of like back and forward and you Tetris

plan the quarter and then you're

Péter (2): Yeah.

Jeremy (2): and then you feel like you're failing the whole quarter because

as you go you've maybe done an upfront project plan already, but it's still.

Péter (2): It's still in your head like it didn't meet reality.

Alright, let's talk about common pitfalls.

Like what are the risks with this process and how to avoid them.

Jeremy (2): Yeah.

let's do this rapid fire.

Time boxes being treated like a deadline and having kind of like a death march

like you just mentioned that, you know, people working or you earlier

about weekends to meet the deadline for the Friday, what we said we would

Péter (2): Yeah,

Jeremy (2): or whatever.

I think like the important part is.

the conversation about the variable scope as early as possible

and focusing on the outcome.

so of course time boxes are forcing function, right?

And that's the whole point.

Like there will be a sprint

Péter (2): be.

Jeremy (2): towards, ah, like this afternoon, I'm just racing to

get this thing so I can ship the demo, but that's okay actually.

but if you're, you know, like, and that's the whole point of the time box, but it

can't, it can't be like that all the time.

so that, that, that, that also comes from being super rigid.

rather than using your judgment, having conversations,

conversation is so important.

I would argue that like at each milestone or like some kind of cadence

in the team as well as at the end of the project, you do retrospectives.

and it would also say like, that cooling off period in between, you

know, like over, like not, not putting enough slack and, and, not having

sometimes a buffer in between, some of the bigger project time boxes that

you're doing, I think is, is a problem.

and like this takes time.

you're not gonna be landing this the first time you do it.

It's probably gonna feel a bit like a car crash, until you've

done like a few of these and then you start to get into your rhythm.

so it's kind of like a, it's like a steep learning curve, to, to adapt to this.

And frankly, biggest learning curve isn't just the team, it's the leadership

in letting go of this upfront planning, deep estimate conversation and so on.

Ultimately, I think for leadership it is liberating because you're able to

more easily adjust direction during the quarter because it's always

leadership that is throwing stuff in.

Péter (2): Yeah,

Jeremy (2): but it, it's hard.

It's hard and,

Péter (2): it.

Jeremy (2): all the time,

Péter (2): it, it's interesting that you mentioned leadership.

I had a talk with a CT of a tech startup.

I was considering, consulting them.

and the main problem they brought me was that, in the last two years we missed

all of our deadlines, like no exceptions.

And what can we do to meet those deadlines?

And I was asking.

What if the, the, the consequences, the the opposite.

Like, why don't you abandon deadlines?

why do you need internal deadlines?

and the guy just didn't understand.

I mean, probably I did a bad job explaining this concept, but, it

was weird to me that, something is not working, but they keep on doing

this, doing this and, and beating themselves up that is not working.

Jeremy (2): and it is funny 'cause in that scenario I would say, if

you made your deadlines fixed?

fixed capacity, fixed time, variable scope.

Then you're actually

Péter (2): Yeah,

Jeremy (2): boxes, you

Péter (2): Plus the, it's guaranteed that you're not gonna miss the

deadline because you didn't say what you're gonna deliver by the.

Jeremy (2): function because you will say, I wanna achieve this

by this date, and we'll cut some corners that we think we can do and

we try and ship something by then

Péter (2): Yeah.

Jeremy (2): retrospect and say, is that enough?

Péter (2): Hmm.

Jeremy (2): okay.

Péter (2): Yeah.

Jeremy (2): So,

Péter (2): I really like also the emphasis you put on retrospective

and learning and improving.

Maybe we should do a separate episode on just the retrospective itself now

that we are called the retrospective.

'cause I think I.

Jeremy (2): Yeah.

Péter (2): there are a lot of pitfalls in that.

there are a lot of teams that are just doing it because it's in the

S Chromebook but they don't really get the value it could provide, so

Jeremy (2): yeah.

Péter (2): just an idea for a future episode.

Jeremy (2): Totally agree.

Péter (2): All right.

I think we talked a bit about the bigger picture benefits like the

company-wide cadence, more predictability.

What else comes to your mind how this could be beneficial in the

bigger picture for engineering teams?

Jeremy (2): so it simplifies planning as we talked about because you have

prioritized topics and you're talking about applying your appetite for how

much of my budget, how much of people's time are we gonna spend on this?

That's your budget and your appetite.

think it makes

Péter (2): I think it.

Jeremy (2): simpler way of working.

It removes a lot of process in terms of potentially removing story points.

I think it, it removes a lot of the kind of upfront planning,

capacity planning, and so on.

So it becomes an easier.

Way of working for new people to join, and is simplified even

if like the fact of having to.

Discuss and change scope is actually gonna be really hard for every new

person coming in and they have to learn.

but it's a different thing.

You have to learn rather than, you know, like all the other stuff.

What does five points mean here or whatever.

I think this, yeah, and then, managing of stakeholders, the ability to

adjust to changing stuff, and so on.

And I think then the other bit that's interesting on this is.

Technical debt, which is like this eternal problem that we have in

engineering, can be time boxed as well.

And that works really well with your stakeholders because, you can say, I

have this problem, I'm gonna try and tackle it in three weeks, this quarter.

and it's fixed.

And it's not like that technical debt project expanded and blew up and took up.

You know, you just realize we only shipped a part of it in the end,

and we need to maybe do some more.

so I think then it compounds, because ultimately.

Um, should be able to ship more because you're being a bit more aggressive

in descoping a bunch of stuff and, realizing that's good enough for now

I need to go after this other thing.

And so, I'm hoping that organizations that adopt this feel they are able to

deliver more on more business outcomes.

Because they're kind of, okay, well, you know

Péter (2): Okay, well, you know what?

We actually.

Jeremy (2): outcome was this.

And you could do that in a very, if you had a three week time box or three

months, maybe the three week can deliver just enough, to make the impact, right?

Um, there's questions about tech debt accumulation and

so on, but I, I think it, it

Péter (2): I think it helps.

Jeremy (2): ultimately push a bit more impactful change to

Péter (2): Mm-hmm.

Jeremy (2): customers.

Péter (2): I would even say more, it can be misleading.

I would say the emphasis is on better, like more aligned with business goals.

we all been there when we release a big half year, two year project,

whatever, and we just realized that users didn't need this.

for a new company, for a small company, this can even mean

the death of the company.

this way of working with the shorter feedback loops and the quicker

learnings, allows you to really deliver the most impactful things.

Jeremy (2): Yeah.

exactly.

Péter (2): what would be the three takeaways that, listeners could take

with them if they hear about time boxing?

Jeremy (2): Yeah.

number one, I would say a time box is about focusing on an outcome, that's like

a variable scope to enable that outcome.

it's not just like a time limit, for a fixed scope or whatever.

it's a forcing function to make you.

Focus on achieving that outcome regardless, uh, and deeply prioritize

as you do that to achieve the outcome.

Number two, I wanna remind you about the two rules, that

I think are non-negotiable.

Ship something at the end of the time box do the retrospective

say, what did we learn?

Should we work more on this?

Is this enough actually, you know, uh, should we do something

else that's higher priority?

the discipline of making it.

And if you're starting out, like number three, if you're starting out, might be

a bit hard to just whole scale do this.

So when you get to that tricky moment in the quarterly planning and there's

a lot of things that you're trying to fit in, you could just say, Hey.

How about we just do a two week spike time box on this topic.

We protect that.

And, um, and that's it, right?

You know, like just apply it a little bit somewhere and see if you can learn.

And then if you can, like, um, if, if, if that's working well, maybe you can

apply it to a few more places and if it's working well for you, maybe the next

planning session or whatever you propose a more of a time box based approach.

Péter (2): Nice.

So yeah, focus on outcomes, not deadlines.

The two main rules.

Ship something before the time box ends and retrospect.

And then start small and build a muscle.

I really like this angle also that you mentioned at the end, uh, some

practical advices or thoughts about how to start, how to switch to this

way of working, uh, as a final thought.

Do you wanna add something on that?

Jeremy (2): I think the way to get people on

Péter (2): people.

Jeremy (2): is to explain this, the triangle of project management

of scope and time and people, or, you know, a resource or whatever

and put that on the table of like.

Okay, well, you know, which, what are we talking about here?

You know, like remind them again about that project management triangle.

and use that to introduce the time box.

I think that's how I would kind of frame it.

Péter (2): Yeah, and I.

Jeremy (2): One thing that,

Péter (2): I if you feel discomfort, you should feel it like this is how it works.

it's gonna be hard.

Jeremy (2): Yeah,

Péter (2): the whole point.

Yeah.

of everything new that you're learning.

Jeremy (2): Because the discomfort, discomfort means, okay, remind

me what's my focus, what's I need to, what am I trying to, what's

the outcome I'm trying to achieve?

How do I aggressively prioritize?

And by the way, when you aggressively prioritize, you take

the pressure off yourself again.

so yeah.

it's a symptom that you need to prioritize.

Yeah.

Péter (2): Thank you Jeremy.

This was super useful.

I already know three people that I'm gonna send this episode once it's live.

and thanks for the listeners for sticking with us.

we are gonna be back soon in another episode where I'm

going to prepare a topic.

see you then.

Jeremy (2): it's great.

And you know, like there's all these algorithm stuff out there.

Feel free to share or like, and whatever the things that feed the algorithms.

we really appreciate our, small group of listeners that listen to

us, when we release an episode.

Péter (2): Exactly, or just do what I'm gonna do and send it

to a friend or someone who you think it could be useful for.

Jeremy (2): Exactly.

Cheers folks.

Péter (2): right.

Bye bye.