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