Attila Buturla

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

Creating working software is relatively easy. Creating high quality software that exceeds expectations is hard. In my last two blog postings I've discussed the challenges of managing software projects, in particular when dealing with external customers. On the one hand a customer wants to know how long a project will take and how long it will cost. On the other hand we simply don't have accurate ways to measure how long a project will take, due to all of the variables involved. One can try traditional project management techniques to pretend to know how long a project will take, or one can use agile techniques which don't lend themselves to determining the cost all up front. I fully understand why a customer wants to know how much something will cost. When I go to my mechanic with a problem, they provide me with an estimate of what they think is wrong and how much it will cost. Of course once they pop the hood and start working they often find unexpected issues, and the

In part I of my blog posting on estimating agile projects, I discussed how a prior employer attempted to use waterfall techniques to ensure that customer's projects were delivered on time and on budget. In the end the waterfall project management techniques added a lot of overheard with negligible benefits. Of course this was just one company's experience. Having said that, I worked for several more companies that also used waterfall techniques and those techniques rarely resulted in software projects that were on time and on budget. On the contrary they added a lot of overheard and did little if anything to improve the quality of the software. Within the last few years agile practices, including Scrum, have become common place in software development. I first used Scrum about seven years ago, and immediately saw the benefits. The focus was on producing usable software, while detailed specs and projects plans were no longer needed. At the time I worked for a company that was

Over the course of fifteen years as a software developer, I've worked for nine different companies. They ranged in size from under fifty employees, to over a few thousand. They spanned many different industries including financial, medical, retail/e-commerce, and custom software development.  While they each differed in many ways, one thing was constant; as software developers we were required to provide estimates for how long it would take to develop our software. In particular, three of the companies that I worked for were software consulting shops. By that I mean we wrote custom software for our customers. In these cases getting software estimates wrong didn't just make the team look bad; they could be the difference between the company making or losing money on a project. If too many projects were underestimated, it could potentially result in financial hardship for the company and ultimately even layoffs. The first software consultancy that I worked for was back in 19