Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] New to Agile. Help with UX Deliverables on an Agile Project.

Expand Messages
  • John Schrag
    ... but ... Hi, Amy. Development from scratch is where Agile works best, in my opinion -- if your teams takes the right approach. Is your team planning a
    Message 1 of 3 , Oct 18, 2007

      Amy wrote:
      > The company I'm working for is transitioning to Agile development, but
      > has never used it to build new applications. They have used the
      > process to manage iterations of existing applications.

      Hi, Amy. Development from scratch is where Agile works best, in my opinion -- if your teams takes the right approach.

      Is your team planning a "cycle 0"?  This is the period when the developers can play with ideas and investigate new technologies --- also where you can do your research into your customers.  Many teams skip this planning step, and it's a big mistake.  It also gives you time to design what should be build in cycle 1, and stay one cycle ahead of the developers.

      Here's how that can work:

      One of the basic ideas of Agile is the recognition of uncertainty in the future.  So at any given time, you know exactly what you're going to do in the next cycle, you have a pretty good idea of the cycle after that, and an increasingly vague idea of each cycle beyond that.  [If you know exactly what you're going to build in a year's time, then you're not doing Agile, you're doing staged development.]  At the end of each cycle you use whatever knowledge you've gained to remap the next cycles -- to correct your course, one might say.  Anything more than a few cycles out you don't worry too much about, because you know that at any given moment you are always working on the most important thing.

      This is a good way to treat UI design in an Agile project.  In cycle zero, you can be working on the UI for what needs to be built in Cycle 1.   While the developers are building what you designed in cycle 1, you can design and prototype and test your designs for cycle 2, etc.  I wouldn't spend too much time worrying about what comes too much after that, because it will change and I guarantee you will have to throw out whatever designs you spent hours working on.  (We did other stuff as well;  basically in any cycle N we would ideally try to:  1. Design the UI for cycle N+1   2. Visit customers, and while there we would usability test the feature that were added in cycle N-1, usability test prototypes of our designs for N+1, and collect whatever information we needed for the features in N+2.  Once you stop having to write huge documents, you'd be amazed at how much you can get done in a cycle.)

      On my very first from-scratch Agile project I made the mistake of trying to create and maintain a UI for the whole completed application.  At each cycle, as we adjusted course, I'd have to redesign huge chunks of it, and I was getting further and further behind.

      Finally I figured something out --- at the end of each cycle, the developers are supposed to have code that is good enough to deliver.  So we took that to heart in the UI, as well --- at each cycle, I designed the UI as if the features we had then comprised the complete application. (I'd keep the big picture in mind, of course, but I wouldn't try to design specific placeholders for all the future features).   Yes, this meant that I was redesigning for each cycle, but I had been doing that anyway, and this was far, far less work.  The trick here is not to just acrete new features, but to refactor them in properly.

      Generally I'd be thinking site map, process flows, wireframes,
      > usability test plans, etc. But with Agile it seems less is more and
      > there is a lot of resistance to any sort of documentation.

      You can make light versions of all of the above, especially if you keep focussed on the next cycle, and you let the future stay vague.  Agile values face-to-face over documents, so this is an opportunity to lighten your own workload.  Instead of writing down every detail of a design, you can keep the document simple -- pictures and call-outs -- and sit down with the developers and explain it to them.  (They'll appreciate it.  They don't read the detailed docs anyhow.)   Of course, if you're not co-located, all bets are off.

      On Agile projects our test plans were light, too, and kept mostly for our own reference.  We did lots of formative testing on low-fidelity prototypes before the developers even started to code it, so often our prototypes were the UI designs we passed on.   Problems that arose from usability testing would not be written up as huge reports --- rather the key changes would go onto the same cards as any other Agile feature, and would be scheduled according to how important it was.

      > Any advice, encouragement, or opinions are greatly appreciated!

      Good luck with this!  Going fully Agile on a new project was a challenge for me at first, but now it's absolutely my favourite way to operate.

      -john schrag

    Your message has been successfully submitted and would be delivered to recipients shortly.