What is #NoEstimates? If you spend much time on Twitter following agile, chances are you have seen the hashtag #NoEstimates. It jumps right out at you; it's catchy, controversial, and thought provoking. Unfortunately, the name is somewhat misleading, although it does help get the conversation started.
To being with, #NoEstimates does not mean "do not estimate". I can't fault anyone for getting confused by the name, as it does seem to imply that. Rather, to quote Woody Zuill, the originator of the term:
#NoEstimates is a hashtag for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development. That is, ways to make decisions with “No Estimates”.
So just to reiterate, it's about questioning how we use estimates today, and exploring alternatives. It is not a prescriptive process on how to run your projects, or how to make decisions. It'a just an idea that asks a question. That's it.
Now a lot of people have seemed to have bought into that idea and have expanded on it to include their own take and suggestions. That's a good thing; the more discussion and input we have the more the idea can move forward. However, there is a downside to this as well. Unlike agile which has a manifesto, there's no formal authority to approve what is and isn't a good approach to exploring those alternatives. Ultimately whatever practices work best will eventually come out on top. But in the meantime, it does leave to occasional confusion amongst people that are not as familiar with the topic.
This also, unfortunately, causes some issues when it comes to the critics. Any idea worth it's weight needs to hold up to the scrutiny of critics. If it can't, most likely it is not that good of an idea. However, in order to have any meaningful discussion all parties involved need to understand the topic they are discussing. If not, such discussions result in an exercise in frustration. There are some very real critics of #NoEstimates, and I believe at least some of those critics are simply not on the same page with the proponents as to what they are debating.
What are my thoughts on #NoEstimates? I'm a strong believer that what is important in software is quality. Software needs to provide value and do it's job well. Sometimes it can be rushed, but more often than not it takes time to produce quality software. When we focus too much on dates, it often results in sacrificing quality to meet those dates. I've seen it too many times when software was rushed to meet a date, and the end result was that it didn't meet expectations. While we do have to be mindful of time, in the end what matters most is the software itself.
So where do things go from here? Agile had a lot of critics until it obtained wide-scale adoption. There were a lot of hotly contested debates, as the status quo was being challenged. However, in the end convincing the critics isn't really what mattered. The reason the agile was adopted was that enough people gave it a chance and the results spoke for them themselves. As word grew, it spread more and eventually became the commonly accepted way to run software projects.
I'm sure there's still people that don't believe in agile, but that's not really what matters. What matters is that the word was spread and it struck a chord with many people out there, and that allowed it to grow. So yes, the proponents should listen to feedback of critics. But ultimately converting the critics is not the goal. If the idea is in fact a good one it will spread and be adopted. And the proponents simply need to get the word out, and keep the message clear, in the hopes that we can continue improve our software development management practices.
Until next time.
To being with, #NoEstimates does not mean "do not estimate". I can't fault anyone for getting confused by the name, as it does seem to imply that. Rather, to quote Woody Zuill, the originator of the term:
#NoEstimates is a hashtag for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development. That is, ways to make decisions with “No Estimates”.
So just to reiterate, it's about questioning how we use estimates today, and exploring alternatives. It is not a prescriptive process on how to run your projects, or how to make decisions. It'a just an idea that asks a question. That's it.
Now a lot of people have seemed to have bought into that idea and have expanded on it to include their own take and suggestions. That's a good thing; the more discussion and input we have the more the idea can move forward. However, there is a downside to this as well. Unlike agile which has a manifesto, there's no formal authority to approve what is and isn't a good approach to exploring those alternatives. Ultimately whatever practices work best will eventually come out on top. But in the meantime, it does leave to occasional confusion amongst people that are not as familiar with the topic.
This also, unfortunately, causes some issues when it comes to the critics. Any idea worth it's weight needs to hold up to the scrutiny of critics. If it can't, most likely it is not that good of an idea. However, in order to have any meaningful discussion all parties involved need to understand the topic they are discussing. If not, such discussions result in an exercise in frustration. There are some very real critics of #NoEstimates, and I believe at least some of those critics are simply not on the same page with the proponents as to what they are debating.
What are my thoughts on #NoEstimates? I'm a strong believer that what is important in software is quality. Software needs to provide value and do it's job well. Sometimes it can be rushed, but more often than not it takes time to produce quality software. When we focus too much on dates, it often results in sacrificing quality to meet those dates. I've seen it too many times when software was rushed to meet a date, and the end result was that it didn't meet expectations. While we do have to be mindful of time, in the end what matters most is the software itself.
So where do things go from here? Agile had a lot of critics until it obtained wide-scale adoption. There were a lot of hotly contested debates, as the status quo was being challenged. However, in the end convincing the critics isn't really what mattered. The reason the agile was adopted was that enough people gave it a chance and the results spoke for them themselves. As word grew, it spread more and eventually became the commonly accepted way to run software projects.
I'm sure there's still people that don't believe in agile, but that's not really what matters. What matters is that the word was spread and it struck a chord with many people out there, and that allowed it to grow. So yes, the proponents should listen to feedback of critics. But ultimately converting the critics is not the goal. If the idea is in fact a good one it will spread and be adopted. And the proponents simply need to get the word out, and keep the message clear, in the hopes that we can continue improve our software development management practices.
Until next time.
Comments