Commenting on Agile Design

by Kevin Makice

John Anderson wrote up a nice overview of an Agile Development process, from a UX designer’s point of view. The reaction in the comments to the article are interesting as well, such as one reader who wrote about the difference between a plan (Agile philosophy) and action (the practical impact of real-world deadlines):

The problem I find is that even though the Agile process should host an environment for quick change and turn around, the Scrum Master or accidental Scrum Master does not as a matter of fact allow this “down” time at the end of a cycle to collect feedback from customers, team developers or stake holders.

Another reader made a plea for revisiting dormant ideas:

I know it can be frustrating to cut designs, comps, and concepts. But, the keyword there is ‘cut’ and not ‘ditch’. It’s important to not forget what you have done. You may be able to reuse part (or all) of your designs in the future. At the very least, maintain a local folder or place where you can keep your ideas and concepts. If you’re working with a design team, you can also make these concepts public and another project or team may be able to use them.

Yet another reader also commented on what is missing: relationships:

[A]gile isn’t just about risk management and iterative delivery, the other half of the agile manifesto is just as important – better relationships with your team members and your stakeholders. Those are the things that can really make or break a project and can’t be understated.

There are many flavors of Agile, and many many more experiences working within the development framework. My sense is that the single most important factor in its success is the ability of team members to know, communicate and apply a shared vision of why the project exists.

UX Magazine (July 18, 2011, by John Anderson)