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
  • William Pietri
    Hi, Amy. I work mainly for web startups and small-ish companies, so any advice I give might require adjustment to your situation, which sounds larger. ...
    Message 1 of 3 , Oct 18, 2007
    • 0 Attachment
      Hi, Amy. I work mainly for web startups and small-ish companies, so any
      advice I give might require adjustment to your situation, which sounds
      larger.

      Amy wrote:
      > So I've been called in to help with the user experience side of things
      > and I'm very unclear (both from the standpoint of the company and from
      > my reading on Agile UX methods) on what deliverables I should be
      > producing and what sort of general UX plan I should suggest.
      >

      Could you say more about the length of iteration and release cycles, the
      amount of time you'll spend on the project, and your physical
      relationship to the other participants like developers and product managers?

      > 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.
      >

      I don't think there's an a priori resistance to documentation. What
      we're excited about is communication and deeply engaged participation.
      Sometimes documents really are the cheapest, best way to communicate.
      But agile proponents do have a learned suspicion of documents. Why?
      Well, relative to in-person communication, they are expensive to
      produce, have low bandwidth, are not interactive, are difficult to
      update and redistribute, are not a two-way medium, and often lose
      subtleties unintentionally. Plus, people never read them as much as you
      want.

      When you get the urge for a document, it's good to ask yourself who
      you're trying to communicate with, what you want to convey, and whether
      there's some more agile way to do that.

      Most of my clients use index cards, white boards, scratch paper, and the
      occasional HTML mockup to run multi-person, multi-year projects.


      > So what does a UEX professional do? Is there a set of alternate
      > deliverables? Without the application mapped out isn't there danger
      > of redesigning the UI with each new story/iteration?
      >

      In my world, we put the UEX professional in the same room with the other
      folks. They collaborate with the product manager and other business
      folks in coming up with a vision of what to build. When it comes time to
      do the building, they collaborate with the product manager and the
      developers on the fine details.

      And yes, there's always a danger. But a web application is never done,
      so there's always that danger no matter how much advance planning you
      do. If in 1994 you had sat down to lead Yahoo's user experience team,
      you wouldn't have tried to guess everything they would do through 2007.
      You would have just made your best guesses, tried to keep things
      flexible, and rolled with the changes as they came.

      If you company is doing their chosen agile method well, it's just like
      that on a smaller scale. You make your best guesses about the future,
      but you don't place any big bets on it if you can help it.

      > I am open to engaging in this new way of doing things, but also don't
      > want to jump in without thinking through the consequences of NOT
      > creating deliverables that I've seen work well in the past.
      >

      Just to make it clear: you have full permission to create anything you
      need yourself. If you get all excited and want to make a process flow
      map on day 1, do it. If you're worried that just thinking about the next
      few features might lead to a mangled architecture, then feel free to
      sketch out your vision for three years down the road, including
      everything you think of.

      The difference with agile methods comes as you communicate things to the
      rest of the team. If you think of just-in-time delivery for
      manufacturing, it's like that. When the team sits down to build this
      week's features, just give them enough for this week. But if the suits
      rush in next week with a new requirement that blows up all your grand
      visions, you just have to make new visions.

      And that's part of why we discourage a lot of investment in documents.
      When things change, you have to spend a lot of time updating all the
      documents. Or you don't, and then you have a bunch of stale documents.
      Either of those can make people pretty resistant to change.

      Hoping that helps,

      William


      --
      William Pietri - william@... - +1-415-643-1024
      Agile consulting, coaching, and development: http://www.scissor.com/
      A team room, in pictures: http://www.scissor.com/resources/teamroom/
    • 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 2 of 3 , Oct 18, 2007
      • 0 Attachment

        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.