How much do you estimate to get across?
Does the mob really use no estimates?
In the time that we have done development as a mob we have done no estimates for management. We value our time as a mob highly and spending that time making guesses about how long it would take us to do something rather than using that time to accomplish that goal does not make sense.
So how do you do it you say?
Well the answer is disappointingly simple. We keep the application deployable between each feature and often deploy it as soon as any one feature is complete. Since we have tests around all of our work we have a high level of confidence in what we have created. There is a light amount of exploratory testing before we are happy with releasing the application.
Making estimated will leave you falling short…
What about hard deadlines?
We have had projects that needed to be complete by a certain date. A hard deadline. This is an interesting scenario. I have been on projects at previous companies that had similar hard deadlines and we would spend a large amount of time estimating tasks that would then get prioritization and finally worked on only to find that the estimates were wrong and some features would be cut. The inverse is to use no estimates and prioritize each feature after the next.
Can you explain how you prioritize a little more?
SURE! When we start working on a project we meet with our end user and show them what we currently have. Then we ask them what the next feature they need the most is. We may collect 2 or 3 features, then send them off and work on those. As soon as each feature is completed we ask them if the others we have are still a priority. We find that usually they have new priorities because they have been using the latest features we developed. They often ask for something completely different. In this way we steer the project toward a better result than if we had predicted and estimated all the features.
Is this approach only for the Mob?
No, you can use the no estimate approach too! Anyone can approach software this way and I recommend it. If you are estimating projects you should consider what value (if any) they bring you ultimately. Ask yourself how often have estimates been wrong? How much time did you spend up front making the estimates only to find out they were useless. Did you prioritize a feature that is rarely used over a feature that was cut just because of an estimate?
The Reason Why
Each bit of work someone does in software development should not be repeated if possible. We want to automate repetitive work. Therefore any work done by a programmer is presumably new work. This is why estimates have no value, you cannot accurately estimate something you have not done before.
Don’t need estimates if you just build it right away!
So No Estimates
It is a simple decision. Do you want to spend money on information that seems to have value but truly does not or do you want to spend your resources on more important matters? In my opinion, software development evolves at such a dramatic rate that estimates cannot be useful.
Another common situation that happens, probably more often that most people will admit, is that at some point during the work the customer finds a third party solution that does exactly what they want. If your team spent a month, a week, or even an hour doing estimates on a project that ultimately ends up being thrown away in favor of an out of the box solution, that is waste. Needles waste on top of the waste that was actual work.
All that time spent estimating, could have been spent doing real work that actually led the customer to realize that there was already a solution or product out there that meets their needs.
Good post on an important topic.
I work for a company that builds systems for Insurance carriers – very complex and with long implementations cycles for customers. In fact, when the product team releases, it is not directly to customers but to a professional services team that then does customization together with the customer before going live. This results in customers not willing to take frequent releases, and forces releases to be larger and less frequent.
I have been trying to promote similar ideas to what you describe in the post, however the argument above is blocking the initiative. I am starting to think that the frequency of release is the one true measure of ‘team agility’…
How do you make a tradeoff as to the return on the investment if you have no measure of the cost/effort involved?
We can calculate the cost of an application based on the time used to do the work of developing it. We don’t need to guess this up front – we know at any point how much actual time has been spent.
If you mean to ask how decisions can get made about “which project to work on” without estimates – the “quick” answer is: we don’t use estimates to make those decisions. However, this blog is about the concept of “Mob Programming” for doing work, and it is beyond that purpose to cover the details of how decisions are made about what “project” to work on.
Here’s how to do it with measuring effort.
There are 3 ways cost (C) and value (V) could relate:
C V – This is a project not worth doing.
You can treat developer cost as a fixed number for a given amount of time.
Let’s say it is $10000/week for 2 developers.
Now you ask – what is the potential value of this project. Let’s say it is $100,000.
Now we know that we would like to have this project done in 10 weeks with our two developers.
We can ask them to estimate their effort.
They could say 4 weeks, and the actual time needed could be 20. The result is the project gets half done, and cancelled after spending $100K, or best case, cancelled after 4 weeks for $40K. Some shops might finish the project and lose $100K
They could say 12 weeks, the actual time needed could be 4. The result is losing $60K of value.
Or we could start the project, and see how we are tracking after 4 week long iterations.
If it is tracking to completion at 20 weeks – we cancel, and lose $40K – same as best case scenario above.
If it is already complete, great – we are +60K
Without estimating the effort, we are coming out better than with faulty estimates.
As the value deliverable becomes a larger multiple of the cost, the need for estimation becomes even less. For example, if I have a feature I know will bring me $1,000,000 in value, then I should just start working on it, since I will have up two years to get weekly tracking and prediction before it is a loser.
The only place this becomes tricky is when the value of V starts to approach the value of C. Those borderline projects don’t provide much value, and need to be tightly cost controlled to the point where I would question if they were worth doing at all. If it costs me $1000 to get back $1001, there are much easier ways for me to get that dollar of profit.
heh – it did not like angle brackets.
C greater than V
C equal to V
C less than V
is what was intended above.
I can see some applicability of this approach in product development teams, in house development teams, or where the customer has committed to a set budget with a flexible scope. How would this approach work for a software development company responding to published requirements for major projects, ie government contracts. I find this approach can only work with small teams. Any comments?
I don’t see any reason this couldn’t be used for any software development and any size of project. However, in many situations the current state of bidding and arranging contracts for work is contrary to this approach. There are many improvements that could and should be made in the world of “major projects” and “government contracts”. The waste and failure often seen in these “larger” projects indicates to me that we should be discovering and re-inventing the typical approach taken for these efforts.