Is UX Strategy Fundamentally Incompatible with Agile or Lean UX?

By Paul Bryan

Published: July 24, 2012

“Do the tenets of rapid iteration and minimal documentation that characterize the lean and agile approaches preclude the research and analysis activities that we typically conduct when formulating UX strategy?”

UX strategy is a growing field that promises clearer guidance for UX design projects. Agile UX and lean UX are topics that have caught fire in the world of UX professionals, promising faster delivery and less waste. Do the tenets of rapid iteration and minimal documentation that characterize the lean and agile approaches preclude the research and analysis activities that we typically conduct when formulating UX strategy?

I posed the question in this article’s title—“Is UX strategy fundamentally incompatible with agile or lean UX?”—to the UX Strategy and Planning group on LinkedIn. The responses passionately asserted quite different points of view. Jim Kalbach, Principal UX Consultant at USEEDS in Germany, wrote: “I think they are wholly compatible. In fact, with agile’s sprints and quick iterations, it’s even more imperative to have a strategy in place before digging in. So agile makes UX strategy more relevant.”

Joseph Borne, formerly Director of UX Consulting at Bullseye, in Sydney, Australia, expressed a different view: “I’m sad to say that I strongly disagree with anyone who feels that agile/scrum and strategic UX have any overlap. I’ve worked in many [agile/scrum] environments where … it overlapped with strategic UX. The inevitable result was complete and utter disaster.”

Given these widely varying perspectives from people who hold responsible positions within the UX community, as well as the fervor with which people are promoting agile UX and lean UX at conferences, I decided to explore the question further. Before discussing their compatibility or incompatibility, I’d like to provide a quick overview of the three topics in question: UX strategy, agile UX, and lean UX.

UX Strategy

“UX strategy is about developing a rationale to guide UX design efforts in the foreseeable future. UX strategy uses data to establish a product vision, goals, and objectives.”

In an earlier column, “7 Ingredients of a Successful UX Strategy,” I wrote that UX strategy is about developing a rationale to guide UX design efforts in the foreseeable future. UX strategy uses data to establish a product vision, goals, and objectives. Some of the key components of UX strategy include the following:

  • business strategy
  • competitive benchmarking
  • Web analytics
  • behavioral segmentation, or personas, and usage scenarios
  • interaction modeling
  • prioritization of new features and functionality
  • social, mobile, and local considerations

The key takeaway is that the purpose of formulating a UX strategy is to develop a rational basis for design decisions, and developing this rationale depends on our having the time it takes to obtain, analyze, and use the data to construct a basis on which we can formulate a strategy.

Agile UX

“Agile has become a fact of life in many companies that produce digital products and their user interfaces.”

Agile development is a method of developing software that attempts to overcome problems that have plagued software development for many years. As Tom Wood, Partner at UX consulting agency Foolproof in the UK explains, “The agile approach [solves] a huge problem that came to head 10 years ago: that IT divisions were incapable of delivering at a competitive pace. Something was needed to smash the old rules, and agile has been really effective at doing this.”

Agile has become a fact of life in many companies that produce digital products and their user interfaces. Agile was created by developers for developers. As far as I can tell, it is completely agnostic with respect to user experience. Executives across a range of organizations have embraced agile development. As Mark Schraad, Director of Mobile User Experience at Sears, noted: “Executives are always quick to back a strategy that promises faster delivery…, and agile teams do commit to that pretty often.”

The “Manifesto for Agile Software Development” clearly states its values and priorities:

  • “Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan”

Agile UX arose organically out of the need for a user experience approach to working with agile development teams. Agile sprints did not leave much room for typical UX activities and deliverables, and this was the source of many conflicts and frustrations when agile first got introduced on a large scale. The momentum of agile was so great and the problems it attempted to solve so severe that UX teams had to adapt or become irrelevant. The response was agile UX.

Lean UX

“Lean UX has been gaining prominence over the last couple of years as an approach to quickly designing new digital products. Lean UX changes the linear path of define, concept, design, and build into an iterative set of design, prototype, and test cycles.”

Lean UX has been gaining prominence over the last couple of years as an approach to quickly designing new digital products. Lean UX changes the linear path of define, concept, design, and build into an iterative set of design, prototype, and test cycles. Lean UX grew out of the enthusiasm surrounding Eric Ries’s book, Lean Startup. Teams within startup companies originally applied this approach to UX design. Ries defines a startup as: “A human institution designed to create a new product or service under conditions of extreme uncertainty.”

I first heard about lean UX through Jeff Gothelf’s talk at SXSW, “Lean UX: Getting Out of the Deliverables Business.” His presentation emphasized a collaborative process of working, a drastic reduction in the number and scope of UX deliverables that designers produce, and shipping better products, earlier.

Editor’s note—Jeff Gothelf presented a variant of this talk, titled “Lean IA: Getting Out of the Deliverables Business,” at IA Summit 2011. To read Pabini Gabriel-Petit’s detailed review of his talk, see “Conference Review: IA Summit 2011: Part I.”

I can understand how a lean startup would opt for very small teams that shape a product quickly, with substantial input from customers. Some popular bands take the same approach when composing a new song. They start with a riff or chord sequence that one member has created. They play around with it, add some lyrics and a bridge, play it a few times for friends and small audiences, then change it up, and, finally, release a version that is usually quite different from the initial song. It’s an efficient, productive, and elegant way for a band to compose music. Seems like a good way for startups to get an exciting new product off the ground, too.

In a very short period of time, lean UX has adopted some pretty specific practices. Giff Constable, a partner of Gothelf’s at Proof, defines the characteristics of a lean product team as follows:

  1. “You are composed of small, goal-driven, cross-functional teams
  2. Each team is tasked with improving a critical business metric (KPI)
  3. Features begin as hypotheses to be tested before heavy investment
  4. Features come not just with acceptance criteria but success criteria
  5. A feature starts as a minimum valuable feature, and then iterates
  6. Proof carries more weight than opinion
  7. The team talks to real customers on a regular basis, including in-person
  8. The team works in agile sprints, with close collaboration across all roles
  9. The team communicates regularly with the rest of the organization and is transparent about priorities and work-in-process
  10. Each team has regular checkpoints where you decide to stop, change, or double-down on pursuing the KPI”

The same description might apply to a lean UX team.

Is UX Strategy Compatible or Incompatible with Agile UX?

“Within an agile development environment, agile UX attempts to optimize the user experience of the products that agile teams produces.”

Within an agile development environment, agile UX attempts to optimize the user experience of the products that agile teams produces. The articles about agile UX that I read in preparing to write this column focused primarily on three topics:

  • participating in an agile team structure
  • modifying UX activities and deliverables to fit an agile process
  • timing UX activities to coincide with sprints

Participating in an Agile Team Structure

For many UX designers, agile UX means becoming a full-time member of a scrum team. Supporters of agile UX encourage designers to expose other team members to their UX design process and to demonstrate early results, giving other team members an opportunity to weigh in and thus develop a sense of ownership in the results. Detractors say this makes lean UX a classic case of design by committee.

Modifying UX Activities and Deliverables to Fit an Agile Process

“It seems to be a foregone conclusion that UX activities and deliverables get cut back in agile environments.”

It seems to be a foregone conclusion that UX activities and deliverables get cut back in agile environments. One reason is that the agile approach is decidedly anti-documentation. Jim Kalbach, however, doesn’t see this as a conflict for UX professionals: “Agile doesn’t mean no planning and no documentation at all. It just doesn’t require programmers to document their code. You still need to develop business plans and strategy first. So there’s nothing inherent in agile methods that excludes UX strategy [in] any way.”

Another reason for a reduction in UX deliverables in agile shops is that it takes a lot of time just to sit through meetings that focus on non-design issues. How can a UX team member complete the time-consuming data gathering and analysis that are necessary to develop a coherent UX strategy if they spend much of each day in team meetings? David Garrett, UX Engineer Lead at FICO, addresses this issue: “Although agile’s short iterations catch small problems before they become larger ones, if you add up all the extra time spent in meetings—me listening to what four other people are doing that I have nothing to do with, which accounts [for] lost productivity time—the hours wasted become significant.”

Timing UX Activities to Coincide with Sprints

“Working from the backlog inevitably pushes small, easy fixes to the forefront, while features that would greatly enhance the user experience, but are difficult to develop get pushed down in priority, effectively removing them from design requirements.”

The timing of UX activities gets a lot of attention in agile UX discussions. Agile development sometimes takes place in two week sprints. How can UX strategy have an impact on the overall direction of a product when a team subdivides its development into two week windows? Mikkel Michelsen, Lead User Experience Designer for eBay Classifieds in Scandinavia, wrote that it is essential to work out your strategy first: “To work with agile UX, you need to have gone [down] the strategic path first and sort of scale down [your] processes and methods to a leaner approach.”

Peter Boersma, an interaction designer in Amsterdam, agrees with Michelsen, writing, “An initial UX strategy would have to be developed before UX design and development starts. Agile teams expect their Customer to come prepared with ideas of what products and services need to be developed, and that requires a strategy to be in place that suggests such products and services. In that case, they are not incompatible; one happens before the other.”

Drew Ellis, President of Dreaming Entirely, agreed that timing represents challenges for UX designers on an agile team: “The process of ‘sufficiently in advance’ is one of the biggest challenges for effective UXD.”

Timing during the agile development lifecycle introduces other constraints on user experience. Participating in an agile team means the prioritized backlog of the scrum team determines a designer’s daily activities. Some UX professionals feel that working from the backlog inevitably pushes small, easy fixes to the forefront, while features that would greatly enhance the user experience, but are difficult to develop get pushed down in priority, effectively removing them from design requirements. Along those lines, Joseph Borne writes that UX team members in an agile environment can be “restricted to addressing granular usability issues. In those instances, the changes necessary to fix one section or field can often create more complex issues or even invalidate any way of fixing other sections or fields. The project becomes a no-win scenario filled with logic puzzles.”

Robert Gillham, Principal Consultant at the UX consulting firm Foolproof in the UK, takes this a step further, saying that the attempt to integrate UX and agile development is not in the best professional interests of UX team members: “Tying user experience design to an agile approach is to risk making UX the servant of coding rather the other way round.” He continues: “Why would a UX designer want to be shackled to something as time-limiting and punishing as agile when it solves none of their problems, but introduces so many more?”

Another criticism of the agile development lifecycle is that it doesn’t allocate time for doing due diligence in terms of strategy or vision. For example, in the interest of rapid development, teams often rely on assumptions in constructing user stories rather than relying on hard data. However, Saumitri Choudhury, Head of the Product User Experience Group at GlobalLogic, doesn’t think that the agile development cycle precludes strategic UX: “It only becomes incompatible if you think of UX strategy as [doing] once-done-and-hand-over, big strategy work up front, as against a Strategize > Design > Get Feedback cycle.”

While I don’t necessarily see UX strategy as a “once-done-and-hand-over” deliverable, neither do I see it as something that a small, cross-functional team should modify by brainstorming on and debating its merits. If you’re going to modify your overarching UX strategy, you need to modify it on the basis of superior or more compelling data, not a freestyle debate.

Dana Martinelli, Director of User Experience at Apangea, stresses the importance of UX research to inform team decisions: “UX cannot be done effectively by iterating with developers in sprints without deep research going in.”

So, Are They Incompatible?

“UX strategists have to get ahead of the curve and do their work before agile development starts.”

My take: UX strategy and agile UX are neither compatible nor incompatible. In an agile shop, UX strategists have to get ahead of the curve and do their work before agile development starts. They need to coach UX team members and convince others on a product team to value the guidance that UX strategy brings to digital design efforts and to follow the strategy in making design decisions throughout the life of the program. Once the agile train gets rolling, it may be very difficult to introduce strategic considerations.

UX strategy can provide the strategic guidance that agile doesn’t attempt to provide. As Liam Friedland, Senior Director, User Experience at Informatica, puts it: “Agile is a process; ergo a set of tactics. Agile is not a strategy. Sun Tzu provides us with a good understanding of the relationship between these two: ‘Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.’”

Is UX Strategy Compatible or Incompatible with Lean UX?

“The lean UX form of UX strategy is too lightweight, too reliant on small data sets, too malleable, and too subject to the assertiveness of a just few individuals. For a large company that has a deep understanding of its market, its customers, and its competition, and the resources to fund the best path forward, it’s not the optimal approach.”

Some time after Jeff Gothelf’s SXSW talk, Jared Spool interviewed him for a podcast about lean UX. During the interview, they discussed the adoption of lean UX by much larger organizations that have little or nothing in common with startups. Such companies are very large, stable organizations that face little uncertainty in terms of running out of cash before their blockbuster product hits the market. They do face uncertainties, of course, such as how to remain competitive in a rapidly changing digital world. But their team structures, availability of analytics and customer data, time and resources for discovery and exploration, brand equity, documentation requirements, and internal processes make them very different from startups. Nevertheless, larger companies are apparently jumping on the lean UX bandwagon, saying, “We need to deliver digital products faster, trim down our teams, ship what customers want, and jettison all those time-consuming deliverables!”

Interestingly, Giff Constable, in his definition of a lean product team, is careful to note that his use of the term lean is “the Eric Ries version of lean, aka lean startup.” Does lean UX make as much sense for large companies, with product and Web teams of 100 to 200 people, as it does for a startup consisting of few caffeine-infused twenty-something year olds, who get by on little or no sleep to achieve the dream of a blockbuster product and an IPO and have a limited pile of someone else’s cash to burn before they have to give up and get steady jobs?

The answer to that question is beyond the scope of this column. Although it does impact my original question: Is UX strategy fundamentally incompatible with lean UX? My answer: It depends on the organization.

For startup companies, UX strategy and lean UX seem like they could be compatible, depending on how one formulates strategy. Joshua Seiden, Founder and Principal at Proof—where Gothelf is also a partner—wrote, “Lean UX is essentially strategic. The central questions it answers are: ‘What do our customers and users value?’ and ‘What will we create to deliver that value?’”

Seiden goes on to differentiate the strategic nature of lean UX from the pragmatic agile UX approach: “People write about lean UX as if it is a synonym for agile UX. It is not. It is a related way of working that uses design thinking, lean startup, agile, and UX methods to go after value. Agile UX on the other hand is a set of practices that UX practitioners can use to integrate into agile development processes.”

Dr. Natalie Hanson, Associate Principal at ZS Associates, adds: “To properly bring lean to an organization and a set of work practices, it, too, needs to be more than just tactics.”

But what about lean UX in large companies? Is UX strategy fundamentally incompatible with lean UX in well-established corporations? After researching lean UX for this article and combining that information with my background in UX strategy in large organizations, my conclusion is: They are fundamentally incompatible.

Am I saying this out of self-preservation? A desire to keep my clients from trying the dark magic of UX strategy themselves and finding out that any three people with a whiteboard can do it? No. I can explain my perspective with a brief illustration. My father used to fly a navy plane, which required taking off and landing on aircraft carriers, where the runways were tiny in comparison to those of typical airports. By necessity, he had to be able to get airborne instantly and to land on a few feet of airstrip. That was the nature of the job, and it was a matter of life and death. However, for commercial pilots, the ability to take off and land a jet in a tiny space is of no value. The size of their aircraft and the safety of their passengers demands that they use the full runway that is available to them.

Startup companies typically have very little runway. They need to get airborne as soon as possible or die. Large organizations have a much longer runway. They can afford to wage a more effective competitive battle and should use every available resource to gain and maintain competitive advantage. The lean UX form of UX strategy is too lightweight, too reliant on small data sets, too malleable, and too subject to the assertiveness of a just few individuals. For a large company that has a deep understanding of its market, its customers, and its competition, and the resources to fund the best path forward, it’s not the optimal approach.

I’ll use few what-ifs to illustrate why I think lean is not only trimmed of fat, but is also missing some of the muscle that a strong UX strategy practice provides:

  • What if customers don’t like the quickly constructed prototype you showed them, but would respond very well to a more complete solution? This is a false negative. For example, a half-baked cake tastes terrible, but the fully baked version of the same cake could be a winner.
  • What if customers try the prototype and don’t like it, because it is void of the data connections that would make it useful in a real-life context? In this case, a critical factor is missing.
  • What if an effective product requires an offline component that would act as a catalyst and lead to its widespread adoption—for example, sales associates’ word of mouth—but you can’t fake this offline component during prototype testing? This is another case of a missing critical factor.
  • What if customers like what you show them, but then, in practice, would use something else because of either its superior marketing or the influence of their peers? The result is a false positive.
  • What if the metrics you gather during a lean UX get-out-of-the-building (GOOB) exercise with three customers indicates that you’ve got a hit, but you’d actually need to do a quantitative study to accurately assess your product’s potential market share? You’d have an insufficient sample size.
  • What if the team creating a complex product is enormous, and your part simply doesn’t work without their part? The whole is greater than the sum of its parts.

In more practical terms, when does lean UX provide an adequate approach to UX strategy? Should a startup trying to invent a manly version of Pinterest use lean UX to guide their design strategy? Absolutely. The vision of their product is clear. They need a design that works, and they need it very quickly. Should BestBuy.com base its UX strategy and roadmap on the ideas of a small team of developers and designers who develop nifty features and try them out on a few customers to see if they fly? No. The latter case is clearly a tactical rather than a strategic approach.

I said earlier that the lean UX process is similar to the process some musicians use for writing a popular song. However, it’s nothing like the process for building a sports stadium or a commercial airliner. Those projects require intensive planning and extensive specifications. Of course, stadium builders and airplane manufacturers could save some time by drastically reducing the scope of the specifications and documentation they create, and they could save money by using much smaller teams of people who merely debate on the best approach, then try it out on customers instead of letting data constrain and define their direction. But the result of such an exercise on products of that scale and complexity would be utter chaos. Will Boeing engineers write the next hit tune? Probably not. Do you want to ride on a plane that the band One Direction engineers? Probably not.

Conclusion

“UX strategy can be effective in an agile environment if you can complete the strategy before agile development begins.”

UX strategy is about building a rationale that guides UX design efforts for the foreseeable future. UX strategy can be effective in an agile environment if you can complete the strategy before agile development begins. Following a lean UX process, you can develop a UX strategy that is sufficient when time and money are very tight, and you need to complete a working product at the earliest possible date. However, lean UX does not serve UX strategy well in large companies that can afford the time and resources to collect and analyze the data they need to formulate a strategic UX roadmap that produces a sustainable competitive advantage.

9 Comments

Wonderful article.

As a songwriter and UX person, the process of creating a song analogy brings up some parallels. Those who do not write songs or are new to songwriting tend to ask ‘how do you write a song?’ The answer is there is no one process but a series of different techniques. Lean UX is akin to jamming a song whilst waterfall is akin to someone sitting down and writing out all the parts in detail before getting a bunch of session musicians in to perform the track.

As you point out, different techniques work in different environments. Agile, for example, allows large organisations to get traction in development if the goals of the project are well understood, but, as you say, requires UX input up front—much as traditional BA (Business Analyst) roles would create key success criterial and, hopefully, would continue to do so along side the UX team.

So, ultimately, there is not magic formula. Lean startup is a very hit and miss thing that appears to make developers more user responsive—but ignores some of the lessons learnt from user research. Something is better than nothing I suppose.

Lean UX is good for reminding us that sometimes the best way to get a project moving is to keep it open and collaborative, but sometimes one person and a day’s desk time can solve a problem a team can’t.

So, just like, as a songwriter, I know there’s a whole bag of tricks I can use to make a song; as a UX person, I know there are many different processes I can use depending on the situation—with no one process being the way to do things.

Hi Paul,

Thanks for yet another great article.

Just to qualify my quote in the second paragraph: The word before is key. That is, the increased relevance agile gives UX strategy exists when UX strategy happens ahead of agile sprints. It’s a matter of timing. Trying to do both at the same time does indeed lead to chaos.

Not everything can be done in agile sprints. And that doesn’t just go for UX design. Even engineers wouldn’t change system architecture in the middle of a sprint. Business stakeholders wouldn’t change corporate strategy overnight. So why should UX designers be expected to create a product architecture on-the-fly in two weeks?

So I agree with your conclusion: “UX strategy can be effective in an agile environment if you can complete the strategy before agile development begins.” If you can do that, the UX strategy is even more powerful because it then drives so much subsequent activity.

Jim

Good article, Paul. I think you make many great points.

I’d probably clarify that you need a different UX strategy depending on your circumstances and that your strategy needs to be constantly refined and revisited based on the current conditions you are operating under. It�s not something you just do before development begins and you�re done.

I�ve started UX teams at several companies and worked in or with many more. I can assure you that one size does not fit all when it comes to UX strategy.

You can’t take the UX strategy that worked at some big company with a giant team and apply it at an early-stage startup. Just as you can’t take a strategy from a lean startup and apply it to a larger non-agile company without some modification.

Lean can be applied at big companies. The principles behind it are rooted in TPS, the system Toyota used to become the largest auto manufacturer. In fact, it’s a key reason why they overtook the US giants in that industry.

The big 3 weren�t lean. Neither are most companies in tech�and these companies are in trouble if their competitors become more lean.

Thanks for your comments, Stew. I like your extension of the songwriting metaphor. I agree with your point that lean UX and other approaches are useful tools when we know when to apply them.

I think the two approaches can work in conjunction, but not in parallel, and it’s very difficult to implement both if the same designer is responsible for everything.

Agile is a tactical tool to achieve an outcome; strategy defines what the outcome should be.

That isn’t to say that insights and metrics gained as part of an agile or lean approach shouldn’t inform strategy. Strategy is a process that is constantly synthesizing that feedback loop against current thinking.

That said, I think it’s a lot easier to introduce both approaches when you are working at a product-focused company—on the client-side—rather than externally, at an agency or consultancy.

It’s very difficult to get stakeholders to embrace strategic work from an external source because it requires a very deep understanding of the business strategy and development constraints. Most business owners distrust outside thinking because they assume that you don’t sufficiently understand their objectives.

Good strategic insights take time to develop and express within an organization. It can be as simple as stating a unifying set of design principles and personas that all UX should be rationalized against, or it can be as all encompassing as a dedicated group to maintain the above along with prototyping concepts, style guidance, and approved pattern libraries well ahead of where the developers are sprinting.

Thanks for validating my inner UX. I think UX is more like architecture where you have to think of the bigger picture. And agile tends to be: let’s design one room at a time. In my experience, it helps to do as much groundwork as possible before going into agile. As for the amount of specification required, I feel it depends if you are building an airplane or writing a song. ;)

Thanks for the article, Paul. You brought together a lot of good information and raised some interesting points. For me, what still resonates the most after reading your article—as well as the comments—is that there is a great deal of confusion amongst each of these terms. We work in an industry where buzz words come and go rather quickly, and folks are constantly searching for the next silver-bullet tool or process to champion.

I think it’s important to remember—as some others have mentioned—that it is often necessary to adapt principles from several methodologies to best fit a given company or working situation.

In that sense, these terms do not have to represent all-or-nothing, monolithic methodologies. For example, I personally do not consider lean UX to be mutually exclusive with creating personas or scenario modeling, or to mandate a restriction on the size of a customer sample set. I also do not consider adopting agile to mean that a team is eager or willing to short-sell epic story decomposition.

IMHO, in a market as fast moving and volatile as technology, the risk of a false-negative or positive is always there, no matter what approach you choose.

Jim: A lot of the responses I’ve received from this article underline your point: that there are UX strategy milestones that must take place prior to beginning agile sprints. Depending on the strategy deliverable or data collection and analysis that is required, this could take significantly longer than a couple of weeks to produce.

Jon: Strategy at small startup companies may be “constantly refined and revisited based on the current conditions,” but this isn’t the case at any large companies I’m familiar with. The business strategy is presented to the board and approved, and the UX strategy needs to be in alignment with and accomplish the business strategy.

Lean manufacturing—exemplified by Toyota—and lean UX—as presented at conferences and workshops—have little in common besides their name. Lean manufacturing focuses on minimizing production waste and on supply-chain management. Lean manufacturing doesn’t organize a small team to put together a minimum viable product and try it out on customers to see how to shape it based on their responses. Lean UX does.

I stand by my conclusion in my column that lean UX, as promoted at conferences and workshops—with a small cross-functional team rapidly concepting, designing, developing, and testing a prototype to establish the UX direction—may be a viable product design approach for startups. However, established companies funding large initiatives would do better to develop their UX strategy practice with robust data collection and analysis, and to develop a rationale for their design direction and user experience roadmap.

Join the Discussion

Asterisks (*) indicate required information.