Of all the software development cycles, Agile is perhaps the most complicated to get to grip with from a User Experience professional point of view.
Unlike previous, more schematic and perhaps rigid development processes, where the design phase had to be fully completed and signed off in all, let’s say, comfort, before the development stage even begun, Agile, and the “ship early, ship often” brigade & advocates came to the rescue, providing just the flexibility and adaptability needed to face the frequent, often sudden changes in requirements Businesses demands nowadays, and that older methodologies struggled to accommodate (with the inevitable financial costs encountered when changes in requirements are paramount and non-negotiable, and large chunks of written code are thrown down the drain, and new rushed, buggy code is produced in frantic timeframes to replace what had sometimes taken months to create).
Agile enables companies to produce quality, working software relatively quickly, and to save money in the process. What is not to like there?
Ask the average UX professional the same question and I am ready to bet money on ‘it’s going to be a long night’.
As User Experience professionals, our main focus is the end user, their experience, their needs, their limitations, and the belief that it doesn’t really matter how jazzy your application is, how quickly was it shipped, and the magic tricks it can perform, because, at the end of the day, unless it supports the User in achieving his or her goals, hey ho, it’s a jazzy piece of software whose main purpose is to satisfy the producer’s ego at best, and a useless piece of software at worst.
Companies seem to have begun to understand this, and, call it ‘desire to produce intuitive, user-friendly software to be proud of’, or call it ‘desire to maximise Return on Investment’, never like today was UX deemed valuable and emphasis was placed on the importance of creating positive User Experiences and satisfying User needs.
Usability departments are sprouting like mushrooms where once upon a time, “Developers, Developers, Developers, Developers” was the only battle shout that could be heard.
Everyone suddenly wants to jump on the Usability bandwagon – and justly so, I hasten to say.
But the reality is that we’re all having to cope with the issue: “How Are We Going To Make It Fit In?”
One of the questions that seem to arise very often is: “Is there really space for any real UX in Agile teams?” and there is no easy answer on this one, unless the two teams in competition (Namely, the Usability Design teams and the Process, Technical & Development teams) are ready and able to co-operate, setting aside petty arguments and demonstrating a willingness to see, understand and embrace each other’s point of view. It really does take hard work, not unlike a marriage maybe. But my experience taught me that where this was possible, the results exceeded the expectations.
Because let’s face it, Agile Manifesto states it. “We are about The People” – Whose people is sometimes hard to understand, granted, but even Agile advocates are users. Surely they want the product to be a success – just like everyone else, and they undoubtedly are prepared to listen where others would want a written document to sign instead.
Agile is all about open communication between departments. Verbal communication rather than written, documented communication that takes ages to produce and no-one ever really looks at ever again, once the stakeholders’ signature is on it. Agile is about trust. The term SCRUM itself borrows from a Rugby practice where the players gather in rows and shoulder-to-shoulder contact, create a binding in order to push the opposition away and re-gain possession of the ball. I mean, how more bonding can it get? But frankly speaking, Agile is all and almost only about The Sofwtare. Which is where, in my view, frictions can occur. But all is not lost.
Simply put, there as many similarities as there are differences between Agile and UX, and more often than not, the problem is created by the people implementing them, but Agile and UX can definitely work together and very well at that.
For example: both disciplines are based on iterative processes; iterative design on one side, iterative coding on the other, but always iteration we are talking about. Additionally, both Agile and UX place a strong emphasis on early user involvement. One does it by conducting user research, the other does it by involving real users in scrums and eliciting requirements on the spot.
Research has been conducted on the subject – see Chamberlain, Sharp and Maiden, “Towards a Framework for Integrating Agile Development and User-Centred Design” (2006) – and a number of principles to follow in order to succeed were identified.
Without going all research-y on you, I will try to convince you of how some strengths from both worlds can be combined to achieve excellence.
For starters, the flexibility and ‘verbalism’ of an Agile advocate can indeed create a bridge and facilitate communication between HCI Practitioners and Software Engineers. Or ‘The Hippies and the Geeks’.
Introducing Usability Experts within a team of Agile Developers can create an immediate shift of focus from finding solutions to problems of technical nature, to finding technical solutions to problems of UX nature. Whereas the UX consultant may be more prone to understanding that certain features that seem so simple can at times be a lot trickier to implement than one would imagine, and often an alternative feature just as valid from a usability perspective, but a lot more simple to realise from a technical point of view can be found, by keeping the communication lines open, and in doing so, a lot of headache be spared.
On the other side, the Agile Project Manager must allow the time to gather real user feedback on the early working prototypes produced, and be willing to give serious consideration to the findings, even if at times this may signify a re-assessment of a sprint or even a release.
In the same way as there is an openness to refactor code to accommodate requirements coming from the Business stakeholders, real success can be achieved by being just as open to refactoring due to changes dictated by user feedback. This will save heaps in the long run, and a lot fewer heads will be on the chopping board when the product proves to be a success than when a products shipped by the deadline gathers dust or even worse, negative feedback.