Showing posts with label software estimation. Show all posts
Showing posts with label software estimation. Show all posts
Thursday, September 04, 2014
The final words about software estimation - Pecha Kucha talk
Here are the slides of my Pecha Kucha lightining talk I gave at #ALE14 in Krakow. Kind of a quick reminder (or kick in the butt, in case one forgot...).
Saturday, April 14, 2007
The dark art of cheating software estimates - Part two.
Just a quick addendum to my previous post about software estimates (and how to fool yourself cheating with them).
The most effective trick to miss a deadline (and the following one) is to put unrealistic estimations over developers activities. To achieve this result you have basically two ways.
Define the estimates at the wrong level
This normally happens when the team leader defines the activities and assigns them over the head of the developers. Experienced developers know better what should be done and which activities take time, so you should rely on their point of view, after all they're the experts in their domain. Imposing an estimation on the developer's head has also the undesired effect to cause an emotional drift in case of activities taking longer than expected. A young developer could assume that he is the problem (and maybe the real problem is just something forgotten at a higher level) and feel responsible for the delay. If you just say "You have 3 days to finish this" you might end up having the only crappy piece of software the developer was able to write in those three days.
And, of course, skills and environmental factors are different, so the same activity could take 2 days if assigned to one developer and 4 to another one. If the estimates are coming from above, it's easier to forget about that, when quickly reassigning activities.
Ok, this is just something that might happen. I am not saying that one should completely rely only on developers' numbers. A good team leader has its own estimates in place, that can be used manage risk related to optimistic developers, and so on. But this is an activity that should be performed behind the scenes (my first team leader always added 30% to my developer estimations). Comparing developers estimates with yours could also help to spot potential problems, like activities that shouldn't take that much.
By comparing different developers estimations on similar tasks, you could also spot if somebody found a smarter way to do something, and have him teach to the others (or discover that somebody is not finishing the activity and leaving some dirt under the carpet as an undesired gift for the following iteration). Put in another way you should rely on the developers on the estimations and take yourself the burden of find out how to speed up activities.
Asking estimations in the wrong way
One thing you should never do is ask "Will it be finished for Tuesday?" and - even worse - the follow-up "You told me this was going to be finished for Tuesday". Of course, in the middle, everything can happen. If you want to be hated you can ask the question one day, then interrupt with a higher priority task, then on Tuesday ask the follow-up, with a blaming pitch.
The point is that, as a leader, you shouldn't forget the effect of your role. A milestone should be a leader's problem, not a developer's problem (and shouldn't be managed in terms of blame anyway). Asking a question in this way is no different from a woman coming out from the hairdresser with a new "transgressive" haircut asking "How do I look?". It's just a compelling invitation to lie.
At the end, the numbers are exactly the ones the team leader wanted, but in this case the blame is all on the developer. Playing this trick, is unfair, doing it repeatedly is just a way to increase pressure and to threaten team alchemy.
The right way to put question is "How much time you need to do this?" and then do everything possible to ensure that all of this time will be spent on that activity. A good leader manages pressure from above and should shield team from it. If the collected numbers are too high, there is probably a problem, which needs to be investigated and possibly solved, soon.
Don't forget that providing a detailed estimation of the activity, is an activity itself. It shouldn't take a day, but be careful when you get an immediate reply; it's a sign that somebody isn't probably thinking enough. So leave your developers the time to think about what should be do and how much time will be needed. As Joel Spolsky states, this is design activity, after all.
The most effective trick to miss a deadline (and the following one) is to put unrealistic estimations over developers activities. To achieve this result you have basically two ways.
Define the estimates at the wrong level
This normally happens when the team leader defines the activities and assigns them over the head of the developers. Experienced developers know better what should be done and which activities take time, so you should rely on their point of view, after all they're the experts in their domain. Imposing an estimation on the developer's head has also the undesired effect to cause an emotional drift in case of activities taking longer than expected. A young developer could assume that he is the problem (and maybe the real problem is just something forgotten at a higher level) and feel responsible for the delay. If you just say "You have 3 days to finish this" you might end up having the only crappy piece of software the developer was able to write in those three days.
And, of course, skills and environmental factors are different, so the same activity could take 2 days if assigned to one developer and 4 to another one. If the estimates are coming from above, it's easier to forget about that, when quickly reassigning activities.
Ok, this is just something that might happen. I am not saying that one should completely rely only on developers' numbers. A good team leader has its own estimates in place, that can be used manage risk related to optimistic developers, and so on. But this is an activity that should be performed behind the scenes (my first team leader always added 30% to my developer estimations). Comparing developers estimates with yours could also help to spot potential problems, like activities that shouldn't take that much.
By comparing different developers estimations on similar tasks, you could also spot if somebody found a smarter way to do something, and have him teach to the others (or discover that somebody is not finishing the activity and leaving some dirt under the carpet as an undesired gift for the following iteration). Put in another way you should rely on the developers on the estimations and take yourself the burden of find out how to speed up activities.
Asking estimations in the wrong way
One thing you should never do is ask "Will it be finished for Tuesday?" and - even worse - the follow-up "You told me this was going to be finished for Tuesday". Of course, in the middle, everything can happen. If you want to be hated you can ask the question one day, then interrupt with a higher priority task, then on Tuesday ask the follow-up, with a blaming pitch.
The point is that, as a leader, you shouldn't forget the effect of your role. A milestone should be a leader's problem, not a developer's problem (and shouldn't be managed in terms of blame anyway). Asking a question in this way is no different from a woman coming out from the hairdresser with a new "transgressive" haircut asking "How do I look?". It's just a compelling invitation to lie.
At the end, the numbers are exactly the ones the team leader wanted, but in this case the blame is all on the developer. Playing this trick, is unfair, doing it repeatedly is just a way to increase pressure and to threaten team alchemy.
The right way to put question is "How much time you need to do this?" and then do everything possible to ensure that all of this time will be spent on that activity. A good leader manages pressure from above and should shield team from it. If the collected numbers are too high, there is probably a problem, which needs to be investigated and possibly solved, soon.
Don't forget that providing a detailed estimation of the activity, is an activity itself. It shouldn't take a day, but be careful when you get an immediate reply; it's a sign that somebody isn't probably thinking enough. So leave your developers the time to think about what should be do and how much time will be needed. As Joel Spolsky states, this is design activity, after all.
Tags:
Tuesday, January 30, 2007
The dark art of cheating software estimates
Most widely used techniques for estimating software projetcs are
In UCP the estimation is the result of two main factors: the application complexity (roughly measured vie the number and complexity of the use cases and actors) and the environment factors which - as everybody knows - heavily influence the outcome of the project.
The second reason why I like UCP methodology is that when I did retrospective analysis on finished projects, the results where pretty precise. Which is obvious, if you think about it, because retrospective analysis is exactly the way estimation methodologies were tuned. There are two important points so far:
Here comes the cheating
The official estimates will be close to reality, but reality is bad news... so what will you do? The problem is that the link between effort and price looks completely blocked before the project starts. During the project, everything might happen: you might be 2 months late, hire new people and train them, and so on. Each time, you add a random factor that invalidates your fixed ratio between worked hours and the overall price. Still what happens 99% of the times, when showing estimates to the management, you'll be asked to reduce them.
Sometimes there are business reasons for it. It's like buying a car, the salesman knows that the final price will be $50.000, but will tell you about $39.900 and the optionals... Some other times it's like a pavlovian reaction: time is a cost and must be compressed. Wasn't it sad enough, I've never heard of a smart suggestion coming out in this phase. Normally you can have one of the three:
a)"Let's skip the analysis phase"
b)"Let's skip the design phase"
c)"Let's skip the test phase"
If you still are optimistic, I have to warn you that the a) and b) almost always imply c). Or, put in another way, c) is always implicit in such a situation.
The most annoying thing is that the same overall result could have been reached talking only about money. Just lowering prices. But everybody assumes that the other one is lying or maybe the way (presumed) cost reduction is achieved makes the difference for somebody.
But let's get to our numbers, as I said before good news are that prediction are rather accurate, still they might fail. One way is having a wrong count of use cases, meaning that more can appear along the way. But a new use case is a new feature (it's the $500 optional on our car) so it's not a problem, as long as the price varies accordingly, and the time also does. Often, what happens in the closed room it's a bargain of money vs time, sort of "I'll pay you this extra money, but you'll have to deliver it all at the original planned date...". hmmm
External factors are more tricky, cause they're harder to evaluate. Sometimes they're just mere assumptions and it takes time to realize if they're right or not. An example of a tricky one is "motivation": you can assume motivation is 3 on a 0 to 5 scale, cause you simply don't know. Then it's hard to find a special moment in the project lifecycle when motivation drops to 2, triggering a recalculation of the estimates. If you have a boss saying "I noted that mood dropped in the development team, can you please update the estimates according to that?".
So your initial assumption are kept "locked" shielding the official numbers from the force of reality. But every time the estimates are kept safe, old, and untouched, you can assume that they're just a lie, and distance from the truth will have to be filled somehow. The difference is that if the truth is exposed, people tend to behave accordingly; if the truth is under the carpet everybody feel free to cheat a little bit more.
- guess a number
- ask a number and multiply it by pi
- pick the release date, count the days backwards and multiply them by the available people
- function point analysis
- use case points analysis
- ...
In UCP the estimation is the result of two main factors: the application complexity (roughly measured vie the number and complexity of the use cases and actors) and the environment factors which - as everybody knows - heavily influence the outcome of the project.
The second reason why I like UCP methodology is that when I did retrospective analysis on finished projects, the results where pretty precise. Which is obvious, if you think about it, because retrospective analysis is exactly the way estimation methodologies were tuned. There are two important points so far:
- The UCP methodology is pretty accurate, if you correctly evaluate the starting factors
- You can still make mistakes, because factors might change (new use cases might be added during development, or environmental factors may change, or reveal themselves wrong)
Here comes the cheating
The official estimates will be close to reality, but reality is bad news... so what will you do? The problem is that the link between effort and price looks completely blocked before the project starts. During the project, everything might happen: you might be 2 months late, hire new people and train them, and so on. Each time, you add a random factor that invalidates your fixed ratio between worked hours and the overall price. Still what happens 99% of the times, when showing estimates to the management, you'll be asked to reduce them.
Sometimes there are business reasons for it. It's like buying a car, the salesman knows that the final price will be $50.000, but will tell you about $39.900 and the optionals... Some other times it's like a pavlovian reaction: time is a cost and must be compressed. Wasn't it sad enough, I've never heard of a smart suggestion coming out in this phase. Normally you can have one of the three:
a)"Let's skip the analysis phase"
b)"Let's skip the design phase"
c)"Let's skip the test phase"
If you still are optimistic, I have to warn you that the a) and b) almost always imply c). Or, put in another way, c) is always implicit in such a situation.
The most annoying thing is that the same overall result could have been reached talking only about money. Just lowering prices. But everybody assumes that the other one is lying or maybe the way (presumed) cost reduction is achieved makes the difference for somebody.
But let's get to our numbers, as I said before good news are that prediction are rather accurate, still they might fail. One way is having a wrong count of use cases, meaning that more can appear along the way. But a new use case is a new feature (it's the $500 optional on our car) so it's not a problem, as long as the price varies accordingly, and the time also does. Often, what happens in the closed room it's a bargain of money vs time, sort of "I'll pay you this extra money, but you'll have to deliver it all at the original planned date...". hmmm
External factors are more tricky, cause they're harder to evaluate. Sometimes they're just mere assumptions and it takes time to realize if they're right or not. An example of a tricky one is "motivation": you can assume motivation is 3 on a 0 to 5 scale, cause you simply don't know. Then it's hard to find a special moment in the project lifecycle when motivation drops to 2, triggering a recalculation of the estimates. If you have a boss saying "I noted that mood dropped in the development team, can you please update the estimates according to that?".
So your initial assumption are kept "locked" shielding the official numbers from the force of reality. But every time the estimates are kept safe, old, and untouched, you can assume that they're just a lie, and distance from the truth will have to be filled somehow. The difference is that if the truth is exposed, people tend to behave accordingly; if the truth is under the carpet everybody feel free to cheat a little bit more.
Tags:
Subscribe to:
Posts (Atom)