50 Responses

  1. Anon
    Anon at |

    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. 

    Good luck!

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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!

      Reply
  2. Cesar Coll
    Cesar Coll at |

    Idea:

    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.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      That’s def one way to look at it!

      Reply
  3. UX and Scrum part 1: The Controversy - Chris Steele on Agile

    […] 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 […]

  4. What I've been reading lately (week 26-28), by Samuel Ericson

    […] Agile is Wrong for UX | Elisabeth Hubert […]

  5. UXSpy
    UXSpy at |

    […] 1) Agile is Wrong for UX  […]

  6. Marcin Treder
    Marcin Treder at |

    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/

    Cheers!

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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!

      Reply
  7. Jason Yip
    Jason Yip at |

    This reminds me of Act First, Do the Reseearch Later, http://www.core77.com/blog/columns/act_first_do_the_research_later_20051.asp

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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. 

      Reply
  8. CB Du Rietz
    CB Du Rietz at |

    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.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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. 

      Reply
  9. Bo Lora
    Bo Lora at |

    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…

    Reply
    1. Lis Hubert
      Lis Hubert at |

      Thanks for reading :-)! 

      Great comments overall… I wholeheartedly agree!

      Reply
  10. Jimi
    Jimi at |

    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

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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!

      Reply
  11. misentoscossa
    misentoscossa at |

    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. 

    Reply
    1. Lis Hubert
      Lis Hubert at |

      If you are crazy… so I am :-). Thanks for commenting!

      Reply
  12. Erik van de Wiel
    Erik van de Wiel at |

    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. 

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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!

      Reply
      1. Ian Adelman
        Ian Adelman at |

        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.”

        Reply
        1. Lis Hubert
          Lis Hubert at |

          Agreed! One day I’ll be more subtle :-).

          Reply
  13. Ben Melbourne
    Ben Melbourne at |

    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.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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!

      Reply
  14. Susan Doran
    Susan Doran at |

    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.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      Thanks Susan and you are more than welcome! I think your step further is a great point to think about!

      Reply
  15. Kedron
    Kedron at |

    Agile is about making “great” software. UX is about making the “right” software. IMO. Great post! I’ll be passing it along!

    Reply
    1. Lis Hubert
      Lis Hubert at |

      Thanks Kedron!

      Reply
  16. Michael Dubakov
    Michael Dubakov at |

    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/

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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. 

      Reply
      1. Michael Dubakov
        Michael Dubakov at |

        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
        etc.

        Release as early as possible to get feedback and adjust.

        P.S. By Design I mean UX, Graphic Design, flows, emotions, etc.

        Reply
        1. Mike Feghali
          Mike Feghali at |

          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”.

          Reply
    2. Eugene Kim
      Eugene Kim at |

      “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.

      Reply
      1. Michael Dubakov
        Michael Dubakov at |

        “throw-it-at-the-wall-and-see-if-it-sticks ” – I don’t like this approach. What I like is sketches and quick tests. 

        Reply
    3. Subeditor
      Subeditor at |

       А, русские оптимисты, восторженные западным творением!
      Но, увы, код – это еще не продукт.

      Reply
      1. Michael Dubakov
        Michael Dubakov at |

        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. 

        Reply
  17. Andy Parker
    Andy Parker at |

    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.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      Great points Andy! Couldn’t agree more. 

      Reply
    2. Mike S
      Mike S at |

      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.

      Reply
  18. Michael Dubakov
    Michael Dubakov at |

    It seems you never worked in agile team and just dont understand how to mix agile and Ux.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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. 

      Reply
  19. Chris Mears
    Chris Mears at |

    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.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      Agreed. Thanks Chris!

      Reply
  20. Thomas Wendt
    Thomas Wendt at |

    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. 

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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!

      Reply
      1. Thomas Wendt
        Thomas Wendt at |

        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.

        Reply
        1. Christopher Burd
          Christopher Burd at |

          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.

          Reply
    2. Jody
      Jody at |

      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.

      Reply

Leave a Reply

12 − seven =