If you have had any involvement with software development over the past 15 years, you will almost certainly have heard of Agile or Agile Software Development. Evangelised by some, it is still misunderstood by many, even feared, and that misunderstanding is holding business back.
Whilst Agile practices have been adopted with great success in many areas, an example of where are they still regarded with some suspicion is in the procurement of software development services from external suppliers.
Agile, as the name suggests, promotes an agile and dynamic approach to software development. In a world awash with stories of budget overruns and project failures; it is much more appealing for procurement to insist on a traditional, fully specified, fixed scope and, usually, fixed cost project. Thus shying away from any uncertainty.
Sadly this approach, more often than not, sets a project up for failure before a developer has written a single line of code.
Why is this? The main problems with this approach are effectively two sides of the same coin:
- The needs of modern businesses evolve so rapidly that as a project is being developed, what was originally commissioned is no longer relevant; in part or as a whole.
- When the end-user and/or the customer gets hands-on with a new application, they gain a new perspective on what is important for the application and their business – Often those features initially thought to be the most important are marginalised and once minor features become truly valuable
Fixing a detailed project specification at the start ignores these facts; resulting in a commitment by both parties to build something that will likely be obsolete or irrelevant upon completion, be it just in part or as a whole.
Traditionally, the answer to this particular problem would be a rigorous change control process; where each change is assessed, specified, designed, costed and added to the existing project. However, this results in a relatively large cost in both time and money, for any deviation from the original plan; so it just exchanges one problem for another.
Agile Software Development was created because this traditional approach just does not work. The Agile Manifesto was created in 2001 by a group of software professionals who believed there was a better way.
Facilitated by management frameworks, such as SCRUM or Feature Driven Development, Agile Software Development accepts these challenges, in fact embraces them, in order to ensure the resulting software applications meet business’ needs.
With an Agile approach there may indeed be an element of uncertainty in the early stages of a project, but that is a reflection of the true nature of all business. Perhaps more importantly; if done well, there does not need to be undue risk.
An Agile project should begin with an honest understanding of the project constraints (budget/scope/deadlines), a high-level understanding of requirements and an agreement between all parties (customer/stakeholders/supplier) on how they will interact throughout the project.
From that point on, the project should progress in small iterations, with close collaboration between all parties and regular incremental delivery of software.
The specific mechanics of this vary between frameworks, but one thing that is common is an insistence on open and honest communication between all parties on every aspect of the project.
The advantages of this type of approach are many, but a here are a few examples:
- Reduction in up-front costs: Whilst there will always need to be some up-front investment, for initial requirements definition and application design; with an agile approach this is greatly reduced. As such, the investment required before the customer receives working software is also reduced.
- Reduced customer risk: Iterative deployments and delivery mean that the customer can review the application early in a project and regularly from then onwards. Should a provider not meet expectations, losses can be cut early. Should a provider go out of business, the customer has already taken delivery of what they have paid for. Should mistakes be made, they can be detected early and rectified before it is too late.
- Reduced cost of change: Without the need for a bloated change request process and providing regular opportunities for change, the cost of change is greatly reduced. Furthermore it should be much quicker to evaluate whether a change is worthwhile, allowing stakeholders to prioritise accordingly.
- Collaborative Approach: The project stakeholders have continuous input into the application as is it built. Working with the development team to build the application, increasing ownership and ensuring key business knowledge is incorporated. The resulting application will not be a nasty surprise at the end of the project, which can often be the case with traditional approaches.
- Applications that evolve with the business: With the regular interaction with stakeholders and the flexibility to change along the way, agile projects are able to adapt to the changing business priorities.
- Building trust: Much of software development is based around trust, particularly between supplier and consumer. Working in small iterations, it allows for trust to be earned by the demonstration of quality and skill at an early stage in the project
I am sure you will agree that, in most cases, these benefits outweigh the uncertainty at the early stages of an agile project. They certainly are more appealing than the pitfalls of a traditional project.
Is Agile a silver bullet? No. Is it without its challenges? Certainly not. What it does is prioritise the building of better software over onerous specification and contractual overheads. That is something that is beneficial to most of us.