OperationsFramework / modelModelAccessible

Agile development

When and how should agile development be applied?

AccessibleOperationalIndividual3 min read

Contents

‘Agile development’ is a software development methodology that emphasises close attention to user needs, fast development cycles and small development teams.

Agile development is an approach to creating software through small teams, short delivery cycles and continuous attention to users’ needs. It contrasts with the traditional waterfall method, in which the full system is designed against a master specification before its components are built. Each approach has strengths and limitations, but agile has become the preferred model in many settings. Its principles now influence creative thinking and management practices well beyond software, including inside large organisations.

When to use it

To respond quickly as users’ needs emerge or change.

To let a software system evolve alongside its requirements.

To make development more participative and engaging for the people doing the work.

Origins

Before the 1990s, most software projects followed a waterfall, or cascade, process. The customer and developer agreed a high-level design; the design was decomposed into specified modules; the modules were coded and tested; and the completed parts were finally assembled and delivered. The discipline produced careful, precise plans, but it could also be slow, costly and resistant to users changing their minds. During the 1990s, several communities of developers began testing more adaptive methods. Seventeen practitioners met in Utah in 2001 and articulated the common ground among those approaches in the Manifesto for Agile Software Development. The manifesto gave the movement a shared identity and greater legitimacy, while specific methods under its umbrella—including Scrum—subsequently became widespread.

What it is

Waterfall organises development into five successive stages: requirements, design, implementation, verification and maintenance. That systematic sequence brought rigour and repeatability to projects; consultancies such as Accenture and Infosys built significant capabilities around applying it. Carnegie Mellon University’s capability maturity model offered a way to assess the discipline and maturity of software-development processes.

Agile arose because many developers found that sequential model too rigid for a world in which users rarely know every requirement in advance and often revise their needs after seeing the product. The 2001 manifesto at www.agilemanifesto.org expressed four preferences that define the movement:

put individuals and interactions ahead of processes and tools;

favour working software over comprehensive documentation;

emphasise customer collaboration more than contract negotiation;

value responding to change above simply following a plan.

The items on the right still matter; agile gives greater weight to those on the left.

How to use it

Agile is a guiding philosophy rather than a single operating procedure. Practical methods translate it into day-to-day work, with extreme programming (XP) and Scrum among the most widely used.

XP concentrates intensely on producing working software and strips away concerns it regards as secondary, including managerial politics and separate quality gates. It cycles through release planning, iteration and acceptance testing. Feedback gathered from users during one pass guides corrections and improvements in the next. Several iterations may be required before the product contains enough functionality to meet users’ needs; that minimum viable product can then be released. Users participate as members of the extended development team and write short user stories describing how they work and what problem the software should solve. Teams integrate changes at least daily, monitor the work closely and use pair programming. Pairing has been found both more productive and more satisfying than programming alone or in a large group.

Scrum takes its name from the tightly grouped forwards in rugby. Its central idea is that a team collaborates at speed to deliver a software increment. Whereas XP focuses primarily on technical practice, Scrum addresses both development and management. Work begins with project scope and software design, then proceeds through clearly defined roles. The product owner represents stakeholders and brings customer feedback into the team; the development team builds the product; and the Scrum master supports and manages the process. Team members select development and coordination work from a backlog and complete it through sprints, normally lasting two to four weeks. Within a sprint, a short daily meeting reviews what was completed, what comes next and what may be blocking progress; participants traditionally stand to encourage brevity. A burndown chart displays the work remaining in the sprint, while the product backlog records requirements not yet included in the release.

Top practical tip

Agile gives development teams greater responsibility and therefore requires room for them to act. If you oversee an agile project, establish clear outcomes and constraints, then resist micromanaging how the team delivers them.

Top pitfall

Agile depends on a tight feedback loop between developers and users. XP user stories are deliberately brief and may leave room for interpretation, so users should review completed work promptly and explain what needs to improve. Without that continuing exchange, rapid delivery can simply take the project rapidly in the wrong direction.