
Published January 31, 2020
Agile delivery comparison: Visibility, adaptability, value, and risk
How does an agile approach differ from a traditional way of working? This post provides a brief overview of the differences and benefits of an agile approach to delivery, illustrating and comparing four key areas (visibility, adaptability, value, and risk) with a more traditional approach.

You may have wondered… how does an agile approach differ from a traditional, waterfall way of working?
This post provides a brief overview of the differences and benefits of an agile approach to delivery, illustrating and comparing four key areas (visibility, adaptability, value, and risk) with a more traditional approach.
An agile approach puts focus on the delivery of valuable items frequently, incrementally, and continuously to the customer.
The most popular agile methodology is Scrum and Scrum variations, i.e. Scrum/XP Hybrid and ScrumBan, which caters for around 72% (ref: State of Agile Report 2019: Agile Methods and Practices).
How does this differ from a traditional waterfall approach?
The differences, and indeed benefits, that an agile approach can enable are illustrated and briefly described below. It covers four perspectives visibility, adaptability, business value, and risk.
I personally find this a useful view to help illustrate the benefits. Particularly when educating those less familiar with an agile way of working. X-axis represents the amount, and the Y-axis time.
Visibility
Visibility is an important metric as it enables, for example, course correction early, and throughout, the delivery process. It is linked to adaptability through more evidence-based and continuous feedback. It was also reported as the second most popular benefit according to the Stage of Agile Report 2019.
With an agile approach, visibility is achieved through the frequent release of incremental change and early feedback from the end user. With a traditional waterfall approach, we tend to get visibility at the start and during the latter stages of the project, i.e. the testing phase.
High transparency of “real” progress, i.e. change in the hands of the customer, along with high traceability – e.g. through a, ideally automated, test suite describing the new feature or change in natural language, corresponding to the original requirement, typically in User Story form.
An agile approach strives to reduce feedback cycles and have demonstrable working, ready to ship, software typically every 1-4 weeks.
Value
With an agile approach, the frequent and early delivery of the product focuses on the most valuable feature, often taking a minimal-viable/valuable approach to incrementally improve the product. Return on investment is realised sooner. While traditionally we only deliver once at the end of the project, when all scope has been completed. Typically resulting in a big bang, high risk, release, with roll-back likely and no doubt with the need of various patches.
This graph illustrates the fact that an agile approach strives to deliver value into the hands of the customer as early as possible and then incrementally enhance. Taking this approach presents the business with the ability to, for example, cut off the tail.
Cutting the tail
What do we mean by cutting the tail? It means that when the team have delivered X – that could represent a series of the most important and/or riskiest features – the business may choose to divert efforts, e.g. spin up another project of more value. Thereby saving time and money on things that would otherwise be of little value. This is an enabler and supports business agility of a organisation.
Agile is a “value-driven” approach with features being variable, it welcomes change, and with resources and time being more fixed.
This differs to a traditional approach that is more “plan-driven”, which typically sees a fixed scope of requirements, with resource and time levers. Further, deviation from the plan is less welcomed and change is avoided in favour of sticking to the plan, i.e. it is less adaptable.
Adaptability
Adaptability is arguably one of the major attractions to an agile approach. It is reported in the State of Agile Report 2019 as the most beneficial aspect of adopting an agile approach – i.e. the “Ability to manage changing priorities”.
An agile approach embraces change late in the development cycle while with traditional methods the requirements are typically locked in early, often very early, accompanied by heavy and detail documentation.
Adaptability is more or less similar at that start but, unlike a traditional approach, remains high throughout the delivery lifecycle. For example, with teams that have adopted Scrum there is opportunity to react and change direction each and every sprint (i.e. every 1-4weeks).
Risk
With an agile approach we start with the high value and high risks items so as to learn, and sometimes, fail fast. With more traditional methods we only reduce our risk profile while testing the product, typically much later in the delivery lifecycle.
As delivery progresses, the risk decreases early and much more rapidly than a traditional approach. We discover integration issues earlier along with validating assumptions and hypotheses. We uncover operational risks and issues early as we strive to deliver working software to the customer (or a pilot group of actual users) to production or a production-like environment from the first sprint.
Benefits
The culmination of these differences can see various benefits emerge.
Speed
- Using a traditional project methodology, it could take a significant amount of time before the benefits of a project were realised – as illustrated in the Value chart above.
- Sometimes we discover that the solution delivered was no longer fit for purpose or the needs of the customer had changed – Adaptability presents opportunity to address this.
Effective collaboration
- Foundational to an agile squad is that it is cross-functional and self-organising, resulting in improved buy-in and collective ownership.
- Effective collaboration is enhanced through breaking down silos – both artificial and physical, along with connecting the right people from concept to customer.
- Collaboration positively impacts all aspects compared, and is improved through the various practices adopted.
Autonomy / decision making
- Adaptability and focusing on the most valuable items, coupled with high visibility, is reinforced through decision making being brought closer to the delivery teams. Ownership and prioritisation of initiatives is held with business owners and product owners.
- Executive leaders tend to operate, in part, more like Chief Obstacle Removers… rather than involved in the prioritisation of work and questioning/overruling every decision. Although this may seem as if control is being relinquished, the vision, strategy, outcomes sought, direction and ultimate decision making remains – with customer wants and needs paramount.
- Bureaucratic, command and control processes have dominated how large, complex organisations have operated for over a century, and an agile way of working take a difference approach through empowering, providing autonomy and decision making with those closer to the delivery.
- Turn the Ship Around, by L. David Marquet, is well worth a read/listen relating to this subject – turning followers into leaders.
Customer centricity
- Planning work is focused on creating value for the customer.
- It might be resolving a long term customer pain points or adding a new feature that saves a little time or even surprises and delights the customer.
- Customer engagement is encouraged and ideally directly in contact with the delivery team.
- Roles in the squads such as a User Experience Specialist and Front End designer reinforce the focus on the customer.
- According to the State of Agile Report 2019, “Customer/user satisfaction” ranked the #1 success measure for projects, with Business Value and On-time delivery second and third.
Hope this has provided you with an easy to see and understand comparison and benefits of an agile approach to delivery.
Thanks to Felix Kiefer, Cate Knowles, James Hume, and Ben Forbes for your contribution.