Can Agile Software Development Deliver a Great User Experience?

Niki Dare from Asynchrony Solutions recently wrote an article about the possibility of just-in-time Agile development and design. Can Agile development, with all it’s quick deployment times, create a user experience that is not only good, but considered “great” for the user? Many people have offered up opinions, including taking advantage of Iteration zero and infusing each story or task with user-centered design principles. But the big dilemma still remains. How much upfront design and usability is too much to be considered Agile?

“As a designer, I have been fortunate enough to be a member of several development teams that each followed their own unique process. Although what works well for one team doesn’t necessarily suit another team’s needs, the principle of integrating just enough user-centered design can be applied successfully within almost any agile development project…” – Niki Dare

Pre-Iteration Planning

Truly embracing Iteration zero, Niki has found pre-iteration planning to be extremely effective. This tactic works great if you have a client that knows what they want about a week in advance and is willing to mostly stay committed. Essentially the user experience team works an iteration ahead of the development team. A short pre-iteration planning meeting is had with the client to determine their upcoming needs for the next iteration. This method is most successful when there is an overall understanding of the application and its functions that is agreed upon. 

Minimum Marketable Features

The idea here is that a succinct set of tasks are identified as a minimum marketable feature. This feature, that should take no more than a couple of months to complete, is then well-defined and understood by the user experience and development teams. Similar to using iteration zero, it is best to allow the user experience group to be a feature ahead of the development team. For the first feature it may be helpful to start with something that is development heavy.

Formative Testing and User Experience Testing

Validating any new additions to the system, this type of testing is very beneficial to maintaining a good user experience. The most effective method is moderated testing conducted on-site so that the users can be observed directly and probed for as much insight as possible.

The best thing to do is to conduct usability tests on individual processes or tasks in the system and then act immediately on the findings. Try to keep the scope of the test as narrow as possible so scripting the test is quick and too many development tasks don’t result from the testing.

The Danger of Only Doing Just-In-Time-Design

The Agile development process boasts doing activities just-in-time to mitigate waste and allow for requirements to change even while code is being written. Just-in-time design can work in cases where a high-level design or concept has been created and approved.

But doing true just-in-time design can run the risk of losing sight of the big picture and creating a disjointed user experience or having to rework previously developed screens when new ones are added.

Interestingly enough, Niki has decided that a user experience team should be different from development, unlike Zuckerberg’s Facebook development teams, where the developers are the UI/UX. All of her suggestions point to a design-grooming of sorts ahead of the team. All this sounds good to me!

[HT: ITWorld]

9 Replies to “Can Agile Software Development Deliver a Great User Experience?”

  1. I agree that the user experience team should be different from development. In general (I admit there can be exceptions), a lot of wait time or re-work later can result if you attempt to design the user experience in the same time frame (iteration or sprint) that the full feature is being implemented. I quote Marty Cagan, author of Inspired: How To Create Products Customers Love, who says, “I have long argued that requirements (functionality) and design (user experience design) are intertwined and should be done together.”

    Niki has the right idea – keep the user experience team(s) ahead of the development team(s). How far ahead is up to you!

  2. I don’t agree: Having the design team segregated from the development team creates a handoff situation that will inevitably cause bottlenecks in the process and worse, cause real problems when the developers run into issues *implementing* the UEX designers’ fantastic ideas.

    I saw this situation firsthand with a customer who ran in two streams, consulting a design firm to develop a whole new UI for their website using wireframes and fanciful Photoshop mock-ups. I watched as the dev team looked on in horror during initial Sprint Planning sessions as they tried to wrestle with how to implement some of the platform-defying ideas within a 2 week iteration.

    As a plan to mitigate some of this friction, the design firm added a branding and CSS developer to the team, and even as good as he is, he ran into some problems that prevented 100% delivery.

    The notion that you can split off design as separate from development is completely wrong and dangerous in an iterative/incremental project. UI/UEX needs to progress in step with the iteration to work with regular inspect/adapt points – if they are running ahead without validation of their ideas *in working software* what happens when the team hits a snag and can’t get something into a Sprint? Now there’s a back-up as they try to fix problems and deal with the new untested ideas that are piling up in the Backlog which may never get implemented.

    If anything, UI/UEX fulfills the same place on a team as QAs and BAs – they have valuable input into the solution and should be kept as part of the team, not some fanciful enlightened satellite that operates above and beyond.

  3. Pingback: Can Agile Software Development Deliver a Great... | Agile | Syngu
  4. @Chris,

    You make a great point — although I still feel that the UX (UEX) teams can be separate, it is important that representation from the development team provide consultation and guidance in terms of what is possible and practical. Another option is to have the development team(s) be stakeholders in the review of the UX team’s work in a review versus assessing things in planning — that way the UX team can make adjustments before the development team takes the work on in a sprint.

    My experience is that the UX is a point where many requirements are revealed as well as conflicts in existing requirements. I like to have those details worked out so that the development team(s) can be productive and to reduce churn.

    1. There needs to be a healthy balance between the two. Every environment is different, it’s about what works for the dev/design and how they can iterate together

  5. I’m a big fan of starting with sprint zero. As for separating the UX team from the dev team, that’s a situational decision. If I worked for Apple, where design elegance is essential, I’d want a highly focused UX team. If I worked for an industrial equipment firm, I’d likely feel differently.

    Fully define the problem space, then apply appropriate agile principles to arrive at an optimal approach.

Leave a Reply