Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

What are some successful examples of UX and the Agile Development process playing nicely together? Traditional agile doesn't usually account for it.

share|improve this question
8  
Agile accounts for anything that delivers end user value. If the Agile team you're working on is not accounting for UX, that is to do with the team, not the process. –  Aaron McIver Jan 4 '12 at 19:24
1  
Related post in Programmers SE –  Naoise Golden Jan 4 '12 at 20:24
    
My one word answer would be 'parallel', especially in an agile development environment. The reasons are all too obvious to those who have been into it. –  Kris Jan 5 '12 at 5:07
5  
Day 0 - see related question from Jared Spool here on ux.se How do you prevent scope creep in agile projects when usability testing? –  Roger Attrill Jan 5 '12 at 7:21
    
I think you should repeat the title in the body of the question. The question is so short, we have presumed it is the same as the title and did not even read it in the first pass! –  Kris Jan 5 '12 at 11:52

8 Answers 8

My response may be biased because I run a pure UX research, strategy and design firm, but as UX practitioners, we're involved in agile projects at the very beginning. As zsiberian stated, getting ahead of development by 1-2 sprints is the only way to keep the process agile. UX involvement in the iteration planning session allows the user story definition to get ahead of the front end development. In our experience, we get 1-2 sprint jump on development by cranking on the conceptual / interaction model, branding/visual design concepts and the first 1-2 user stories (wires) when the development is identifying and standing up the various back end technologies / architecture. Hope this helps.

share|improve this answer

UX, along with all of the other disciplines involved in your project, should be involved from day one. The team should strive to work in parallel with each other as much as possible. To achieve this, it is imperative that the UX resource(s) participate in all daily Agile rituals and meetings. This is especially true for backlog grooming and prioritization. In addition, the UX resource(s) on your team should open up the design process to the entire team allowing for input and concept ideas to come from developers, product managers, QA, marketing, wherever.

Through these group brainstorming sessions, the UX designer(s) become facilitators and stewards of the design. Their goal is to communicate a vision for the product by building a shared understanding across the team. This shared understanding comes about through regular conversations and discussions around early design ideas. These ideas should be validated with customers and stakeholders early and often to ensure that the team is spending time refining and building the right solution. To put it another way, the team should be minimizing the amount of time they're wasting pursuing the wrong solutions.

Lean UX is one approach to solve this Agile UX integration problem. The ideas espoused by Lean UX (at least as I've defined it) require the UX design teams to work in a much more transparent fashion then they've had to in the past. In addition, the process they employ must be far more inclusive than the more traditional ways of designing. These processes manifest in the forms of "light" deliverables (if any) like whiteboard sketches, rough wireframes and prototypes of the experience (that ultimately become "the spec" for the product).

There is a ton more detail in an article I wrote for Smashing Magazine, Lean UX: Getting Out Of The Deliverables Business.

share|improve this answer
    
Jeff: I attended your virtual seminar several weeks ago. Great stuff. (As well as cathartic!) To everyone else, I highly recommend his talk: uie.com/events/virtual_seminars/lean_ux –  DA01 Jan 6 '12 at 1:28

Agile seems to come in a variety of flavors, but the theory is all the same, and based on that theory, UX is part of the mix from day 1...as is business line owners, customers, IT, marketing, etc.

I usually find the problem is when UX is still doing waterfall but dev is trying to go AGILE. Lots of UX teams still want to pump out piles of wireframes, which is the antithesis of what Agile is supposed to be.

A great place to start is to google 'Lean UX' and read up on some of those concepts. In my opinion, 'Lean UX' is a clever way to brand 'Agile' so that UX teams will embrace it.

share|improve this answer
    
Thank you, this is a great tip. That is the current challenge. –  Christie Day Jan 4 '12 at 21:42
    
How true! -- 'when UX is still doing waterfall but dev is trying to go AGILE'. And, +1 for 'Lean UX', gotta check that one out rightaway. –  Kris Jan 5 '12 at 11:48
    
@Kris +1 for Lean UX. Don't miss Jeff Gothelf's answer below. –  Patrick McElhaney Jan 6 '12 at 0:47
    
@PatrickMcElhaney: Thanks, it sure's a learning experience. –  Kris Jan 6 '12 at 4:29

An approach which I find very fitting on where the UX role should intervene in Agile (Scrum in this case) development is:

  • In the product backlog, translating end-user feedback into specifications.
  • In the sprint planning meeting, providing mockups so both the Team and Product Owner have a better idea of what will be built and how.
  • At the end of each completed task, where sometimes tests or Unitary Testing is run, also Usability and UX should be tested.
  • In the review meeting, to test overall UX and taken into account for next increments.

The role of UX in Scrum

You will find a lot of presentations about UX+Agile in SlideShare.

share|improve this answer

From my own experience I would say you work in a parallel stream ahead and after Development and if you take it literally not in Agile Development at all.

Why? Because in my understanding Scrum, which we do at my company, is about production and development in iterations. But tasks itself not. You take a single task and work on it until its finished. Then next one. Thats how coding works. As you said Traditional agile doesn't usually account for it.

But Design works different, because you have Iterations in tasks. So, I found myself working on task cards, putting it back to ToDo Column (Scrum), and for refinement taking it again, and so on, until its finally done. (Actually its the way I work because I can't finish Designs on a single day - I like to have a fresh view some days later.) So, in Design you have iterations in tasks, but thats not possible in Scrum. and if you take a close lok at Naoise's scheme you will see no UX Designer in Scrum Sprint only beginning and end.

I think thats the reason why most Designers work in parallel streams and Im not sure if they work with Scrumboards for Design as well. Design is still a little Waterfall - you need to think and know what you are doing, you need a glimpse of a big picture, you need to think and try, not just doing. Lets say its a small, quite vivid waterfall.

I had some trouble to get it running well (working in a small team) and at the moment I think best suited for Design in a Agile enviroment is Kanban, but haven't tried it yet. I like Kanban because you can merge working process of both, Design and Development, or open a Kanban board for Design only. Kanban and Scrum are quite close, but the main difference is, you can place as many columns as you like to, not just Todo and in Process. enter image description here

You could put columns like Analysis, Raw Design, Fine Design, Testing, Production here to scope Designers workflow.

Kanban links: What is Kanban and Kanban and Scrum - making the most of both Picture source the latter pdf.

I know this answer is going slightly to be offtopic with this Kanban stuff. But its agile and development/design process as well.

share|improve this answer
    
+1 for introducing me to Kanban...something I had never heard of before. Off to research it! –  DA01 Jan 6 '12 at 1:30
    
I've been running UX in a Kanban-styled project for a year. Works beautifully, as long as you apply Lean UX-thinking and deliverables. –  Martin Christensen Jan 17 '12 at 12:59
    
Ah, it works ;) May I ask, what colums you have? How many and what tasks? Any recommendations? –  FrankL Jan 18 '12 at 10:29

Ideally it needs to start as early as the final stages of the opportunity pursuit when the UX lead is invited to the closing meetings with the potential client and has reviewed the SOW. That does two important things: gives you voice in conversations about scope, which in tern gives you heads up about project and what it's going to take.

Christie - I know you asked specifically about "the development process", but that sort of implies that you've been through the Discovery (6 - 10 weeks) and have already cranked out an approach and few high level wires to stay 1-2 sprints ahead.

If you are brought into a picture by the time development has started - it's no longer Agile, you'll need to run pretty fast to get ahead of the dev team.

share|improve this answer
    
In theory that works, but are there any tips to get it to work successfully? Many people think this can be attempted through iteration. While others think the UX needs to be done up front. What are some ways to get everyone to buy into the process? –  Christie Day Jan 4 '12 at 19:48
    
What are some steps you would go through to align ux and iteration with the agile process? –  Christie Day Jan 4 '12 at 20:00
    
Well, 1. I wasn't speaking from theory, rather from personal experience on several projects. 2. Iteration? Absolutely, but only when it's properly aligned with the Agile process. 3. All of UX upfront? Not going to work because you need #2. Getting everyone on board - that is a strange question if you joined an Agile project, the project owner should know the process and where UX fits in, if he doesn't he needs to pick up amzn.to/2Bue0T –  zsiberian Jan 4 '12 at 20:08
    
Basically the idea behind Agile and UX is whatever you (UX) produce, the dev team builds, and while they are doing that you're working on the next chunk for them to build. So it's a dance where you have to stay a bit ahead (I mentioned 2 sprints before). I would ask to participate in what is called "sprint planning" and get familiar with the project plan - i.e. what gets developed when and how fast. That will give you an idea of how you want to pace yourself, what deliverables need to be done when, etc. It's hard for me to speak without knowing the context. Hope it still helps –  zsiberian Jan 4 '12 at 20:12
    
I do find it hard, but not impossible, and strangely much more pleasant in the end because it's a bit more structured and you're on the hook for the exact thing you and the client discussed extensively during sprint planning, no more and no less. –  zsiberian Jan 4 '12 at 20:18

Coming from agency-land, agile was a new concept for me. But the way it's shaken out after 6+ months in an agile shop, is that I try to get out in front with wireframes and requirements (I'm about a month to six weeks ahead of the dev team). There's a kickoff meeting in which I get a lot of feedback from Design and Dev, another iteration or two, then those docs form the basis for the sprints. After the release goes into alpha, there's a period for review, usually some remedial WFs, then more dev and progress to beta, QA and final release.

Lighter weight projects get correspondingly "leaner" documentation.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.