metaUsable

3 Problems with UX in the Agile Enterprise

Posted in general on June 21st, 2015

Many enterprise organizations are in the process of adopting or are already practicing some form of Agile development. Digital experience architecture and design professionals need to adopt Agile approaches when working with Agile development teams. While it has been the method of choice for start-ups for many years, most enterprise organizations have struggled to go fully or even partially Agile. Some of this has to do with the large number of stakeholders and teams involved in enterprise development. Where I work currently has been trying to go Agile for several years now and I have talked with a few colleagues where they have had more success. The following are some common issues I’ve faced or heard about from UX teams in enterprise organizations trying to adopt Agile methods and some suggestions on how to overcome them.

Other Teams not Working Agile

Aside from restructuring teams into smaller work groups, it can be difficult for Agile development to take off when other teams do not also work in agile ways. This includes project managers, business analysts, product owners, and particularly the (user) experience architecture and design team. When these teams continue to do silo work long before the development is to begin, it creates significant churn as that work suffers from the problems agile was intended to address.

When development gets the requirements and design specs, they start breaking it into epics and user stories as needed. Which is when gaps and the need to rework due to technical constraints or even rethinking the problems, start coming out. The UX team then needs to rapidly redesign, in some cases the whole concept, making much of the early work a waste of time. To be fair, the teams probably did learn things when doing the first concepts. The problem is, despite all the documentation, those design learnings were not likely documented fully and have to be rehashed for the development team.

It is the amount of detail that is put into the first design that leads to frustration for the team. As there is time wasted creating those details and documentation that then need to be significantly reworked. There is a balance between having no planning at all (which is not suggested here or elsewhere in Agile) and having a complete detailed design that is based mostly, if not entirely, on assumptions. Which is unfortunate, as there are ways to mitigate or deal with assumptions, with early testing of design concepts.

What UX can do to support the shift to Agile

If you haven’t already, go read the Agile Manifesto as well as the wikipedia article on Agile development. Agile is a set of principles for developing software and organizations may use several different methods that follow those principles. It will help you greatly to adapt UX to the Agile methods that your organization is using by understanding and learning those specific methods as well as others they may be considering.

One of the main things to understand is that the Agile manifesto was created as a response to poorly run software projects. The goals of Agile and UX are actually aligned in the delivery of valuable software. If anything, UX has a greater opportunity to impact a team using Agile methods than it ever did with any other development approach. UX can be seen as a significant ally if they help push the other teams to work Agile as well including product owners, and business analysts. We also have tremendous abilities to help teams collaborate on design.

UX Research Marginalized

There are a lot of great resources that explain how to adapt UX processes to Agile (See list below), but one area of UX that seems to be problematic for many organizations following Agile methods is incorporating or maintaining design research. Abandoning or ignoring the need to do user research early in the design process is quite common. Having spoken with a few UX colleagues, it seems that there are a number of both product owners and/or development leads who feel that this type of research is not really needed.

The question often asked when suggesting to test design concepts is… If it can be built in just a week or two, why not push it out? On the face of it, this makes sense, why indeed would you waste time testing something, when you can get real time feedback. The problem is this assumes that all ideas being pushed into development are good, or at worse only need some minor refinements.

Agile however, does not prevent teams from rolling out potentially disastrous mistakes that could severely damage your brand and the experience causing people to abandon your product or service. Further, it may take more than just one development sprint to recover. Which means you lose productivity to work on other items on the backlog that might have actually produced a result.

In fact, Agile without user research is just as prone to building unwanted and unusable software as any other process. It just does it in smaller pieces at a time. While it is certainly a benefit of Agile that course corrections are made with each sprint, but several bad iterations may lead you to venturing far off-course. It is possible you are not even headed in the right direction.

Adapting user research to Agile

Most organizations that work with Agile at the very least use informal interviews with customers and/or customer support feedback as sources for defining new features. Additionally, a number of Agile teams use A/B testing, which is great at ensuring that a new feature is being measured. These are great things to do, but they are not enough in themselves. Yet, if either of these are not yet being done, they would be a good place to start.

It is well known that customer feedback is limited in its ability to identify significant innovation. It is also prone to focus design and development efforts on fixing symptoms with features rather than solving real problems. So it is very helpful to do in-depth field research either with contextual interviews or some other formal observational study to understand unspoken needs and identify new opportunities. Actually, this type of research does not need to be tied to the Agile schedule and may be done only once a year or every other year as needed.

While A/B testing can show if something new performs better than the previous version, it does not tell you why. It also does not help produce better design in the next iteration as there will still be a gap in understanding. It is essential to conduct usability testing to observe how people actually interact with your product/service. This is great if it can be done early in design process, but it can also be helpful when it is done at any point.

Performing usability testing at what ever point and including members of the development, product, and business helps everyone to grow in their understanding of the people who use what they build. While it would be ideal to have testing coincide with every sprint, this will likely be too costly in resources and expense. You also do not need or want to test absolutely everything. Having some usability testing of early designs every two to three sprints is a good place to start. Combining rapid prototyping and usability testing with Agile allows for better design outcomes.

This also depends on the length of a sprint. For the common two week sprint, usability testing could possibly be done every three or four sprints. If the sprint cycle is four weeks or longer, then it may be possible to do every sprint.

As for expense, there are additional ways of keeping the testing costs down by mixing remote and in person sessions. Remote testing is great for smaller features and quicker turn around, but it does not always give the opportunity to get clarification or deeper understanding that an in-person session allows.

You can also leverage using internal people as participants who are representative of the ones who use your product, but are not on the project team prior to testing with external people. This is very helpful with remote testing as you can make adjustments in the test itself based on the internal tests. This is commonly referred to as pilot testing, but it can be extended to more than just one or two internal people. Keep in mind that internal people may still have too much familiarity to provide non-insular insights.

Development Release Cycles Too Short

There is nothing magical about the two week sprint. Yet this is the most common release cycle for Agile teams. This however often does not allow for UX to do a lot of the deeper analytical work that is needed to solve some complex problems. This has definitely been my observation for enterprise organizations in the B2B space. In an ideal world this could be mitigated by having two design teams for each development team. While one team is working on the immediate sprint, the other team could be preparing for the sprint to follow. This would provide each design team 2 weeks to do deeper analysis before being on tap for the sprint to execute. But many organizations would struggle to have enough staff to support that.

So a frequent complaint from UX professionals due to this short cycle is that Agile teams are often entirely tactical. This also contributes to the previously mentioned issues of struggling with non-agile areas and cutting out any research that can interfere or slow down the sprint delivery. Instead of appearing collaborative and open, UX is viewed as a bottleneck or hinderance. Sadly what happens is UX gets pushed aside or reduced to just simple user interface/interaction design.

Adjusting UX activities to fit any development cycle

It is incumbent upon UX to adapt to Agile timelines. Google Ventures has come up with a 5 day Design Sprint that includes user research. While it is unlikely that would be sustainable for most enterprise teams, especially in b2b or niche markets, it serves as an example of how much UX can be condensed.

This is where taking a “lean UX” approach can help. Wireframing should be an end to a means. Wireframes are intended primarily to communicate design intent. Creating dozens if not hundreds of wireframes for an enterprise app may give a sense of accomplishment, but it also likely includes many defects as do all artifacts. So while they are used as a reference, they are typically out-of-date and likely do not match the system the day after the release.

You may want to consider sketching and do minimal wireframing and instead consider going straight to prototyping where possible. This works best when UX is able to work directly with development, who are also then involved in prototyping. If that is not possible, then some amount of wireframing may need to be maintained, but it should be focused on the unique elements of the interaction design. Building and using a design and code pattern library or design system for common interactions that is ready to use by the development team can help minimize the amount of wireframing needed as well.

It may also make sense to create a separate stream for the user research that supports the sprints, but is not tied fully to the sprint schedule. As mentioned combining a prototyping/usability testing methodology with Agile is possible. Alternatively, UX can also push for and use Scrum Spikes as time to also conduct needed UX research.

It may also help when other team members participate in the tactical design research with the UX researchers acting as coaches helping the non-UX members in conducting tests. The research team can then also focus on strategic long term research. This allows the research team to uncover and provide deeper behavioral insights for both strategic and tactical initiatives all of which lead to better design.