Alan Cooper, joined by three colleagues from his renowned design firm of the same name, discusses the challenges faced and lessons learned from their forays into using a more agile process for design consulting. Questions from the audience help drive the discussion towards topics of interest specifically to developers.
Cooper Panel: Agile and Interaction Design
Tuesday, December 23, 2008 | Run time: 63:36
This talk is interesting from a process perspective, but I feel like it leaves some core project management questions unanswered.
The reality I have to work with as a PM on an agile project is communicating to a client that they’re getting the “thing” they paid for (not just the experience of working through a challenge—that’s expected), what the constraints are around getting this thing (i.e., making sure we get paid for the time we spend iterating) and being able to feel confident about meeting real deadlines and budgets. Prioritization and phasing helps with this, but agile is not necessarily the most comfortable process for a client—it allows them to change their mind more, but it also comes with fewer guarantees.
Incorporating design into an agile tracking method has been very imperfect to me so far. The people who do the work on my small team work together really well, but from a tracking tool perspective, how can we accomodate both work processes without asking either side to waste time doing redundant documentation? For example, one wireframe might span a dozen user stories. Do we have a separate card for design tasks that we link to dev stories? How does that change what “done” is? I need accurate tracking that doesn’t get in the way.
June 17, 2013 at 3:17 pm