It’s time to let you in on The Secret. Don’t tell anyone, but “How long does it take” is the wrong question.
I planned for this post to be about statistics and how to calculate probabilites. Instead it turned into a rant, of sorts. You see, there’s another Secret buried here: If you really take the time to learn how to estimate risk correctly, this will help you learn the following fact about the outcome of your project: It is very uncertain. I guess that’s helpful. Sort of.
“That’s just baloney,” I can hear some of you say. “My projects are consistently on time and on budget,” you continue. Maybe so. Let’s examine the famous “project triangle” for a moment.
Ever wondered why it isn’t a square? Because quality is a result of the other three, some might say. “That’s just baloney,” you can hear me say. I think it’s because cost, scope and time is easy to measure and easy to adjust. Quality? We always deliver perfect quality! We are professionals! Let’s just put that in the middle, and hope no one pays too much attention.
You, the guy who screamed “We always deliver on time and on budget!” a moment ago. How about scope? “Hah! We delivered all the functionality as well! All the developers bitched about them having too much to do in too little time, but my project plan showed them wrong!”
That’s impressive. But even when we go to the painstaking length of figuring out the risk and uncertainty of a project PROPERLY – You know, with Statistics and stuff, not just, God forbid, guessing or anything – it still comes out as being very uncertain. So how come you can consistently deliver your projects on time, scope and budget? Your team don’t have much choice, do they? They have to reduce quality. Luckily for you, no one will notice until the project is over. And they couldn’t really measure it if they did. What IS quality anyway? Sounds like a made up word to me.
So what did I mean by “how long does it take” being the wrong question?
There are a couple of problems. First of all, what is this “it” that we are doing? When you start the project, odds are neither you or the customer knows what the end result is supposed to look like. You may think that you do, but you don’t.
If it is a waterfall project, the customer will say “This is what I want” while dropping the dreaded Complete Requirement Specification on your desk. Then you go away for three months with a team of developers to create whatever is in the specification. “Here is your product!” you exclaim with great enthusiasm when you come back. After the customer has tested it, she goes “Nope, that’s not it.”
If it’s an agile project, your team of developers only go away for maybe a couple of weeks at the time. Each time you come back and show a little bit of the product, the customer tests it and goes “Nope, that’s not it either. And where’s the rest?”
However you go about it, both you and the customer learn a lot DURING the project. Mostly what they don’t want. Needless to say, this process takes quite a bit longer than just doing stuff once. No one knows what done looks like until, well, you’re done. And please remember, we’re not BUILDING a product, we’re CREATING it. The first of its kind. Your developers aren’t packing meat in boxes along a conveyer belt, they’re freaking SCIENTISTS! So stop pretending you are a production facility. The product you’re creating has never been built before. If it has, please go and buy that instead.
And that’s not even half of it. What did you say were doing again? A project, right? Well, most of the time we’re not really creating projects, we’re creating PRODUCTS. The funny thing about products is that they don’t end when the project ends. That’s kind of when they start. In terms of cost, that means roughly 90% of the total cost of a product comes AFTER the initial release. Maintenance, bug fixing, additional development, paying back technical debt, people spending most of their day swearing over how horrible it is, and so on.
Here’s the Third Secret: The less time you spend on quality during the “project” phase, the higher the total cost of the product.
So whenever you pat yourself on the back for delivering “on time” (usually a random point in time decided by anything except the actual amount of work that needs to be done before that date), that probably means you have reduced the overall quality of the project, and increased the total cost of the product you delivered. That doesn’t really sound like back patting performance, if you ask me.
Did you think this series of posts would culiminate in How To Estimate Accurately In 3 Easy Steps? Well, it sort of didn’t. If you’re still looking for that guide, you should probably read “The Flaw of Averages: Why We Underestimate in the Face of Uncertainty” by Sam L. Savage.
I’m not sure it will make your estimates more accurate, but at least you’ll understand why.
So, what’s it all about, this software business? Making money? Isn’t any business? Figure out how to bleed the customer of as much money as humanly possible, while doing as little as you can get away with. It’s a bit of an art, really.
It doesn’t matter if you’re buying software services for your company, or a carpenter to remodel your house. They strip you naked and hang you out to dry. That’s just the way modern business works, I guess.
Or is it?
At Revio we have a set of core values. One of them is Proud. By the end of the day, we need to be able to stand up straight, and be proud. Proud of who we are. Proud of what we accomplished.
Proud of how we have treated others, and proud of what we have delivered to you.
As much as we would like to be flawless, we are not. There are times when we look at the result of a project, a system update or some other deliverable, and must admit that it falls short. We ask ourselves if we can be proud of that delivery, and the answer is No, we can not.
I hold both myself and the rest of the team to high standards, so when that happens I feel really, really bad. Then our COO looks at me and says:
“Meanwhile in Africa..”
What he means is that sure, our server is down, our customer is furious, and it sucks. But while the customer may very well be furious, he’s not dead. He is not being killed in front of his wife and children in Libya, and luckily – neither are we.
When we’ve reminded ourselves that no matter how bad we screw up, most of the planet is still doing quite a bit worse than we are, it’s time to get back to work. Whatever was wrong must be put right, and whatever the customer is expecting, we must try to achieve.
Our way of conducting business may not be saving lives. However, by being honest, dependable and proud of what we do – we hope we are able to make yours at least a little bit better.
The middle manager. The useless fat of any bloated organization. They delegate all their work to other people, and then they wander around aimlessy, doing nothing at all expect worry about what happens if the delegated work doesn’t get done in time.
Being useless fat can be both rewarding and fun, but most of the time it is a difficult job. Even so, it must be done. After all, stuff doesn’t get delegated by itself..
It’s an interesting and not entirely new question. What to do with middle management in a company that is agile, stuffed with self organizing teams that in turn are made up of super-cool and smart people that don’t really care very much for authority figures who try to tell them what to do. Do we really need them around?
In an “agile organization” (whatever that is), stuff still needs delegating. But perhaps you are delegating goals and projects, instead of tasks. Less time is spent reporting against imaginary project plans, more time is spent actually creating value for the customer. Sharing information, explaining goals. Discussing possible solutions. Developing said solutions, showing them to the customer early and often.
As an agile or lean manager, I’m not really the boss of someone else. I am simply responsible for other parts of the value delivering process. I am also responsible for optimizing the process itself. I also try to inspire everyone else to optimize their part of the process, whenever that is possible without hurting the process as a whole.
My job is to protect tech people from nosy sales people, help sales people understand difficult tech people, explain to owners how a little money now isn’t always better than a lot of money later, and that more quality actually equals less cost in the long run. If all of the above goes well, the result is surprisingly often that we deliver valuable and useful software to customers who don’t always know what they need, but always know where it hurts.
Basically it is understanding, sharing and aligning goals and mindsets. And that is a really fancy way of saying that you need to talk a lot. I don’t really like talking to people very much, so I guess that explains why I spend half the time worrying instead.
It may not be very effective, but at least worried people look busy. And looking busy is important when you are useless fat.
I’ve been around my fair share of useless people, I’m sure you have as well.
I don’t know about you, but I hate it.
I can handle people who are genuinely useless, but useless people who are actually intelligent and could have been competent, those guys I really hate. I hate it when people do a crap job even though I know they could do so much better. It’s amazing how much you can’t get done when you’re armed with a lack of motivation combined with a healthy dose of ignorance.
I hate leaders and managers who think they are doing a great job, but actually suck at it, and blame their employees for their own shortcomings.
When I started out as a manager (and to a certain extent even today), I always took the blame for anything my employees did wrong. When you made an error, so did I. Why is that? Because I hate it when we suck. I try to do my very best, every day, all day. I seldom succeed, but at least I try. I want you to try too. Hard.
So when I take the blame for your mistake, that isn’t right, is it? I don’t want to take responsibility for your mistakes, I want you to take responsibility. Own up, move on, do better next time.
You’re at the office doing whatever it is you do most of your waking hours anyway, so you might as well be passionate about it, right? It wouldn’t kill you, would it? If it did, at least you’d die doing something you were passionate about. It sure beats being bored to death.
The next time someone gives you feedback (that’s a nice word for someone shouting at you and telling you that you suck), hold back on that excuse for just a minute. Because they already know the specification wasn’t perfect. They know the customer is a jerk. They know you have a cold. And deep down you both know that you are capable of doing a better job. That’s probably why the guy is shouting at you in the first place. It’s no use shouting at an idiot, but he knows you can do better. So why the hell didn’t you?
I’d love for us to just get rid of all the terrible excuses and blame games (even though I still catch myself participating in them from time to time). And just. Get. Better.
So whenever you get yelled at, tell them that yes sir, you are exactly right. It was my responsibility to identify that the specification was incomplete. It was my responsiblity to figure out what the customer really wanted. It was my responsibility to make sure this new feature didn’t break anything else. I will go out of my way to do better.
I for one, will love you for it. And I will do my best to follow your lead.
W. Edwards Deming (Wikipedia)
The system. W. Edwards Deming claimed that 95% of the performance of an organisation is based on the system, and only 5% is based on the people. I won’t dare go so far as to contradict Mr. Deming, but as a manager in a small company, I am tempted to look at it from a slightly different angle.
A brilliant employee will never perform in a mediocre system, and a mediocre employee will do a decent job in a brilliant system. But if your company is twenty, ten or maybe just five guys (or girls) – surely, people must matter?
You can not blame the worker for wrongdoing, most defects and quality problems are a result of the system. But if you are five guys sitting in the same room trying to make your company succeed – well, you are the system. The five of you. When Joe screws up and says to the other four guys, “Sorry, I’m a victim of the system!” they will probably look around the room and go “Uh, what system?”
But wait a minute. However small a company, there are someone in management, there are someone in sales, you have a customer department, and you’ve (hopefully) got someone actually producing whatever it is you are attempting to sell. Maybe Joe is both management, sales and customer department, but those roles still exist in the company. So however small, your company is an ecosystem. And if you haven’t given that much thought, possibly not a very good one.
You may just be ten guys, or just five. That doesn’t really matter. You should already be thinking structure. Processes. Quality. Why didn’t Joe tell Pete about the complaint from their most important customer? Why did Pete forget to test the new software that Mike just hacked together? And why did he hack it together when they all agreed last month that the software needed to be robust and well built?
I can hear you shout: “We can’t afford all that stuff, we’re just a small startup company!” Well, to paraphrase old William Edwards Deming: If you focus on quality, quality increase and costs fall over time. However, if you focus on cost, costs will rise and quality decline over time. Surely, that’s not what you want?
So did I answer my own question? Well, kind of. Even though “people are only 5% of the performance”, in those early days you need people who understand just that. That takes us back to where we started, perhaps having gained somewhat of a paradox along the way:
People are helpless to fight a faulty system, but to build the right system, you need the right people.
I’m pretty sure that if a developer built a house, it wouldn’t have any corners. Their first instinct at the sight of an obstacle would be to get rid of them. Corners you say? Who needs them! And then they’ll all start chanting: Cut a corner, cut a corner!
At Revio, we challenge the developers to deliver estimates that they believe in. We tell them not to consider the expectations of management or customers. Consider the task at hand, and attempt to figure out how long it will take to get it done, and done right.
As discussed in an earlier post, accurate estimates are hard. That means even though we estimate with the best intentions, we might still end up hard pressed for time. And even in the flowery, sunny world of our little company, we occasionally misunderstand the customer. So there we are, with maybe 3 developers in the team, ten days until deadline, and 500 hours of work yet to be done.
Fig. to take shortcuts; to save money or effort by finding cheaper or easier ways to do something.
To do something in the easiest, quickest, or cheapest way, often harming the quality of your work.
In a situation like this, the vision of an unexperienced developer often narrows down to the very next line of code as he mentally calculates how to shortcut his way out of his misery. Must. Code. Faster.
Let me share with you what I as a manager would want the developers to do in this situation:
- Give me a calculator, help me type in 3 developers times 8 hours times 10 days equals 240 hours. Explain that we have 500 hours yet to be done. Then ask me patiently what I would like to do with the 260 hours worth of work that we do not have the capacity to complete.
- Tell me to read “The mythical man month” if I suggest to add another 3 developers to solve the crisis.
- Ask me wether moving the deadline is a viable option (More often than not, it actually is).
- Work together with me in order to figure what features can be moved to a later phase, while still delivering as much value as possible in the current phase.
- NEVER EVER cut on code quality (architecture, coding practices, coding conventions).
- NEVER EVER cut on quality assurance and testing.
If you discover mid-project that you have more work than you have hours available, you will not get everything done in time. Period. Going into a team-wide panic and start building up technical debt like crazy won’t really help. In the long run, it’ll just make things worse.
Often, quick and dirty actually takes even longer. This is especially true if you have poor specifications and need to do a lot of re-work. When you tell me “yes we can” when actually we don’t, that’s bad for both of us.
So in conclusion: The next time you’re stuck in a doomed project, make sure you stay realistic and maintain your own integrity. Your manager may ask you to get 20 days worth of development done in 10 days, but it’s up to you to accept it.