Delivery Method Conundrum

There is a wealth of fine literature in circulation regarding the use of different delivery methodologies that organisations might adopt as they move along their digital transformation journeys. These predominantly fall into two categories namely the traditional ‘Waterfall’ approach, which has served the technical community well since the days of yore, or Agile which in itself has been around for a number of years already.

Having been involved in a number of projects and programmes on both sides of the delivery methodology ‘fence’, and based on some recent discussions during this COVID-19 lockdown period, a couple of things have got me thinking about what organisations actually need when they begin to think about how they would deliver a new services, transform existing services or look to generally improve their whole delivery process.

While likeminded businesses share similar processes, aims and endeavours, each will have different approaches to getting their products to market. Another variable might be how mature they are with regard to technology and their ability to adopt change.

When faced with a new project, programme or transformation, it can be easy to say ‘we want to be Agile’ when what most people actually mean is they want to introduce ‘Agility’ into the way they deliver their goods and products into the marketplace. This is based on the premise that most companies today have a digital footprint of one form or another.

In reality most organisations that aspire to be Agile for instance are miles away from being truly so. What tends to happen is that they drift towards a so called ‘Wagile’ or ‘AgileFall’ i.e. a Waterfall / Agile type of arrangement. The figure below shows this in more detail and is arguably a better delivery model especially for clients who need more attention to regulation or stricter adherence to design gates or measures.

This type of approach does not mean that all your design work gets done up front. Indeed, as part of any Agile delivery you will need to introduce pockets of design for each new component, function or solution but this can be focussed on the individual piece rather than trying to boil the ocean up front. A good way of managing the supporting design work within an Agile phase is to use a Wiki tool such Atlassian Confluence, ProofHub or similar. This gives the flexibility to share designs and accompanying documentation easily with peers for review and confirmation purposes.

In short, do the enterprise stuff and end to end designs up front, but leave the component designs to feature as part of the Agile sprint work. This will mean having an architectural presence as part of your scrum teams. Not a bad idea!

So, in summary if your organisation aspires to be Agile but sees the journey to this as somewhat insurmountable, consider a hybrid Waterfall / Agile (Wagile) approach and aim to get the best of both methods. This will combine the ability to fail fast and deliver quickly while keeping the necessary governance and controls in place to ensure success.