Sunday 30 March 2014

What #NoEstimates has taught me

This is a story from a real life scenario. It's about how estimates was turned against me and how #NoEstimates has taught me to act next time. At least, try to act. I.e. explore :-)

The scenario

I was hired as a "resource" (consultant) at one of our customers. Once we had a meeting. They wanted to discuss a new (a larger) change on an existing application. I.e a new feature. I was the one who was going to build it. After discussing their new great idea, the inevitable question came: "Can you look at this and get back with an estimate on the size of this?".
You all know this story, but here it is anyway:
I knew this customer, I had worked with them for quite a long time. I knew they actually said "Give us a promise!". I knew they would complain that my estimate would be "to expensive" and I should look at trying to cut it.
But at the time I didn't think this was something strange, "It's how it is, it's how it's done".
Thus, I got back with an estimate (I actually kind of already "knew" the size, or what I was going to answer, when we discussed the idea). Knowing they would use it as a promise I first got an approval of my estimate from my manager. I presented my estimate to the customer and was very, very clear (did I say very clear?) that it was an *estimate*. They where actually all great with that and didn't even asked if I could cut it. Happy days!
Not. The estimate became a promise anyway. And the estimate turned out to be "wrong". Things took longer than expected (has that ever happened to you? :-) And my estimate was held against me.
As I said, you all know the story.

What I'm going to try next time

I don't work with this customer anymore (for other reasons than my estimates I should point out. It was actually a great customer, even though I don't describe it as one). So, I'm not sure I will be ably to try this approach, but I might try it in another form on other customers.
I should have played with opened cards. Knowing they wanted promises and not merely estimates. This is what I should have said (or at least this is how I feel, now, I should have said):
"I think you want a promise, a commitment, and not an estimate. Is this true?" They would probably not admit this and answer something like "No, we want an estimate to know what this will cost us and when to expect it." I should then try to respond "If it is an estimate you want, I think we should book another meeting and look at the size of this work together. We will then, all, have a shared understanding and a better sense of cost and time." They would probably say "That is not necessary, you are the expert, we believe in your expertise.", me: "Then I believe you do want a promise and not merely an estimate. I then would like to discuss what we should do if my estimate turns out to be wrong, before I provide one." Maybe I would add: "I have a sense of the size of this work already if you'd like to hear? And I believe you already have a budget for this, explicit or implicit, but let's all try to be explicit; may I ask what you had in mind and see if we share that view?"
You have to know that this was actually a very decent customer (even though it might not look like it). Perhaps a customer with some dysfunctions (who hasn't got any?) Thus, I think they would get this. How the discussion would've turned out after this I can't grasp right now. But it's a start. I'll try and evaluate and learn, and try new things again.

Any ideas? Please, leave comment with your thoughts and experiences.

Wednesday 26 March 2014

The NoMeetings Hashtag

This article was removed.
It could easily be interpreted as "mocking" or a "parody" of another hashtag. And it also could be read as a bit "aggressive".
This was not my intention, sorry.

Monday 24 March 2014

Respons to "Estimation Isn’t Agile" article

This is a response to a blog post written by Craig Buchek: http://blog.boochtek.com/2014/03/23/agile-estimation
I claimed, on twitter, that I had this opinion once as well, but have "changed my mind". He then asked me to write a blog post about my thoughts on it. It's a great idea. So, here it is.
I'm going to quote his blog in here, for easier reading.

I don’t believe that estimation should be part of any Agile practice.
Estimates is a powerful tool. Like any powerful tool, you must learn to use it first.
If you can be agile with or without estimates is an opinion, I don't question that :-)

One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).
The text makes me think that the estimates was delivered as "single point numbers"? Estimates should come with a range and probability. There are lots of ways to do this.
Secondly, I think it's time to talk to this manager. She needs to learn how to use estimates as well. It's not only developers that needs to improve. Solve the root cause first, don't "blame" estimation. Her behavior will not get better if you (or anyone) stop doing estimates.

But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.
The reason estimates are treated as commitments or promises is because how we use them and present and communicate them. If they become contracts is up to you.
E.g. if a bunch of developers take half a day (or a couple of hours or maybe days) to come up with a, probably "accurate", number, no wonder the estimates are treated as commitments. Who wouldn't? They don't know how you came up with that number. They think you are professionals!
Instead, deliver a range with probability. Some say this doesn't work. I disagree. It's not uncommon to hear the doctor say: "It's a 70% chance this operation goes well". You can handle that, everyone can handle that. And then you trigger another discussion, an important one: "What's the 30% risk?"
And, some kind of "promise" must be made. The ones paying us to write their software should be able to know, in advance, roughly how much they're expected to pay and when to get it. Why should we not answer that?

Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.
Yes, agile is about seeking improvement. And doing things better. Improve how you use estimates. Improve how you use your tools. That goes for any tool in your toolbox. As I said, estimates is a powerful tool. Learn to use it. Improve, yes.

Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.
This is a red herring. No project should be on time and budget. Then you're doing it wrong. If you hit time/budget, then you A) Was very, very lucky or B) Adjusted things to hit the time and budget. I'd rather have something great a bit late and more expensive than something bad on time and budget. That is, if budget and/or time isn't crucial. But then, I'd have no problem cutting scope.
This goes for everyone. Put on your customers glasses - they'd probably have no problem if you signal, in time, that the estimate seems to be wrong. It should actually have been a part of the risk discussion before project was started. But still, adjust estimates when you know better. Remember: customer collaboration.

Improved Estimation

To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.
Yes, plans change. Estimates change. Embrace change. Don't lock estimates, keep the conversation going. If you must lock them? Get good lawyers :-)

When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.
I agree. Story points are "lousy" when talking to the ones paying you money to write their software. But this is only my opinion. Some use story points, and they work great. Good for them.

Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.
Don't be optimistic when delivering estimates. This is a common mistake. Why not deliver your "worst" estimate? Who will be sad if you deliver faster? Probably the opposite - they'll be glad! Until they've eventually seen through your "scam" :-) And if your'e trying to "win" a project, or if customer wants to decide if a project is "worth doing" then you should *not* provide your "worst" estimate.
So, start by trying to deliver your estimates with ranges and probability.

What Can We Do Instead?

Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?
I don't think so. If we can, great! Please, let me know! :-)
If managers use estimates to create "predictability", they should improve. Nothing will fix "stupid". Other than stop doing stupid things. Stop estimating will certainly not fix that.

I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.
Agree, but this doesn't exclude estimates. You can do this anyway. But, how do the ones paying us to write their software know (roughly) when the thing you're building for them is "shippable"?

What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.
Agree. Nothing to do with estimates though.

Arguments 

1. Why can’t you just tell us how long it will really take?
Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.
No, you don't *know*. That's why we're *estimating*. If someone takes your estimates for "knowing", rethink how you deliver those estimates. Again, you can't refuse the ones paying us for writing their software the right to get a sense of how much and when.

2. But we have to tell our customers what to expect.
Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.
No, they don't need exact dates. Why do you think they do? Instead, stop delivering exact dates. But they do want to know roughly how much and when. And, estimates comes with a probability.
And everyone should/must have a common understanding on what "done" looks like. No chance of success otherwise.

3. But we have to have messaging about new features.
OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.
I don't understand this point.

4. But we’ve promised these new features to the customers by this date.
Ah, so you’ve made promised to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.
Put on your customers glasses. If someone has promised to deliver something to you and they don't, what would you do?
And, you are actually at it. Don't be optimistic when delivering estimates. Common mistake. Also think about how you deliver your estimate, they should not be interpreted as promises.

Risk

Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.
This is a bit of a confusing point. Yes, estimates are risk. Talk about it with the ones paying us to write their software *before* the risk becomes a problem. Customer collaboration. The risk was *not* to ask for estimates. And don't put trust in them. But that depends on how you deliver them, how you communicate them - customer collaboration.
By the way, who asks for estimates? I've never heard: "We want to buy some estimates!" What they want to know, roughly, is the cost and time. How you provide it is up to you. If you can do it without estimating, good for you! But you can't "blame" the ones paying you to know roughly, in advance, how much and when to expect it. Usually/always you must estimate that.

Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.
Agree. Nothing to do with estimates/no estimates though.
Usually, in all other situations you handle "unknowns"and uncertainties by having margins or "buffers". If you want to buy a TV, you have a "roof" price, but you might still adjust it depending on what you find :-) And if you go on a trip, don't you bring "a little extra", just in case? And if you remodel you kitchen, don't you have margins for certain "unknown" costs that might occur? Well, you should at least. And wouldn't you want to have someone, an expert, to point out these "uncertainties"?
Same thing with software. Talk to the ones giving you money to write their software. Let them know your "unknowns" and your uncertainties. Maybe they want to create "buffers" or margins as well. It's called risk handling. And let them decide later if to use them or not - in collaboration with you.

Friday 21 March 2014

#NoEstimates is easy

To discuss #NoEstimates (or #BeyondEstimates, I like it more, but let's stick with the "No" in this article) we first must define what an "estimate" is, before discussing it. Otherwise, we are not going to get anywhere in this discussion. And if we have a common definition of "estimate", #NoEstimates is actually quite easy.

The "broad" definition of estimate

First, I'd like to state that "no estimates" doesn't exist. What do I mean? If you merely look at the definition of the word, estimates are always present and always needed. What is this definition then? I take it from Merriam-Webster, I believe it's a reliable source, correct me if I'm wrong. Here it is: http://www.merriam-webster.com/dictionary/estimate. Read it and get back. 
Done? Great! A note, the definition talks about "cost". This is not the "money version" of cost, it's the "cost" of anything. As in the idiom: "Everything comes at a price" (again, not solely money).
Thus, it's used for making decisions. A decision is about choosing among future paths. And whatever we know about those paths, they're estimates! Simple.
That's the "broad" definition of an estimate. Always present, always needed when making decisions. The "world was once flat" argument is not relevant or equivalent, it's more like "do something has to be, or made, of a roughly round shape to roll?" Yes, it's the definition of "rolling". No one has ever thought anything else.
Thus, "no estimates" - in this definition - doesn't exist.

The "developer" version

But that's not how a developer would define an "estimate". And it's the "developer" version of "estimate" that #NoEstimates is trying to address. In my opinion, I must add.
What is this definition then? I'll give my version:
"The formal delivery of the estimated size of a task/item that is to be done".
I.e. the "process" that goes along with when someone asks a developer to "estimate". One, or usually a team, of developer(s) sit down and play some "planning poker" or whatever he/she/they do to come up with a figure or range.
This process is sometimes waste. This is what #NoEstimates is trying to address.
Note, I said "sometimes". It's not always waste. Sometimes it's actually very useful (depending how it's done, of course - improve!).
And that's why #NoEstimates is easy! Just start thinking! Question wasteful behaviors.
I.e. ask: "In this specific situation, is estimates (as the 'developer version' above) useful?"
An example: someone asks "Before you start working on this item/task, estimate it first!" Sometimes this is not needed. Just start working on it might be the most valuable thing to do. Whatever that reason might be. One example could be that everyone (even the one asking) has an "innate" feeling that the "size" of the item/task is not "2 hours or 1 week, it's something in between" and in this specific situation it's sufficient knowledge to know it's worth start working with it.You could call it an "implicit" estimate. Making it explicit would be better? Yes (see my "final thoughts" in this article). But, we are talking about the "developer" definition of an estimate here.
Hence, that estimate would probably not even be used for anything. Except maybe to use it as a commitment (a promise)?
There are a lot of examples of when estimates can be wasteful. This was just one example.
Some do this already. Some are already doing #NoEstimates. 
Thus, "no estimates" - in this definition - exists.

What #NoEstimates is not

#NoEstimates is not about "Everyone in the entire organization should probably stop estimating!". Because everyone in the organization has their own version of what "estimate" is. Depending on their role. For some, all their estimates is probably useful. And #NoEstimates is not trying to question those estimates.

A final thought

Let's play with a thought. A silly thought perhaps, but still a thought.
What if "the ones giving us money to write software" could estimate software work themselves? What if the "estimation process" then turned into a conversation with those providing us money instead?
"You may say I'm a dreamer, but I'm not the only one" :-)

TL;DR

As a developer I estimate all the time: "Should I write an if-statement or a switch-case? Should I create an abstract class or an interface? Where should I put this code? Should I write a test? Should I use this framework or that framework? Will this or that code be more readable? What will be most maintainable? What will have the highest performance? What will be easiest to write? What will take shortest time to write? etc etc etc"
Hence, "no estimates" doesn't exist. But it's not those types of estimates #NoEstimates is trying to address.

Thursday 13 March 2014

#NoEstimates is not for me, part II

I've written some posts about the #NoEstimates topic. I found it very interesting. And very "giving" and learning. But I've come to the conclusion that it doesn't exist. Why? Let me explain.
But first, this is my definition of "estimate", the transitive verb: http://i.word.com/idictionary/estimate

"Estimates are waste"

Yes, they might be. Anything can be waste. Easy: Stop! Don't do stupid things on purpose. Nothing new or special about that. #NoAnything would apply, or maybe more specific #NoWaste might be a more appropriate tag? Nothing more to say about that.

"Explore alternatives to make decisions in software development. That is, make decisions with 'no estimates'"

Why would you want to do that? Why find alternatives to something obvious? Can we make decisions without meetings? Sure. But why? Meetings are a great way to make decisions. Making decisions with other people is the best known way to make decisions. Why explore alternatives to that? Same thing with estimates. Are there alternatives to the wheel? Yes, you can use an airplane or a boat. But the *wheel*, it's unbeatable, one of the first thing mankind invented, and it's still the best. Why explore?
And, a decision - by definition - is to choose between one or many future paths. And whatever we say about the future - it's an estimate. Can't argue that. Thus, "no estimates" is not applicable when making decisions. At least not in software development.

Update:
If "exploring alternatives" is what we like to do, with the purpose that it's better to have *more* alternatives, then I don't get the "no estimates" either. Estimates are great knowledge when making decisions, why remove that alternative? Why remove any alternative?

"Not getting the question of 'how much/when?' at all"

This I can get. Deliver often and more important: deliver something valuable often. But this is true even when you choose to do estimates. Nothing to do with "no estimates". But if we work this way, the question of "how much/when?" might not come as often (or at all)? Sure. But still. Someone has to pay for the work getting done. That person wants to know, roughly, what he/she is expected to pay. And he/she wants to know in advance. Can't question that. Unless you plan to work for free, this is always true. Thus, "no estimates" doesn't exist. 
In the "smaller loop" (when someone already knows, roughly, what the expected cost is and "the work" has started) you might throw away estimates. This is the only valid point of "no estimates" as I can see. I've done similar things before (without even knowing that "no estimates" existed). But it's close to my first point above. Don't do stupid things. If no one requires you to do estimates - don't! And if this is the only valid point of "no estimates" then it's not much to "hang in the Christmas tree" (as we say in Sweden when something is of not much value).

"Focus on value instead of costs or estimates"

Yes, of course. But this has nothing to do with estimates or "no estimates". You can do both. At the same time. And value is tightly coupled with cost. At least in software development.

"Forecasts is not estimates"

No comments on that. Learn English, maybe?

Final words

I might still be convinced though :-)