While ‘agile’ methodologies (and ‘rapid’ before them) have been around for decades, the ubiquity of consumer-facing mobile applications, software-as-a-service (SaaS) alternatives to on-premise software, and the increased accessibility of cloud infrastructure and DevOps has meant that traditional, ‘waterfall’ delivery approaches are often viewed as old hat…
…But doing agile right is far from easy. The Berkeley Partnership has many years’ experience delivering large, complex technology-enabled change using both waterfall and agile approaches. Here are some lessons from our experiences.
Recognize what ‘agile’ is - and isn’t
IS: both a philosophy and a series of tools and techniques:
ISN’T: a replacement for good program and project management discipline. Agile philosophies emphasize ‘self-managing teams’ - and certainly, trust, and appropriate levels of delegation within teams is key to a successful Agile project. But in our experience, delivering enterprise solutions inevitably involves teams who are structured around more traditional waterfall phase gates. Project management involves ensuring that - all aspects of the project - including business readiness, data migration, - user training, audit and regulatory compliance, legal and commercial issues, etc - are dealt with adequately.
ISN’T: a project without any documentation - agile control systems need to be just as - if not more - sophisticated and rigorous as on a waterfall project. Documentation needs to be developed as each requirement is delivered, and work cannot be declared ‘done’ until it is documented, tested and formally handed over.
The product backlog
The product backlog is the list of requirements, sequenced in the order in which they will be delivered - factoring in both business priority / value, delivery dependencies (you can’t build a roof before the walls) and risk (don’t leave it until the end to discover you’ve underestimated the time required to deliver the complicated stuff).
Requirements are often documented using ‘user stories’, a technique which captures the requirement and the desired benefit, along with the criteria against which successful delivery will be tested.
Story points and consensus-based estimates
At the start of each sprint, the team should review the backlog, and estimate the amount of work that the delivery of the next story in the sequence will take.
Techniques such as ‘planning poker’ are used - where each team member independently estimates the amount of work (in ‘story points’) that a story will take - and the estimates are reviewed and discussed by the team as a group before the estimating exercise is repeated until all team members agree on the same consensus estimate.
Agile can really enable your IT projects to deliver business results more responsively and more quickly
The Minimum Viable Product and the 50% rule
The Minimum Viable Product (MVP) is the subset of requirements which are absolutely critical for go live.
Think of the MVP as a line drawn on the sequenced product backlog; if anything ABOVE the line is not delivered by go-live, there’s a ‘NO-GO’ decision. If everything above the line is there, it’ll be a ‘GO’.
The 50% rule states that when you embark on the project, you should plan the delivery so that no more than half of the capacity (in story-points) you have available is used to deliver the MVP. The remaining 50% is scope contingency for new functional requirements that crop up during the project, and to account for things that turn out to be trickier / more complicated than first thought…
For example - if you have an MVP that you think will consume 50 story-points to deliver- and you have a team with a velocity of 20 story-points per sprint - you should plan for at least 5 sprints (100 story points delivered).
You can’t buy agile projects in the same way you buy waterfall projects
It is critical that procurement teams understand the concept of Agile = Variable Scope.
That means that there is no pre-defined specification that can be referenced in a fixed-price contract. There is no one simple answer to best-practice agile contracting, but in our experience, contracting for ‘velocity’ - getting the supplier to underwrite the number of story points their team will deliver in each sprint - or buying a fixed number of story points are alternatives that have worked well.
The Berkeley Partnership has extensive experience of working in ‘hybrid’ project environments - integrating agile working practices into large organizations with complex legacy systems and support functions geared to waterfall ways of working. Let us know if you would like to discuss how we can help you with your agile delivery agenda.
