(Fr)agile

by Foolproof

Spending a large proportion of my time out in the field with various client organisations it’s impossible not to notice the increasing number of projects following an agile methodology.

Emerging initially from the software development world, it is taking hold within significant development projects and is being more widely used, not just within the IT space.

Agile is a lightweight approach developed in answer to the traditional, heavyweight ‘waterfall’ approach to project management, which has its roots in manufacturing. It hinges around iteration, cross-function collaboration and getting to code fast and clearly has value in software engineering and hence its ascendancy.

But I’m starting to question agile’s suitability for creating customer-facing systems with a coherent end-user experience. It also seems to me that many projects labelled agile are in fact waterfall projects with agile characteristics. And sometimes this means the worst of both worlds.

The purpose of an agile approach is to arrive at the final, live solution in the most time and cost efficient manner. Evidence I have seen would suggest that a number of projects in the agile framework are taking longer to deliver and proving more costly as sprints are essentially being repeated to incorporate fixes that were discovered too far down the line and too late in the thought process.

The need for speed calls for the delivery of tasks in parallel. In my experience that can often mean it’s not until the end of the process that components are stitched together – making for a fractured, inconsistent user experience. From a programme management point of view it can be an effective approach for delivering swiftly, but from a user experience perspective it brings a risk of needing to go back and fix after the event.

Every major agile project must have a clear vision for the ‘end game’ and from the customer’s perspective. To this end it is vital that a ‘sprint’ is included which gives the overview of the whole experience and is the constant reference point for all teams working in their own sprints.

My other observation is that a UX specialist or IA is needed in most sprints, pushing up the headcount and lapsed time for each sprint. Even then there is a risk of inconsistency from an experience design perspective.

Agile’s benefits are too great to ignore in some contexts, but it does need careful thought and consideration across all aspects of design. Some tips on what might make your agile approach more successful would be:

  • Identify at the outset if agile is right for your organisation and the project – the waterfall approach may actually be what you need (or try taking a look at Eric Ries’ The Lean Startup for a more ruthlessly customer-focused approach)
  • Ensure everyone is aligned to the approach from the word ‘go’ – this may require some cultural change within the organisation, not least to the agile scrum team
  • Key decision makers should be engrained into the process and readily available to allow for quick and rapid progression
  • Make sure you have allowed for ‘sprint 0’ and walk out of the blocks initially before you run
  • Have a consistent UX or IA lead in from Day 1 of the project
  • Build in time for iterative test cycles and don’t shortcut on testing to save time

Author: Patrick Goffin

What do you think?