Tag Archives: scrum

The Meaning of the Word Estimate

The technology business is one of those industries that comes jammed packed with its own set of jargon. You would think that the use and misuse of this jargon is a contributing factor to the reason why so many software development projects are “challenged”.

Not so! In fact, one of the biggest problems with software projects is the collective agreement around what the term “estimate” means.

The English oxford dictionary defines estimate (noun) as:

“an approximate calculation or judgement of the value, number, quantity, or extent of something”

That seams pretty reasonable to me. It is clear that even though you’ve sized something up, it is only an approximation. Unfortunately what others sometimes hear is:

“a binding contract of cost and time, in which every other variable (often scope) can change, but which cost and time cannot”

To be fair, here is what a software developer might be thinking when they hear the word estimate, or provide an estimate:

“a optimistic guess about how long something might take given the incomplete and inconsistent description of something that needs to be built. I don’t ever expect to be held to this.”

I think that the oxford description is probably the fairest, where those doing the estimation need to give their best estimate, and take reasonable steps to clarify unknowns, but those receiving the estimate need to acknowledge that given imperfect knowledge, the resulting estimate will also be imperfect.

The real question is – given an imperfect estimate, who carries the risk and reward when the estimate is wrong. In our industry many customers believe that vendors should provide fixed-price estimates, and that any additional costs should be worn by the vendor.

In some cases the vendors accept this if only to avoid the uncomfortable conversation about the true nature of risk in software projects and structure in punitive change control clauses.

I prefer to get a good collective understanding of what an estimate is, and in the case of a particular estimate put some boundaries around what the estimate includes and what its relative strengths and weaknesses are.

Further, we have to acknowledge that way more than the envisaged scope for a project goes into producing an estimate. More often than not there is a critical business event which sets a deadline for a particular project (e.g. a legislation enforcement date), or a budget constraint (we can only afford 12 months of development at a certain team size).

Budget is usually the big one. A customer will typically only have a finite budget, so the project simply can’t cost more than that. The question then becomes what can you fit within that budget.

The challenge then becomes producing something of value in that budget. And that is also where the real risk is. You see if you can produce something that returns sufficient value for the money spent. If you can balance money spent, with value received as you progress with a project then there is very little risk of the project being classified as challenged.

For this reason I prefer T&M style projects where the project team has to actively work with the customer to provide value. When the value stops arriving, then the project either stops or changes direction.

At the end of the day, software development isn’t about estimates, and the vendor and customer getting one over on each other, it’s about trust. Trusting that the vendor is bringing the right technical skills to the table and working as fast as possible whilst achieving the quality outcomes the customer expects, and trusting that the customer will be engaged enough to direct the scope and priority of the project, and that the money that is being spent is going into something worthwhile.


Nine Years of Application Lifecycle Management

When I first started working with .NET in 2000 the “process tooling” for the platform didn’t exist, heck the platform wasn’t even released. It didn’t take long however and immigrants from other platforms were getting involved building out the tool-chain required for agile software development, including build scripting languages, unit test frameworks and CI build engines.

Having come from other development platforms I was familiar with the alternatives to these tools and was comfortable stringing them together and I adapted my knowledge to work with .NET. From my very first .NET project I made sure that assets were in version control, that builds could occur automatically and that we got a shippable product every time someone checked in. My tools of choice were NAnt, NUnit and Draco.Net, CVS and/or Subversion.

I introduced these tools to many software development teams and they appeared to help the team produce software on a regular basis. This is really when I started to “care about ALM” although the acronym ALM wasn’t really defined back then.

In late 2004 I became aware of a new product that was being developed at Microsoft (code-named Whitehorse from memory). It was set of extensions to Visual Studio which brought team collaboration directly into the IDE. It combined Microsoft interpretations of all of the above tool-types and baked in one of a series of development processes.

Around the same time I had started experimenting with Scrum as a way of focusing development teams that had been under-performing (for various reasons) so the idea of a product that combined a process and tooling appealed to me. Of course Team Foundation Server and Team Explorer shipped with an updated version of Visual Studio and I changed from being an ASP.NET MVP to an ALM MVP.

Fast forward to present day and I am just as interested in ALM as I was back then, the big difference is that the tooling has improved significantly (including cloud support) and now has direct support for Scrum as a methodology in product. With these new capabilities the expectations on teams have increased and we are now talking about DevOps as a way of reducing the length of the feedback cycle.

Agile methods themselves are now finding their way into enterprise organisations (even outside of software development teams). This is creating a demand for training and certification so that businesses can have the confidence that the new methods are embraced and well understood.

Nine years in I still think that ALM tooling, and good agile processes are the key to successful projects (good people helps too!). Looking forward to what the next nine years brings.