Agile NPD Process

A reaction to the problems and restrictions that some software developers saw in the Waterfall method, the Agile method focuses on ‘working software over comprehensive documentation’. Its main strength is in projects where it is difficult to ascertain the customer’s requirements with sufficient certainty. Therefore the best route is to quickly develop some software and show it to the customer to elicit feedback and in this situation the Agile process can end up with a more successful product, that has been developed more efficiently, than with the Waterfall method.

The Agile Manifesto

In February 2001, 17 software developers (see below) met at the Snowbird resort in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick  

© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

Agile Pre-History

Incremental software development methods were probably first used at IBM’s Service Bureau Corporation in 1957, where, according to Gerald M. Weinberg, (as quoted in Larman, Craig; Basili, Victor R. (June 2003). “Iterative and Incremental Development: A Brief History”. Computer 36 (6): 47–56), it was thought that ‘waterfalling’ of a huge project was rather stupid, or at least ignorant of the realities.” (See Waterfall Process)

In the early seventies a number of authors described similar methods of software development and management. Then in the mid-1990s a number of lightweight agile software development methods evolved, such as Rational Unified Process (1994), Scrum (1995), Dynamic Systems Development Method (DSDM) (1995), Extreme Programming (1996) and others, in reaction to the heavyweight waterfall-oriented methods, which critics called heavily regulated, regimented, and over-managed. These are now collectively referred to as ‘agile’ methods, after the Agile Manifesto was published in 2001 and proponents of lightweight agile methods contend that they are returning to development practices that were present early in the history of software.

Agile Principles

The Agile Manifesto is based on 12 principles.

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximising the amount of work not done—is essential
  11. Self-organising teams
  12. Regular adaptation to changing circumstance

Agile Methods & Features

By far the most popular of the Agile methods is Scrum, named after the scrum in rugby and first defined as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach” in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the “New New Product Development Game” and practiced by manufacturing firms in the automotive, photocopier and printer industries – so not a software process at all initially.


Scrum involves a small cross-functional, self-organising team, (min 3 people, max 9 people, so ideally 6 people), breaking the workload into short time periods, called sprints. As well as the team, there is a Product Owner, who is the voice of the customer, and a Scrum Master, who is a facilitator.

  • The Product Owner creates a prioritised wish list of work, called a product backlog.
  • There is a sprint planning meeting, where the team takes a manageable amount of work from the top of the list, a sprint backlog, and decides how to implement that work. The sprint goal is to complete the sprint backlog.
  • The sprint is a “timeboxed”, i.e. it is a fixed duration. This is typically two weeks, but it could be anything between 1 & 4 weeks. There is a daily meeting to assess progress (a daily scrum, or ‘stand-up’). This is usually 15 minutes, first thing in the morning (to make sure everyone turns up on time), and during the meeting, each team member answers three questions; “What did I do yesterday?”, “What will I do today?”, and “Do I see any impediment to achieving the sprint goal?”
  • Along the way, the Scrum Master chairs the meetings and keeps the team focused on its goal.
  • The idea is that by the end of the sprint, working software should be produced, that can be shown to the customer.
  • The sprint ends with a sprint review, where the software is demonstrated to the customer and a sprint retrospective, where the sprint itself is reviewed, by asking two main questions: “What went well during the sprint?”, ” What could be improved in the next sprint?”.
  • As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Comments on Agile

A cynic might say that the Agile Manifesto just gives licence to do what everyone else always thinks about software developers – they just want to lock themselves in a room and play all day at developing ‘cool’ stuff, without having to bother about any of the boring stuff, or being told what to do by the ‘suits’. One could call it the software version of the 1940’s  ‘Skunk Works’, a (perhaps rather arrogant) small elite group that works on its own to develop a product away from the rest of the company. An appropriate motto for the Agile movement might be Kimi Raikkonen’s quote ‘Leave me alone, I know what I’m doing’. After all, he did win that Grand Prix (Abu Dhabi, 2012).

However one of the authors of the Agile Manifesto, Jim Highsmith said,

“The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modelling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker.”

A key difference is that in a traditional waterfall or plan-driven process, where the focus is on setting requirements up front, the requirements and hence the features are fixed and if something has to give, it tends to be time and cost, and sometimes quality. In an agile approach, the timescale (and hence cost, if there is a constant team size), is fixed, and if necessary the number and complexity of the features is reduced in order to meet the timescale. See the illustration by DSDM:

DSDM Fixed Time


Agile Advantages

It would seem that more organisations are turning to agile methods, at least for some types of software development. The State of Agile survey, produced by a vendor of an agile project management platform, tracks agile trends and reported benefits from the users of agile methods for software development. The 2013/4 survey says that prior to adoption the main reason for going agile was the expectation of ‘faster time to market’, and that this usually turned out to be true, but that the biggest benefit recorded once agile had been adopted was ‘ability to manage changing customer priorities’.

Agile Issues

Agile development is especially suitable for small teams of experts in relatively small projects. However whether it will be as suitable for larger teams, larger projects, projects that involve hardware as well as software and hardware only is a matter for debate.

It is also a ‘bottom up’ type of process, so projects that would benefit from a top-down approach, i.e. designing the architecture of the system before starting to code, may experience difficulties with agile.

The focus in agile is on getting to working software as quickly as possible, especially if the customer does not know what he wants, rather than on contract negotiations. Thus it would seem to be best suited for internal projects, or external projects that are cost plus, i.e. the customer is billed for the hours, whatever they may be. However as described above it would seem to be less suitable for a fixed price contract, with fixed deliverables, because the ‘Agilistas’ don’t want to do the contract negotiations. It may be a more productive method, but the customer usually wants to know what he is getting for his money before the work starts.

At the 10th anniversary of the Agile Manifesto a small group compiled a list of about 20 elephants in the room (“undiscussable” agile topics/issues) were collected. As Philippe Kruchten wrote in ‘Agile’s Teenage Crisis?’,

“The agile movement is in some ways a bit like a teenager: very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times cocky and arrogant. But I have no doubts that it will mature further, become more open to the outside world, more reflective, and also therefore more effective.”

Elite’s Take on Agile

Elite Consulting is concerned with product development of all types, whereas Agile is mainly focussed on software. It clearly has some advantages in that world. The question is how much of the Agile approach can be applied to advantage in other situations, modifying it to suit where appropriate, so as to get the best of both worlds.

Currently Elite Consulting is working on just such a marriage to obtain an agile, but controlled, product development framework that can be adapted to as many situations, industries, products and companies as possible.

So if you are in a hardware company, or one that combines hardware and software into your products, and you are interested in how you might use the agile apprioach, then please contact us for a chat.