Predictive & Adaptive Delivery Approaches, Bye Bye Agile & Waterfall

In recent years, the term 'agile' has been thrown around the IT industry with great enthusiasm as the silver bullet that will solve all our project delivery issues. It carries positive connotations of 'getting things done quickly' without all the documentation we're used to enduring with traditional methods before we can even get started.

Unfortunately, after browsing the internet for 'scrum' and substituting the words, 'meeting' and 'week' with 'stand up' and 'sprint' and haphazardly sprinkling some task cards on a board with columns, organisations all over the country now think they're 'doing agile'. There is still a lot of education needed in many organisations before they truly realise the benefits of true agile project delivery. It takes discipline, process and structure, just like anything that's intended to work well needs. There is a risk that those that misuse agile principles will taint the term for those doing great work using the principles in the proper context. It's time to remove the confusion around this term and start talking about projects for what they are without all of the jargon.

An unfortunate consequence of the rise of agile in New Zealand organisations has been the fall in popularity of the methodology and the term 'Waterfall'. Many consider this a dirty word especially on software development projects but the reality is that many of the principles of traditional Waterfall are alive and well in many organisations though most would not want to admit it. Essentially the project approach selected should be based on the levels of complexity and risk the project presents and the availability of the participants.

The International Institute of Business Analysts published version 3 of their Business Analyst Body of Knowledge in April 2015 and in it are extensive references to agile project methodologies, sourced from hundreds of professional practitioners the world over. They have deconstructed agile and waterfall and stripped them down to their basic principles. Under this redefined terminology, your project will fall somewhere along the continuum between a 'Predictive' and an 'Adaptive' approach.

Predictive approaches focus on minimizing upfront uncertainty and ensuring that the solution is defined before implementation begins in order to maximize control and minimize risk. These approaches are often preferred in situations where requirements can effectively be defined ahead of implementation, the risk of an incorrect implementation is unacceptably high, when a high degree of formality and auditability is required or when engaging stakeholders presents significant challenges.

Adaptive approaches focus on rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding the overall delivery of the solution. These approaches tend to be preferred when taking an exploratory approach to finding the best solution or for incremental improvement of an existing solution.

Predictive approaches typically call for formal documentation and detailed representations. Information may be captured in a formal document or set of models following standardised templates. Information is captured at various levels of detail often with costings and sign off at each level. While this gives stakeholders more certainty on scope and cost up front it often sacrifices time to market and the process itself can be costly and erode the project budget.

Adaptive approaches favour defining requirements and designs through team interaction and gathering feedback on a working solution. Mandatory requirement are often limited to the items at the top of a prioritised list. Additional documentation may be created at the discretion of the team, and generally consists of models developed to enhance the team's understanding of a specific problem. Formal documentation is often produced after the solution is implemented to facilitate knowledge transfer. While this gives organisations the ability to 'start now' and adapt the solution as they start to use the working software to more closely align with the thing the users wanted, it does sacrifice certainty around how much each feature will cost and how much scope will actually be completed.

Other considerations that may affect the approach include:
o Complexity and risk - Not planning thoroughly could cost lives or it's so complex it can't be fully understood until some experimental code is written.
o The organisation is in a heavily regulated industry - Failing to exactly meet regulatory requirements could cost millions of dollars
o Contracts or agreements necessitate formality - A strong audit trail of granular detail is required to ensure obligations have been met.
o Stakeholders are geographically distributed - Regular face to face collaboration is very difficult.
o Resources are outsourced - Often outsourced resources will be willing to work in close proximity and will have a singular focus on the project.
o Staff turnover is high and/or team members may be inexperienced - High risk of wasted time and delays due to regular hand over, rehashing meetings and upskilling.
o Requirements must be formally signed off - Detailed documentation must be completed before the next milestone can begin.