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

[shameless self promotion] managing scale vs. scope

Expand Messages
  • Jeff Patton
    I have a column this week on StickyMinds.com: http://www.stickyminds.com/sitewide.asp? Function=WEEKLYCOLUMN&ObjectId=10330&ObjectType=ARTCOL&btntopic=artcol&t
    Message 1 of 2 , Feb 13, 2006
    • 0 Attachment
      I have a column this week on StickyMinds.com:
      http://www.stickyminds.com/sitewide.asp?
      Function=WEEKLYCOLUMN&ObjectId=10330&ObjectType=ARTCOL&btntopic=artcol&t
      t=WEEKLYCOL_10330_readon The UCD people here will recognize use of
      user and task modeling mentioned in the column. But, the big idea is
      leveraging those things along with the notion that what we know about
      users and the tasks they perform help us appropriately manage the scale
      of our design solution.

      In many of the contexts I work in I listen to lots of folks engage in
      in-and-out of scope arguments. Often everyone knows that taking the
      support for the task out of scope isn't an option. This is my attempt
      at letting people know there are other options. Managing feature scale
      vs. scope is a subtle - and possibly forced - distinction, but it's a
      distinction and opportunity I often see people fail to make and take.

      thanks,

      -Jeff
    • Desilets, Alain
      What a great column Jeff (as usual)! When is that book due to be published ;-)? I think scaling features appropriately is a core principle of Agile
      Message 2 of 2 , Feb 15, 2006
      • 0 Attachment
        What a great column Jeff (as usual)! When is that book due to be published ;-)?

        I think scaling features appropriately is a core principle of Agile (StartWithTheSimplestThingThatCouldPossiblyWork) and it is one that I have applied with great success over the last 4 years.

        I had never thought of this, but your column made me realise that UCD is highly complementary to Agile in that respect. Indeed, in order to determine what COULD possibly work, you need to know your users pretty well. Over the years, I have relied on pretty informal ways to get that kind of knowledge (ex: immerse myself in the user's domain and task until I feel I could look like a user to someone not familiar with that domain), but I can see how more formal UCD methods might help.

        One thing I noticed was that you focused on a scenario where features are scaled down mid-iteration. Because of the way I operate, I find that I am more likely to look for ways to scale features UP in mid-iteration than DOWN.

        The way I work, all the scaling down happens at the START of the iteration. For example, I will start by doing a mini-design exercise for a feature. Once I have a design that I think will work for the user, I ask myself "Is there a solution that is simpler to implement and that will still allow the user to get the job done". The answer is invariably yes. I then come up with an implementationally simpler solution, and ask myself the same question again. Usually, I find that I can scale the design down one or two notches before I start feeling that the solution will be unacceptable to the user. I then go ahead and implement the last solution I came up with that I thought might work (but I document the other designs so I have an upgrade path ready for if and when I need it).

        This is one of the most useful tricks I have learned from Agile. Over my 25 year career, I have lost so many times by first going for a design that I thought was "mid range", but turned out to be gold plated and hard to implement. But I have NEVER lost (truly!) by first implementing the SimplestThingThatCouldPossiblyWork.

        Of course, very often (but not always) I will have to scale the feature back up and this might lead you to believe that implementing the simplest thing first was a waste of time. But it's not for three reasons.

        The first is that only a portion of my SimplestThings will turn out to be inappropriate. Usually, I find I cannot predict ahead of time which ones they will be. So by starting with those SimplesThings, I have saved myself the work of implementing the "mid-range" solutions for all the ones where the SimplestThing turned out to be just fine. Also, I get to spend more of my time on upscaling the features that really matter.

        The second reason is that by giving the SimplestThing for users to play with, I often gather information about where the actual sore spots for a features are, and the direction in which I need to scale it up. Very often, that direction turns out to be quite different from what I had originally envisaged, and it is something that would have been hard to find out a-priori (sometimes the user did not even know this before he started playing around with the real thing). To take your swing example, it may be that after I deploy the SingleCableNoBoard solution, I find out that the real issue is not the number of cables nor the presence or not of a board, but rather the length of the cable (which greatly affects the speed at which the swing can swing). Or it may be that by deploying a number of instances of that SingleCableNoBoard solution, I find out that the ones that were hung off a tree close to a lake are the ones that kids use most (because they can jump off the swing into the lake), and therefore the location of the tree is the real issue.

        The third reason is that often some of the work done to implement the SimplestThing can be reused to build the more complex design. Even if no part of the SimplestThing implementation can be reused, I will still have learned a lot about the implementation issues of the feature and this helps me build the more complex design. Using again your slide example, once I have built the SingleCableNoBoard solution, I may be able to reuse the cable to act as the right side cable of the TwoCablesRectangularBoard solution. I can also more easily create the second cable, because I don't have to measure it (I just have to cut it to the exact same length as the first one). Also, I will have learned how to do a knot wide enough for a kid to straddle comfortably, and strong enough to support his weight, and that will certainly help me make a knot wide enough and strong enough to support the board on which the kid will sit.

        Together those three reasons mean that the time I waste by reworking inadequate SimplestThings is usually offset by the time I would have wasted by implementing more complex (and possibly inadequate too) features that were not warranted. I don't have empirical evidence to back that up though. It's just a sense I have based on my own personal experience.


        Alain Désilets, MASc
        Agent de recherches/Research Officer
        Institut de technologie de l'information du CNRC /
        NRC Institute for Information Technology

        alain.desilets@...
        Tél/Tel (613) 990-2813
        Facsimile/télécopieur: (613) 952-7151

        Conseil national de recherches Canada, M50, 1200 chemin Montréal,
        Ottawa (Ontario) K1A 0R6
        National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
        K1A 0R6

        Gouvernement du Canada | Government of Canada



        -----Original Message-----
        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Jeff Patton
        Sent: Monday, February 13, 2006 4:19 PM
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] [shameless self promotion] managing scale vs. scope


        I have a column this week on StickyMinds.com:
        http://www.stickyminds.com/sitewide.asp?
        Function=WEEKLYCOLUMN&ObjectId=10330&ObjectType=ARTCOL&btntopic=artcol&t
        t=WEEKLYCOL_10330_readon The UCD people here will recognize use of
        user and task modeling mentioned in the column. But, the big idea is
        leveraging those things along with the notion that what we know about
        users and the tasks they perform help us appropriately manage the scale
        of our design solution.

        In many of the contexts I work in I listen to lots of folks engage in
        in-and-out of scope arguments. Often everyone knows that taking the
        support for the task out of scope isn't an option. This is my attempt
        at letting people know there are other options. Managing feature scale
        vs. scope is a subtle - and possibly forced - distinction, but it's a
        distinction and opportunity I often see people fail to make and take.

        thanks,

        -Jeff







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