The #NoEstimates questions, Part II

Last week we did not cover all the questions on #NoEstimates. Twitter gave us a lot more questions than could be listed last week, and even more interesting ones. Read on for the questions and my take on their meaning.

How do I choose between options or opportunities (without having estimates regarding the cost)?
• Choices are hard to make. When you are deep into the development process you inevitably come up with many ideas. But how should we choose between all those ideas without a detailed estimate? I believe this question implies that we have no way to assess the opportunity cost of selecting one of the options. I propose we challenge this assumption in a later post.
How to win a government contract without estimates?
• A very common question, also present implicitly in last week’s post when a questions asked: How to practice #NoEstimates in companies where estimates are "mandatory"? When the legal framework (or contract) requires you to provide an estimate of the length of the work you just have to do it, of course. But a more interesting question to tackle will be: how do we use #NoEstimates to our own (and the customer’s) benefit even when we have to provide estimates before we can win the contract?
What visual indicators do you have in #NoEstimates to show if you deviate from the "optimum"?
• Are we going in the right direction? Are we progressing towards the goal? Do we have the right features? Will we be on time? There are many implicit questions behind this one. While exploring the answers to these questions, I hope we can generate “heuristics” that are relevant and actionable for people interested in the “end game” for a project or a delivery. Including heuristics based on visualization.
Will #NoEstimates give me better predictability even when not using estimates?
• The holy Grail: predictability. In my view, the temptation is to say: if you have time-boxes you don’t need more predictability, you already have it. However, I think this question goes beyond “delivering on time”. In fact, I believe that this question is about predicting “everything” (scope, quality, cost, length, …) We have to explore what #NoEstimates can help with, and what it can’t help with when it comes to looking into the future.
If I just "play the game" with project managers and give estimates that I know aren't right, am I already doing #NoEstimates?
• This question is perhaps related to the one above where we tackle how to use #NoEstimates in an environment where we are asked to provide estimates. It must be said that lying (providing information you know not to be true) is not right, deceiving is not right - no matter what method you use to manage your projects. I hope to clarify how my practice of #NoEstimates can help you tackle the estimation requests you get, but still benefit from the added information #NoEstimates can provide.
Is there some analogy between SQL/NoSQL and Estimates/#NoEstimates?
• Many people comment on the choice of tag (#NoEstimates) for this wider discussion on estimating and managing projects. It is true that if you look at the hash tag used and the previous SQL/NoSQL discussions there is a similarity in the surface. However, I think there are further similarities between these two movements. I’ll explore those in a later blog post.
Does #NoEstimates aim to change existing social constructs (e.g. capitalism, budgets) to remedy the need to estimate?
• As far as I understand this question explores the possible impact and consequences of #NoEstimates, including on the budgeting cycle and the business models. I don’t think #NoEstimates tries to tackle business models at all, in fact I think it aims to enable more business models. On the other hand, #NoEstimates does try to change the way we look at budgets - project budgets at least - with the aim to make those more transparent and reliable. This topic promises to be very interesting as it has generated a lot of discussion on twitter.
Is it accurate to say #NoEstimates is for projects in Cynefin's complex domain?
• For those of you that haven’t followed the Cynefin model or Complex Systems discussion, let me just clarify that Complex Systems are such that causality can only be attributed in retrospect, i.e. we cannot anticipate how the system will react to a certain stimulus, therefore we must experiment (Probe-Sense) and Respond to the results of those experiments. While I believe that #NoEstimates is a perfect fit for Complex environments, I don’t think it applies only in that domain. There are benefits to be gained in other domains: Cynefin/Complicated, Cynefin/Chaotic and even Cynefin/Simple.
If we elect not to take on the risk of predicting an uncertain future, who do we think should, and why?
• I believe this question is trying to answer: Who should take the risk for the (future) results of our actions? Obviously I think we - the people in the project - should take the responsibility for tackling the project in all its characteristics and risk. I don’t think #NoEstimates leads to a shift of the risk carried in any project, and in fact I believe #NoEstimates approaches can be much more effective at uncovering and tackling emergent project threats or risks. More on this later.
Why would we choose not to judge likely outcomes, when worthwhile human endeavors necessarily carry risk?
• My interpretation of this question is that it asks: Should we even look into the future at all? Equating #NoEstimates with #NotLookingIntoTheFuture is a red-herring in my view. I’ll try to explain in a later post how, in my view, #NoEstimates approaches can deliver a much better model of “the future” for any project.
What is and isn't 'estimating' when people form and act on expectations of an uncertain future every day?
• If I remember correctly somebody tweeted: “how can you say “don’t estimate!” when even the act of getting up in the morning requires estimating?”. Perhaps this comment comes from a misunderstanding of the domain we are talking about when we use the term #NoEstimates. It is important to state that we are using #NoEstimates in the context of estimating large software endeavors (i.e. projects), not simple tasks or even fixed/variable-costs calculations (e.g. servers, bandwidth, person-hours, etc.).

This is the list of questions that I’ve collected in the last few weeks on twitter. I hope to answer them here on the blog with your help. Please contribute to the prioritization of these (and last week’s) questions by leaving a comment below with the questions you’d like to tackle first.

Once prioritized, I’ll start answering those questions and we can have a longer discussion about each of them here. After all, twitter, is a great conversation starter, but we need blogs to develop them further ;) Photo Credit: Brad Hoc @ flickr