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.
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.