When to use agile development on your project

Jake Woodward - 07 May 2020

The world of digital is constantly changing. 

While this is particularly visible in areas such as design, marketing and tech, behind the scenes project management is also evolving, improving innovation, efficiency and delivery.

Agile is one approach that has become increasingly mainstream but when is it right for your project?

Here we take a look at some agile techniques and how these were used successfully on a recent user design-led development for a client.

Waterfall vs agile

Waterfall is still one of the most widespread approaches in project management. It emphasises linear phases that run sequentially, one after the other, with feedback rounds at the end of each, until the work is complete. 

This is a very useful way to work if there are clear and detailed requirements upfront but it does add time and expense to a fixed-price project if there are changes once a phase is complete. 

In other words: perfect, if you know exactly where you’re going and how you’re getting there; not quite so good if you don’t.

With an agile approach, an overall budget range is agreed but design and development are only defined after a rigorous scoping phase at the outset. 

Scoping provides a thorough understanding of audience needs, organisational goals and what a minimum viable product (MVP) will look like at launch. The solution takes shape around these findings and resource can be assigned where it’s most needed ‘in flight’ since design and development are scheduled in iterative ‘sprints’ and can include multiple rounds of feedback.

As one of digital’s great truisms has it – a wise person knows just enough to know what he or she doesn’t know. 

Anatomy of an agile project

Orchard Court Management (OCM) approached OWA to develop a property management system (PMS) to oversee all its property services, including building maintenance, communal cleaning, insurance, repairs and capital works. The PMS would also act as an information sharing repository for residents and administrators – logging, reporting and managing service incidents, schedules and suppliers.

OCM supplied OWA with a summary brief – and based on this asked us to propose a solution within a fixed budget range. Given the high level of unknowns, we agreed with the client that an agile approach, working in iterations, would be the best way to design in flexibility and deliver an MVP for launch within the agreed costing.

The project began with a thorough piece of scoping to explore and prioritise what was needed and identify the best-fit technical solution.

We asked who the primary users would be and spoke to a small representative sample to establish what they wanted and expected from the new service. Many are elderly residents so accessibility quickly emerged as a key requirement.

We spoke with OCM team members and stakeholders to understand what organisational objectives needed to be met and how critical each was for launch; we also looked at how problems were currently reported and tracked.

Armed with this information, it quickly became apparent that a custom-built web application would be most suitable and cost-effective for OCM. 

Assigning resources

With scoping finalised and the system’s key users identified, it was clear a simple and intuitive layout and user interface would be required. We recommended focusing resource away from design and into development of low-fidelity wireframes to help validate the user experience (UX) and information architecture (IA) through a cycle of user testing. 

As part of this learning and iterating, and with accessibility best practice in mind, we proposed using WCAG 2.1 AA standard as a benchmark wherever practicable during design and development of the system. 

Simple and clear designs for each key template emerged quickly as the user testing and IA were updated. At the same time, we started the first of three intensive development ‘sprints’, which allowed us to make modifications to functionality and features as we went along. 

Having developers mobilised on a single piece of work during each sprint helped to maximise efficiency. Quick-fire stand-ups every morning enabled the project team to run through the previous day’s work and flag obstacles ahead, ensuring any issues, refinements and bugs were caught in (almost) real time.

And working in agile development sprints certainly meant there was less debugging and fewer glitches during quality assurance and testing. Taking an agile approach reduced the amount of rework following user testing and overall meant that the project was delivered on time and within budget.

Making your decision

So, how do you know whether agile is right for your project?

A good technology provider will help guide you through the process at the start of the project – with your budget, requirements and users to the fore – before recommending and agreeing a best fit. This will all be part of the service so do talk it through.

Ultimately, there are a number of different ways to organise and deliver a project and no two pieces of work are ever quite the same. Selecting the most suitable project management approach is like picking the right tools from the toolbox in the correct order – get it right and the work moves forward smoothly and efficiently; get it wrong and the project risks taking longer and costs may go up.