Agile…
It’s a term that you are sure to hear from nearly every one of the technology partners that we work with. While a few claim that they are fully Agile, many others will tell you that they work in a hybrid way.
Typically, in my experience, the majority of our partners will combine a Waterfall discovery process and full, end-to-end specification, with an iterative Agile development. But there is more to Agile than simply developing and releasing in bursts. While you may be nervous starting a project without defining all your needs in detail, Agile is not a methodology that lacks a plan. In fact, a cycle of planning and re-planning is baked into the method.
Agile is not a methodology that lacks a plan
Where’s my specification?
Yes, it’s true…
When working in a fully Agile project you will not be given a detailed specification. Instead, after the discovery process you will receive a number of high-level Features. These features will describe the functionality required but not at the same level of detail as a ‘Waterfall’ specification. The full project team, both partner and client, will then meet to agree the Feature roadmap, assign effort (budget), and agree the ‘minimum viable product’ – the smallest, most high-value, functionality that you require for your business-as-usual at go live.
This approach is not disadvantageous; it is highly collaborative, with the partner able to comment on the likely complexity of the work required to support your needs, with you providing insight into your business priorities, and the highest value functional items, to agree a delivery roadmap. The process cannot work without this symbiotic relationship between partner and client.
And, importantly, this relationship continues throughout the development sprints.
Agile (Adjective); Able to move quickly and easily
A detailed specification provides reassurance; everything you think you need is written down and you have signed it off. But what if things change? The Discovery process missed something? Or, when Sprint 3 starts, the partner suddenly realises that the requirements are more complex than first assumed. All these items result in change requests, additional cost, and additional time. With little opportunity for you to understand or discuss them or investigate alternative approaches.
Because an Agile methodology continues to define the detailed requirements (user stories) throughout the development process, there continues to be a very close and collaborative relationship between you the client and the partner. This means that you can change, adapt, and reprioritise your requirements as the business changes. It enables discussion around the full range of potential solutions to a business need, whether a fully automated technical solution, or a change to your business processes, as you see and learn about your new systems, and it means that the project can flex within the budget available.
It’s a Sprint, not a Marathon
Each development Sprint is preceded by a dedicated planning session where the whole project team, including the partner’s business analysts and developers, will meet to discuss the users stories, the effort (and therefore the budget) required to deliver them and their value to the business. The backlog of undelivered user stories can be stack ranked (prioritised) and many user stories parked before development effort is spent on them.
This continuous cycle of discovery, user story prioritisation and planning for each and every Sprint empowers you as the client; it allows you to understand the impact on the project budget of each and every deliverable, and make better decisions based on the cost versus value of every item. This level of transparency and collaboration throughout the development, I believe, can often be missing from a hybrid approach leading to higher costs and an extended timeline.
There are many myths about the Agile Methodology, and it is certainly a very different project experience for a client. The lack of an upfront, detailed specification, however, does not mean that Agile lacks a plan. In fact, when Agile is done right the opposite is true, but with more opportunity to flex, change and adapt as the project progresses, and your business changes.
