A topic that seems to be occurring with more regularity is whether UX can work with Agile methodologies. I think many UX folks may have struggled with organizations that are planning or already use an agile development method for a couple of reasons. However, lets start with understanding what Agile is and what it is really intended to solve. In my humble opinion, Agile is actually designed to address the fact that there is little or no UX process or UX people in the places that pioneered and use this approach.
What is Agile?
First of all, Agile is not just a single methodology, but rather a set of values and principles that can be used to judge whether a methodology is Agile or not. You can head over to the Agile wiki page to read more, but I think the main things for a development methodology to be considered Agile is increased collaboration with stakeholders/users and incremental/iterative development of working software.
Problems for UX with Agile
That should sound very familiar to UX practitioners, as those are also some of the same principles we follow for good UX. The biggest difference comes with how iteration is carried through to the final development. So instead of handing off a set of UX deliverables (wireframes, UI specs, task flows, etc) and moving on, UX needs to be heavily involved throughout the implementation and delivery.
Agile does not necessarily remove the tensions between product owners/business needs and user needs. Agile is great at allowing regular input and feedback from the product owners/business. However, it does not completely remove conflicts over what is to be built. Agile also does not do anything to prevent scope creep. It also does not have any specific provision for including user research and in some cases there is not even enough time for wireframing.
So there may still be push back when there are more things than can be addressed in an increment. Particularly if there is additional functionality required based on user needs discovered late in the process. In that case, those items will have to be done in later increments or as a phase/version for a second project. So despite regular input/feedback and iteration, opportunities can be missed and unneeded features developed wasting time and resources.
Get Agreement to include UX
In general it can sometimes be just as hard to promote user needs in an Agile environment as it is in places with non-Agile development methodologies. In both environments it is best to get agreement at the start of a project what UX activities, input, and feedback will be included and prioritized by the teams. Not getting that agreement up front can result in a classic turf war over whose input should matter the most (typically this will be the HiPPo).
So how can you actually get agreement to allow UX work & analysis to be included? You can use the same reasons and justifications for getting UX into any process, Agile or not. You can start with high level ROI and cost reduction examples. It is also great if you can show how you can be a valuable partner at first, rather than trying to take ownership over things that the team feels they already do well. This is especially true where Agile has already been successful without UX being involved.
Of course, it is always easier if you have a senior level leader who supports your efforts and inclusion. So it often pays off to work with the upper level leadership to ensure you have the support to be involved in the right ways.
In some situations when there has not been any UX team previously, if you look closely, it is likely someone is doing some form of UX activity already. Hopefully, you can show that by allowing you or your team to assist, if not take over those responsibilities, it will free them up for other needs in the process. Most of all, don’t be afraid to continue to share the UX work being done with non-traditional UXers.
Finally, even when you have some agreement to allow UX input, don’t forget to invite the product owners/stakeholders as well as developers to any user research activities. There is nothing better to getting buy-in to the value of UX than having these folks see firsthand the problems users have with an application or service. Again, you may find in places that do Agile successfully, that they already have methods in place to gather some form of user feedback. Work with the people who gather that info and seek ways to expand on their efforts.
What UX methods can you use with Agile?
In terms of what to actually do for UX when working with Agile, it is best to dispense with fancy reports and get down to the list of findings and recommendations from user testing. There is a high level overview of incorporating user testing with Agile on the usibilla site.
Quick sketches and whiteboard work may have to suffice in place of detailed wireframes. This is part of an approach called “lean UX”. There may be little or no time to keep detailed wireframes up to date so don’t waste time on them. That may sound like sacrilege I know, but honestly if development can build something in hours then you can really just work quickly with them to see how something works.
Developing or using an existing UI pattern library can help mitigate a lack of wireframes, where similar interactions can be leveraged across a project by reference to an online pattern rather than detailing them out for a specific instance. There is a great virtual seminar on the story mapping technique used with Agile as explained by Jeff Patton an expert in combining UX with Agile.
When Agile is really something else
A common challenge for integrating UX with Agile has to do with whether an organization is really using Agile or just pretending to be Agile. Most places that move from waterfall to Agile do not fully embrace Agile as is the case in places I have worked. They usually end up with some hybrid that really does not help them. Often Agile is seen as a way to accomplish one or two things; to speed up delivery of new features and/or improve the resulting code work. These are two things which are often side benefits of Agile, but not the main purpose and often are not always achieved even in well run Agile projects.
In these situations, the “psuedo-Agile” team goals are to simply chunk up development and hit certain release dates. There is little or no iteration and consequently no real opportunity to actually change things. Even when UX input is allowed, there is typically only room to do one or two items on a list of twenty.
Often places that switch from waterfall to an Agile method use the same project management and scope limiting techniques as when they were non-Agile. They prepare requirements ahead of the project and simply chop them up to plan out the incremental work. This is then coupled with the fact that the increment is not actually iterative, but simply a small piece of work that no longer has any context. So you can still be stuck with the documentation of some earlier defined requirement as a prohibition to change.
What to do
The best you can do in these situations regardless of the methodology, is again work on getting agreements for allowing more UX input and trying to change the working relationship. However, you may be better off sticking to non-Agile UX processes as well, since you are not really dealing with Agile. Look for ways to be involved in the earliest requirements gathering/planning phase as that is where all the decisions still get made. And look for a senior leader who may be persuaded to support increased UX involvement.
It is becoming more common for some organizations, as they mature in UX and Agile to separate out a track of UX work that is done at a slower pace. This allows for the deep, longitudinal research that aides in understanding of your users and discovery of new needs. Again, this is essential regardless of the development method practiced by an organization. Unfortunately, many organizations do not realize the value of this kind of UX activity.
Go to the comment form
When I previously did development work, I used an informal process that more or less was agile long before I ever heard of Agile. I have found most places that try to do Agile don’t actually commit to it fully. The goal is to produce better software in a timely manner, by ultimately being more flexible in the requirements. Instead most places look to use it to develop faster and generally achieve neither better software nor get it done any faster.
There is another way to work with Agile where essentially UX is completely separate from the development teams. Working more strategically you can focus on the major innovations that can then be fed to the Agile teams at one time in the very beginning of a project. This of course requires trust in the Agile methodology and team, but it could be workable with Agile when it is done iteratively. This accomplishes much of what is needed from UX without a UX person being involved in the scrums.