I probably have misinterpreted how the questions should be used, but here it goes anyway.
Here are my answers:
b: to determine roughly the size, extent, or nature of
c: to produce a statement of the approximate cost of"
Here are my answers:
- What are estimates, anyways?
b: to determine roughly the size, extent, or nature of
c: to produce a statement of the approximate cost of"
Source: http://www.merriam-webster.com/dictionary/estimates
In software, it's usually perceived as the act of guessing how "big" something is. Usually disconnected from the business needs (those buying the code we write), but I'll get there.
In software, it's usually perceived as the act of guessing how "big" something is. Usually disconnected from the business needs (those buying the code we write), but I'll get there.
- Are estimates useless? wasteful? harmful?
They might be perceived as those things. Usually because they are disconnected from the business needs (those buying the software). We need to collaborate and communicate better. If you produce estimates down a "promise chain", and you're at the bottom, of course that's what you'll feel. But does that make estimates wasteful and harmful? No. The use of them might be. But can be avoided with better communication and collaboration (internal and external).
If they are percieved as the things above (i.e. as a "weapon" and not a tool), you are probably a victim of "dysfunctional management". Don't "blame" estimates for that. And, starting with (or even trying) "no estimates" will certainly not stop this "dysfunctional management". It might even make it worse.
A "thing" cannot be harmful, only human behavior.
- Who needs them? Who is asking for them?
In the end, or directly, those who is going to pay for the code you write. They want to know, roughly, how much and when to expect what they pay for. Usually that is missed down the chain.
- Why do we think we need them?
Who are "we"? Developers? We don't really need them. But they might be a great additional tool when e.g. discussing the complexity of something, read more here: http://eirabrunstad.blogspot.com/2014/01/no-estimates-hype-or-not.html
I like to have more options, not less, so removing estimates ("no estimates") as a tool seems unpragmatic, in my opinion.
- Can we have successful projects without estimates?
Not sure. Depends on domain and context. And what is "successful"? To me it's about delivering something my customers are happy with and hopefully provides expected value to them. But if we deliver late and over budget, they are of course not going to be happy. But customer must feel that the "cost" put in to it is less than the value it provides. Both must be estimated beforehand, otherwise business (those buying our software) can't evaluate if it's worth starting the project at all.
- When will this be done? How much will it cost?
Estimate it. Those buying the software wants to know. Of course they want to know. It's their right to know, it's their money.
If you can give a sense of cost and time without estimates, please let me know.
I've often heard: "Fix budget. Define cost and let scope flex." But if I was a buyer of software, that's not how I would prefer it. Not always at least. And how will that solve any problems? How do we avoid customer adding lots of scope? The cost is defined - let's add! Or, how do customer knows what they have in mind will be done in time and available for the cost defined?
The "problem" will just be pushed to another place, "same sh*t, different name".
- How can we decide if we should do a project without knowing the cost?
Flip coins? :-) Jokes aside, there might be occasions for this, but they are probably rare. I don't even know any.
I wouldn't want to do anything without knowing the cost of it. I'm a DIY. I always "require" estimates from myself. Why? To know the cost and value for different solutions. Why? To determine which way to go. I.e. which project to start now, and how to do it.
I don't think software is any different. I write code as well, and writing code is just as uncertain as remodeling my old house :-) But a rough sense of cost and "benefit" I certainly want before tearing down a wall. To not mention my wife :-)
I don't think my customers reasons any different.
- Is NoEstimates better than MoEstimates?
Less is more :-) Not having any estimates at all (no estimates) seems worse than swimming in them. At least as a buyer. But if I (as a buyer) is going to pay for the estimates, I'd like to have "enough". Enough so you, as a provider, feels comfortable with them. Up to a level where I will not be certain you know what you are doing at all :-)
- How expensive are useful estimates?
Very context depending. In my domain, they are not very expensive. We could (and should) improve how we deliver them and communicate them and collaborate them. But expensive? Not very, in my opinion.
- How useful are inexpensive estimates?
Ours are pretty inexpensive, and useful for our customers. Useful enough so they can decide.
Consider "blink estimates": http://dannorth.net/2013/08/08/blink-estimation/
"Gut feeling" (instant) estimates are actually very useful.
- If it takes you “no time” to do estimates, are they of any value?
"No time" I interpret as "blink", thus see previous answer. They are valuable. Wouldn't write a contract based on them, but valuable? Yes.
Some say "gut feeling" or intuitive estimates are not estimates in that sense. I might agree on that, at least I know what they mean. But, even if we do "implicit" estimates, why not make them explicit? What's wrong with that?
Some say "gut feeling" or intuitive estimates are not estimates in that sense. I might agree on that, at least I know what they mean. But, even if we do "implicit" estimates, why not make them explicit? What's wrong with that?
- If estimates are waste, would you still do them?
No. Of course not. But are they? Really?
- Is the reason you do estimates because “someone requires I do estimates”?
No. Customers wants to know what they are expected to pay and when to expect it to be finished.
I can still see how some organizations fail to communicate the need for them. But fix that. Don't start (or try) "no estimates" first of all. Communication and collaboration will get you to a point where you see the real need and use of estimates, why we provide them and what they are used for by those really wanting them.
- Why do they require you to do estimates – is it because someone “higher” is asking them for estimates?
No. But I can see how this can be in some organizations. But I've covered this. You won't fix "dysfunctional communication and collaboration" by starting with (or trying) "no estimates". Fix the other things first.
- When someone asks for an estimate, what do you do?
I make sure they are connected to real need (time and/or money or prioritization of items based on effort vs value). In my domain they usually are.
A good approach would be to ask what the estimates are going to be used for and who is the real receiver of them.
- When estimates don’t work well for us, should we just get “better at doing estimates”?
No. Do a root cause analysis of why estimates isn't working for you. I bet you will see the root cause as "bad communication (internal and external) and collaboration (internal and external)".
- If estimates are useful and easy to do, why do we still have so many problems with estimates?
They are not easy to do. Is programming easy? If we are skilled enough to write software, we should be skilled enough to estimate the effort to write it as well.
Why do we have problems with them? Again: "bad communication and collaboration".
- How would you plan a project if you were NOT allowed to do estimates?
The same way as I do today. Define what "done" looks like (in collaboration with customer). And in which order things needs to be done, and prioritize valuable and/or "risky" tasks first. And discuss project risks overall
If you ask how to schedule a project and connect resources without estimates, I have no idea.
- Can you imagine any reason why estimates might be harmful?
No. Only the use of them. A "thing" cannot be harmful, only behavior can be. Considering doing away with estimates (no estimates) won't fix the reasons for harmful behaviors.
Remember the "statement": "Guns don't kill people, people kill people". That statement is actually true, but contains a big error. See it? Well, guns are designed to kill. There is no real usage of guns except killing (well there are some sports made up around gun shooting, but that's basically playing: "who's the best at killing most efficiently"). That's not the thing with estimates. Estimates aren't designed to be harmful. They have been around since mankind (heck, even animals estimate). But are they harmful by nature? No.
Remember the "statement": "Guns don't kill people, people kill people". That statement is actually true, but contains a big error. See it? Well, guns are designed to kill. There is no real usage of guns except killing (well there are some sports made up around gun shooting, but that's basically playing: "who's the best at killing most efficiently"). That's not the thing with estimates. Estimates aren't designed to be harmful. They have been around since mankind (heck, even animals estimate). But are they harmful by nature? No.
- Can you imagine some better way?
No. There might be alternative ways. But better? Don't think so.
- How important are predictions?
Very.
- Can you “sell” programming without estimates?
No, not in my domain at least. More important question: is buyer willing to pay for programming without having a sense of how much? It's not the "seller" who gets to dictate the rules. It's not his/hers money. "Customer is always right".
If we can "sell" programming without making estimates I would be happy to know how that can be done.
- What about estimating the “value” of a feature?
Yes, that needs to be done as well. Business (or "buyers") do that already (hopefully). Anyway, it's not your money. But let's try to keep communication and collaboration open. That goes for everyone.
- Are there things where estimates make sense?
Yes. Lots. I've written about some already: http://kodkreator.blogspot.se/2014/04/useful-estimates.html
- What is “No Estimates” anyway?
Exactly, good question. I don't really know. Usually it's interpreted as "refuse to estimate" and/or "estimates are always waste". But I think it's not. Don't really know how to approach it though...
- If estimates are good for some things, does that mean they are good for everything?
No, of course not. But estimates are very often present in everything we do in life. "How much shall I eat? When? Will I make it to the meeting in time? Can I afford this? Is it worth it? Can I cross the street before that car gets here? Will this thing fit here? Will this code be more readable than that? Will it be more maintainable? Will it have good enough performance?" etc etc.
We haven't found a better way to "create letters on some media" to communicate and/or document some text. Should we seek ways to stop that and try better ways? Maybe, not sure it's sane though. I believe estimates are the same. We have even been doing estimates longer than we've been creating letters on some media. Why should they go away now?
- Does “No Estimates” mean we don’t use estimates at all?
No. But where do we use it and where should we not use it? How should I, as a developer, approach it?
- What are “Whole Team Estimates” and does it help at all?
The team sits and estimate together. Collaboration is great. So yes, it helps. Better up would be "Customer collaboration estimates", i.e. estimate in collaboration with customer. Not sure how that can be done though.
- If you are estimating about work you don’t yet understand to be done by someone you haven’t yet hired, is that meaningful?
No. If you don't understand enough, collaborate with customer: "How do we progress?" Everything will be great if we start communicate and collaborate.
The team/developer building the thing should get a chance to estimate it again. Or the team/developer estimating should be the one(s) building it. Important "rule". Poor management if that doesn't happen.
- How much are you willing to invest in estimates to get useful information from them?
That depends. Talk to customer. Collaborate and communicate. It's their money. "Spikes" and "Proof of Concepts" are some tools to gain knowledge for better understanding or build prototypes or mockups. But those needs to be estimated as well, "How much should we budget for a PoC?". But that's approaches to be able to produce more accurate estimates.
- Does it matter how good estimates are: are “wild guesses” good enough?
Why make "wild guess"? If uncertain, talk to costumer. Collaborate.
- Are the decisions you are making that are based on estimates good decisions?
Yes. Depends on how the estimates are delivered, under which circumstances and by whom.
No comments:
Post a Comment