Lately I've been involved in a number of interesting conversations regarding agile development, particularly in how it affects estimation and project management.

This is less relevant to internal IT departments, or those developing products. This concerns the world of bespoke software, custom-developed line-of-business applications, where your obtaining work is often less about what you'll actually deliver than the promises you make up front.

An agile refresher

Agile by definition does not constrain scope. It avoids BDUF. It works with the customer to keep development effort focused by priority. Scope becomes fluid, the constant development of the next most important feature. Change is welcomed, as it is only a misunderstanding of what the customer really needed. It is a paradigm shift, an attempt to reverse the trend of failed software projects.

At agile's heart is the rejection of the notion that software can be constrained. It acknowledges that users can't completely define their requirements in a workshop. It concedes that system analysts cannot specify how to build software through UML. It recognises that real requirements gathering begins when developers start building, and start to question what is and is not possible. It embraces the fact that a user will change their mind when they interact with what they asked for. More than anything, it's all about ensuring that the customer gets what they need.

You want an open chequebook?

This of course conflicts with many accepted business practices. Software costs money, and is a significant investment. Decision makers need to know what is required and why. Companies need budget approval. Procurers need a means to evaluate different tenders. Boards need to know how much the software will cost. Up front!

This creates a quandary. Do we concede that we can't tell a company how much it will cost ("yes, we want an open chequebook")? Do we go through the motions of tendering, completing documents that we know are worth little more than the paper they're printed on (but cost more in man-hours than the printer and network that printed them)? Do we estimate what the other tenders will be, and undercut them, dealing with the fallout later knowing that it's easier to get budget extension than initial approval?

NO, none of the above

We educate. We engage with our customer, reminding them of the failures of our industry, and the collective learning of the last decade or so. We ask them what success they've had on software projects recently, and whether what they received matched their needs, on time, within budget. We explain that Agile is about continuous delivery, and that we'd rather take a small piece now and prove ourselves before we've both entered into a contract that will likely fail.

With this small piece we prove our capability. We build a trusting relationship. We bring the customer into our team, involve them in the daily challenges of building software. We surprise them when we smile when we hear that they forgot about the workflow of an entity, and not demand RFCs or other contractual documents. We delight them when we show them that this workflow has been included the next week, and is ready to be used. We impress them by the high quality of our work, and share a laugh over the joys of automated tests.

We demonstrate delivery momentum, and together understand how much software can be delivered in any given period. We share openly what challenges the future holds, and how demonstrated momentum will fluctuate with complexity. We agree to the renewed now-six-month contract, and our development output doesn't skip a beat.

We build on our success, and change the appalling track record of our industry, one less failed project at a time.

But what if they don't buy in?

We leave our contact details, and walk away.