Do you remember your very first job? A junior software developer or a quality engineer. An intern maybe. You were expected to do something. All the time. I mean someone paid you and wanted to keep you busy. You didn’t see a big picture. You just had a queue of tasks you should do. One after another. Like building a brick wall. Brick by brick. Done with one? Here’s another.
More interesting question is: has it changed over years? I mean you probably changed the role a few times, possibly went through a handful of companies. Odds are you see a big picture now. Or at least a big part of a big picture. Maybe you’ve grown to be a leader or a decision maker. Maybe even things are under your control.
Nevertheless I’m still interested: whether you or your bosses still expect people to be busy doing the project tasks all the time?
I guess this is true for vast majority of organizations. We still build brick walls. Brick by brick. Done with one, here’s another. Why bother, you ask.
Well, this approach means basically aiming to have all the people doing something, for the sake of this post let’s call it “project tasks,” all the time. It means aiming for 100% utilization of people. And you know what? If you aim for 100% utilization you’re likely to get pretty damn close to it.
The problem is we don’t get paid for being fully utilized. We get paid for delivering projects (again, please let me go with such a generic word).
Thus, we should be aiming for effective and optimal deliveries and not for having everyone around busy.
And there the fun begins.
Intuitively we follow the way of thinking which tells us that we do most work when everyone actually is doing work all the time. Finished with one feature? Go, start another. The project will end faster.
Except it isn’t true.
We don’t do simple manual work. We don’t build a brick wall where each and every task of adding another brick is similar, simple and almost completely independent of other tasks. And most of all it can be done without much, if any, cooperation with others.
There are a few areas where 100% utilization hits us hard.
This is an obvious statement but switching context comes at a cost. I guess we always perform better when allowed to complete one thing uninterrupted before starting another and the nature of task doesn’t matter here. However, when we think of knowledge work there’s another cost we pay – time we need to get at full speed back again. Time to get into the context of the task. It’s not just another brick which we don’t even think of as our hands do the entire job.
100% utilization means basically more tasks being done concurrently, because we want to have so much work started that everyone has something to do. It means that tasks are waiting for people. It means that quality engineers have enough developed features to test that they’re never idle and so on.
OK, but what happens when someone finds a bug? Well, a developer switches back to this feature and fixes it. Then they’ll go back to this new feature they’ve been working on. In the meantime the quality engineer started working on something else and now they need to come back to this issue to retest it. Another context switch. Now, multiply it by a big number and that’s what is happening in many software development teams. Constant context switching, sometimes to work items which were waiting so long that people barely remember what they were all about.
It costs. Each time probably just a bunch of dollars, but multiplied by a number of such situations it stacks up to huge piles of money.
Another problem which comes with having tasks waiting for free people on every stage of the process is that we have lots and lots unfinished work. It means significantly bigger coordination effort you need to invest to keep you machinery working. It means way more prioritization work as every now and then people need to decide what to next. After all they are choosing among a number of different options.
It might surprise you but prioritization can take a huge toll in terms of time consumption. Let’s go with a simple experiment: prioritize whether you prefer to drink or pee at the very moment. It was quick, wasn’t it? Now, prioritize importance of each and every thing which lies on your desk. How much longer the second task took you?
Many ongoing features usually also means that you add cost attached to all the product politics. If there are many decision on priorities during the whole process it means there’s a temptation to change these priorities so team members start attending meetings or having discussions where they are told to add this little gizmo to the next release as it will allow conquering the whole world. No! Not the world, the whole galaxy! Now, imagine you could just avoid all that and focus on value-adding work. How happy you would be.
Time to market
This one is tricky. If you asked any decision maker whether they want to have shorter time to market they would eagerly agree. However, pretty often shorter time to market bears not that much value. Think of fixed priced custom project for a big client. Even if you can release per feature or you can deploy a new version weekly, chances are good they won’t touch it, even with a stick. And if you deliver the whole solution a month earlier than planned they won’t have capabilities to run user acceptance tests, thus you’ll wait anyway.
However, there are project where shorter time to market has huge value. Ask almost any web based app targeted directly to end users. In such cases longer lead times are actually counted in dollars.
Early issue discovery
Although personally I think this one is overhyped it can’t be omitted. If there’s a problem in your process there’s big value in discovering it as early as possible. Think of broken deployment. If you wait until you deploy the huge product at the very end of the project you are screwed up. However, if you care to deploy first bunch of features as soon as it is possible and reasonable, you discover the issue early, sort it out and eventually live through the final deployment with little or no problems.
On a side note: why do I think this one is overhyped? Well, if I hear examples of sending mass snail mails, you know, printing some papers, putting them into envelopes, sticking stamps and so on I wonder what can go wrong with such process. Yeah, envelopes can have wrong color. Wouldn’t I notice it instantly? Hopefully our teams know at least part of their craft at this level as we do mailing.
OK, either way there are quite a few places where we actually pay for 100% utilization. The result is that with the very same team we deliver later when they’re fully utilized than we would if they weren’t.
I know, this is counterintuitive.
It also means that avoiding 100% utilization means that we can build our projects cheaper.
I know, this is counterintuitive.
Actually, it means that letting our people do nothing on occasions means that we can perform better. And I mean nothing like, well, virtually nothing.
I know, this is counterintuitive.
The funny thing is we aren’t that surprised when we think about a highway. When we pack as many cars into highway as it is possible (100% utilization) we expect to see a traffic jam. And that’s what happens. We’ve been there. We’ve seen that. We expect nothing different. Then it is intuitive. Maybe because we’ve experienced that.
Maybe we should give ourselves a chance to experience it in our projects as well?
And yes, we can do better than let people doing nothing when they don’t do project work. But that’s a subject for another post.