About Agile Development

Agile Development is a concept rather than a formal “methodology”.  Agile Development accepts that requirements can evolve during a project lifetime, acknowledges that this is unavoidable, and suggests that project processes should be set up to welcome and accommodate this change, rather than try to restrict or avoid the inevitable.

Acknowledging and accepting that requirements change during a project – and that this needs to be dealt with rather than avoided – Agile Development focuses on putting in place the right people, the right communication between them, and the right technical processes to accommodate vague and volatile requirements.

Specifically, Agile Development encourages a change of approach in the following three areas:

• First, it encourages close and continuous collaboration between business and technical teams to facilitate continual review and feedback of the solution as it develops. It also encourages frequent delivery cycles to support this.  Giving software developers a high degree of freedom and responsibility to make design decisions and “get things done” is also encouraged, which emphasises the need for a high-quality (skilled, experienced and motivated) development team.
• Second, it prioritises working software over detailed documentation.  Large requirements documents produced prior to development are often too abstract or too vague, and become inaccurate over time as requirements change or evolve.  By contrast, functioning software that has been tested by end users is concrete and tangible, and solicits accurate and specific feedback on the real requirements and whether they have been satisfied.
• Third, it encourages high quality technical design and software architecture. This ensures that the end solution is flexible and “future proof”, minimising the cost of accommodating future requirements, foreseen or otherwise.

Agile Development – the Client’s Perspective

Agile Development can be attractive to you as a client if you aren’t clear on your project requirements and need to see an initial prototype “for real” before you can form a detailed picture in your mind of what the end product should do and how it should look.

Agile Development is also attractive if you previously invested in consultancy services for “requirements analysis”, only to receive large amounts of documentation that did a poor job of describing the requirements.  Worse still, perhaps this documentation only made sense to the consultants who produced it, eliminating your options for switching suppliers between the requirements and development phases.

But how do these attractions compare to the commercial risks of engaging a supplier that is proposing to follow an agile process?

The Cost of “Going Agile”

Most discussions around Agile Development tend to focus on the project and technical processes, rather than the commercial or contractual aspects.  But as a project owner, you will also need to agree and secure budget and manage commercial risks. Agile Development is proven to deliver successful end products, and to provide efficiency improvements in software development teams. But how does it give you any certainty that for a spend of X you will be able to deliver Y?

A lot of Agile Development thinking today assumes a “time and materials” style of engagement, wherein you will buy a team of resources that run an agile process, rather than buying a specific end product for a specific price.  But what if you have a clear idea of the customer need and the end product that is required, and want a fixed cost for the entire delivery?

A traditional approach starts with a requirements analysis project, arriving at a requirements document and a fixed cost for development (but fixed only if the documented requirements are adhered to).  By comparison, an agile approach is usually more opened-ended, with development activity starting earlier in the process and continuing, at variable cost, until an appropriate solution is delivered.  The traditional approach relies on the accuracy of a rigid set of requirements to establish firm costs, while the agile approach does not address this at all and provides little certainty with regard to costs.

Agile Development attempts to address what happens in the real world of IT projects.  But in the real world of business projects, you need to engage with suppliers in a way that combines both old and new to give you both the flexibility of an agile approach, and the cost certainty of fixed requirements.

Client/Supplier Risk Sharing

Allowing one variable to change (the project requirements) while fixing the other variable (the project cost) is only possible with a degree of risk sharing between client and supplier.

Your challenge as the client is to find a supplier that is willing to share a sufficient degree of risk on the project.  The supplier must to be willing to commit to a fixed cost (or narrow cost range), to deliver an end product based only on a high-level business requirement or product concept, while using an agile approach to development.  The supplier must be willing to accept a degree of requirements change, with no impact on cost, as may be necessary to ensure a successful end product.

The onus is on the supplier to propose a fixed cost that incorporates their risk factors and can absorb changing requirements.  Meanwhile, the onus is on the client to use the arrangement to deliver a successful end product, not to extract the maximum amount of work for the fixed cost.

Four Rules for Agile Success

In conclusion, if you adopt Agile Development, use the following four rules to ensure your project is successful, both technically and commercially:

1. Only engage with suppliers who provide highly experienced and motivated development teams and whom you trust to do the right thing. Worry about the team you will be asked to work with, not the process that they will follow.
2. Expect continual development with frequent release cycles that deliver incremental functionality in the most valuable areas. Expect to see progress early on, in the form of a real, working solution.
3. Expect your supplier to share the project risk by committing to high-level project costs and deliverables, up front.
4. In turn, share the risk with your supplier by using them to deliver the best possible solution in the agreed timeframe. Be prepared to de-scope requirements in the interests of higher priorities, rather than just attempting to maximise the work received for a given outlay.