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

Re: top down, or bottom up?

Expand Messages
  • Jeff Patton
    ... down vs ... for ... see it. I ... that maybe you ... I definitely am being tongue in cheek when I implied you /only/ work top down. [That is a
    Message 1 of 36 , Apr 24, 2005
    • 0 Attachment
      responses in-line below:

      --- In agile-usability@yahoogroups.com, acockburn@a... wrote:
      > This note comes in two parts. (A) where is the top? and (B) top-
      down vs
      > bottom up.
      ...
      >
      > (A) where is the top?
      > never all or nothing - we all do a bit of both I suspect - except
      for
      > Alistair ... ;-) ]
      > >>
      >
      > I was looking for the tongue in cheek indicator there but didn't
      see it. I
      > originally assumed you were joking, but this later append hints
      that maybe you
      > weren't:

      I definitely am being tongue in cheek when I implied you /only/ work
      top down. [That is a winking-smiley after your name up there.]

      > That's when I got my surprise.
      > For me "user-goals" sit at the middle level. I can't imagine them
      being the
      > top. If someone names 30 - 50 user goals such as Ring Up Sale,
      Handle Return
      > Item, etc, then we immediately have a problem on our hands --- how
      do those
      > all fit together to make a coherent business operation?

      I'm not seeing "ring up a sale" or "return item" as goals, but as
      tasks. I know we might be splitting hairs here - because someone
      really does sit down to ring up a sale, and doing it successfully is
      indeed a goal. But for me, as soon as a users hand touches the
      keyboard, they're engaged in a task. The goal is in the head - the
      task is in the doing. For example I brush and floss nightly [well
      ok, sometimes I skip flossing...] - but those are tasks. My goal is
      to avoid tooth decay and be eating with my own teeth when I'm 70.
      The goal "avoiding tooth decay" has lots of tasks. So again, ring a
      sale isn't a goal, it's a task in my potentially-warped vocabulary.

      > Each of those operator tasks has been nominated as useful, but
      each was
      > named out of context. To validate their reason for existence and
      learn their
      > respective place in the overall operation of the org, I go ^up^ a
      level to
      > "kite", which shows work-flow or life-cycle: how do various
      people's work sew
      > together in a bigger picture or walk through the life-cycle of an
      item.
      >

      I tend to get that bigger picture by building affinity diagrams or
      workflow diagrams with those tasks [my span plan is a workflow
      diagram]. Doing that I suspect is similar to writing use cases in
      that as you're assembling a workflow with those tasks, you'll find
      missing tasks. And, often you'll find named tasks that don't seem to
      have a place in the workflow. This gives you the opportunity to dust
      off your Seinfeld and ask "what's with that?" When you've assembled
      some of these tasks, you can then make some assertions about the
      goals someone engaged in these tasks might be. If you have
      appropriate user roles, those should match. Often they don't. That
      gives you an opportunity to question and revise the user goals, or
      question and revise the workflow - both being good outcomes.

      The trick for me with all this is not working top down... but rather
      using the bottom to validate the top - or in some cases to derive it
      when I can't get people to state their goals. [These are people who
      haven't given much thought to why they brush their teeth every day.]

      > So from my own parochial and self-justifying perspective, I don't
      work
      > top-down at all, but rather middle-out.

      I believe you.

      > well here again Jeff's posts surprised me, but in a different way.
      >
      > I hadn't considered that anyone would really work from the clam and
      fish
      > level activities and build up a larger picture and hope that
      meaningful and
      > sensible business operations would emerge from that picture. Jeff's
      notes
      > indicate that Holzblatt's techniques do just exactly that, which if
      an accurate
      > portrayal, says that I am surprised, and Jeff's question still
      stands.

      I think we need a contextual designer to speak up and debunk what
      I've said. Contextual design does gather a lot of very low level
      data... and I believe it's pretty valuable stuff. They've even got a
      handy tool to keep that data, and help that big picture emerge - or
      look back and make sure the big picture that did emerged is still
      accurate as more data comes in. [http://www.incent.com/cdtools%5d

      [It's important to point out that the data gathered represents fish
      and clam level details about people, current workflow using current
      software products or paper driven approaches - not clam level details
      about the software we'll be building. /Those/ clam level details are
      a product of design.]

      > In my experience, if I find a single predominant pattern of use
      case
      > creations, it is
      >
      > sea --> kite --> sea --> fish & clam.
      >
      > That is, people start off talking about a system by naming a
      handful of
      > specific things they want to accomplish with it (sea level goals).
      > We then brainstorm and name a whole pile of those and ancillary
      things they
      > think people will want to or have to accomplish with it (more sea
      level
      > goals).
      > We then create a higher-level (kite) story that contextualizes,
      justifies
      > and links (and creates new) all the sea-level things.
      > We then (and this is the "top-down" part Jeff refers to) examine
      each
      > sea-level use case for its specific sub-tasks and activities.

      So using that same notation - which I like.. I do this:
      kite [gather user roles & goals] --> fish & clam [gather task
      details] --> sea [model tasks to derrive sea level] --> kite --> sea -
      -> fish --> sea --> kite.... [this is where I start porposing/zooming
      to validate back & forth.]

      > A competing notion seems to be to do ethnographic investigation
      with
      > grounded theory annotations applied to the field notes, and from
      those obtain common
      > patterns of movement that should be supported in the UI. Is this a
      correct
      > if short statement of the alternate view?
      >
      > This alternate view implies the sequence is
      >
      > clam --> fish --> sea (and I'll be surprised if anyone in this
      view creates
      > kite-level views)

      If we can consider kite level as the user goals captured in a
      persona, or the labeling on clusters of clusters of notes in
      contextual design [the pink ones?] - if those are analogous to kite
      level, then UCD people do really move from pretty small details
      gathered about individual behavior to arrive at pretty high level
      goals.

      I believe that UCD people are looking for those little details, lots
      of them, and those are used to validate the big picture. This is
      where I see UCD approaches as mostly bottom up - or at minimum
      placing high value on lots of accurate details. It's not that more
      traditional analysis approaches don't value details, just that they
      tend to seek them after looking at higher order processes - kite
      level things. That, for me, has the affect of looking for evidence
      to validate your hypothesis... and we all know we can find facts to
      validate anything we want. It's those pesky little facts that don't
      that I'm looking for. That's what I meant by the little details that
      people forget.

      Thanks Alistair for your post!

      -Jeff
    • Glen B Alleman
      Alistair, Crystal has a variety of options. Others are narrower. Few are as broadly based as your approach. I m more focused on specific development method
      Message 36 of 36 , May 8 9:55 AM
      • 0 Attachment
        Alistair,

        Crystal has a variety of options. Others are narrower. Few are as broadly
        based as your approach. I'm more focused on specific development method that
        move outside their "sweet spot" leaking into other areas - off the sweet
        spot. I see this not as an issue of the method but it's application. Mis
        applied CMMI, mis applied XP, mis applied TOC.

        Glen

        -----Original Message-----
        From: agile-usability@yahoogroups.com
        [mailto:agile-usability@yahoogroups.com] On Behalf Of aacockburn
        Sent: Sunday, May 08, 2005 10:46 AM
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] Re: elite methods

        I'm sure you mean "almost" everyone, Glen --- I've been researching
        and publishing on the topic of selecting methods for over a decade
        now, have a PhD, three books, a dozen articles and most of a website
        on the question of selecting a process. I'm not alone: that aspect of
        my PhD wasn't considered novel at all but rather as fully established
        in the research community; Capers Jones talks about it in his
        benchmarking book; RUP and the UP are all about that; Boehm has a
        book and articles about it, there are others.

        By this late date, the notion of a single methodology as a silver
        bullet is severely outmoded.

        Alistair

        --- In agile-usability@yahoogroups.com, "Glen B Alleman"
        <glen.alleman@n...> wrote:
        > Jon,
        >
        >
        >
        > The problem of deciding how to apply a processes to a problem
        domain is
        > nearly universal. Ranging from heavy to light. I've experienced
        poorly
        > applied CMMI to poorly applied XP and everything in between. No
        one seem to
        > want to approach the "improvement" process from an external point -
        as you
        > suggest - selecting the right process for the problem. I'm
        searching though
        > for the solution - none found so far. Everyone's got a silver
        bullet looking
        > for the werewolf to shoot ;>)
        >
        >
        >
        > Glen B. Alleman
        >
        > <http://www.niwotridge.com> www.niwotridge.com
        >
        > www.niwotridge.com/Blog
        >
        >
        >
        >
        >
        > _____
        >
        > From: agile-usability@yahoogroups.com
        > [mailto:agile-usability@yahoogroups.com] On Behalf Of Jon Kern
        > Sent: Friday, May 06, 2005 6:36 PM
        > To: agile-usability@yahoogroups.com
        > Subject: Re: [agile-usability] Re: elite methods
        >
        >
        >
        > i don't think there is any indication that anyone meant that all
        heavy
        > processes are to hide incompetence.
        >
        > however, i submit there are at least a few reasons for introducing
        process:
        > - because someone has a good set of steps worth repeating (good
        teams do
        > this automatically)
        > - because someone wants to ensure a set of steps are done and
        may not
        > trust the doer at knowing what to do (bureaucracies are good at
        doing this)
        >
        > i hope i left wiggle room in my original post for applying the
        right process
        > for the right reasons. my flippant remarks are intended to jolt
        people into
        > thinking if they are applying the right level of process. a
        heavyweight
        > process (such as might be applied in your NQA-1 example) applied to
        a
        > mediocre business app is probably not an effective use of resources.
        >
        > also, i have seen people conduct process steps "just because" --
        either
        > because they cannot think for themselves, or that they are dis-
        incented to
        > not follow process, or they are naive, or they do not care if they
        are
        > wasting resources (money and time).
        >
        > but, for a mission critical app, i hope the right process is
        followed... as
        > it is in almost every "hard" engineering discipline i ever worked
        within.
        >
        >
        >
        >
        > -- jon
        >
        >
        >
        >
        > Glen B Alleman said the following on 5/6/2005 8:54 AM:
        >
        > Jon,
        >
        >
        >
        > Mission critical can be applied outside man rated as NASA uses that
        term.
        > Mission critical can be applied to a brad variety of system from
        process
        > control, to supply chain management. Pacemakers are 21CFR,
        petrochem is OSHA
        > 1910.119, rod control for a reactor is NQA-1, the ground mission
        planning
        > and dispatch for air defense has another framework.
        >
        >
        >
        > The comment (now seen a flippant) that poor developers hide behind
        high
        > ceremony struck me a uninformed about those working in the high
        ceremony
        > development envirnemnt that also use agile methods. Thy are not
        mutually
        > exclusive
        >
        >
        >
        > Glen
        >
        >
        >
        > _____
        >
        > From: <mailto:agile-usability@yahoogroups.com>
        > agile-usability@yahoogroups.com [mailto:agile-
        usability@yahoogroups.com] On
        > Behalf Of Jon Kern
        > Sent: Friday, May 06, 2005 5:17 AM
        > To: agile-usability@yahoogroups.com
        > Subject: Re: [agile-usability] Re: elite methods
        >
        >
        >
        > please define mission-critical...
        > man-rated, mission critical systems are a different story.
        >
        > always attach the right level of rigor and process as needed...
        >
        > software for an embedded pacemaker is different than making an
        online
        > mortgage loan application system.
        >
        >
        >
        >
        > -- jon
        >
        >
        >
        >
        > Glen B Alleman said the following on 5/5/2005 11:40 AM:
        >
        > As one who leads CMMI IPPD development this is likely not true in
        > practice...but simply conjecture on the part of those not
        practicing heavy
        > processes in a mission critical environment.
        >
        > Glen B Alleman
        >
        > -----Original Message-----
        > From: agile-usability@yahoogroups.com
        > [mailto:agile-usability@yahoogroups.com] On Behalf Of aacockburn
        > Sent: Thursday, May 05, 2005 9:35 AM
        > To: agile-usability@yahoogroups.com
        > Subject: [agile-usability] Re: elite methods
        >
        > At least, they will defend them because it's easier to hid :-)
        >
        >
        > --- In agile-usability@yahoogroups.com, "Cummins, Darin"
        > <mailto:Darin_Cummins@a...> <Darin_Cummins@a...> wrote:
        > > If you twist this one more time, does that imply that incompetent
        > > developers choose heavy processes because it's easier to hide? ;-)
        > >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        > _____
        >
        > Yahoo! Groups Links
        >
        > * To visit your group on the web, go to:
        > http://groups.yahoo.com/group/agile-usability/
        >
        > * To unsubscribe from this group, send an email to:
        > agile-usability-unsubscribe@yahoogroups.com
        > <mailto:agile-usability-unsubscribe@yahoogroups.com?
        subject=Unsubscribe>
        >
        > * Your use of Yahoo! Groups is subject to the Yahoo!
        > <http://docs.yahoo.com/info/terms/> Terms of Service.





        Yahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.