Every once-in-a-while I come across a tweet that dumb-founds me. I don’t intend to reveal the identity of the tweet’s author (though you are free to search for it if you are really interested) as my issue is with the message not the messenger.
So, without further ado, today’s ‘Twitter Duh of the Day’ is:
If you want certainty around ‘when’, don’t estimate. Invest in an infrastructure that allows fortnightly (or quicker) delivery. #agile #pmot
Without context and an example (that can at least get discussed and critiqued) this is simply nonsensical and nothing more than a meaningless statement.
Think about it!
Shim,
You think too hard!
Attaining certainty on “when” would require a potentially large effort otherwise your answer is “I don’t know”. Don’t estimate and your answer is also “I don’t know”.
Two benefits to not estimating are:
• So save on effort
• You guarantee an adventure.
Patrick Richard recently posted..The Illusion and Promise of Self-Organizing Teams webinar
Haha, I still can’t stop laughing. Certainly the lesson for me is that I need to learn to think outside the box (a skill you seem to easily have).
The tweet did have context. The other tweets preceding and following it. There’s also Neil’s blog (http://neilkillick.com/) where you can find a number of posts about estimation and agile (with an emphasis on Scrum) in particular from around this time. Quite good content from a bloke who actually helps others delivers working software.
Note that I’m not affiliated with Neil by the way – I don’t even know him personally – I just happen to like his work. From his LinkedIn recommendations it seems lots and lots of other people do too.
Great to have you around Zed, and I appreciate the time you take to respond.
I happened to browse through Neil’s blog, which is, BTW, a great one to read. I do however maintain my position that I am unconvinced (just like others who query this approach on Twitter) where the fundamental question of ‘how much $ will it cost me to do X’ is still very much unanswered (at least not in a manner I would find satisfactory).
I am often frustrated by tweets that send a simplistic message to a topic that is quite often complex. On this very occasion I felt (and still feel) that tackling the this complexity with a comment that offers not much in tangible solution is wrong.
Cheers, Shim.
Shim Marom recently posted..Let’s Be Serious About the Agile Manifesto
It’s 140 characters. What detail were you expecting?
Statements like that need to be put in broader context. Unless you’re RT’ing or posting a link to something you can usually find that context. It also serves as a conversation starter.
The problem is that X is never really known. Customers and product owners often delude themselves into thinking that a specifications document tells the project team exactly what’s required. But unless you’re putting one brick on top of another and building a wall, no one really knows what they want until they start. This is why projects have scope creep. As a fellow dev once told me years ago, if there’s scope it will creep. I challenge you to point to a project where the scope was fixed at the beginning of the project and never changed. One where no change requests were raised, no issues arose as a result of discovering how to implement something and everything was delivered on time, on budget and with all the requested features of the original spec. Isn’t that why most people in IT state that you can have two of those three?
Agile still works if the contract is fixed price. Instead of estimating against a requirements document you estimate against a backlog. You estimate story points for all the items in your backlog and from that determine what can be delivered for a given cost based on a predicted burndown. It’s not hard to do. It just means more work up front and the ability to communicate the advantages. If it’s a choice between working software – even if not all the features are delivered due to unforeseen circumstances along the way – most clients would no doubt prefer that delivery over something incomplete.
Neil has his own take on it http://neilkillick.com/2013/02/08/noestimates-part-2-contract-negotiation-and-the-old-banger/. A quick Google search will also help to give more context as well as some interesting stuff others have to say about fixed price agile projects.
Zed, the argument that X is never really known is simply not valid. I take the train to work every morning. Do I know exactly how long will my journey take? NO! It can be anything between 25 and 45 minutes but most days it is around 32 minutes. So if someone asked me how long it takes me to get to work would it be valid for me to say I don’t know as it always changes? Of course not. I could say that my best guess is 32 minutes but I could also add that this could vary between 25 to 45 minutes. If I wanted to be more accurate I could even attach a distribution list, showing the relative probabilities of arriving within a certain time range. This is how estimates are done. You ask someone with experience in the domain to give you their best estimate, based on their experience and quantify and qualify it with statistical distribution. The notion that it is bad practice to estimate just because nothing is ever known is simply an escape from reality.
Now you raise a good question about scope creep, etc.
The fact that requirements change and issues and risks are encountered is NOT an issue that negates the ability to perform estimates. Good estimators will take potential risks and build those into the schedule and cost of the project. I am yet to see organizations agree on the investment of millions of $’s on project expeditions where they don’t know how much it will cost and when it will be delivered.
For the life of me I can’t understand how agile became so dependent on an approach that has nothing to do with either the Manifesto or its associated principles. No where in the Manifesto or its associated principles does it say that agile projects will shy away from estimates. While the issue of incorrect estimates is a universal one, the solution to it is not NoEstimates but rather better estimates and whether it is an agile or non-agile project, at the end of the day, if you want to use someone else’s money you need to be answer some basic questions and then competently mange it.
Would appreciate your thoughts on the above.
Cheers, Shim.
Pingback: The #NoEstimates Movement | quantmleap