Core User Experience Team (part 2 of 7)

When trying to leverage a handful of UX specialists across a large number of agile develoment teams, the first question is, should we just divvy up the user experience (UX) specialists across all the teams? I say no. That would give each UX specialist 5 teams to support, and would more or less require each UX specialist to be good at the whole range of UX tools, from IA to interaction design to user research. I think a 1:5 ratio is too small for this to work. So I'm starting on the premise of a core team that provides support as a team.

Who's on the core UX team?
This team will include...

• UX specialists
• Creative specialist
• Page developer
• Product Owner
• Scrummaster
• Business Analyst
• SME who understands the web sites built so far

We start with 2 people with formal training and significant experience doing things like IA, usability testing, interaction design, etc. We've gotten approval to hire two more.

We'll start with one creative specialist (graphic design of UI). He's formally part of a small creative group, so he can call in help as needed, and he'll have help from the creative group in terms of staying on brand, etc.

We'll start with one page developer who will do HTML, javascript, CSS, Ajax, etc. In our case, the page developer(s) will need to really understand how to work with WebSphere Portal (themes, skins, page layouts, etc.), since that will be the presentation layer for much of what we do.

This core UX team will operate as a scrum. Just like any other scrum, they'll have a product backlog (more on that below), sprints, releases, daily scrums, etc. The key difference between this core UX team and the more traditional scrums (are we allowed to call scrums "traditional" yet?) is the nature of the product and the backlog.

A new spin on the product backlog

In most development teams, the product is a functioning collection of software that meets specific non-functional requirements and produces business value. A roadmap might typically include a list of major batches of features, with some infrastructure along the way. And the typical product backlog would be specific bits of functionality that can be coded.

The core UX team I'm proposing will still have a roadmap and a backlog, but the product might be described as "user centered design across the enterprise." An initial product roadmap might include things like...

• Training program
• Repeatable process for usability testing
• High-level IA and wireframes
• Design pattern library
• Model for financing work requests from development teams
• Reusable navigation widgets

The product backlog would include relatively tangible things, like page templates or reusable navigation widgets, but it will also include less tangible "services," like training programs and user research. I could imagine the team focusing a release on an initial training program. In the first sprint of the release, the team might produce all the materials required to train one development team in the art and science of personas and scenarios. Just like "potentially shippable software" of a traditional scrum, the Product Owner could decide whether to go ahead and conduct that training, or to wait for the next sprint to produce training materials that enable a business analyst to conduct card sorts.

Sprints that don't produce code

The team would figure out how to maximize the use of all team members during the sprint--if the creative person isn't needed for the card sort activities, he or she could spend that sprint preparing reusable CSS and background graphics, for which a training could be quickly developed in the following sprint.

We'll have a challenge figuring out how to maintain a unifying theme for each sprint, when not all activities involve graphic design or page development, but this sounds similar to a typical agile team when they're in a sprint focusing on something like upgrading the hardware infrastructure. Team members will go in seemingly unrelated directions, but they'll understand amongst themselves how it will all come together.

Ideally, the team would prioritize repeatable processes that could be used immediately by specific development teams, and would create just enough organizational infrastructure to support the immediate needs (e.g., initially just a sign-up sheet for training; a later release might include a recharge mechanism and a schedule for giving the core training to 200 people.)

These are just some quick examples. The point is that the product backlog contains both software and services, both of which are "potentially shippable" at the end of each sprint. A release could consist not only of software, but of a repeatable process with the infrastructure in place to support it.

What do you think? Does this sound like an agile team? Will it work? What am I leaving out?

Next post will be a draft approach to UX training throughout the enterprise.