Attila Buturla

The hashtag #NoEstimates was originated by Woody Zuill for "exploring alternatives to estimates [of time, effort, cost] for making decisions in software development." What began as a conversation between a few people ( Woody , Neil Killick , and Vasco Duarte ) grew into a much larger discussion. As the year 2015 is now over, let's take a look back at what we learned from the discussion. A lot of different people have participated, each bringing their own unique views and experiences. There is no single "#NoEstimates view"; what one person says doesn't represent the rest of the group. Some argue that estimates should be used more sparingly, others never at all, and yet others that suggest that only under certain circumstances . Despite the differences, there seems to be consensus on the following key points: Software project often fail. Perhaps the use (or misuse) of estimates play a role in this. Estimates are often turned into commitments. This mech...

Recently I was reading a discussion on Twitter about software projects, and it reminded me of something. Many years ago I had a conversation with my dad about moving. After just having moved, he wasn't too pleased with the moving experience. He mentioned that there was essentially two models that movers operated under. The first was you paid a fixed price for the move. I don't remember the exact details, but the movers quoted a price most likely along the lines the square footage of the house, or some similar metric. The other model, was simply to pay the movers for their time. If it took them 20 hours to complete the move, you paid for those 20 hours. Now the catch was, as he described it, if you paid for a fixed price the movers didn't really put a lot of care into the move. They simply wanted to get the job done as quickly as possible. I seem to recall that if they broke something, they would reimburse you. However, that wasn't a pain free process. More importantl...

Software development methodologies have evolved significantly over the past several decades. They once involved a lot of upfront, detailed planning sometimes taking more time than actually writing the software. Today the focus is on building software in small increments, in part to quickly validate assumptions. While some level of planning does occur, we assume less and validate more. When done right, it focuses on maximizing value and as a result eliminates waste. Another significant change is a shift from top down, command and control style project management, to self managing teams. Teams work with a product owner, and in many ways are equals in terms of suggestions and ideas on how improve the product. While the product owner most often has the final say, it is considered a collaborative effort. For best results both parties need to work together to form a cohesive unit. This in stark contrast to the team simply following orders from above. The need to be able to deliver so...

According to a study by CEB Research, 70% of software projects are delivered on time, but only on 38% meet stakeholder's expectations. In most cases the people that use your software will not even be aware of internal project deadlines. Case in point, think of all of the software the you use everyday. You are rarely aware of what the due date was. However, what you do notice is how well the software does it's job. It's it's of low quality, you'll very likely notice right away. Even if it appears to be of high quality, if it doesn't provide any major value to you, chances are you still stop using it. With that in mind, then why do many software projects today have a set scope and a hard due date? When building software for a customer, it's only natural for them to what to know what exactly they are going to get and what is will cost them. That is a very reasonable thing to want to know. Even when developing software internally, there are often similar expe...

Over the past several years agile techniques, including Scrum, have become the predominate way that software is produced in organizations across the world. Of course that wasn't always the case. Early on during the transition there were a lot of hotly contested debates between the pro-agile crowd and the traditional project management/waterfall crowd. Today if software isn't developed using agile techniques it's definitely an exception to the norm. Similar to how there was a transition from waterfall to agile in software development, we appear to be in the early stages of examining alternative ways to structure organizations. And just as there initially was a lot of resistance to agile principles, there is similar resistance to changing organizational structures. Some of the newer concepts include flattening/removing hierarchy , revisiting the role (and need) of management ,  removing centralized authority , and challenging the ways that organizations make decisions just...

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 lo...

For today's blog posting I thought I'd do something different. I'm going to tell a story about a real project that I worked on to help illustrate a point. Some of my more recent postings have focused on the various ways to deliver software, and some suggestions on how best to run software projects. More specifically, I've advocated an approach that focuses on quality of the software over when it will be delivered. If you deliver a great piece of software it can potentially be a game changer. Software can make your company more efficient, or give it a competitive advantage. In some cases it can even impact the lives of millions of people, or potentially make you rich. What's important is getting the software right. Of course you, your company, or your client don't have unlimited funds. There does need to be a balance. But what's ultimately going to determine the success of the software is how well it does it's job. If it doesn't do it's job well...