A guide to commissioning software part 1: The advantages of agile development

This is the  first post in a series about commissioning software from agile developers, and working effectively with them. Subsequent posts will deal with a number of topics, concentrating on how clients can maximise benefit to themselves by selecting an appropriate company to undertake the development, and how to best work with the developers.

What is this beast called agile development? In brief, agile development combine clients’ business knowledge together with developer skills to realise systems that meet business need. But let’s talk first a bit about what I’ll call conventional software development and then contrast that to agile software development processes.

Many readers will have seen a popular cartoon typifying what can go wrong in software development projects:

tree swing development requirements

Figure 1: A popular conception of software development
(please click to see a larger view)

This is a bleak view of software development. Unfortunately, this is very much the view of the Standish Groups CHAOS Report, an annual survey and publication (that is hard to find without paying large amounts of money). Luckily, a  2012 Standish report appears on the Web. It states:

The 2012 CHAOS results show another increase in project success rates, with 39% of all projects succeeding (delivered on time, on budget, with required features and functions); 43% were challenged (late, over budget, and/or with less than the required features and functions); and 18% failed (cancelled prior to completion or delivered and never used). These numbers represent an uptick in the success rates from the previous study, as well as a decrease in the number of failures. The low point in the last five study periods was 2004, in which only 29% of the projects were successful. This year’s results represent a high watermark for success rates in the history of CHAOS research.

A 2013 survey, which defines project success in a more nuanced way, is provided by Scott Ambler in Dr Dobbs Journal and on his site. Scott discusses reasons for differences between his results and the Standish Group’s in the Dr Dobbs article.

Success rates for conventional projects are low in Scott’s results as seen in the following table. Just to satisfy my curiosity, I added in the Standish 2012 CHAOS survey results in the last line of the table. But please remember that those results don’t differentiate on methodology like Scott’s results.



Successful Challenged Failed
Lean 72% 21% 7%
Agile 64% 30% 6%
Iterative 65% 28% 7%
Ad hoc 50% 35% 15%
Traditional 49% 32% 18%
CHAOS2012 39% 43% 18%

The relative effectiveness of development methodologies across four different success factors was surveyed, and provides further food for thought:



Time/Schedule Budget/ROI Stakeholder Value Product Quality
Lean 5.7 6.0 5.5 4.8
Agile 4.3 4.2 5.6 3.8
Iterative 4.9 4.2 5.6 3.8
Ad hoc 0.0 -0.4 1.9 -1.4
Traditional -0.7 0.5 0.1 1.9

I’m going to be fairly loose: For the purposes of this post, I’ll refer to lean, agile and iterative (in the table above) as agile methodologies, and ignore the differences between these. I’ll  also refer to ad hoc and traditional as conventional  methodologies.

Why do conventional projects perform so poorly? In these projects those commissioning the software may not have a good idea of what they actually need from their projects. So at the time that they specify a product (up-front in the development cycle) they may specify something that is not actually what they need, but rather what they erroneously think they need. This leads to major problems at delivery time.

Instead agile development  allows for specification as the project proceeds. Stakeholders see the product developing and learn more about it and how it can be developed to support their needs as the project progresses (including how the project will address user need, deliver business value,  and maximise ROI).  Together with the developers they work on the development of a system that meets their real needs.

In an agile approach, system development becomes a process of increasing understanding of the product with close communication between developers and stakeholders. By regular communication centred around working software and demonstrations (see figure 2), clients and developers have something concrete to discuss and learn from. Developers can ask how well the system fits client needs, what is the next most valuable thing to add to the developing system, what needs rework or revision, and so on. Clients are able to refine their ideas of what the system should be as it is developed. The end point is that the client is delivered a system that fits their business and user needs and that delivers real business value.

conventional and agile client-developer communication

Figure 2: Client and developer communication
(please click to see a larger view)

As a slightly more technical explanation of figure 2:

With ‘conventional’ projects, client involvement is typified by an up-front specification phase, with acceptance testing happening at the end of the project. In agile project there is no up-front specification, instead the client interacts with the developers in regular cycles as the work planned and then demoed to the client. The two parties act to bring a system to life that as ideally as possible meets the clients business need. In agile projects, in response to seeing the system develop each cycle, the clients refine their own ideas of what the developing system should be as the project progresses. This markedly assists creating a system to address the client’s business needs.

Agile developers demonstrate a working system at the end of each cycle of development, progressively adding more functionality to the system with each cycle. For each cycle the client, with technical advice from the developers, decides what to implement next during the upcoming cycle. This choice is made by the client on the basis of what will, at that stage of development, provide the most business value to the client. This means the functionality with the most business value can be realised early in the project, and that functionality can be rolled out and used as soon as it is developed. Advantageously this provides real business value from the project before it is completed.

This incremental delivery of  functionality providing business value can’t be realised in conventional projects: These projects provide a single delivery at the end of a project when separately-developed layers in a system (see figure 3) are completed integrated.

Agile projects develop and incrementally deliver slices of  functionality  across all layers to provide business value during the project (see figure 3).

conventional layers and agile slices

Figure 3: Big bang delivery and incremental delivery
(please click to see a larger view)

In summary, agile development reduces the risk of up-front specification and ‘big bang’ deliveries which fail to address business need. Rather, agile brings client business knowledge to the development throughout the development to provide better solutions. The agile process is responsive to client needs and developing client understanding of the problem and its solution, and delivers business value as early in the project as possible.

This entry was posted in guide, projects. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>