Top

Becoming an Agile Company

Ask UXmatters

Get expert answers

A column by Janet M. Six
April 30, 2018

In this edition of Ask UXmatters, our experts consider how best to lead UX design efforts when a company is becoming an agile house. First, our expert panel considers where UX design fits into the timing of agile sprints. Then, our panelists discuss the different flavors of agile—some of which are adaptations that are not truly agile.

Our expert panel also discusses how to present the benefits of agile for the company, as well as the final product, while ensuring strong UX design. Finally, the panel explores the challenges of working for developer-centric companies.

Supporter Advertisement
Continue Reading…

In my monthly column Ask UXmatters, our expert panel answers readers’ questions about a variety of user experience matters. To receive answers to your question in an upcoming edition of Ask UXmatters, please send your questions to: [email protected].

The following experts have contributed answers to this edition of Ask UXmatters:

  • Steven Hoober—Mobile Interaction Designer and Owner at 4ourth Mobile; author of Designing Mobile Interfaces; UXmatters columnist
  • Jordan Julien—Founder of Hostile Sheep Research & Design
  • Gavin Lew—Managing Director at Bold Insight
  • Christian Rohrer—Principal and Founder of xdStrategy

Q: When a company is becoming an agile house and the development team is already resisting the shorter develop-and-launch cycle, how can you effectively involve them in the UX design process without overwhelming an already stressed development team?—from a UXmatters reader

“The very first thing to determine is whether there is an expectation that UX design activities should occur within the same sprint as the development that implements the output of UX design,” replies Christian. “If so, you’re in big trouble because most development sprints are so short—just two or three weeks—that there is literally no time to design—let alone research—any feature of significance and still have time to develop it by the end of the sprint. Many companies try to force-fit design into this way of working, thinking that agile will solve their problems. But I have never seen this work for user-centered design in practice.

“Instead, try implementing a dual-track agile process, in which user-centered design activities are also broken up into sprints and their output is fed into later development sprints—preferably two or three sprints later to give you a buffer. If you use the same language—user stories, epics, sprints—in the design phase, this can be a more acceptable approach within environments in which agile has taken on a holy status.”

The Benefits of Agile

“As with all UX endeavors, you need to amplify the benefits of User Experience to the agile team,” answers Gavin. “Emphasize how User Experience can make the designers and developers more efficient within the agile timeline. On agile teams, everyone typically pays lip service to User Experience, but what User Experience actually does is quickly bring knowledge and understanding to the team. Emphasize the value of this role within short agile sprints. By testing even low-fidelity mockups, collecting feedback, and quickly making design changes, the development and design team—while working in parallel—can code better designs that won’t need as much rework later on in the project timeline. Waterfall development lost much time to redesign. Use UX research methods to discover insights and do iterative design before major coding has begun.

“With agile, UX research must be part of the overall strategy as a means of collecting data or evidence that the design is evolving. Otherwise, User Experience can become a one-off or afterthought. Do not let anyone argue that UX timelines negatively impact the overall process. User Experience should be part of the workflow, not an add-on. Imagine a 12-sprint development cycle. Lock in User Experience for Sprints 3, 6, and 9. User Experience can do testing during these sprints. Whether you’re just testing paper prototypes or what was implemented during a sprint, something will get tested because the dates are on the calendar. Come hell or high water, this is your team’s chance to get smarter. Agile teams will start to see the benefits sooner. This up-front strategy usually gets everyone on board.”

How to Involve the Development Team in the UX Design Process

“Regarding your question about how to get Development involved in the UX design process, you may have to start gradually,” continues Christian. “Often, this comes down to how to involve developers in activities for a sprint when they’re not going to implement the design until another two or three cycles later. If you have succeeded in getting buy-in to a dual-track agile model, the best way to do this is to break down the developer time spent on this sprint into two separate categories:

  1. The time developers spent reviewing design demos or research results from the UX design team’s current sprint, which will be coming to development in two or three sprints. This is a good time for developers to provide guidance on whether the design solutions are feasible, which will help reduce rework later on. This effort should take maybe 10% of developers’ time during a given sprint.
  2. The time spent doing development for the developers’ current sprint, which includes back-end work, but also the development of the solutions the UX design team provided two or three development sprints ago. The developers will probably have questions about issues that they didn’t think of before—perhaps because they weren’t fully engaged because they weren’t coding. This will probably take the majority of their time—about 90%.

“For UX design, the above percentages are flipped: they will spend 90% of their design sprint doing design and research and 10% clarifying developer issues regarding design work they did two or three sprints ago.

“Admittedly, doing this doesn’t actually involve the development team much—we got only 10% of their attention. But you can increase this percentage a bit over time, by either:

  1. Showing how having developers participate in UX design and research improves the overall quality of the solutions you jointly build—if this is true.
  2. Showing that this collaboration reduces rework later on.

“Neither of these is easy to show because you need to gather the stats. Plus, I feel that dual-track agile just doesn’t allow for a ton of overlapping, simultaneous work by developers and UX designers.”

“There’s a difference between simply becoming more agile and using an agile project-management methodology such as SCRUM or XP,” says Jordan. “Generally, if the Development team isn’t involved in the UX design process, it’s not really an agile project. I’m guessing the Development team might be resisting the shorter develop-and-launch cycle because they aren’t involved in the UX design process.

“Keep in mind that the goal of an agile process isn’t necessarily to launch, but to demo at the end of each sprint. You don’t want to end up releasing partially complete work.

“Many organizations structure supposedly agile projects as mini-waterfall projects. These involve discrete User Experience, Design, and Development phases during each sprint. This often leads to the Development team being told what to do instead of their being included in the definition of what the team can accomplish.

“For instance, let’s say you’re on a two-week sprint schedule, and the UX Design team uses the first week to design and the Development team uses the second week to develop a demo. If the Development team isn’t involved from the beginning, they’ll have to wait until the designs are complete before they can start building a demo. In contrast, if Development is involved from the beginning, they can start building out the broad strokes while the UX team is defining the design details. Keep in mind that UX design needs to be as agile as development. In many cases, UX design implies a technical solution without sufficient thought. For instance, it may not make much of a UX impact whether a design uses a modal window or an off-canvas drawer. However, this choice may have significant technical impact.”

The Lean Alternative

“An alternative to agile—dual-track or classic—that may work is to instead adopt a Lean method of working, in which a cross-functional team focuses on the most important question for a given sprint and expends a minimum of effort to answer it satisfactorily,” continues Christian. “When this is done correctly, such a cross-functional team will spend many of their Lean sprints creating concepts or prototypes and testing them with users rather than developing code that leads to a release. This is the most efficient way of answering the most important questions. Later on, when there is more certainty, a lot more coding happens, and the UX Design team may be either working tactically on that solution or getting ahead of the game by doing up-front research for future Lean sprints.”

Developer-Centric Companies

“By the way, the reason you and other readers have this question and encounter this problem is because most companies are developer centric, which can lead to the widespread and sometimes thoughtless implementation of a developer-centric process such as agile,” concludes Christian. “This happens because developers are the largest headcount cost, so companies believe they need to optimize these resources more than any others. In reality, however, they are missing the fact that most of what gets developed must go through the UX design team, which is typically much smaller—from six to 33 times smaller. Adopting a process that makes UX design less efficient tightens the bottleneck further and has the unintended consequence of making many team members even less customer centered.”

“Why is the Development team the one we always worry about being put upon with so much work?” asks Steven. “I have never worked anywhere that User Experience wasn’t outnumbered by Development at least 50:1. No, I’m not kidding. I went back and looked at headcount charts. I’ve been at places that were closer to 200:1.

“So I have to say to any developer who thinks his or her life is hard, spend a day in our shoes, working every part of a project, talking to every constituent team, and doing that on five projects at once.

“It is not the job of User Experience to make anyone’s life easier except the user. Ideally, we are actually judged on those results—and at a few places I have worked, we were, with things like a quarterly SUS (System Usability Scale) being the guide.

“But back to the specifics of the development process, it’s not clear to me why developers wouldn’t want to be involved in the design process. And not just the UX design process, but the whole concept of product design. Far too many implementations of agile force developers to produce code on Day 1. What happened to planning, software design, or even iteration?

“Without these, Development teams get stressed out in the same way you might imagine a construction crew becoming stressed if they were given a pile of lumber, some hammers and nails, and a photo of the front of a house to build. If the foreman were to say, “No, don’t think about it, or talk, or stake out the site, just start building!” Things would go poorly and require a lot of rework, resulting in slipped schedules, unhappy customers, and more stress.

“Resistance to shorter cycles on agile teams results from these sorts of bad process decisions—for example, from management insisting that Development complete entire features in each iteration. From the false assumption that faster iterations are not just a different cadence, but literally faster—so if something takes four weeks today, switching to two-week iterations will make everyone go twice as fast!

“So there’s only so much the UX team can do about much of the development process. But you can try to explain the cost/benefit tradeoff of developers being involved in design up front. If developers plan, design, and use spikes properly to investigate effort and build proofs of concept, when they get to writing the final code, it will be better and it will soon become easier to estimate.

“All of this should sound familiar to most UX professionals. We do our work because we believe in better outcomes through knowledge, planning, and consideration. This applies at every level of the development process.”  

Product Manager at Tom Sawyer Software

Dallas/Fort Worth, Texas, USA

Janet M. SixDr. Janet M. Six helps companies design easier-to-use products within their financial, time, and technical constraints. For her research in information visualization, Janet was awarded the University of Texas at Dallas Jonsson School of Engineering Computer Science Dissertation of the Year Award. She was also awarded the prestigious IEEE Dallas Section 2003 Outstanding Young Engineer Award. Her work has appeared in the Journal of Graph Algorithms and Applications and the Kluwer International Series in Engineering and Computer Science. The proceedings of conferences on Graph Drawing, Information Visualization, and Algorithm Engineering and Experiments have also included the results of her research. Janet is the Managing Editor of UXmatters.  Read More

Other Columns by Janet M. Six

Other Articles on Agile UX

New on UXmatters