Main menu

Over the past few years, I’ve been a lead UX designer in an Agile environment. To clarify what I mean by this, I’ll define Agile as a specific development framework designed for rapid iterations of functional software. This is accomplished by the use of two-weeks sprints where developers will tackle a particular user story with a chunk of software. When I worked with Salesforce, we were doing a custom implementation for a client who had a lot of specific requirements that were not immediately met by the out-of-the-box solution. The Agile approach was to break each specific element of the software into a user story with its own requirements and functionality. Each user story was assigned a velocity to determine how quickly it was to be accomplished, with all of the various user stories in the sprint forming part of a larger picture called an Epic. The software used for keeping track of this was Rally, one of the better Agile tools out there.

At Caterpillar, we were building a portal for the various dealers to manage their machines, parts inventories, repair orders, and so forth. There was also a need for the dealers to keep track of their customers. All this was built on the IBM Websphere Portal, a java-based platform of immeasurable complexity that has been the backbone of many American enterprises for years. The product owner and scrum master were based in the US, while the development teams were all located overseas. The tool used for keeping track of all this was Pivotal Tracker, another good Agile organizer.

So where did UX fall in with this? In neither case was it baked into the process, mostly because there was inadequate understanding of the role of UX in the process. A proper User Experience methodology relies on a lot of research up front as well as plenty of validation and testing throughout the process. The ideal is to not waste time designing and building things that don’t work for what the customer wants to do. This is vastly different than building functional software, which only needs to be able to perform the tasks it was designed for to be judged a success. I think of it like this: Agile is all about building working software quickly, and UX is about quickly determining what software will work.

In the case of Caterpillar, there was really no way to do any pure UX other than to observe the dealers wherever possible and ask them questions about the sort of things they did day to day. In this, I was able to help prioritize what the portal needed to do in context (for example, it was important that the rental portal have a mobile component that would allow the dealer to visibly inspect equipment and take pictures as necessary.) Largely, the job became more about applying UI best practices to a complicated interface.

In the case of Salesforce, a lot of the UX research was done up front and throughout the sprints. Development and UX were done in tandem with lots of field studies and specific task and journey mapping that allowed the users to access what they needed in the context and time frame most useful to them.

The biggest takeaway from my experience is that UX needs to be at least one sprint ahead at all times, and more if it’s possible. It also helps if UX is brought in from the onset of the project with a clearly established role and timelines.

During a recent Nielsen Norman Group training, I came across a great case study that I present here as an example of how UX and Agile can be integrated effectively throughout the project:

I recently interviewed eight professionals who work in Agile environments to learn about their journey, their successes and failures. I spoke with people ranging from User Experience (UX) designers to developers and product owners. All worked in an Agile environment for at least two years.

Agile Is Here to Stay

There is no going back. Everyone that I spoke with admitted that the process is not always smooth, but today it is much better than when they first started several years ago. Even at the 2-year mark, some people confessed that it’s not all roses, but it’s much better than it was before—no one wanted to revert to a traditional development process such as the waterfall.

In general, Agile teams agree that this framework facilitates transparency. Issues are identified sooner and features are delivered faster. Gone are the days when developers and designers spent months and months cranking away, working independently, and only identified issues at the end. Agile has minimized last-minute surprises and allowed developers to predict timelines more efficiently.

“We are working smarter. No more 14 hour days for an entire month. We are a team and we are releasing more often… Since we’re working with smaller chunks that are not monolithic, it is easier to predict than something that is huge and can take 9 months. Everyone is aware of progress sooner.” Victor, Software Engineer

“Before Agile it was harder to stay on track. There is more accountability now. Things are more transparent.” Anca, Software Engineer

Practice Makes Perfect

After a few years of trial and error, Agile teams are getting the hang of it. People are better at timeboxing or setting time limits on activities. Daily standup meetings that used to go on for 30 minutes or more are now getting closer to 15 minutes. Team members are better at being concise and sticking to the agenda. There is a greater understanding and appreciation for the “rules” and how the process benefits releases.

Time estimates are more accurate. In the early days, some teams took on more than they could handle insprints (or units of time), but today this is less of an issue because they have learned what is reasonable work for a given sprint.

“The awkwardness is wearing off. People had to get used to the funny way of calling things and the new activities.” Michelle, UI Designer

Communication Is Key

For some team members, the biggest benefit to using Agile is communication. The Scrum method provides the structure for cross-functional team members to contribute ideas, share responsibilities, and refine the process together.

“The biggest advantage to Agile is retrospectives. It allows people to air dirty laundry, improve, and try different things… At first I was very focused on following the rules. After working in different Scrum teams, I’ve learned that I have to work for those teams… Now we have a shared vocabulary, a shared understanding.” Jeff, Product Manager

“The value of scrum is conversation. Don’t beat yourself up over following all the rules. We do as much as we can.” Cathy, Product Owner

Agile Challenges Within Organizations

For many people the Agile road is still bumpy. Gaining company-wide support has been an uphill battle. Teams must work hard to show nonbelievers the value of Agile and encourage them to break out of their comfort zones.

Lack of Executive Support

One of the major challenges with Agile is getting support from the top. Some of the people I spoke with expressed their frustration with the lack of engagement with management. Without executive backing, teams are forced to cut corners and work less effectively. Misunderstandings about the Agile process result in communication breakdown and incoherent planning.

“Requests from stakeholders that are outside of Agile mess with sprint planning.” Julia, UX Designer

“We’ve had to work on stuff that is not part of planning.” Cathy, Product Owner

“Our group is embracing Agile, but our organization is not there yet. We’ve had a couple of Agile coaches, but the coaches were not great at swaying senior management. They didn’t have an impact to get senior management onboard.” Mandy, Senior Programmer Analyst

Inadequate Resources

The lack of executive support usually results in diminished resources. The practitioners I talked to agree on the merit of Agile and Lean methodologies such as Scrum. Each Scrum component is structured to address a process need. Some of the most successful projects occur when teams can commit to the methodology. However, almost everyone I interviewed didn’t follow the recipe or was forced to take shortcuts. The main reason: lack of resources.

Absence of User Research and Usability Testing

Our Agile panelists agree on the importance of validating designs. Unfortunately, most teams don’t conduct user research on a consistent basis, if at all. People cite tight deadlines and staffing shortages as reasons for deficiencies in user-centered activities. However, discount usability methods can accommodate short timelines as needed.

Skipping user research is extremely risky. Even the best design ideas are just assumptions. There are limits to a genius designer. User research allows us to test our assumptions and prevents cognitive bias from taking over and leading us astray.

“We work under internally imposed deadlines and sometimes need to push things out without testing, which is suboptimal for users.” Julia, UX Designer

“It’s really hard to make usability testing happen. We are short-staffed and don’t have a primary researcher. We’ve borrowed someone from marketing, but he doesn’t know the product enough or abide by our philosophy of ‘we love our users’.” Julia, UX Designer

“We don’t have time to run user testing.” Victor, Software Engineer

The good news is Lean UX techniques such as sketching, wireframing, and paper prototyping have gained support. Designers are encouraged to create low-fidelity prototypes as a way to demonstrate ideas and reduce heavy documentation. The downside is that many organizations are not testing them with target users.

“We try to be somewhat lean. My boss is encouraging us to not use wireframes—go with sketches. It was a difficult transition. People joke of me being a wireframing addict. Sketches helped me understand the idea of what we are all thinking.” Julia, UX Designer

“We’ve been doing quick and dirty paper and drawing mockups and collaborating with development more.” Mandy, Senior Programmer Analyst

Tips for Running Smooth UX Agile Teams

Keep Teams Consistent

It takes time to build a good, cohesive team with the domain knowledge to make the right decisions quickly. Each Agile team may work differently and have a unique team dynamic. Disrupting the system wildly interrupts velocity because knowledge and expectations must be reestablished.

“It’s a challenge for me because resources are not dedicated. One week we have this person; next week we have another person. We got an Agile coach onsite but if everyone doesn’t get the training or stick to a project long enough, then you have to start over again when you get a new person… Don’t move people back and forth between Agile and waterfall.” Michelle, UI Designer

Be Proactive Not Reactive

If you are used to working “head down” for long stretches of time, then you need to change your work style or risk being outdated. Collaboration is key in successful product development. The involvement of cross-functional team members facilitates transparency and allows issues to be identified early. Be involved in all aspects of the design process, including planning. Be prepared to share your ideas, show what you are working on, and contribute to discussions.

“Everyone needs to be proactive in improving communication. Be invested in your team and what you are creating. Be an owner not a renter.” Julia, UX Designer

“Developers need to ask, not just take orders. Everyone needs to be interested in working as a team.” Julia, UX Designer

Have a Dedicated Scrum Master, Especially at the Beginning

If you are thinking about going Agile or you are just starting out, make sure to allocate budget for a Scrum master. This person will ensure that the process goes smoothly. Without an experienced coordinator, there is a good chance that things will go wrong, leaving people feeling disgruntled about the process.

“Make sure you have a dedicated Scrum master. If you can’t do that, be clear about roles.” Mandy, Senior Programmer Analyst

“The Scrum master is a sheep dog, bulldozer, and coach. They make sure issues get resolved and the team is motivated. The danger of not having a Scrum master is that everyone thinks the process is disorganized.” Jeff, Product Owner

UX Must Work at Least One Step Ahead of the Sprint

Agile is development friendly, but that’s no excuse for reducing UX’s influence. Effective UX professionals incorporate themselves in the Agile process by actively contributing ideas—from backlog grooming and print planning to wireframing and user research. UX designers must plan activities before the sprint occurs, which means being proactive and testing assumptions and tackling designs ahead of the rest of the team. They conduct “show-and-tell” activities ahead of sprints to introduce concepts to users and team members so that, when development is ready to begin, the team has the designs that they need.

“The UX designer must be at least one step ahead of the sprint. In other words, do research and design work outside of the current sprint. I have to keep laying the tracks for the team.” Derek, Lead Researcher & UX Designer

“Design a little ahead of development. Development is more comfortable with that. They don’t want ambiguous concepts.” Jeff, Product Owner

Conclusion

Agile will continue to gain momentum as organizations discover the benefits. UX professionals must adapt to Agile and lean UX processes, which value transparency, collaboration, and responsiveness or risk being left behind.

The Agile user-experience process is more than just being a thoughtful designer; you must first know the user and continually test your assumptions. Don’t allow user research to run away from you during the compressed timeline of the Agile process. Get out of the office and learn from your users. It is possible to incorporate lean UX techniques into an Agile development process. Methods like online user testing can get you user feedback in minutes.