Most people have heard the term ‘Agile’ being thrown around in conversations about web development, start-ups and design thinking.
This approach to project management and product development can be confusing. There are endless definitions and philosophies of the concept. So let’s take a look at how the benefits of Agile are realised in website development, both from a client and developer point of view.
Typically in Waterfall project management, aspects such as budget, project requirements, scope, features and timelines are planned and defined upfront. You roll through the project in a linear fashion, bound to the critical path and are relatively rigid in the definition of the end product. Changes to scope generally result in a change request and incur a cost. There is also often a great deal of pressure on testing and bug fix turnaround times.
Timelines may be overrun, and consequently the budget as well. By the end of a lengthy project, features originally in scope may even be redundant.
Having said that, I generally find a Waterfall approach fine on smaller projects, particularly where development risks are low and scope is easily defined.
However, in larger projects where:
- There are unknowns
- There are potentially complex development aspects
- Requirements are unclear
- Question marks exist around features
- There are risks associated with attempting to define scope absolutely
Then Agile, or a hybrid combination of Waterfall/Agile (Watergile anyone?), is my preference.
So what is Agile?
Essentially it’s an approach (note: it’s not a methodology. Scrum is a methodology) to product and software development, although it has much more far-reaching application and has been adopted in broader business processes.
Some characteristics of Agile are:
- Value and outcome-driven
- Cross functional
- Responsive to change
The purpose of Agile is to achieve the most valuable outcome (or product) given budget and resource constraints.
I regularly come across misconceptions around Agile, such as
- Budgets can’t be set
- A client has to place an inordinate amount of trust in the developer to build them what they need
- You can’t have fixed deadlines
- Requires no planning
None of these points is true, and quite to the contrary. An Agile project still involves all the usual project elements, such as:
- Defined business goals, requirements, desired outcomes, budget and timelines
- A solution or product engineered at a high level to meet the desired outcomes
- Estimations that are as accurate as possible for work/ resource involved to develop the solution/ product
- Features and items for development identified and estimated at a granular level
- IA, design, development and testing
- Set budget and timelines
So, in practical terms, what’s different about an Agile website rollout?
One of the major differences is when the scope is defined. Agile provides the framework to define and prioritise as you go, rather than attempting to capture everything upfront.
It does mean you need to be agile in your project expectations – being able to shift the goal posts as you go requires careful prioritisation of the most high value elements of your project. It doesn’t mean you can have more for a finite overall budget.
Implementation is undertaken in short cycles or sprints, generally 1 – 2 weeks in length. Decide you don’t really need that feature? Pull it out at the start of the next sprint and allocate a higher priority. Agile is cross-functional and cyclical. This means that by the end of a sprint, something that has been designed, built and tested, is in a working environment for the client or product owner to review.
There’s a focus on efficiency. Teams are self-organising, collaborative and don’t rely heavily on highly detailed documentation – they opt for regular, swift, face-to-face communications.
I highly recommend checking out the original Agile manifesto, if only for the nostalgia you’ll feel for websites from the early 2000s. Amazingly, it’s still being updated month to month with new signatories www.agilemanifesto.org