A customer's guide to agile software development: part 1 - what is agile?

A customer's guide to agile software development: part 1 - what is agile?


Author: Michelle Sherwood

Agile software development is fast becoming a mainstream development methodology and has seen a steep increase in use over the last decade.

For example, SAP, Microsoft and IBM have implemented agile development components and/or practises and, more recently, in 2012 Hotels.com moved to agile development principles.

In part 1 of this guide, we provide an overview of the agile development process.

What is agile software development?

There is no definitive definition of agile software development, but it uses methods based on iterative and incremental development.

This type of development does not define the solution (i.e. via a specification). Instead, the supplier and customer work together to write business or technical scenarios; for example, problems a customer has that require a solution (the 'scenarios'), and the supplier will assess how to solve or fix them.

What is the agile development process?

A customer looking to purchase an agile solution should familiarise itself with the agile software development process and not be put off by the technical jargon used:

  • The customer and the supplier will write the scenarios.
  • The scenarios are put into the product backlog (i.e. customer's high level requirements), which determine the features that go into each 'sprint' (a micro-release of software/development output).
  • The scenarios will be assessed and the customer will decide which scenarios it wants the developer to address in each sprint, these make up the sprint backlog.
  • The scenarios will be ranked, i.e. each scenario is given points based on the difficulty and time that scenario will take to solve/de-log, defining the complexity of the scenario.
  • The parties will define how the scenarios will be delivered and identify the timeframes for deliverables to be submitted or achieved, i.e. setting the scope and timeframe for each sprint. A sprint can be anything from 24-hours to a month in length, but are restricted to a specific duration.
  • The parties will hold planning meetings to identify the tasks, goals and commitment for each sprint. The customer will identify which product backlog items it wants to be used and/or completed within each sprint and the supplier will confirm what it can commit to and place this in the sprint backlog.
  • Each sprint will include any applicable testing, and by the end of each sprint there should be a completed step or portion of the software product.
  • At the end of each sprint the parties will hold a meeting to review progress, lessons learned, and decide whether to redefine or amend future sprints. Uncompleted items return to the product backlog.

Waterfall versus agile

Waterfall software development is seen as a steady flow downwards through phases such as analysis, design, implementation, testing, integration and maintenance.

As demonstrated above, agile development represents a departure from this traditional, plan-based approach to software, because agile methodology has evolved from a desire to meet the challenges and limitations of waterfall project experiences.

Some of the advantages and disadvantages of the waterfall and agile methodologies are:

Advantages Advantages
Clear specification to work (and warrant) against Focus on customer satisfaction, problem solving and delivery of useful deliverables
Certainty as to price and timeframes Iterative and adaptive process
No confusing messages from customer i.e. customer not knowing what it wants and having continuous input Continuous input from customer and increased visibility
  Cooperation, interaction and communication between customer and supplier
  Receipt of output/product quickly - at the end of each sprint
  Testing is integrated into the development process
Focus on documentation i.e. set specification Lack of documentation - no set specification
Restrictive, rigid process i.e. requirement for change control procedures Lack of certainly and difficult estimating price and timeframes
Lack of visibility for or input from customer Project can lose focus/get off track if the customer is not clear what they want or fail to input into decision-making
Patches (i.e. additional software required to fix problems with the software) are required because reworking where a problem is identified is not possible Intensive process for developers - only suits certain suppliers
  Time required from/culture of customer may mean agile is not appropriate/feasible

Organisations moving from waterfall to agile methodology often find themselves using a 'mini-waterfall' method. For example, they start doing iterations, but each one resembles the development lifecycle they had used previously.

For some business structures, this may be the most appropriate form of using agile software development techniques, but in doing so, such organisations tend to face the same problems as seen using a waterfall methodology.

What does this mean for customers?

It is important to assess whether a project is suited to agile methodologies and if the infrastructure and personnel of the customer and the supplier are suitable to run such a project. In the event that an agile method presents a viable solution, a customer should ensure it enters a contract which protects its position.

In Part 2, we will look at what customers entering an agile project should do to ensure they are geared up to implement such a project, and that the documents governing the project adequately protect its position.