Time to stop saying "Fr-Agile"
A few years back when we were all caught up in the Agile euphoria, the phrase “Fr-Agile” was coined to describe projects where Waterfall and Agile delivery were combined. This was initially called “W-Agile”, but then some bright spark said “don’t you mean “Fr-Agile!”. We all laughed, nodded and agreed that combining the two was a recipe for disaster – the worst of both worlds. However, a few years on and the world is changing. Fr-Agile may well be the best answer for many organisations.
Waterfall v Agile
Waterfall as an approach for delivering projects can be highly effective. For all its detractors, it does bring structure and logic to delivery of many changes requiring co-ordination of efforts for a set period of time. It works particularly when projects are small and contained. It provides a clear view on end dates and a plan to get there.
However, Waterfall has acknowledged issues. The main one is that fully locking down requirements and a design before build begins can be highly problematic, as often you might need to start building to really understand what you need. Waterfall also means that it is difficult to get value early, as you typically need to wait till the end before anything is delivered.
Agile in contrast to Waterfall allows for ‘build’ to start when the requirements and design are still being progressed. This allows for an important feedback loop from build back into design. This can result in a better end product, with the ‘customer’ having been able to get early visibility of what is being created, allowing them to then to then better clarify what is really needed. The early delivery aspects of Agile also mean that you can realise some benefits earlier – no waiting for that big bang delivery in the distant horizon.
However, Agile equally has weak points. It needs notable time commitments from business stakeholders to provide that all important feedback. This is often time that business stakeholders can’t spare. Agile also can lead to notable rework if the fundamental issues with the design get realised late on when the full requirements and optimal design become clear. It also tends to struggle with classic corporate structure and financing, which have tended to be organised more in a manner suiting waterfall governance.
So both Waterfall and Agile have their pros and cons. To decide on which approach to use, you need to best consider the type of change you are targeting i.e. will be most benefit from the pros, and be least impacted by the cons. Sometimes there isn’t a natural binary choice between the two. Sometimes a mix – a hybrid model – is the obvious choice. This is where W-Agile comes in.
Welcome to W-Agile
There are different versions of W-Agile, but the common one that is getting traction is what we call the Dynamic Delivery Model at Enfuse (we’re consultants – we had to come up with classic flashy name!). This has the following four features:
Initial phases more closely resemble waterfall – requirements and design are specked out – but only about 70% or so. This gives the project enough forward clarity to begin build using Agile methods but with a notable lower risk of rework. It also allows the project to commit to higher cost and/or long lead-time activities that require a high degree of up-front thinking e.g. selection and procurement of new software, recruitment of key hard to find resources, building procurement, data centre moves, security pen tests etc
Build done in a largely Agile manner – with the design ~70% clear, this can be further refined and perfected as the build proceeds utilising Agile (pick your flavour – Scrum, Kanban, other!).
Releases are a mix of continuous delivery and set period regulated drops – Releases of outputs into the live world are classified as either ‘drop in when ready’ or ‘must schedule into agreed release drops’. Both exist. This allows for early releases and realisation of benefits where there is low to no risk for these going live. Equally, it ensures that those releases that may need more planning and support can be properly controlled and managed.
Lean principles applied – Just as Agile bakes in Lean principles, so does this model. Aligning teams more around value streams, constant challenges around value, delivering when the customer needs it (getting their ‘pull’), and establishing the build phase to maximise flow (which should be easier as have more time during design phase to get this setup correctly) are all key precepts for this model.
This Dynamic Delivery Model doesn’t sound like rocket science, and is certainly something many organisations have done whilst slowly transiting from waterfall to Agile. The issue is that this model has often been viewed as sub-optimal. It was been described as Fr-Agile by many Agile evangelists and this populist style retort betrays the truth. This model deserves recognition as a viable option. It can be the most effective delivery answer for the organisation. It is time to stop saying Fr-Agile, and to start praising this dynamic, lean answer. It’s time to define it as an official approach and build in the long-term thinking and quality this model deserves.
