How does this correlate to estimates or "no estimates"? Well, in many cases estimates becomes just that: promises. It shouldn't, because is just an estimate, but can you avoid it? Have you ever given an estimate that didn't end up becoming a promise of outcome? Well, lucky you, if so :-)
Because when asked "How long do you think this will take?" simply honestly say what you think. It's as easy as that. It shouldn't be more complicated than that. It's an estimate, god dammit! (sorry about that rant...)
But, the problem arises if you give them a number (or a range, for that matter). Because it's very easy for that number/range to become: a promise. And more specific: a promise of outcome. And the problem becomes even larger if that number starts to travel up to the organization. It becomes a "promise chain", and you're, unfortunately, at the bottom. This is nothing strange really, it's human behavior.
So, what can you do? Easy. Don't give a number/range.
Wait a minute... Will that actually work in business?
No. I'm sorry that won't work. People need that number. So you have to give that number. And you will (one day or another) get in to trouble. It's as simple as that. Well, to be honest, if you get in to trouble it wasn't because of the estimate, something else is wrong or dysfunctional (and that's my version of #NoEstimates, as in: "It's never the estimates fault", but people don't seem to buy that :-)
So, to get around the problem you can try to pad that number and talk about margins, probabilistics and all kinds of stuff. But I'm sorry, it makes no difference. It will still be a promise of an outcome. And since you can't possibly *know* the outcome, it's always a risk.
Sure, if you're very very confident (like 99.99%, can you ever be 100%?) you will make that number, give that promise. But how often are you in a situation where you can be that confident for software you're going to write? If you think of it, you're always too optimistic and, at best, give maybe 50/50 chance. Read more here "My estimates are too optimistic" And if you would start to give higher confident estimates (to give a "promise of outcome" I'd say you need to go up to over 99.99%) your customer will probably say "That's way too much money". And then all you did was to help them abandon the project. Or you resort to promise an outcome with lower confidence = RISKY!
And I would even claim that if you (with customer) don't come up with other ways of solving the problem or that you (with customer) learn something - along the way, as you *do* stuff - that will make the solution even better than what you initially thought, it's probably a failed solution. At least it's a mediocre solution if that happens. So, the only thing you *know* is that things will change - if you (with customer) wants to build better. This is basically why most companies abandon waterfall and go for agile; you can't know in advance what you want, so it's better to iteratively work the requirements as you go. But how can you ever promise an outcome if you *know* it will change? Easy, you can't promise that.
What to do?
I'm sorry, there's probably nothing you can do. Give numbers and get in trouble :-)
Actually there are ways of working that minimizes or even eliminates the need for someone to ask for numbers. But that is out of scope of this article.
Still...
If it's possible there's something you *can* do. I'm not saying it is possible in your scenario/situation, it's up to you to decide.But you can decide how you want to lead your life. It's up to you. If you give promises of outcome it may affect you or others negatively. Working long hard hours, neglecting family and friends to meet that promise you gave. It creates pressure and stress that will lessen quality of what you build and will increase the technical debt. And more. All in all, promises are powerful stuff. It affects you heavily. But you can choose how to live.
You can choose to say no. If it makes your life better. It's up to you. And good people will probably appreciate someone who says no.
What do I mean by saying "no" in this case?
If you are going to estimate cost/time. Require that the person asking gives *you* an estimate first. An estimate of benefit or a budget and when it has to be done. You can call it "real constraints". And then all you (together) have to do is to see if what you think (yes, an estimate) is close to what they think (yes, an estimate). If it is close, then there's a risk. Simply discuss this risk then. Solve it together. Probably you (as in: you and your customer) will end up cutting scope to a point where you feel comfortable you *can* promise an outcome (that 99.99%). And if everything works smoothly (how often does that happen?) there might be time left to add small improvements one by one (this is close to the approach I talked about earlier, on how to not getting a request to give a promise of outcome at all). Hence, this scope cutting can result in a half MVP (Minimum Viable Product): a PYNPO (Product You're Not Proud Of), or even a half PYNPO: the PYMTGO (Product You Managed To Get Out). :-) Then work from there.
Or maybe not. Maybe you are comfortable to say something like: "I see no problem to get this done for that price and/or that time." Sure, that's a promise. But if you know you *will* make it (fulfill promise of outcome), unless you get run over by a truck or get your hands cut of: make that promise! But how often are you that certain of your promises of outcome in software development? Given you cannot know in advance what you will learn and improve and adapt to as you go along.
Or you (as in customer in this case) can agree to "live with the risk". Simply "Let's do our best. If it succeeds, it does. At least we have tried and has gotten something." I've actually worked like that in many cases, when something started a bit (or way?) too late and cutting scope is not applicable. If you're honest, customer is usually fine with that, they know they started late and can't require you to do miracles just because of that.
Bottom line, avoid signing contracts that acts as promises of outcome. It can be done. And remember "Customer collaboration over contract negotiation" is being agile.
I've also written another blog post on almost the same topic: "What #NoEstimates has taught me"
Risk sharing
I've mentioned risks. And in this case it's about "risk sharing". You both take a risk when getting into a project with only "I think this can be done within this time/budget, but I can't promise it". If you think of it, risk sharing (in itself) is actually fine. Because it is a promise of behavior: "I promise to ___ if ___ happens". That is all fine. It's an easy promise to keep, if you know you will do ___ if ___ happens, that is :-)
So, how do you come up the figures of what ___ is? That is up to you. But do you have to put up figures there..? Think about it.
No comments:
Post a Comment