Selling Agile to the Business

Agile can mean many things to many people, and that is often the crux of the issue when trying to sell the benefits of its approach to any business. To some it's a software development methodology, to others it's a way of thinking and to a few it's a cult that only the enlightened may join.

The best way to view Agile is as an idea of incremental business value that the business can stop paying for at any time, and in theory, always have something that does something.

The key selling point for Agile is that the stakeholder gets to prioritise issues, and you give him quick feedback by delivering frequent releases. This way he can find out if he made a mistake in the requirements before it costs him 6 months of development time.

There are already a growing multitude of books and articles on the web which dictate a specific Agile methodology; XP, Scrum, DSDM and Crystal being just a few. However every organisation and every team within an organisation are different; enforcing conformance to some pre-determined monolith is likely to bring out as many minuses as pluses.

Many of the projects that I have worked on, or managed where Agile has been used, have almost grown organically. Typically existing ways of working are either shown or known to be at fault and by adopting part of an Agile methodology benefit can be shown to provide improvement. Then the door is open to demonstrate increased benefit with further adoption. The only other option to this I have witnessed is where the whole team were existing agilists and the project was entirely green field. Even then the team adopted pragmatic agile method components were deemed they were needed.

It is best to look at the whole process space within an organisation, Agile is about software development/delivery, but you may struggle to fit it across a whole company. This is often where the need for a process toolbox is required; pragmatic selection of the best parts of various processes best suited to the needs of the various organisation units.

The process space can be defined as the set of all processes required by different levels of an organisation and the interaction between those processes.

• Different levels of an organisation need different processes.
  • Programme Management need gated status reports
  • Project management need exception planning
  • Developers need to know what is going on
• Different Processes therefore appeal to different organisational levels
  • Prince 2 for Programme Management
  • Unified Process ( Rational or Enterprise ) for Project Management
  • Agile for Development

To sell Agile to any business you first need to identify the key stakeholders, those individuals within an organisation who make the informed decisions, and who are listened to by the herd. These are not necessarily senior management, they could be a well respected developer, or architect, or a manager with a reputation for success and delivery within an organisation.

These individuals can often illicit a huge amount of information on how projects are run within an organisation, the major problems, the major successes. They will often be willing and open to listen to new ideas, especially if those new ideas can be shown to benefit the organisation as a whole.

Once you have the ear of the key stakeholders, you need to start selling the big picture benefits of Agile. Any software development project has distinct phases ( initial idea, evaluation, construction, validation and deployment ), what is required is a flexible use of these in a framework which

• Provides rapid feedback of progress.
• Can pro-actively re-act to changes by the customer.
• Deals with a risk first approach, so that big problems that could affect the whole project are dealt with in the early stages of the project.
• Provide gated milestones on which the progress can be measured.
• Requires continuous and constant customer input and feedback to ensure the project is delivering what is required.

This approach can be summed up in the beliefs and approaches put forward by the Agile Manifesto ( http://www.agilemanifesto.org/ ) which believe there is a better approach to software development and has spent many man years proving it. The approach can be summed up in the following points :-

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

This breaks down into an approach centred on Iterative Development. A project is broken down into lots of small steps. Each step may look like a Waterfall project in its own right, but only lasts 1 - 2 weeks. At the end of the iteration, a fully working system is available. In the early stages, only as a prototype to view progress, but as the project continues the system becomes more and more like the end product.

By breaking down the project into lots of mini sub projects a number of benefits arise. Every few weeks an entire project is completed, management begin to receive continuous and repeated feedback on the entire project. This approach allows for a risk first development. The highest risks to the project are those which are addressed first in the initial iterations. The areas of greatest unknown are fleshed out and expanded on at the beginning of the project. In the extreme, it quickly becomes apparent if the approach taken can actually deliver, or whether a significant change is required in the project.

Compare this with a typical large scale Waterfall project, in which development may not even be addressed until months or years after the project started. What happens then if the initial assumptions for the development of the software, which will have influenced analysis and design, suddenly turn out to be unachievable.

By building a new version of the product, each week or month, customer interaction becomes a stable part of the project, rather than a customer stating the requirements, and then waiting for development to be completed. With Agile they become part of the team, they become involved in all of the decisions within a project, providing feedback and correction as the project continues.

Finally change can occur, its a fact of life so get used to it. In Agile, change is accepted, in fact to certain degrees it is encouraged and controlled. Change can come from many directions, and an iterative approach provides the ability for the project to accept it, and then change the focus and/or direction of the project as required.

Agile development, rather than present an idealistic approach presents a pragmatic approach in which ever changing needs and drivers are recognised. It also recognises the fact that software development is still in its infancy although maturing slowly. It is time the software industry faced up the realities of software delivery. Projects which take months or years to deliver, in an industry which measures itself in weeks between technological change and revolution, need to adapt or die.