Who's on the core UX team?
This team will include...
- UX specialists
- Creative specialist
- Page developer
- Product Owner
- 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.
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.