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

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

Expand Messages
  • William Pietri
    ... I wouldn t sell briefings short if I were you. Unless your project has huge turnover, it s often the case that the time expended in creating and updating
    Message 1 of 12 , Oct 25, 2007
    • 0 Attachment
      heyrobertdavis wrote:
      > They can look at the finished product
      > but that just shows the destination -- none of the journey. Same with
      > stories. We end up having to do lots of verbal briefings, which are
      > resource-intensive and imperfect, as is the nature of memory. Thoughts?
      >

      I wouldn't sell briefings short if I were you. Unless your project has
      huge turnover, it's often the case that the time expended in creating
      and updating documentation is well more than enough meetings to make a
      new person comfortable. Especially when you count the time it takes for
      a newbie to figure out which documentation addresses their actual needs,
      rather than those imagined before they showed up.

      Imperfect memory can also be a bonus. Often the question of, "Why don't
      we try X" is worth asking again.

      However, there's one sort of documentation that costs a lot less than
      others: journals. It's cheaper because journals aren't expected to match
      the current state of things; they're just a record of a view at one
      point in time. Most other documentation, on the other hand, either
      imposes a permanent update tax or goes stale.

      One of my clients captured this value by setting up company blogs. One
      blog per person plus one group blog per project plus a little bit of
      coordinated tagging makes it easy to capture a fair bit of knowledge in
      a low-cost way. For people looking to understand the journey, that
      personal narrative is often much more valuable -- and much more engaging
      -- than the traditional sorts of documentation.

      William


      --
      William Pietri - william@... - +1-415-643-1024
      Agile consulting, coaching, and development: http://www.scissor.com/
      Use your geek-fu to fight poverty: http://www.mifos.org/
    • Adrian Howard
      On 25 Oct 2007, at 17:03, Austin Govella wrote: [snip] ... [snip] Things like this - documentation that we need to produce for third parties not involved with
      Message 2 of 12 , Oct 26, 2007
      • 0 Attachment
        On 25 Oct 2007, at 17:03, Austin Govella wrote:
        [snip]
        > But we need the site map and test reports for product and business
        > management (not executives). The site map and content inventory are
        > also consumed by metrics, SEO, advertising, and marketing.
        >
        > I guess my question was: if you communicate with these other units,
        > how do you do so?
        [snip]

        Things like this - documentation that we need to produce for third
        parties not involved with development - I treat like any other
        Customer story. They get prioritised along with the other things of
        business value in the list. Seems to work pretty well.

        We don't do them as a "standard" part of the process because,
        sometimes, getting feature X up and running properly is more
        important. The person who understands the business value best is the
        right one to make that decision.

        It also helps because it forces the other people like marketing, SEO,
        etc. to ensure that their voices are heard by the Customer -
        otherwise their stuff doesn't get valued and produced. Once folk
        learn that lesson the last minute surprises drop off :-)

        Cheers,

        Adrian
      • Desilets, Alain
        ... Sounds like a really cool idea. I ll try that. For years, I have been using wikis in that same vein. Each task or user story gets a wiki page. People who
        Message 3 of 12 , Oct 28, 2007
        • 0 Attachment
          > However, there's one sort of documentation that costs a lot less than
          > others: journals. It's cheaper because journals aren't
          > expected to match the current state of things; they're just a
          > record of a view at one point in time. Most other
          > documentation, on the other hand, either imposes a permanent
          > update tax or goes stale.
          >
          > One of my clients captured this value by setting up company
          > blogs. One blog per person plus one group blog per project
          > plus a little bit of coordinated tagging makes it easy to
          > capture a fair bit of knowledge in a low-cost way. For people
          > looking to understand the journey, that personal narrative is
          > often much more valuable -- and much more engaging
          > -- than the traditional sorts of documentation.

          Sounds like a really cool idea. I'll try that.

          For years, I have been using wikis in that same vein. Each task or user
          story gets a wiki page. People who work on that story or task are
          encouraged to take notes on the wiki page. It's not compulsory, but
          basically, we tend to write down anything that we think important that
          we may not remember in a few months time. For example, design rationale.

          Alain
        • mitchgrrt
          If you can get people to write about what they are doing that s great. Design decisions and ideas, it s great to record them. Very useful later when going
          Message 4 of 12 , Oct 29, 2007
          • 0 Attachment
            If you can get people to write about what they are doing that's great.
            Design decisions and ideas, it's great to record them. Very useful
            later when going back. I think it's a cultural thing at a company.
            If people use the wiki and really write things there, later it will be
            very valuable. Years ago at a company where I worked there were
            internal newsgroups that worked really well for recording things.
            Since then nowhere I've worked has had a system that actually got used
            very much. I don't think it's a technology thing - wiki vs newsgroup
            vs something else - I think it's a cultural issue of getting people to
            use it.

            In agile I worry very much that we are losing the motivation behind
            stories, and the design alternatives, and even the finer details of
            how features are supposed to work. Anything that gets people to write
            that stuff down while it's still fresh in their minds is a big plus.

            - Mitch Gart


            --- In agile-usability@yahoogroups.com, "Desilets, Alain"
            <alain.desilets@...> wrote:
            >
            >
            > Sounds like a really cool idea. I'll try that.
            >
            > For years, I have been using wikis in that same vein. Each task or user
            > story gets a wiki page. People who work on that story or task are
            > encouraged to take notes on the wiki page. It's not compulsory, but
            > basically, we tend to write down anything that we think important that
            > we may not remember in a few months time. For example, design rationale.
            >
            > Alain
          • Desilets, Alain
            ... I agree that lightweight tools like wiki or newsgroups are not a sufficient condition for people to write down design rationale, etc... However, I think
            Message 5 of 12 , Oct 29, 2007
            • 0 Attachment
              > If you can get people to write about what they are doing that's great.
              > Design decisions and ideas, it's great to record them. Very
              > useful later when going back. I think it's a cultural thing
              > at a company.
              > If people use the wiki and really write things there, later
              > it will be very valuable. Years ago at a company where I
              > worked there were internal newsgroups that worked really well
              > for recording things.
              > Since then nowhere I've worked has had a system that actually
              > got used very much. I don't think it's a technology thing -
              > wiki vs newsgroup vs something else - I think it's a cultural
              > issue of getting people to use it.

              I agree that lightweight tools like wiki or newsgroups are not a
              sufficient condition for people to write down design rationale, etc...
              However, I think that having such tools helps greatly in encouraging
              people to do so. I doubt that you would have as much success if the only
              tools at the dispositions of developers for writing that stuff were
              heavy duty UML-based tools.


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