Thanks to advocates in Agile community, many software developers have gotten proficient at delivery. Perhaps now it is time to examine what we’re delivering.
Better questions and attentive listening might avert those occasions where we do an outstanding job of delivering the wrong thing.
Discovery & Delivery
At last week’s last week’s CodeFreeze 2010 on the University of Minnesota campus (my alma mater), speakers David Hussman and Jeff Patton were wearing t-shirts that said Discovery & Delivery.
The authorized theme of CodeFreeze was Redesigning Agility. The unauthorized theme might well have been as David and Jeff’s t-shirts said — Discovery & Delivery.
How do we integrate Interaction Design into our Agile projects?
Looking retrospectively beneath the vaulted glass and wood ceilings of Memorial Hall, where CodeFreeze was hosted, one might conclude that the Agile community deserves kudos for improving our ability to deliver software. One also might conclude that we have yet to make significant progress integrating interaction design and usability into the Agile cookbook.
Interaction design and usability considerations will continue to play a significant role in whether people are satisfied using our products. We had better jump on the design band-wagon, or at least appropriate all the most forward-thinking interactive designers as our own.
Jeff Patton posed the following question to the CodeFreeze audience
If you evaluated the quality of your process based on customer satisfaction, what would that process look like?
Jeff’s question helped solidify an approach I have been considering for months. Three influences on my thinking are:
- Google’s slogan of Launch Early and Iterate (see my post Launch Early and Learn);
- Eric Ries‘ concept for startups of a Minimum Viable Product; and
- At CodeFreeze, watching Alan Cooper talk about Interaction Design and watching David Hussman and Jeff Patton talk about Discovery (e.g., Story Mapping).
I have concocted a recipe for a discovery & delivery process that I am eager to share and to take for a test drive.
User-Driven Rapid Prototyping
Lets call it User-Driven Rapid Prototyping. As the name implies, the approach involves rapid prototyping. It is also user driven because the people who use the application help the software team prioritize the backlog. The challenge and proposed approach are a follows:
|Challenge||Integrating Interactive Design into Agile projects|
|Iterative Cycles of
The diagram below shows what the iterative cycles of User-Driven Rapid Prototyping might look like
- The hand palming the spiral is a Discovery or Re-Discovery Iteration
- The subsequent handless spirals are Delivery Iterations
- Discovery iterations, after iteration zero, are called Re-Discovery
- Odd iterations are for coding and delivery, while Even iterations are for discovery (interactive research and design).
Iteration zero – Iteration zero is a discovery iteration. The goal is to learn as much as is reasonably possible about the community for which you are developing the product. Iteration zero might include chartering, creating personae, and story mapping. Also it might include any of the groundwork you typically lay before iterating in earnest.
Wouldn’t it be a kick if the picture below could just as easily be the people using your software as the people crafting it?
- Tim Brown urges designers to think big in this video on Design Thinking.
- In Usage-Centered User Stories & Story Mapping Part 1 and Part 2, I explain what post-Agilists like Jeff Patton and David Hussman, have been telling the Agile community how we might help teams enrich poorly conceived user stories and how we might better use our iteration zero time for product discovery. That is, how discovery might be improved.