When shooting the movie, the director doesn’t necessary film the scenes in the order they’ll appear once edited. Instead, the filmmakers shoot the pieces according to other constraints, such as the availability of actors or locations, or accommodating variability in the weather. It’s not unusual for the movie’s final climax to be among the first scenes shot.

It occurred to me, while talking with Jeff Patton last week, that the same can be true in an Agile development process. Often times, the team will start with a piece of the project that isn’t the first thing the user experiences, but instead might be at the end. For example, they may start by building the functionality to save a file in Photoshop format – technically an important, high-risk part of the project, but not much of a user interface beyond a simple “Save as PSD file” option.

Jeff mentioned that user experience designers on the Agile team end up adopting a similar role to the person who gets the credit of “Continuity” in a film. It becomes their job to make sure the final experience makes sense, even though the order of construction was not linear. This is a huge challenge and one that has come to forefront as more teams move to an Agile development method.

Jeff has been researching the new challenges that arise when teams try to merge their UX efforts in an Agile process. In his travels, he’s assembled a slew of best practices that result in the development of great experiences. In this week’s UIEtips, we’re proud to publish the first installment of a two-part article where Jeff describes 12 of his best practices.

If you’re a user experience professional working inside an Agile development team, you’ll want to check out Jeff’s full-day seminar on this topic. He’s updated it with his newest findings and it’s promising to be one of the most popular sessions at our upcoming User Interface 13 Conference in Cambridge, MA this October.

Are you working to improve the user experience in Agile development projects? What practices have you found to work (or to avoid)? Share your thoughts with us.

Thank you for pointing out this post. I have found Accurev to be an important element of our agile practices and wondered if you had ever heard of it? I’ve never used anything that allowed teams to adapt so quickly and give visibility into what everyone was doing. Now if we could just figure out how to keep our velocity in check when adding in time for bug fixes.

I understand how Agile can be beneficial from a development perspective, and I do like how there is a more inherent sense of collobaration and overlap of project phases, but why is this a better approach for Product Managers and Designers? And outside of theory, why is it a better approach to make more usable and desirable products?

Agile can work…if implemented correctly. Its here embrace it. I have had success on many Agile projects by being part of the team and integrating myself into the process. UX team members cannot work in a bubble and expect Agile teams to listen to recommendations. Be Flexible find ways to make it work.

2) Research, model, and design up front – but only just enough
> A vision/direction becomes more important on an agile project. If no direction is set, an Agile project will design and build software features that are not used. Rather then cutting requirements you will end up removing large chunks of designed pages or worse putting them out there with the product just because they are finished.

4) Use parallel track development to work ahead and follow behind
> Working in a parallel track or working a few sprints ahead is vital to integrating requirements and UX work into an Agile team.

7) Schedule continuous user research in a separate track from development
> It does not have to be in a separate track, but it must be done before and after coding. A separate track may make it easier to schedule or plan but it is not necessary. Getting a sprint or two ahead of the development team is vital, user research is nearly impossible during the sprint the story is being coded. (not impossibly just nearly ok just a lot harder) Save yourself some heart ache and get a sprint or two ahead. Also complete the User research of the developed system early enough to incorporate the feedback; during functional testing, is a good time because the team is still making changes on those stories. Teams don’t like to close stories and then open them again for usability changes. If this happens make new stories for usability changes.