On this past Wednesday evening, Anne Jackson facilitated an engaging discussion about where UX Designers belong in an agile team during the February PittAgile Meetup. While I cannot say that we landed on a definitive answer to everyone's burning questions on this topic, it got me thinking about how I have approached the issue in the past.
In my mind, the issue comes down to one of engagement. When and where should UX Designers be engaged with an engineering team? Should they be embedded in the agile engineering team? Should they have their own work tracking system (e.g. their own board)? How do you prevent the job of designing a solution to a problem from becoming a waterfall-ish phase gate before the engineering team starts delivering value?
All of these are great questions, and I found myself falling back to the roots of agile methodologies and how best to shorten feedback loops between teams and iterate to a phenomenal product. I have always separated UX Design and Engineering in the following terms -- Designers are responsible for making certain we create the right product and Engineers are responsible for creating the product in the right way. Given that point of view, Designers need to work ahead of the engineering team for the simple fact that it's not very effective to determine what you want to create during the sprint that you are attempting to create it. However, Designers still need to be available to the engineering team to discuss the design and tradeoffs that may need to be made during the engineering process. But none of that requires the Designers to be full members of that engineering team. If anything, their involvement is closer to what an engineering architect might have with an engineering team -- they are there to guide, but not to be directly responsible for the engineering team's delivery. I will note, however, that if the designer is not available to the team when they need answers or clarifications, that designer suddenly becomes an impediment and they should expect a visit from the team's ScrumMaster.
That all brings us back to the question about how to track a designer's, or a design team's, work. The most effective method that I have come across is to treat the designer's work the same way that a researcher's work would be tracked in an agile framework, which, for me, is by time-boxing experiments, whose outputs are either product designs or more experiments. Never leave these open ended and have them take the form of "I am going to do ____ and expect to learn _____," or something similar. The design team has their own board. Their output is an input to the engineering team's board... under the oversight of the Product Owner.
A few words of caution though... I stated above that the goal is to shorten the feedback loop. You don't want to fall into the trap of waiting until the designers have finished a large design before the engineering team starts -- or even before the engineering architecture team weighs in. Everything should be done in pieces that are as small as is practical to deliver value, but not so large as to be a problem if the engineering team discovers a limitation that makes the design costly or impractical. Additionally, engagement at all levels is critical to success, and transparency is key.
Now that you have heard my thoughts, I would love to hear yours.
If you wish to read further, this article by Paul Boag does a great job of diving into the issues.