What are some successful examples of UX and the Agile Development process playing nicely together? Traditional agile doesn't usually account for it.
UX is something you have to test actively from day one, and keep on testing while the product develops.
Beware! It's super easy to forget about UX testing while you are pushing the developers hard and everybody is working like hell in your team.
UX testing has to be part of your Definition of Done! Meaning that no "story" should be considered as Done, if UX testing was not finished. (obviously note necessary for backend stories)
If you don't have a designer or UX expert in-house. You'll need to do it yourself. There are tons of great resources online about UX, so Google like hell.
These days a smooth UX is not a differentiator. It's a must have for new products. So it can make our break your business!
Initially I was finding it difficult to match my standard ux design process to Kanban, but after a little while it started to work. It took a lot of changing and rethinking stuff though.
This was a bit of inspiration for me: http://kanbantool.com/blog/kanban-for-ux-design
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.
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.
this is not bad at all
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.
You could put columns like Analysis, Raw Design, Fine Design, Testing, Production here to scope Designers workflow.
I know this answer is going slightly to be offtopic with this Kanban stuff. But its agile and development/design process as well.
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.
You will find a lot of presentations about UX+Agile in SlideShare.
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.
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.
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.