I know, I know…you’ve heard it all before. And yeah, yeah, we’ve all worked in an faux-agile stylee. Not strictly agile, just in the style of; a version of an iterative approach if you will. Having said that, we also, ashamedly, find ourselves working in a faux-UCD fashion usual as a result of tight project turn around times; if the user’s aren’t involved, it doesn’t countJ
Before I start going on about a smarter UCD approach and get caught up in semantics, let me remain on the subject at hand: How can you design for and with the user when working in an Agile project environment?
The general feeling from those I’ve spoken with in and across the industry seems to be that true to its roots, agile works wonders for development (amazingly if done by the book I would assume)
On the other hand, for those trying to tred water with high agility in the strategic, planning, IA and design pool, the general feeling here is that rapid development doesn’t equal rapid thinking.
The tug ‘o’ war between design and development is nothing new and we kinda get by; but now throw in a desire to still adhere to a UCD approach – putting the users at the centre of the design and build process within an agile approach and what have you got? Not only now do you have team roles differing in the way in which they need to work (thinking upfront and doing and finding out) but you also have on one hand an approach that seeks to use behaviour to inform the product and another approach that seeks to design, build and learn in the most efficient way possible.
This doesn’t mean that one is wrong and that the other is right – they just come at the challenge from different angles. It means that we should create a way of working that supports the two approaches; by embedding the two approaches within one another, we create a UCD-Agile approach that is neither a pure agile approach nor is it a pure UCD approach.
We can flex and extend the pure agile way of working into the strategic UCD way of working and vice versa; we extrapolate the UCD mindset all the way into agile development. The highest concentration of the combination of the two practises is clearly demonstrated in the multiple rounds of iterative prototyping and testing. In this way we can reconcile the two different approach angles to meet on delivering a user-centred designed product delivered in the most efficient and effective way.
One folly, not unique to UCD-Agile but one which has a hard hitting ramification for is not accounting time for getting up to speed, researching and understanding the product, the business, its competitors and the environment. This must happen first.
Strategic UCD activities that help to create a solid UCD foundation for Agile includes:
1] Everyone on board with the strategy and business objectives
2] Understanding stakeholder requirements and turning these into user stories
3] Understanding user behaviour and articulation of those user via personas
4] Determining user needs and requirements via conceptual and logical scenarios and turning these into user stories
5] Capturing and feeding in tracking, AB/MV testing and SEO requirements
6] Prioritising user stories based on business objectives, technical feasibility and the user
Efficient and effective Agile activities that support UCD through Agile includes:
1] Design and IA always involved in build and working with user stories – the more granular you get, the more you run the risk of being further removed leading to the undesirable outcome of only an agile sub-set of team members focussed on user stories and the remainder focussed on asset production
2] Do not dissociate client and user feedback from the user stories – otherwise it becomes an exercise in responding rather than developing; we need thoughtful optimisation through iteration
3] Have appropriate sprint lengths – not too small so that design and IA becomes reactionary in its iteration and looses touch with the user stories but not long so that the project loses momentum
4] Usability testing with real end users throughout key iterations
Agile is renowned for its minimal documentation stance; but it is just that – minimal. It doesn’t mean that you don’t have to write things down because Agile believes that the team members are all clairvoyant or that they will never ever leave the team; rather Agile encourages high ROI documentation practises such as keeping live documents, updating only when nothing else will do and simple, function over form documentation.
In amongst the high ROI documentation types is a high level project plan. It seems to be a common misunderstanding that because Agile encourages such high and intense levels of collaboration, that the team, by working together so closely will determine their deliverables as they go. This is true, the team will determine their deliverables as they go however they still need to know where they are going, the high level steps to get there and timings.
In the absence of a high level plan, and especially if the UCD part of the UCD-Agile approach is bypassed, the team is just making it up – making up what the system should do and how it should work against their interpretations of what they think is important, and for when. Whilst there’s a lot to be said for wisdom of the crowds, launching the entire team straight into the Agile part comes with all the risks associated with not understanding the business, users and context – sometimes it works, sometimes it doesn’t.
One could argue that the conditions of a constantly iterative and high collaborative project environment, having a plan to know where you are going, for when and how to manage the team is a must.
Because you see collaboration is not a project methodology nor is it a project plan; it is something that happens as a result of working on a project – a behaviour; a way of working. Collaboration happens when 2 or more people are working together to achieve a common goal; even the waterfall project methodology is collaborative albeit to a different degree for Agile does pull an often larger number of team members in and more often.
A UCD-Agile project approach? Nothing new you say? I know.
Everything I’ve just said has already been said a million times before? I know.
Retrospect really is a wonderful thing? I know:)