When something is wrong, it deviates from truth or fact. And I can say, with more confidence than ever, that traditional Agile software development methodologies (i.e. Scrum) are wrong for UX. In order to prove my case, I want to take you back to the inception of Agile (as I have read and experienced it) and its related software development methodologies. Along the way, we’ll point out the reasons these methodologies are incompatible with the field of User Experience Design.
The birth of Agile
Agile principles and related methodologies were created for several reasons. Perhaps one of the bigger reasons was in response to the problems of the waterfall software development methodology (the most popular methodology in use up until this point). The waterfall methodology involves defining all system requirements and designs before beginning to build the software. Once these requirements and designs are defined and signed off on, the development team begins to build the software to spec. However, because of its rigid, separate phases, this system proves ill-equipped to handle the changes that can come about as new ideas arise and requirements evolve. This inability to handle change throws off build time and costs in a big way. Thus, the problems of waterfall include high costs in development resources with low return in quality code. Simple put, waterfall proves bad for business.
From this, Agile principles were born. These principles include: 1) a focus on adaptive methodologies, 2) a focus on people and 3) a focus on self-adaptive processes. Different methodologies utilized these principles in order to create working software more rapidly and iteratively to decrease costs and increase quality. And, that is something that Agile methodologies do very well. They enable businesses to make software cheaper and faster, and they also help to incorporate more user feedback in the process. So, why am I saying the methodologies born out of these principles are wrong for UX?
The second principle of Agile is a focus on people. This must mean that there is a focus on user experience design, right? Wrong. At least, this is wrong for many of the adaptive methodologies that we are putting into practice when we say we are “doing Agile”. Agile methodologies do focus on feedback from users to help create a higher quality and more usable product. However, what you’ll note is that nowhere in the above story of Agile’s birth was any other participant in the software development lifecycle mentioned except for the development team. The focus in creating these agile methodologies was simply on making the development process more efficient. UX was not even an after-thought (It really wasn’t. We had to butt our heads in and keep reminding them that we existed. Nod your head if you agree… Ok, you can stop nodding.) Thus, Agile principles are great, but the adaptive methodologies that employ these principles do not take into consideration anyone else but developers (and stakeholders… someone’s gotta pay for the work, afterall). Furthermore, there is an important reason why these methodologies don’t take anyone else into consideration. Put simply it is because Agile adaptive methodologies are software development methodologies, not product development methodologies. Thus, Agile methodologies were not designed for, nor intended for UX practitioner participation.
To make matters worse, our businesses have latched on to Agile methodologies as a way to decrease costs and increase production. Because of the appeal of saving money, decreasing time and increasing quality, the business hasn’t stopped to really think about how Agile methodologies should be employed, and the effects of employing them incorrectly. The result is that they have confused software development with product development. They are trying to substitute software development methodologies (Agile’s adaptive methodologies) for product development processes in hopes to speed up the entire product development lifecycle. Therefore, the business cuts out any thought of upfront product validation and research, as well as, any product strategy work because these processes are not “part of Agile”. Ultimately, by the business trying to replace product development processes (where UX contributes the most value) with Agile methodologies (which weren’t designed to include UX in the first place), we see UX processes and procedures get pushed out of product development all together (are you pissed off yet?).
Please let us play
In the fury of switching to Agile methodologies, UX does not want to get left behind. Therefore, we keep trying to fit ourselves inside of Agile methodologies (Note: Some companies and startups have found a way to do this very well, but most are still lacking). Most of the time, UX is looking for ways to ensure we are involved, and are thus constantly compromising our processes and beliefs in order to stay relevant. In the process, we lose more and more of the value that we bring and make ourselves more and more irrelevant. We decide that research doesn’t need to be as extensive as we think (and yes, sometimes this is true), and so we cut down on it. We decide that design thinking can be sped up and so we skip through that. Basically we are doing everything to ensure we don’t get kicked off the playground and sent home.
Obviously, Agile isn’t going away (for good reason), and UX can’t just stop trying to bring our knowledge to projects. So, how do we solve the issue mentioned above? I think the first step is truly internalizing the issue, that of businesses using Agile methodologies for product development. We need to realize that Agile methodologies are great for software development, but are not great product development.
Second, we need to become educated about the difference between using Agile methodologies for product development versus for software development so that we can educate our businesses to this fact. And, how do we educate our clients and businesses about this? Easy; we tell them how they are wasting their money trying to fit a square peg into a round hole. Businesses have employed agile methodologies to decrease costs (see Learn the Business Behind Our Business for more thoughts on this), but using them incorrectly will only increase costs in the long run. By applying Agile methodologies to product development, something they were not designed for, businesses are dumping money into an investment which will yield a small return. Because they are disregarding upfront research and strategy, they have no idea how their product will sit with users and this is a huge risk (for more info see How to Know When Your Product is Going to Fail). They are also using the wrong resources for the wrong responsibilities at the wrong time, and this is even more costly than returning to waterfall!
Third, we need to design a solution that works, for everyone, and then sell this to our businesses. This might mean a methodology that includes Agile principles in its build methodology (see The Secret Step to Agile: Discovery for initial thoughts. Slides also available), or it might include an entirely different thought all-together. But, we have to have a solution to product development that is cost effective, user effective and tech effective in order to push out Agile as the reigning product development solution. Agile is meant for software, not products…. we have to spread this message.
Once we educate our businesses and help them to see the error in their ways, some important outcomes occur. We get a change in the system of how products are developed that allows UX to exert its value, Tech to exert its value, and Business to be successful. Agile methodologies don’t reign as product development methodologies, but continue to evolve along with their related software development methodologies. This helps to create software cheaper and faster, but also software that is relevant, delightful and useful. But, UX can only get there if we cause a shift in the times, and that shift is the outcome of us changing our ways from people just trying to get invited to the party, to the people who are throwing it. The choice, is ours.
Here is your problem statement: In the fury of switching to Agile methodologies, UX does not want to get left behind. Therefore, we keep trying to fit ourselves inside of Agile methodologies.
Fine. I don’t disagree but you could easily change this to say “In the fury of switching to [insert any SD methodology name here] methodologies, UX does not want to get left behind. Therefore, we keep trying to fit ourselves inside of [insert any SD methodology name here] methodologies.” You say that a focus on people is one of the Agile values. That isn’t exactly true. Agile values customer collaboration over contract negotiation which is not the same thing. Is it possible that you twisted this to fit your model of the world and are now disappointed because agile was embraced but you and UX were not? Look, I feel your pain but the challenges you are describing have nothing to do with agile or even the differences between product and software development; you are up against a leadership/vision/corporate culture issue. Until you realize that you will be swimming upstream.
Hmmm interesting points Anon… Thanks for them… and for reading! to me the problem statement is more along the lines of we are using a software development methodology to develop products, and because UX is more about product development as opposed to solely software development it is not a part of Agile. Perhaps that did not come across clearly in this piece, and I thank you for pointing it out. I agree that this is a leadership/vision/corporate culture issue and yes, until that changes there is little point in fighting the river!
Have a UX Backlog. The UX team can work creating items at its own pace. Just as in a normal backlog, new items added to this list have a coarse description. UX can then prioritize and decide which items to work in the next UX sprint (completly independent from the Coding Sprint).
Because of the creative nature of UX, sprint lenghts can be more flexible, but the end product of every sprint is a full item in the Coding Backlog. They can later decide if they include it right away, or if it makes sense to wait a couple sprints for it.
So, the role of UX is to make sure that the Coding Backlog has enough items. If the list starts getting to short you can add some easy-to-define but hard-to-implement items to win some time.
That’s def one way to look at it!
[…] or even to be a productive member of the team. It isn’t uncommon to hear UX teams disparaging agile methods altogether, or Scrum in particular, as unworkable and infeasible to implement fully given their role in the […]
[…] Agile is Wrong for UX […]
[…] Agile is Wrong for UX | Elisabeth Hubert […]
[…] 1) Agile is Wrong for UX […]
Liz, thank you so much for this post. It might be perceived controversial for some readers, but after all it encourages to think not just accept.
I gathered my thoughts and experiences on UXPin blog: http://blog.uxpin.com/922/agileheads-wrong-for-ux/
Thanks Marcin! Great piece… you point out some interesting and important points!
And… you are more than welcome. Thanks for reading, commenting, and using to curate your own piece. That’s what it’s all about!
This reminds me of Act First, Do the Reseearch Later, http://www.core77.com/blog/columns/act_first_do_the_research_later_20051.asp
Great point Jason! I do love this piece, and agree. But the opportunity to access the need for UX and research I think is good to have.
I was actually preparing a longer reply, but after reading Ben Melbournes coment, I felt I had nothing to add.
In short, the problem lies not within the principles, nor the methodology, but in poor execution.
The general principle is to actually be doing things, rather than hamper the organization with tedious administrative duties – and learning while doing these things.
It’s plain wrong to focus too much on Agile being software-centric. While this usually holds true, the bigger picture is that UX:ers and developers alike (and a lot of other disciplines) are ‘Creatives’ that produce stuff, and should be treated as such.
United we stand. Together, we deliver. (And – hopefully – are having fun doing it.)
The most devastating way of messing things up is to start using an iterative process without fully letting go of the tried and tested waterfall method, thus creating the ‘Iterative Waterfall Pseudo-method’, best illustrated by the Penrose Stairs.
Great points indeed! Thanks for sharing them! I agree that we are all part of one team, devs (of which I was once one) and UXers alike.
Lis, great article! I’ve always been of the mind that Agile is great for UX as longs as we don’t involve developers.. lol
I like the comment about the “”infamous Sprint #0” – so true.. really the only way to to “”Agile”” with development teams because by the time the cogs get moving in sprint #1, it is too late for UX.
That’s why I’ve always had a bent towards rapid prototyping even if its throw away code. Within a UX team if you have a way to prototype, you can churn really easy through prototypes without worrying about production issues. Just design and build on the fly as many times as possible. That way the product development cycle is not stifled by all the limitations IT has.
Thanks again for a great article…
Thanks for reading :-)!
Great comments overall… I wholeheartedly agree!
Please read “The New New Product Development Game” by Takaeuchi & Nonaka (HBR 1986). Then go to Jeff Patton’s site http://www.agileproductdesign.com and look around for awhile. After I would go back to whoever you have been working with that gave you your experiences to date and perhaps punch them…hard. And if you happen to be in Dallas in August come to Agile 2012 and sit in on my w
Now this… this is the top of thinking I have been looking for (referring to Jeff’s site)… thank you! If I make it down to TX in August I will be sure to come to Agile 2012 :-). Thanks Jimi!
Thanks, I was thinking to be crazy…
The difference between product development and software development is important. What I feel in the Agile methodology is the over-fragmentation of tasks and visions. Being concentrated in goal to achieve, step by step (micro step by micro step), makes people loose the full vision of the product and the longterm purposes.
Product development needs to see over the short term period, have a general purpose (which, of course, is flexible and reflects the short terms ones) so have a complex vision that cannot focus only (and get lost) in the micro tasks.
If you are crazy… so I am :-). Thanks for commenting!
Lis, interesting post. I’ve been working intensively on a couple of scrum project myself as designer and I recognize most of what you describe.
I do have a question. I don’t really understand the difference you make between software and product development. Am I correct to state that by product development you mean the development of a physical product? Because in my opinion software as a whole is a product.
Thanks Erik. To answer your question, but product development I am not just talking solely physical products and I am a HUGE proponent of the fact that software is a product (it is, after all, my profession to help create these software products. I should have been more clear. When I talk about product dev I am talking about both the execution of the ideas (i.e. software development or “the build”) as well as the research, strategy, analysis and other thinking that goes into coming up with, defining, scoping those ideas. Thanks for allowing me to clarify, as well as for reading and posting!
Lis – this is something that I have been struggling with for the past few years. I am a huge fan of the principles that guide agile software development.
Though I still want for a solution, I have found a way to describe the issue in a more (I think) neutral manner: agile is well suited to development, but not to _definition_. Which I believe is what you mean when you say “product development.”
Agreed! One day I’ll be more subtle :-).
Lis, I understand the problems that you are facing, but I don’t believe that Agile is the source of them.
What you have described comes across as an Us vs Them mentality. It doesn’t sound like you’re sitting in the same room, working in a collaborative, multidisciplinary team, developing a high quality product. It sounds like a designer is sitting somewhere separate to where the Developers are, who are sitting somewhere different again to the person who owns the product. This would automatically lead to a disconnect between what you are doing as a UXer and what the Dev teams priorities are.
Design should be seen as a continuous activity that happens throughout the entire product development process, from product envisioning, through delivery, to being evolved.
Once you are all co-located working as part of the team, all these problems start disappearing as it becomes everyone’s priority to either learn more abouts users (research) and how the product should be built to support their needs (design). This is part of the UXer’s role in the team, facilitating the creation of a great UX by helping the Devs build empathy with users.
This is also were the ‘People over Processes’ part comes in. People too often see Agile as a prescribed set of methods (i.e. Scrum/XP) where it should be seen more as a set of values and principles. Once you get the right people working together on a project they will figure out the best methods that allow them to create a great product.
The other underlying problem is Product Management, in particular believing that Agile will solve everything. If your Product Owner/stakeholder doesn’t have a clear vision for the product and what they want to achieve, then having a Dev team build software is always going to create a less-than-great result.
Yes, Agile is a software development methodology. What it is great at is
giving a Product Owners the ability to be in control of the development of their product. Just like UX Designers are great at helping Product Owners understand their users and turn that understanding in to a well designed user experience.
Where tensions typically surface is when a Dev team starts building software without a clearly understood and articulated vision. But likewise problems come up equally often when a vision is designed and locked-in with consideration the technology medium that it will be built it. Doing either of these in isolation will always lead to problems. The right balance between the two is a judgement call that has to be made on a project by project basis. And that judgement is best made by a collaboration between the Product Owner, Devs and UXers working together.
I completely agree with these points. I have worked in successful co-located collaborative teams, and I agree that it is more than just beneficial but necessary. I do love your point “The other underlying problem is Product Management, in particular believing that Agile will solve everything. If your Product Owner/stakeholder doesn’t have a clear vision for the product and what they want to achieve, then having a Dev team build software is always going to create a less-than-great result. ” – this is exactly what I am talking about, the use of Agile methodologies for the wrong means.
You’ve given great insight into this discussion… Thanks for reading and posting!
Finally someone had the “balls” to say this; I have been talking about this for YEARS, way before agile hit the mainstream – was extremely excited about its potential for incorporating UX into the process, and after years of trying found just what you are saying. I’ll take it a step further and say I am not convinced that agile is optimal for all software development; in part because rarely is there a vision and objective that is continually looked to throughout the developments cycles; often any bigger picture gets wiped away and the product is continuously being tweaked for the sake of being tweaked at a very tactical level. That’s radically at odds with UX, and more broadly I’m not convinced over the long run it does save companies money. Anyway, thanks for the article! Agile will not be going away for a while–tho it has become, in some circumstances and to some degree, the tail that wags the dog and that will eventually be discovered–and so it’s incumbent on us UX practitioners to figure out how to make it all work well together, and not lose the vital value-add we bring to the table.
Thanks Susan and you are more than welcome! I think your step further is a great point to think about!
Agile is about making “great” software. UX is about making the “right” software. IMO. Great post! I’ll be passing it along!
OK, I will provide more meaningful critique.
>The result is that they have confused software development with product development.
If I understand you correctly, you think that software development != product development. If we talk about hardware devices this is true. But if we talk about software itself, it is nonsense. Software development IS product development. You just can’t have any separated methodology to create software, it is straight road to mediocre products. There is no separation. UX should be embedded into development process.
Indeed, agile was born with no UX in mind. Moreover, RUP, Waterfall, etc. do not pay attention to UX as well. So this is very common for software development companies to ignore UX. However, recent attempts to incorporate UX into agile are quite successful.
>Businesses have employed agile methodologies to decrease costs
Nonsense. First goal of agile is to create working software. It may be even more expensive, but it will be released sooner and with better quality. Agile gives feedback cycles, that is how you can adjust and change. Cost is not the reason to apply agile.
>Because they are disregarding upfront research and strategy
What do you mean by this “research”? Usually such researches are waste of time. If we talk about basic prototype and some proof of concept tests it is OK. If we talk about “market research” with complex focus groups, surveys etc – it is waste of time.
In fact you do not propose any solution, you just talk about that we need to find it. Solution is already there, just google Agile + UX and try to apply numerous practices that tried by many teams over the world.
Again, your main mistake is to think that product development does not equal software development.
We started UX adoption 3 years ago. I can’t say we are perfect, no we are not. But there were no critical blockers, adoption was quite natural. http://www.targetprocess.com/articles/agile50months/
Thanks for the critique! Very helpful in seeing your point of view. I think the main point where we differ, you are correct in stating this, is the difference of product design and software design. I by no means mean to see that software isn’t product, however, to me I also design for the emotions, needs, goals, and tasks of the user. While working within Agile iterations, there was not room for proper research and strategy around these user motivations. I am not talking about market research, I am talking about user research, a very important aspect which can and should be flexible to product needs. I would wager that the majority of products fail without it. If we are defining UX in the same way (not just wireframes and interface) I’d love to hear how you are adapting indepth user behavioral research into your agile system.
UX should never be done inside iteration. It is just impossible to do that. In an iteration you can slightly correct things, no more.
UX is a separate activity that runs in parallel with implementation and ahead of it.
It is not that hard at all. You should split system into quite large chunks and run UX for these chunks separately. Sure, you should have a vision of a whole system, but it does not make sense to design and polish it before implementation.
So the flow is:
1. Gather requirements
2. Think, brainstorm, sketch.
3. Create a high level prototype (very rough) to see how the whole system can behave
4. Proof this prototype with target audience
5. Split system to large Epics
6. Design 1-3 Epics, create detailed prototypes (if it is fast)
7. Start implementation of these Epics iteratively
7a. Run usability tests on a prototype or live system
7b. Start designing next 1-3 Epics
Release as early as possible to get feedback and adjust.
P.S. By Design I mean UX, Graphic Design, flows, emotions, etc.
Michael, your argument fell over at Point 1- Gather Requirements. Where are you gathering these from? I’m guessing it’s getting people into a room to talk about “features”. I’m also guessing this because of your other failed point about most research being a waste of time. When you break clear from solution mode, try reading Indi Young’s “Mental Models”.
“Usually such researches are waste of time.”
Michael, this then is simply a fundamental difference in how we think about design. The ol’ throw-it-at-the-wall-and-see-if-it-sticks approach after you’ve already started coding won’t tell you hardly anything about your users’ needs.
“throw-it-at-the-wall-and-see-if-it-sticks ” – I don’t like this approach. What I like is sketches and quick tests.
А, русские оптимисты, восторженные западным творением!
Но, увы, код – это еще не продукт.
I don’t know what do you mean by 1st phrase. But it is quite obvious that code is not a product. Design is not a product as well.
I do get where you’re coming from. Having worked for companies who used XP or Agile, XP did facilitate that research phase better. blocking out a suitable time based on the scope we always had enough to do the primary bit of research and design before it went into development. The development cycle also allowed us to gain additional time for testing throughout the process.
With the company that ran in Agile, we fabricated the infamous Sprint #0. This was a block of time for producing the product backlog of what would be going into Sprint #1 and building user journeys and wireframes for that covered those items.
It did work, but meant there wasn’t enough time at the end of a sprint to run a measurement period to see what success rate there was and to be able to prioritise the items for sprint #2.
Where I believe the problem lies is that companies that are below a certain size do not invest in R&D in the pure sense. They’re not throwing around ideas to see whether something is viable before putting it into production.
The other element which I feel is important to raise is that UX should be at the core of the product – not part of a cycle. There are tasks to be undertaken within the cycles yes, but it is not a by product, or a service which can be slapped on either end and have a ribbon wrapped around it.
Great points Andy! Couldn’t agree more.
I believe you’re crossing Scrum and Agile. Agile takes no stand on iteration length, Scrum prescribes a consistent iteration or Sprint length.
Regardless, if you are having difficulty in fitting a piece of the process into an iteration, then the piece is insufficiently defined or its complexity is underestimated.
It seems you never worked in agile team and just dont understand how to mix agile and Ux.
I’d be interested to hear why you’re thinking so? Perhaps you think that UX is solely about the interface, wireframes, etc? Perhaps something else… but I’d love to hear why… I’m sure you have some interesting insight.
I actually have worked with many agile teams. These thoughts come from the perspective that no matter how many “scrum masters” and “agile experts” I worked with, each told me it was my job to figure out how UX fit in. This bothered me, as UX was obviously not yet on their radar, and I wanted to expose that here today.
But, don’t get me wrong. As a software development methodology Agile’s adaptive methods work, and work well. And there are ways to fit in tactical “UX” but as far as fitting in strategy, research and analysis work, the work of product development overall, I think it falls short.
The main thing Agile brings to the table for me is breaking down a problem into manageable chunks.
The upfront method of defining EVERYTHING, including UX, no matter how much strategy or user research went before hand is unwieldy and unrealistic.
No amount of prep (thinking of waterfall here) will solve all of the issues that come up during development and for that reason you need a UX designer who can work WITH developers to overcome these issues.
“We decide that research doesn’t need to be as extensive as we think”…then that is an issue with the UX designer compromising too much. As the evangelist for the user you should be fighting your corner, and if additional research needs to be done before something can be implemented that that needs to be absorbed into the iteration.
You need to be involved with prioritising tasks, and be able to identify where additional UX time will be required, so the project plan can take this into account. Sitting in the background fed up because you didn’t get 6 weeks of wireframing and researching done points to an non-adaptive mindset in my opinion.
Agreed. Thanks Chris!
I suppose I agree that agile wasn’t born to embrace UX, but does that stop us from adapting UX practices to work nicely in an agile setting? I don’t think so. It’s a problem of naming and the difference between nouns and adjectives. “Agile UX” is a misleading. It implies that if you’re not doing “agile UX,” (noun form) then your work is not “agile” (adjective). Unless you’re completely married to process, any UX practitioner can fit him- or herself into an agile development team where it makes sense. Likewise, an agile development team can easily embrace UX if they are not reliant on their process. In either case, it’s about remaining agile (adjective) and not getting buried in what it means to do “agile UX.”
It’s a question of certainty. Everyone wants to say “this is what I do, and this is how I do it.” It’s also what clients/stakeholders/investors want to hear, which is why communicating agile methods can be tricky. We try to assign a name to signify a process, but the lack of strictly defined process is what makes agile effective. It takes a lot of trust to pay someone for work when you’re not completely clear on how they produce results. So we assign names to processes, and these names come back to bite us in the ass.
Thanks Thomas! To an extent… I agree. Although to me UX is so much more than what happens during the time of development. And if we neglect that, I think there is a lot of harm to our profession. Yes we can fit user flows, sketching and wireframing… and even user testing and research into these methodologies, but I don’t think that we can fit the entire product development lifecycle into them… if that makes sense.
Thanks for reading and commenting!
Yeah, I see what you mean. There is a time and place for it. I’m a big believer that research and strategy needs to be more than Sprint Zero. Too often people get excited about a product and want to go straight to development. But proper planning is necessary, and Sprint Zero often comes up as an afterthought. Maybe that’s the strategist in me talking.
The phrase “reduced costs” tends to send upper management into an opium dream, so arguing for expensive additional processes outside of Agile is going to be arguing uphill. What’s needed, I think, is some empirical data showing that the additional investment in UX pays off. I recall that the shift from waterfall methodologies was largely driven by metrics suggesting that waterfall projects were failing.
This is so well-timed, as our UX team is new (we all moved tour roles in the last two months) and I’ve been struggling mightily with how to fit all of our needs into one developer sprint. I’m now wondering if we can have our own sprint schedule, framed around deadlines and development, but with our own deliverables and features that we can deliver to the team–and, of course, be integrated into the process of development, as well, for the unpredicted events.
Our challenge, right now, is figuring out how to develop enough UX for the developer to be able to estimate well–where’s the line between Sprint Zero and a full blown waterfall spec doc? And of course we have to meet deadlines… AND have time for clients? Like I said, I’m new to product design (and came from a PM/dev background) so still feeling a bit lost.