I’m on my way back from Agile 2010, the main industry conference on Agile methods and tools. As always, I come back with lots of thoughts and insights into the state of Agile development today. If I had to choose one theme for the conference, it would be something like “Agile Grows Up”—not only has Agile become mainstream, but the community is starting to recognize and tackle the real issues of doing development in organizations.
What I saw was a community that is continuing to learn and grow. Agile methods were pioneered by developers, for developers, and tended to be restricted to the perspective of developers. But, of course, creating products and systems is not just about cutting code—there are many other tasks and skills that have to be coordinated. Agile 2010 was, in large part, about how to bring those tasks and skills under the umbrella of the Agile approach.
This is causing a little heartburn among the old-time developers. Bob Martin, “Uncle Bob” to many, one of the initiators of the Agile approach, complained that programming and programming issues are becoming a minority of the sessions at the conference. A lot of people would like to see the Agile community return to its code-cowboy roots.
But I’d say it’s not that the coding contingent has shrunk at all—it’s that the conference has grown around them. As the conference addresses more and more of the overall problem of delivering working systems, more and more roles and issues are being addressed. And overall that’s a good thing.
At this conference, for the first time, the need for a “concepting” phase seems to have become generally accepted, and people understand that this is separate from a “sprint 0”. Dave Thomas, in his keynote, called it a “sprint 0”—but then added that it might well take several sprints’ worth of time. And he recommended iteration of the concept with users—he mentioned 6 iterations of the concept and 3 iterations of detail, if my notes are right—before Agile development starts. (I think he overstates the case, at least for most projects. See my monograph for a process structure that can get this feedback more quickly.)
Dave also discussed the need for designers to be involved in creating the product backlog—because the user stories represent a design that had to be envisioned as a coherent whole. See what I mean about Agile growing up?
Gerard Meszaros added detail to this high-level claim in his very good talk, From Concept to Product Backlog—What Happens Before Iteration 0? (PDF). Gerard laid out the tasks that really need to be done between developing the product concept and writing user stories. (Including prototyping the concept with users! Yes!) One diagram of his is particularly useful—it’s head-slappingly obvious once you’ve seen it, but not something that has been much discussed at this conference before.
Of course, I expect the next response will be for Agilistas to take all those activities and start working on ways to make them smaller and faster, and make them happen closer to the time when their results are used. It’s a conversation I look forward to.
Our own field of user-centered design is coming into its own at this conference as well. A few people—not me!—are talking about how to gather data, how to do rapid prototyping, and how to guide development from user data. Contextual Inquiry was mentioned several times as a standard research technique useful in an Agile project.
There’s beginning to be an understanding of why the user experience has to be designed as a whole. Gerard talked about “story blinders”—how Agile can lead to limiting your perspective to a single story at a time—and how that can lead to a disconnected user experience as well as to an incoherent architecture. In the session, Distributed and Automated Testing Usability Testing of Low-Fidelity Prototypes, the presenters discussed many of the same issues and did a very nice summary of the value of low-fidelity prototypes in an Agile context (as well as showing a potentially useful tool for distributed testing). Making Usability Testing Agile offered some practical experience of a UX team integrating with Agile development.
Oh, and my own session? I used a board game of my own design to show developers and UX designers how to work together within Agile sprints, getting the design done just in time for developers to pick up and work on. The session went really well, and we had good discussions after the game about how the continuous back-and-forth between UX and development led to shared goals and shared success, and how the flow of user stories became the kind of lean development that the Kanban folks are looking for.
Finally I’ll leave you with what was maybe the most profound insight of the conference, offered at the session Product Management, Agile, & Customer Development:
Why do most products fail?
Lack of customers.
Hmmm.