(Fr)agile

Original post by former Foolproofer Patrick Goffin

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 – 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’ from the customer’s perspective. To this end it is vital that a ‘sprint 0′ 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

04/07/11 Tim Ferguson said:

Really interesting post Patrick and very timely for many large companies who have been sold the vision of agile as being quicker, cheaper and of higher quality. For me it's key that the UX prerequisites are clearly defined and delivered before sprint 1, avoiding the misconception that the UX architect will arrive in the morning of day 1 and the code is being cut by the afternoon.

05/07/11 Elsa said:

Agile and creating good UX is a balancing act for sure. This article reflects my own experiences. Issues I've had is that there is a much larger dev resource than design, so pages a developed up before they are designed. This causes fundamental issues and often means that design can be little more than a paint job. Especially since despite claiming to be agile, there is actually little willingness to go and revisit code that is considered done. I love the principles of agile and infact it should allow for taking UX learning that we gather along the project as part of usability testing. I don't think you can do all the UX upfront either, but there needs to be an ability to do some work that is ahead of the iteration as well as meeting the needs of the team working on the current iteration. Perhaps more balanced teams would allow for this?

05/07/11 COTIN VALOIS Christophe said:

yes you're right (in France) there is generaly no UX architect / designer at this time, so the Agile team are generaly only leads by technical managers reporting to marketing people... reporting to... reporting to... reporting to the deadline defined for the launch campaign! thanks for this post !

06/07/11 Mike said:

As a freelance consultant I'm seeing the 'agile' approach for all the projects I'm involved in and I whole heartedly agree with what you've said, especially the part about agile costing more due to the amount of rework required, never mind the amount of scar tissue it leaves on the code. Also if agile is used, there needs to be time for the UCD 'Discovery' phase and UX needs to work at least 1 sprint ahead with a clear understanding of the 'end game' for it to stand a chance. Thanks for sharing, it's nice to see I'm not the only one who feels this way

07/07/11 Olga Kouzina said:

Hey Patrick, just a curious, have you seen my post with this (fr)agile spelling? or have you invented the (fr)agile word on your own ?:) Here's the post, I've written it in March 2010. http://www.targetprocess.com/blog/2010/03/fragile-teams-handle-with-care.html

07/07/11 Patrick Goffin said:

Thanks Olga, no I hadn’t seen your article (or indeed your excellent blog) before. I suspect we’re not the only people to come up with the Agile/Fragile wordplay: it’s a pun that needs to be punned!

10/08/11 Gregor McKelvie said:

I think you're right about this. A few things I've experienced with agile in order to make it work include: Separating the UX process from iterations, but having a UX representative on the team for communication purposes A clear product ownership e.g. who calls the shots, makes the decisions, etc. in order to drive the product forward Best practice development techniques including a lot of testing to help get around the things that haven't been thought about

17/08/11 Andy Thelwell said:

Nothing wrong with agile at all, and I believe it can work wonderfully well if used correctly. 'Correctly', as other commenters have noted, means a-number-1 having a dedicated UX person or team with excellent cross-functional knowlege and understanding (I call it Full Spectrum UX). It means starting out with clear high-level objectives, dedicating plenty of up-front time to do user research etc. - the 'Discovery' phase as a previous poster put it. Once you've got all that high-level stuff in place and it's clear to everyone, then you can set about the development phase in the classic agile way. This for me is the perfect balanced methodology: be up-front and 'waterfallsh' about setting high-level goals and objectives, do your UCD discovery, document all of the above, then iterate like crazy on the detailed implementation.