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

Re: High-fidelity Visualization – an Agile accelerator?

Expand Messages
  • marty.nelson
    Marvin - One suggestion would be to focus on those features that show satisfaction of desires versus (or before those) that are mechanisms of fulfillment .
    Message 1 of 20 , Feb 4, 2011
    • 0 Attachment
      Marvin -

      One suggestion would be to focus on those features that show 'satisfaction of desires' versus (or before those) that are 'mechanisms of fulfillment'.

      They tend to cost less because they are simpler, they validate high-level concepts (fulfillment mechanisms are /just/ necessary evils), and they precede mechanism requirements so it prevents more costly churn.

      --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@...> wrote:
      >
      > We are only 25% into into our grand 4-day experiment of engaging a large stakeholder community for the purpose of feedback for a Mobile Application. Thirty-five of us met for an hour and ten minutes today to begin formulating our learning. So far - the talk centered around the decomposition of the term "Fidelity" as follows:
      >
      > Visualization Concerns:
      > a. Fidelity of Navigation (between pages)
      > b. Fidelity of Interaction (within a page)
      > c. Fidelity of Data (sample vs. contextualized)
      > d. Fidelity of Rendered Page (hand drawn vs. pixel perfect)
      > e. Fidelity of Business Rule (i.e. You can only attend one Conference session at the time.)
      > f. Fidelity of failure modes
      >
      > Two Principles have tentatively emerged:
      >
      > 1. The analysis of the usefulness of this type of tool is nuanced and project specific.
      >
      > 2. It makes a difference if it is Mobile Application:
      >
      > a. Form factor matters.
      > b. The mobile community tends to be impatient and intolerant of poor usability... perhaps more so than a web application.
      >
      > ... More to come ...
      >
      > --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@> wrote:
      > >
      > > We want to engage scores of stakeholders in contributing to a Mobile Application – to mature a first-draft concept. We are publicly sharing our approach. See if you think this approach using "High-fidelity Visualization" makes a positive contribution to `executable requirements'.
      > >
      > > http://tinyurl.com/45qcfkm
      >
    • MarvinToll.com
      @marty - Can you make this concrete for me? In the context of our particular visualization what would constitute satisfaction of desires ? What would
      Message 2 of 20 , Feb 6, 2011
      • 0 Attachment
        @marty - Can you make this concrete for me?

        In the context of our particular visualization what would constitute 'satisfaction of desires'?

        What would constitute 'mechanisms of fulfillment'?

        http://tinyurl.com/45qcfkm

        --- "marty.nelson" <noslenytram@...> wrote:
        >
        > Marvin -
        >
        > One suggestion would be to focus on those features that show 'satisfaction of desires' versus (or before those) that are 'mechanisms of fulfillment'.
        >
        > They tend to cost less because they are simpler, they validate high-level concepts (fulfillment mechanisms are /just/ necessary evils), and they precede mechanism requirements so it prevents more costly churn.
      • marty.nelson
        I think there are clearer examples in the SimBank sample iDoc. The Registration Confirmation page is the satisfaction of desires (How will the system
        Message 3 of 20 , Feb 7, 2011
        • 0 Attachment
          I think there are clearer examples in the SimBank sample iDoc.
          The 'Registration Confirmation' page is the 'satisfaction of desires' (How will the system show/prove that user got what they wanted out of registration?), the Registration page is the 'mechanism of fulfillment' (What user uses to get what they want out of the system).

          Of course, there may be other needs unexpressed, for example what does the bank need to see from the system to show them they are getting what they want (desire) out of people registering.

          Ticket Confirmation and My Tickets are both 'satisfaction of desires' and Create Ticket is 'mechanism of fulfillment'.

          In the Agile and Beyond scheduler app, I would assume that the 'My Sessions' page is the 'satisfaction of desires' and the 'All sessions' with some type of 'choose this one' is the 'mechanism of fulfillment'. If this wasn't the intent of the app, then using this technique explicitly would help clarify the purpose.

          Now if this all makes sense to you, one thing you may notice is that the 'satisfaction of desires' feature defines the interface and needs that the 'mechanism of fulfillment' must ultimately provide. What this means is the 'satisfaction of desires' features can be used to test drive 'mechanism of fulfillment' features.

          (An unrelated comment, the technologist in me cringes at having to download and install an app to run iRise. The fact that it runs in a browser doesn't help but make me wonder why it wasn't delivered as a pure browser solution. Maybe the writer component? Anyway, just .02 on that one)

          --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@...> wrote:
          >
          > @marty - Can you make this concrete for me?
          >
          > In the context of our particular visualization what would constitute 'satisfaction of desires'?
          >
          > What would constitute 'mechanisms of fulfillment'?
          >
          > http://tinyurl.com/45qcfkm
          >
          > --- "marty.nelson" <noslenytram@> wrote:
          > >
          > > Marvin -
          > >
          > > One suggestion would be to focus on those features that show 'satisfaction of desires' versus (or before those) that are 'mechanisms of fulfillment'.
          > >
          > > They tend to cost less because they are simpler, they validate high-level concepts (fulfillment mechanisms are /just/ necessary evils), and they precede mechanism requirements so it prevents more costly churn.
          >
        • MarvinToll.com
          hmmm... How do these two concepts improve our application? How do we use satisfaction of desires features to test drive mechanism of fulfillment features?
          Message 4 of 20 , Feb 8, 2011
          • 0 Attachment
            hmmm... How do these two concepts improve our application?

            How do we use 'satisfaction of desires' features to test drive 'mechanism of fulfillment' features?

            What outcome(s) can we anticipate from this exercise?

            (I'm a Java guy and am struggling to catch-on to the concrete value-proposition for our application.)

            --- "marty.nelson" <noslenytram@...> wrote:
            >
            > In the Agile and Beyond scheduler app, I would assume that the 'My Sessions' page is the 'satisfaction of desires' and the 'All sessions' with some type of 'choose this one' is the 'mechanism of fulfillment'. If this wasn't the intent of the app, then using this technique explicitly would help clarify the purpose.
            >
            > Now if this all makes sense to you, one thing you may notice is that the 'satisfaction of desires' feature defines the interface and needs that the 'mechanism of fulfillment' must ultimately provide. What this means is the 'satisfaction of desires' features can be used to test drive 'mechanism of fulfillment' features.
            >
            > --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@> wrote:
            > >
            > > @marty - Can you make this concrete for me?
            > >
            > > In the context of our particular visualization what would constitute 'satisfaction of desires'?
            > >
            > > What would constitute 'mechanisms of fulfillment'?
            > >
            > > http://tinyurl.com/45qcfkm
            > >
          • marty.nelson
            ... Users/Customers care about satisfaction of desires , and tolerate mechanisms of fulfillment in order to get that. So your application improves because
            Message 5 of 20 , Feb 11, 2011
            • 0 Attachment
              > hmmm... How do these two concepts improve our application?
              Users/Customers care about 'satisfaction of desires', and tolerate 'mechanisms of fulfillment' in order to get that. So your application improves because it a) gives users and customers more of what they explicitly want, and b) only thrusts upon the users the minimal mechanism need to achieve those outcomes.

              > How do we use 'satisfaction of desires' features to test drive 'mechanism of fulfillment' features?
              > What outcome(s) can we anticipate from this exercise?

              While the conversation is about 'satisfaction of desires' is subjective, once agreed upon it implies very specific requirements about what the system needs to provide to support that artifact. This is essentially the output side of an "acceptance test", so you can then define inputs and can create the 'mechanism of fulfillment' in a test first manner

              > (I'm a Java guy and am struggling to catch-on to the concrete value-proposition for our application.)

              Well another great reasons to have these conversations is that they expose weak or missing 'value-propositions'. For example, is the point of your application so that an attendee would have something to tell them the 'next session'? Is the point to provide a way to learn about sessions? Both? Does a user want to decide everything ahead of time? Or would having something with a 1st, 2nd and 3rd choice for each time slot that allowed JIT decisions be better? What does the organizer need to be shown to know this system is providing value? Are they hoping to do some planning or room balancing based on expected attendance? Is this meant to be a vote sessions up or down kind of thing?

              The point being, any investment in 'mechanisms of fulfillment' are dubious if we don't know what the various constituents hope to get out of the application ('satisfaction of desires').


              > --- "marty.nelson" <noslenytram@> wrote:
              > >
              > > In the Agile and Beyond scheduler app, I would assume that the 'My Sessions' page is the 'satisfaction of desires' and the 'All sessions' with some type of 'choose this one' is the 'mechanism of fulfillment'. If this wasn't the intent of the app, then using this technique explicitly would help clarify the purpose.
              > >
              > > Now if this all makes sense to you, one thing you may notice is that the 'satisfaction of desires' feature defines the interface and needs that the 'mechanism of fulfillment' must ultimately provide. What this means is the 'satisfaction of desires' features can be used to test drive 'mechanism of fulfillment' features.
              > >
              > > --- In extremeprogramming@yahoogroups.com, "MarvinToll.com" <MarvinToll@> wrote:
              > > >
              > > > @marty - Can you make this concrete for me?
              > > >
              > > > In the context of our particular visualization what would constitute 'satisfaction of desires'?
              > > >
              > > > What would constitute 'mechanisms of fulfillment'?
              > > >
              > > > http://tinyurl.com/45qcfkm
              > > >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.