This post need to start with an disclaimer;
I write this since I have run into several people to which these
thoughts are new and confusing. If you are an agilista you will not
find anything new or exciting here.
Really… there’s nothing new to see here. Go away you scrum-lovers -
this is not aiming for you.
How’s that for scaring people away from a blog post. If you’re still
around… Anyone… Hello? Ah - there you are. Well – let’s get started
then.
I recently have introduced agile in a large company and tried to do it
through the whole company, business and IT working together in brotherly
company. As you can imagine I ran into some problems. And still to this
day we need to explain for the business why they would and probably
should look into agile thinking (or was it lean maybe?). I was thinking
on starting a small series on some of the explanations I often use and
sometimes succeed with. If for nothing else just to be able to send
people here when I talk to them.
The fact that we still have to explain this to the business is troubling
in itself but that a whole other story.
In this post I’m going to take a look at timeboxing and why that
actually not only is the best out of three bad choice but also can give
you an advantage.
Time boxing
Time boxing is a fundamental thing to many agile methods but foremost
Scrum. The idea starts out in the fact that there are always more to do
than we have time and resources for. So we need to balance these 3
artifacts against each other; time, resources (people, money etc - in
essence costs) and features. In reality there’s also quality but we
seldom want to take a chance with that dimensions, since bad quality has
a nasty way of coming back and biting us later. So often you just talk
about Time, Cost and Features.
Time boxing propose that we fix the time and resources and let the
feature that we cope with vary. But let’s take a look at our options;
Options - Time, Costs and Features
Let’s fix Features and Time and letting Cost vary. This
means that you get everything on your list, at an exact time but we
cannot say what the cost will be. Two fundamental problems here;
- Most (business) people don’t like to have cost be an undecided
factor (I say – neither do I). It might become very expensive.
- Secondly software development doesn’t always go faster by just
throwing more money and people into the process. Just as 9 women
cannot deliver a baby in 1 month. Some things take time…
Ok - that didn’t work. Let’s fix Cost
and Features instead. That means that you’ll get everything to a
fixed cost but we cannot say when (Time). This is not acceptable for
most business either, but it’s at least accomplishable in a pure
technical way.
So that leave us with the final option;
Fix Time and Cost and let Features vary. This means that we
will say exactly when we’re done and on the cent what it will cost - but
we cannot say what will be delivered. This is, sadly, not very nice
either… at least in this pure form (but there is help - see below).
But it’s the best (least bad) out of these options for most people.
What to do?
### Fix them all
Actually - there is still one option left; fix all of them! **Time,
Cost** and **Features** are fixed. This is what is known as Fixed
Project. I'm here to tell you business people that this is bad for you.
Maybe even the worst of these alternatives.
Imagine that you were asked to create a dinner for 50 people. 3 courses,
all new recipes, please. And you need to be done at 19:03 tomorrow. And
you need to tell me on beforehand what it cost. To the dollar. And I'll
fine you if you're late.
If you ran a catering business - how would you tackle this? Yeah - you
would say a sum that is higher than you think, to cover up for the risk
you're taking.
> Short side-story; I was in a project that ran way under budget and we
> held a retrospective to find out why. So the business people said; how
> could you be so fast this time?
> IT-person; well ... you know ... when you ask us for a fixed date,
> fixed scope, fixed cost estimate we always take our estimates times 3.
> This made the business people laugh through their nose. When they had
> calmed down they managed to explain why;
> Business person; You see... we don't trust your estimates. So we take
> them times 3.
The thing about that story is that not only was it stupid to take times
3 times 3. No that they actually took the time to do that exercise at
all.
### Small things often vs large things seldom
So it seems like we're stuck. The least bad is to fix Time and Cost and
let Features vary. But you, dear business people, can use this
limitation to your advantage.
If you give the team a list of things to do you have total freedom over
the things that the team is not working on right now. You can change it,
reorder it, split or merge items on that list. The team will not care -
as long as you don't change the stuff they're working on right now.
Well - you could change those items to but then they have to stop and
restart and loose concentration, momentum and speed.
Not only that - the smaller items you drop to the team the more speedy
they will be delivered. Which in turn render you more fine grained
control how the resources of the team is used.
One gotcha only - you need to engage in what the team does. But if you
don't - how important is this for you really?
### Less is more
For extra credits - let the team themselves pick from the (prioritized)
list what they think they cope in the next couple of weeks. That is much
better than to push work out to them. It's probable to think that the
team knows their capabilities at any given time better than someone
outside the team.
This is based on the thinking behind
Littles Law, which put simply says that the more
items you are doing at the same time the longer each items will take. So
for example:
> If we're doing 12 items at the same time and finish 12 item each week,
> the time take for each item is.... 1 week.
> By simply doing 6 items at the time. Still working the same and
> completing 12 items each week; time taken per item is 1/2 week.
> But if we do more stuff; 24 items that is pushed out to do. Still
> working finishing 12 items / week that will make the time taken per
> item to go up to 2 weeks.
So the fewer items we're working with the faster each item flows through
the system. You and your team can achieve this by letting the team draw
new work to themselves when they have capacity.
### Conclusion
Fixed price/date/scope is bad for you. It's not using the scarce
resource that your team is in an optimal way. It's wasting resources and
will force the team to add costs to take risk into account. A better way
is to let them pick from a list that you prioritize.
These are some of the reasoning I often find myself relating when
introducing agile thinking to people that haven't heard about it before.
I hope you found this helpful