In the last article we looked at the background to Agile delivery methods, and the benefits they purport to provide. Boiled down to basics, these benefits are typically thought of as below, although there are others:-

  • Business more likely to feel ownership of the Solution
  • Prioritisation enables the project to deliver on time while protecting quality
  • The risk of building the wrong solution is greatly reduced
  • Deployment is more likely to go smoothly

How do these Agile approaches deliver these benefits then ? Let’s dive into each one in turn.

Business more likely to feel ownership of the Solution

Under the traditional Waterfall approaches, the end Customers are consulted heavily in the early stages by the Supplier organisation to determine their Vision and Requirements. These are then developed into firm Specifications, which the Customer is asked to review and sign off by the Suppliers. So far, so good.

The next stage is the point at which the Customer’s and Supplier’s expectations may start to diverge. The Supplier team go away and develop a solution based on their understanding of the Specifications. They will test the solution themselves in terms of its ability to meet the requirements at a modular level (Unit), at a joined-up level (Integration), at a non-functional level (System), based on Tests written by themselves. Finally a solution will be presented to the Customers who will be asked to perform their own testing (User Acceptance Tests = UAT) based on Tests written usually by the Customer and often in consultation with the Supplier. These UAT tests will be confined to what was requested in the Specifications and not allowed to include scenarios not covered by the Specifications.

This is where the issues normally emerge – by this time, the Customer’s vision may have evolved, their understanding of what they wanted or needed may have evolved, and when presented for the first time with a solution developed by somebody else, they often feel as if it has been ‘done to them’ rather than ‘done with them’.

What Agile approaches do, is to maintain close and (fairly) constant interaction and communication between the Customer and Supplier, to the extent that they both commit resources to integrated Delivery teams who work collaboratively to deliver the solution together. This ‘one-team’ approach fosters stronger engagement and a sense of ownership by all involved.

Prioritisation enables the project to deliver on time while protecting quality

Predictive, or Waterfall methodologies entail deciding what requirements are In-Scope or Out-of-Scope, on a binary basis. Then, all In-Scope requirements are developed and delivered. With this approach, the only variables available to the Project Manager to manage the Project are Time (Schedule) and Resources (Money, Personnel, Tools). So, managing expectations becomes a challenge as the Customer usually expects delivery on Time (Time), and within Budget (Resources). In these situations, Quality can often be compromised in order to meet the expectations.

Agile approaches rely extensively on Prioritisation, based on expected Business Value. Some approaches, like SCRUM, adopt a relative Business/Customer Value as a means of ranking, such that higher value items appear higher up the ‘list’ of requirements; other approaches such as DSDM use a prioritisation framework know as MoSCoW (Must-Have, Should-Have, Could-Have, Wont’Have). These methods, combined with the concept that ‘The customer doesn’t need everything they ask for’, are used to ensure that at least a ‘Minimum Viable Product’ (MVP) is delivered (i.e. Must-Haves), and also as many Should-Haves and Could-Haves as possible within available Time and Resource constraints. NB The most successful Projects will deliver all.

Combined with this Value based approach, is the Agile concept of iterative and periodic deliveries is achieved by what’s referred to as Time-boxing, or Sprints – repetitive and short time frames that each deliver something usable. These Time-boxes or Sprints are often set to be 4 weeks long (or less), where the joint Customer/Supplier delivery team work collaboratively together. Each Time-box or Sprint is usually planned to deliver Must-Haves or the higher Value items, along with other smaller items.

This approach tends to protect Quality, and ensures on-time delivery of at least the most vital requirements.

The risk of building the wrong solution is greatly reduced

Earlier in this article I highlighted the risk of the delivered solution diverging from Customer expectations. In Agile approaches, the concept of ‘All Design Up Front’ is eschewed in favour of ‘Enough Design Up Front’. This is achieved by having an iterative approach to requirements gathering and design; typically high level ‘User Stories’ will be captured and agreed by the Customer Supplier in the early stage of a Project, at a level sufficient to base initial Planning of a Start-up Phase, during which those requirements will be further deepened or de-composed (say from around 10 high level to 100 more detailed) sufficiently to allow planning of the Delivery phase on a Time-box basis. Then in Delivery when the Time-box or Sprints approach is used, the Delivery team work together collaboratively to develop a solution based on the ever-developing understanding of the Customer.

Change is therefore also handled dynamically within the Delivery team – subject to tolerances about impact on the MVP – and the regular deliveries of working product mean that the Customers are much more likely to get what they want, as they have a significant input in the evolution of the solution.

Deployment is more likely to go smoothly

If the appropriate solution, that meets at least the most valuable requirements, developed hand-in-hand by Customer and Supplier is delivered with frequent releases, then the Customer who has been engaged throughout, will be far more likely to be rolling out a solution that its remaining workforce is likely to accept. This benefit is largely a by-product of the first three, and in fact although I’ve presented certain aspects of Agile approaches as supporting those individual benefits, those approaches really support each and every one together.


In conclusion, it’s the integrated, enough design up front, regular releases and value driven nature of Agile that delivers the benefits over what Waterfall does. In this short article I’ve had to skim over many aspects of Agile, and focus on the common ones from the various different Agile frameworks. In future articles we’ll further explore some of those aspects in more detail.