Why it pays dividends to pause and ‘cover the bases’ on agile software development as the digital surge accelerates
While e-comm has grown year on year, it has largely been possible for the luxury sector to resist that shift. Perhaps until now (for obvious reasons). Even vendors and consumers of luxury goods are suddenly being forced to consume digitally to varying degrees. With that shift, comes the ‘experiential’ journey, which of course is super important to luxury brands and is no easy task to create digitally, especially when required ASAP by the C-Suite (or others) within a fixed budget.
The CIO/CTO, Marketing Director and their teams typically bear the brunt of this challenge. So, often for good reason, along comes Agile (or increasingly Wagile). Because Waterfall is (‘of course’) too time consuming. All CIOs and CTOs know the challenges of Agile, but what is time and again under appreciated by others is the risks associated with this choice.
In our experience, successful Agile projects need the following:
- Upfront investment of time, pre-contract signature, to ensure there is a true alignment of goals, priorities, budgets, organisational culture between customer and vendor
- A real focus on pricing (and measures to cost under control), coding quality and remediation tools (as defects and unanticipated issues) will arise.
As lawyers, we see the successes of Agile, but also the blown budgets and the fallout. Taking the time to pause and cover the bases in a comprehensive contracting process is important.
What is often forgotten is that one of the main reasons for a decent Agile document is to flush out the gaps, overlaps and misunderstandings as to what is being delivered, and for what budget. The RAID log can help but often it is used too late in the process.
We give you permission to ‘slow down fast’, with our three top tips for de-risking Agile projects.
01 Reach out and engage the right stakeholders
Ensure that, from the outset, you engage all the correct stakeholders from all teams. This will be especially important to any DPIA and privacy by design obligations that need addressing. Your development team needs to be energised by the project, and willing to make a substantial time investment.
Ideally, agile teams are co-located as this facilitates a more immediate flow of information and feedback. However, if you’re still unable to get everyone in the same room, harness the power of video calls and regular virtual ‘stand-ups’, ensuring that everyone has had a chance to feed into goals, priorities and constraints, in order for these to be aligned in a way that is crystal-clear.
This route will also allow people to take ‘ownership’ of tasks (rather than waiting to be told what to do), which is especially helpful where there is a development team comprising vendor and customer team members.
02 Keep hold of the purse strings
You will (almost certainly) be taking on greater financial risk in an Agile project than in a Waterfall project. This is usually because specific deliverables are not agreed upfront, and thus usually not for an agreed price or an agreed delivery date.
Failure to achieve deliverables within a timeframe will not necessarily create a ‘breach’ of contract. Instead, these deliverables (‘user stories’) are simply added to the ‘Backlog’ of items to be addressed later, depending on your assessment (as a customer) of your business priorities.
This can mean that you pay more overall as Agile projects are typically charged on a T&M basis. Ways to manage this cost include:
- Setting an overall anticipated project budget (perhaps with a tolerance) within which ‘overarching’ concepts or deliverables are to be delivered (but there is an inherent tension here).
- A mechanism to measure, and incentivise, increasing ‘velocity’ (the speed with which the vendor performs tasks as it gets to know its customer, their platform and their needs better).
- Ensuring the customer has adequate ‘early termination’ rights, albeit as a last resort.
03 Don’t accept anything less than high quality code
The vendor needs to deliver high quality code. You can achieve this by regression (and other) testing at the results of each ‘Sprint’ against agreed ‘acceptance criteria’. By doing this at the end of each Sprint, the potential for future surprises reduces. However, the acceptance criteria should be described in detail upfront (so far as possible), rather than relying on less formal descriptions in user stories. This demands serious collaboration upfront.
Be aware that your approval of results achieved during earlier sprints may preclude you from objecting later, if it transpires that the earlier results do not provide an adequate platform for future work. Remedial work is possible as a
further requirement to be included in the ‘product backlog’, but the cost of that extra work usually falls to you unless specific responsibilities and principles are otherwise agreed upfront.
In summary, while Agile may be the optimal way to create your new digital solution, we dare you to slow down fast, and make time, to ‘cover the bases’ in the contracting process. You won’t regret this investment of time.
Want to join The Collective, and contribute to the debate?
Email us at: The.Collective@lewissilkin.com