Last month, the estimable Scott Brinker of ChiefMartec (and HubSpot) published a thoughtful piece about the apparent dichotomy between two models of technology adoption: the waterfall approach and the agile approach.
Those latter terms come, of course, from the Devs world, the former signifying a structured, planned approach to a development project, the latter a flexible, sprint-based approach, associated with minimal viable products and “failing fast.” Applied to marketing technology, the two approaches might be clarified as follows:
- Waterfall: thoroughly audit and analyse the full range of marketing challenges to be solved, the outcomes (KPIs, ROI) sought, plan the deployment of the software, and bring all stakeholders into the process
- Agile: pick a current challenge which needs to be met, and have a small, cross-functional team make minimal investment in SaaS software to address just that challenge
Both approaches have downfalls, as Brinker notes. A big ticket tech purchase to satisfy the Waterfall model can take an average of over 16 months to complete. The audit and analysis phase, and getting buy-in from stakeholders, might overlap with the purchase cycle, but then there’s deployment and training. All while doing business as usual, and praying that your requirements don’t change before the system is in place. Oh, and there’s high cost too.
As for agile, teams could waste a lot of time buying and scrapping solutions which don’t really meet the need, and if there are multiple teams (perhaps in different functions), there’s a risk of duplication, and/or failing to learn from mistakes already made at the other end of the corridor. Nevertheless, and certainly for businesses below the enterprise level, agile in on form or another seems to have been winning out.
As Brinker points out, while it’s helpful to understand and distinguish these approaches, choosing between them really represents a false dichotomy. There is no reason short-term, agile projects — especially aimed at “today’s” problem need to be put on hold while a more holistic solution is being considered; nor is there any reason to put off waterfall thinking while agile projects are running. In fact — and ideally — symbiosis can occur. Learning from “fail fast” type projects can inform thinking about long-term procurement, while those short-term projects will likely relate in some way to longer-term challenges waterfall thinking is meant to address.
And again, ideally, some of those immediate software investments, even if they’re easily disposable, should preferably build the stack in the direction of an overall vision of needs and returns.
But all this is clear enough from Scott’s piece. What he doesn’t take account of (in this blog at least) is the elephant in the room. Also known as, the existing stack. Other than the freshest of start-ups, how many businesses are starting from a green field, and thinking “Well, we can start to adopt technology this way, or that way…”
Almost every business confronted by this (false) dichotomy is sitting on legacy software, whether it be old, custom-built, on-prem suites, or dozens of SaaS subscriptions which are somehow still being renewed. Very often, core business processes are being run on that legacy software. It can’t just be switched off because you’ve found something else which seems worth switching on. And, very often, your business has invested in reams of shadow software IT doesn’t even know about.
Whether the way forward is waterfall, agile, or more likely an informal combination of the two, the first step which suggests itself is a joint audit of legacy software and the processes it supports. For one thing, the waterfall project can’t get off the ground unless business processes are fully understood, and where possible optimized — because why invest in costly long-term procurement to support flawed processes? At the same time, layering new short-term processes and software on top of not-fully-understood existing processes may be agile, but may also just add to the chaos.
Nobody said this is easy, or that it’s anything other than an ongoing process. But the best advice seems to be to understand where you are and where you came from, before choosing the road forward.
