Integrating Agile methodology and User Experience Design has long been a challenge. This diagram shows how the two can work in harmony with each other to produce profitable products that meet the demands of stakeholders.
Tags
.net .NET Framework Android application lifecycle management ASP.NET MVC azure BizTalk BizTalk 2010 BTDF Business Connectivity Services (BCS) C++ calculated column Code Camp CRM CRM 4.0 CRM 2011 dependency injection development FAST FILESTREAM formula HTML5 IIS IoC Java JavaScript jQuery Microsoft Dynamics CRM MVC 3 NuGet Presentations SharePoint SharePoint 2010 SharePoint 2013 Silverlight SQL SQL Server SQL Server 2012 SSRS training User Experience UX visual studio Visual Studio 2010 WCFCategories
Archives
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- September 2010
- August 2010
- July 2010
- June 2010
- April 2010
- March 2010
- December 2009
- September 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- October 2007
- September 2007
- August 2007
- April 2007
- December 2006
- November 2006
- October 2006
- September 2006
4 Comments
I’ve been researching processes that integrate UX with Agile and this is the best diagram I’ve found. Are there any details you can provide or caveats you’d care to share from using this with actual client projects? Thanks!
I’ll be explaining this diagram soo…I hope. It certainly needs a little discussion, but our aim was to just get it up there for everyone to see, first.
I like the general approach, and I think it makes sense to say that UX generally works a sprint ahead of development. But, one of the things that is hard to represent in any of these kinds explanations/diagrams is that there is often a disparity in effort between design and development for the same features. For example, “undo” might take 5 minutes of UX time (“here’s the undo icon!”) and weeks of development effort. Another 30 seconds and you have a “redo” icon… and potentially a whole lot of additional development effort (“when we built undo, redo wasn’t a requirement!”). So in practice, either the process is much messier (because the UX and development efforts aren’t really in that close of lock step) OR you have people try to stick to the process literally and the work expands/contracts to fill the available time (I have a week to work on this, so you a week’s worth of design or development on it, regardless of whether it should really take a day, a week or a month).
@Adam:
You are correct. You have hit upon one of the biggest problems in Agile working with UX. It’s not going to go away soon, it’s one of the reasons it took a long time for us to develop this diagram. Furthermore, as you might have guessed, this diagram does not / cannot be the be-all-end-all of Agile-UX relationship diagrams. The problem is that you need a few diagrams to really fully explain all that needs to happen as opposed to all that does happen. Very briefly, the middle blue “stream” between the dev and ux tracks labeled as the Feedback loop is designed to mitigate the problem you are spotlighting.
To address your thoughts: You’re right of course, in the case of the Undo/Redo example, what takes a UX person 2 minutes to think up and add to the wireframes is certainly NOT 2 minutes in development time. We at Tallan firmly believe that it’s imperative for the designer to have a good sense of the technology that is being used to develop the application, as well as some solid grounding in basic programming and data structure principles so that no UX team member “pulls things out of a hat.” It leads to another diagram I’ve often shown to clients to make them understand how best to marry UX and development stages — you need one member of the product business team, at least one developer, and the UX designers to sit together to really design things right because you do not want to simply throw features and options into the fray without thinking about the consequences to the schedule and budget. But that is easier said than done, especially when the developer on the committee is also responsible for output of production code.
Moreover, if you’re using Scrum to organize and develop — and are doing it right — some feature that a UX designer might have thrown into the mix is surely to get ousted based on the triage of the backlog. If you don’t constantly review your backlog in relation to the new things that are being added to it, all you’re doing is making a ToDo list, not deciding which are the most important features to work on.
You only have so many tokens. You put something in, you take something out. Unless your budget, timeline, or manpower increases (and even then it’s not a sure thing) you cannot add more to the development schedule and stay on target.
One Trackback
[...] This post was mentioned on Twitter by donguy, UX Feeder. UX Feeder said: Delicious: Agile User Experience Design: http://bit.ly/eQ8M2W [UX] [...]