I was reading Volume 9 Issue 1 of UX, User Experience, the magazine of the Usability Professionals’ Association (http://www.usabilityprofessionals.org/). I’m not a member but I know someone who is. Anyway, Nancy Frishberg reported on Agile from UPA 2009 and Cindy Lu, Thyra Rauch, and Lynn Miller discussed best practices for interation design within Agile development. Obviously they were focused on their role but it didn’t take too much imagination to build on their ideas and extend them to other folks such as the architects and customers.
Agile fans love to talk about the Pigs and the Chickens. The core team of programmers and testers and technical writers are the Pigs (committed to giving the bacon) and as far as they are concerned everyone else is a Chicken (committed to providing the eggs). That may or may not be accurate or fair but I’m not going to discuss that here. I want to take a look at the Chickens and how they fit their activities around the schedule of sprints.
First, who are the Chickens? They’re the customers, management, the architects, the usability professionals, and other people involved in the creation of the product but aren’t necessarily involved in the daily scrums and nitty gritty of the core team.
What do they do? Lots of things but it boils down to 4 stages… Research, Contribute, Consult, and Evaluate.
Research is looking ahead. It’s gathering high-level requirements. It’s checking out applicable standards and regulations. It’s figuring out what kind of user testing is going to need to be carried out. It’s paper-prototyping user interfaces with the customer. It’s discovering the current customer processes. It’s gathering user stories.
Contribution is creating design and architecture documents that give guidance to the core team. It’s adding flesh to the items in the backlog. It’s developing the requirements and flowcharts for the user interfaces. It’s further defining the user stories.
Consultation is staying involved with the core team. It is helping them with the detailed design by clarifying requirements and helping to define what “done” means.
Evaluation is making sure that what has been done is what the customer needs. It’s user testing. It’s gathering of feedback from the customer and management. It is defining the changes that need to be made to guide the product development so that it converges with the customer needs.
That’s all very nice but how does that fit around the sprints?
Starting out there needs to be a sprint 0. While the programmers and testers are busy planning their development and testing architecture and setting up their systems, everyone else should be busy researching and preparing their contributions for sprint 1.
The development in sprint 1 should focus on “under the hood” work to build a strong foundation and to give adequate time for the refinement of the design. The Chickens should be consulting on sprint 1, preparing their contributions for sprint 2, and researching for sprint 3.
When sprint 1 is completed, work for the chickens consists of evaluating the results of sprint 1, consulting for the core team on sprint 2, preparing contributions for sprint 3, and researching for sprint 4.
The remaining sprints will follow the same pattern of evaluating the previous sprint, consulting on the current sprint, contributing to the following sprint, and researching the sprint after that.
Does that make any sense? Does that conflict with your experiences in this?