RallyDev.com
Tue 30 Aug 2011
Top 3 Reasons Designers Object to Agile and How to Overcome Them
As larger organizations are diving into using Agile methods, we hear a lot of questions about how teams integrate various specialities and skill distributions. One common question that is frequently asked by traditional UX departments is “How will our work and focus change?” Moving from traditional design practices to agile design practices is a big step and requires a significant shift in both thinking and approach.
Jeff Gothelf is the Director of User Experience at TheLadders.com and is at the fore-front of the Lean UX movement. Jeff is also active in the Lean Startup community and posts frequently to his blog and twitter (@jboogie).
I first ran across Jeff at a talk that he gave at the SXSW conference this past year called “Lean UX: Getting Out of the Deliverables Business.” Jeff’s talk was excellent, extremely well-received by the audience and heavily discussed across the Lean UX and Lean Startup communities for quite a while after the conference. I frequently send copies of his Smashing Magazine article (written to accompany the SXSW talk) when UX teams enquire about the shift to agile thinking.
In this post, Jeff shares his experience in addressing the top 3 reasons that designers initially object to agile and ways that we can help introduce alternative thinking to traditional practices.
———-
When first introduced to Agile thinking and processes, user experience designers often balk. Years of software projects and interactive agency-driven initiatives have built strong waterfall muscle memory. Successfully integrating these designers into Agile teams and, more importantly, Agile thinking requires allaying their most important concerns. The three objections below are not the only obstacles to Agile and UX integration but they are the biggest ones. I’ve provided ways to overcome these issues that have worked with my team at TheLadders. Succeed here and you’ve taken a significant step towards creating a higher-performing team.
Objection #1: No more BDUF
BDUF stands for Big Design Up Front. It is what’s known in the waterfall world as the “Design Phase” – a period of time that can last anywhere from a couple of weeks to a couple of months where designers can take the project’s requirements and ideate, at length, over how the solution will manifest in interactions and aesthetics. Designers will typically explore various workflow options, data collection tactics alongside aesthetic, layout and typographical treatments. Even with the addition of a Sprint 0, which allows designers one sprint to get “ahead” of the development team, BDUF vanishes. Designers new to Agile will protest that they are not given enough time to think about the solution and that in no way can they turn around a design in the given timeframe. This resistance alone can quickly kill the momentum of an Agile team.
To understand how to resolve this issue, we need to examine its root causes first. BDUF allows designers time to think about the entire experience the team is building. The expectation is that at the end of the design phase, the entire product is designed and spec’ed out. In addition, this is typically the first and last time the designer will get to spend a significant amount of time on the project so everything must also be right as there’s no (significant) going back.
When introducing Agile to designers, it is imperative to stress that they focus on only a sprint’s worth of design work. In fact, they should hesitate to design too far “ahead” of the development team as priorities may shift after each incremental release and that additional work may go unused. Focusing on a sprint’s worth of work dramatically reduces the workload for the designer. All of a sudden, turning around a much smaller amount of design work becomes much more realistic in the given timeframe.
Second, Agile is iterative. There will be another sprint and it will provide another opportunity to refine and build on the work currently being implemented. The waterfall designer’s mindset doesn’t expect that. The expectation is that the work will be launched never to be touched again. By convincing your designer that this is the first iteration of the implementation, that learnings will be collected and that subsequent iterations will give her opportunities to update, improve and resolve the UX you begin to alleviate the concern that a less-than-finished piece of design is released to customers.
Objection #2: Minimum Viable Product
Designers don’t design Minimum Viable Products. They design robust experiences that demonstrate years of training and skill. The idea of putting out an experience that is “good enough” is antithetical to a designer’s mindset. To her, it feels like half-assing the project.
“Yes, I can lay out a simple, grayscale grid that displays the data but with a few more days I can create color-coded representation of that same data complete with hover states and interactive menus.”
This is a variation on a common refrain from designers new to Agile thinking. The idea that each iteration is being used as an experiment to prove a hypothesis runs counter to the on-the-job training many designers receive at companies and agencies they’ve worked with in the past. In those scenarios, there was typically a “big idea” conceived by a high-ranking stakeholder and the team executed that idea to its fullest. There was no opportunity to get a lightweight version of the idea out, validate it’s potential and iterate from there. This is the true power of the MVP.
A good UX designer is well-aware of the benefits of customer research. Couch the MVP as just that – a way to ensure we’re meeting customer needs. What is the least amount of product we can design to prove this approach is valid or not? Using the MVP as a research tool puts it neatly within a familiar UX toolkit, demystifying it and increasing the designer’s level of comfort with the technique.
There’s a second challenge with the MVP – who gets to define what is minimally viable? In many organizations it’s the development team. In others it’s the product owner. As the responsible party for the User Experience, the designer wants a say in this decision. By including the designer in this decision, you, again, increase their comfort level with releasing what they feel is an incomplete product. Because they had a say in it, they can reconcile the experience in their minds as “complete enough” for this iteration.
Objection #3: Collaborating with non-designers
Agile espouses collaboration and conversation. Designers are comfortable with these tactics, as long as their collaborators are other designers. When asked to discuss their unfinished work with their teammates, defense systems are engaged. At the root of the problem is the designer’s sense of uniqueness and value derived from a belief that only designers can design. Hence, why should she consider the opinions of a software engineer regarding the informational hierarchy or layout of the page? This objection is exacerbated by the other two mentioned earlier. The lack of up front design team and a drive to release minimally viable experiences early on leads to what designers perceive as “unfinished” work. It’s one thing to show rough sketches (both literal and digital) to another designer but a non-designer will likely misunderstand it, provide feedback on the wrong elements and critique elements that aren’t fully baked.
To mitigate this, focus these conversations with non-designers more on functionality and feasibility rather than design elements. Review the rough work for the interactions and data requirements and set those expectations up front. Stress to your designer that discussing these directional sketches earlier in the process provides the developers with a better idea of what they’ll need to do, especially on the back-end, to bring this experience to life. If done well, these initial conversations will build a level of trust between designers and others on the team paving the way for more open discussion and the ultimate contribution of everyone to the design.
While there are other reasons designers struggle with Agile adoption, these three are the hairiest ones to overcome. Each one is a challenge and can take many months to get through. The mitigation tactics laid out in this article are techniques that have worked well for TheLadders. They are, by far, not the only way to bridge these gaps and bring teams closer together. What’s worked well for you? What other objections do you think should be on this list?
Ben Carey is an Agile Coach with Rally Software. You can find Ben on Twitter at @bencarey
Nice article. Designers are also concerned about getting feedback from users before features are implemented. I’ve found that quick and dirty usability testing techniques can mitigate these concerns and I’m interested in how the author and other designers are getting feedback.
We’ve built in a light, weekly usability testing cadence. This rubric has 3-4 customers coming in every week and we show them whatever we have ready. If nothing is ready, we simply have a conversation about their pain points with our products and the jobs space in general. The interesting result from all of this is that, knowing users are coming in on Thursday, the team has stepped up to get clickable prototypes ready for the testing.
In addition we have a steady stream of voice of the customer (VOC) activity going on with phone calls, surveys and interviews both on-site and in our offices.
[Jeff]
I really like the method that is discussed in Rocket Surgery Made Easy (by Steve Krug). Lightweight usability testing can be a huge advantage – even if those tests are done at a whiteboard or with simple paper prototypes.
I think a regular cadence of lightweight usability testing can offer tremendous feedback and I really wish I saw more people using the technique.
Hi Jeff – I agree that getting away from BDUF is important, but I’ve experienced agile where there is also no BPUF (Big Planning Up Front). I feel that it’s important to work out an overall plan first, a rough idea (without specifics) of what will be delivered, such as a high level requirements or goals list. Is this planning important up front, or is this just me being one more UX person who can’t accept agile? Where does research and product management fit into this?
Research belongs as a constant stream supporting all design and dev activities (see my response to the comment above).
Agreed that some level of planning needs to happen up front but to what extent is contextual to your organization. Since most organizations (not startups) are not starting from zero, getting a strategic sense of what’s important to the company is most important. Setting KPI’s and problem statements to set the teams against is usually enough for the teams to then go off and figure out how to best solve those problems.
Does that make sense? Let me know.
[Jeff]
You’re trying to rise out of designers with how you started Objection #3? Good designers know that design = collaboration – and not just with other designers.
Are designers inherently defensive? Sure, ’cause everyone can design. And it takes real trust within a team to accept feedback and expertise from one another. But that’s what I like about Agile — it’s about communication, which helps foster trust. Which is needed to have great, high-performing team.
The communication between team members encourages transparency. That transparency builds trust and cross-pollinates design knowledge with developers and dev knowledge with designers. The silos begin to break down and productivity and quality soar.
[Jeff]
It’s bailed us out many times to focus on User Stories and setting IX/Pattern portfolios which can be another objection for designers. Ditto for dumping the huge requirements documents.
If pattern portfolios are the same thing as style guides, then yes! This is a killer tactic to getting teams starting from a level playing field.
[Jeff]
“When introducing Agile to designers, it is imperative to stress that they focus on only a sprint’s worth of design work… Focusing on a sprint’s worth of work dramatically reduces the workload for the designer.”
As long as Sprint 1 is the conceptual phase, i.e. thinking about the big picture. It’s bizarre how often PMs think you can dive straight into building out features without first thinking about the overall concept.
If the first sprint requires an approach of “only think about x and y, not z”, it actually increases the amount of rework later on. Without thinking about the big picture upfront, teams end up working out a series of parts that lack gestalt, resulting in a piecemeal solution that requires bolted-on frankenstein solutions later on; it’s impossible to design elegant systems this way. “The Big Idea” is an important one.
My experience is that a combination approach works best; work on the big idea upfront, but in very broad brushstrokes. A high level conceptual model is very useful for communication and collaboration within the wider team. The rest of the design phase can then be divided up into defined sprints.
“Without thinking about the big picture upfront, teams end up working out a series of parts that lack gestalt, resulting in a piecemeal solution that requires bolted-on frankenstein solutions later on; it’s impossible to design elegant systems this way. ”
I disagree. We live in an evolved world, not a designed one. We have evolved as a species ourselves. Each of our brains develop in an ‘agile’ manner, so to speak, through trial and error of neural connections. Although we think we are capable of true Design, that is an illusion. The best ‘designs’ invariably come from an evolutionary process. That is, in small steps, through trial and error, over time.
As an experience designer (not a graphic designer) and IA, I completely agree with Kim-Leigh; the risk and amount of re-work later if the entire experience is not at least conceptualised at the beginning would rapidly erode any benefits of agile in a design environment.
Sholom is forgetting one thing: that evolution takes time and only builds on initial successes, so if you launch a product/service that fails because of inherently flawed design or a piecemeal experience, your company may have died thanks to customers failing to welcome it before you get a chance to iterate.
I can understand and applaud agile for development and build and testing phases, but I’m far from being sold on its benefits in an experiential design environment.
This is a pretty simplistic response:
“When introducing Agile to designers, it is imperative to stress that they focus on only a sprint’s worth of design work … All of a sudden, turning around a much smaller amount of design work becomes much more realistic in the given timeframe.”
And it doesn’t answer the need that designers have for BDUF. If a designer works on only a small portion of a site without understanding what else will be on the site, then the design and user experience is likely to be inconsistent or jarring with other parts of the site.
The alternative is, of course, massive rework. We experienced this where we worked on left navigation behavior for the first page in the chute in isolation from whatever else might be coming up. Then, several iterations later, we found a different part of the site required completely different behavior. The rework was massive, as the first left navigation behavior made large assumptions about how the content was authored and deployed, how often it might be changed, how many items there should be, and what level of the IA it can contain.
We are proponents of agile. But this is an overly simplistic response that does not address the legitimate concerns of UX and design.
A combination of some BDUF, identifying and agreeing a minimal marketable feature set, and iterative design has worked for us at autotrader.co.uk. Our Product development projects (which comprise s/w dev, marketing, sales…) require a business case and board approval. This means some UX design is needed upfront, and for major investments is vital. However, the product, s/w dev and design teams collaborate very closely during a project scoping exercise we call “inception”. We create wireframes and user journeys, identify and size user stories, identify possible feature sets and find the right balance of cost, schedule and user experience. We try to do enough planning, UX design and s/w design to size the project, without specifying the final behaviour and design of every component. The detail is added and agreed to when each user story is picked up. It’s possibly more fluid than a sprint by sprint approach. It’s taken us a few years to get to this stage, but on the whole works for product, UX and s/w teams.
The agile philosophy it’s beautiful. The only problem is that companies don’t ever implement the 100% agile. What I see happening most of the cases is a mix of waterfall with agile. This approached confuse them and required lots of efforts to get throughout the process.