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

Re: [agile-usability] Re: New Member Introduction - Jim Jarrett, Usability Manager, Rockwell Automatio

Expand Messages
  • John Schrag
    ... I agree with you on that, and I m all in favour of lots of contact between the whole team and the end users. My claim is that the UX person, working with
    Message 1 of 176 , Oct 22, 2007
    • 0 Attachment

      On 22-Oct-07, at 7:43 AM, Adrian Howard wrote:
      > UX skills are certainly great to have in the Customer role. Whether 
      > that makes a UX person the ideal Customer I'm less certain. No matter 
      > how much time we spend with the client there are always elements of 
      the business that they will know better than us.

      I agree with you on that, and I'm all in favour of lots of contact between the whole team
      and the end users.  My claim is that the UX person, working with (hopefully multiple) end
      users should be better able to collect and communicate this knowledge.  On a number
      of occasions I've done comparitive notes where I first get a user to tell me about their 
      work, then observed them doing the work.  The observation would always reveal all kinds
      of things that the user didn't tell me about, either because they didn't notice it themselves,
      or because they thought it so obvious or unimportant that it didn't require mention.  I tend to
      think of it as an architect designing a house for a plumber --- the plumber will be heavily
      involved, and will have final say, but it's still best to let the architect to actually do the

      I wrote:
      > And since developers are notoriously bad at caring ("The feature
      > works. if the user can't figure it out, he's an idiot."), a very
      > good way to deal with this is to ensure the UI designs are usable
      > before the developers even start working on them. We achieved this
      > by designing, prototyping, and conducting formative usability
      > testing one cycle in advance.

      Adrian replied:
      I personally think that that stereotype of developers is unfair - and
      mostly due to the development environment they're placed in. Working 
      in a more agile environment that values meeting the users needs kills 
      that attitude dead.

      Developers really want to make great products - honest :)

      You are, of course, correct, and wet noodles to me.  (I used to be a developer
      myself.)  Developers in many circumstances are enouraged to not care by
      environments that strongly reward getting features "done" and that do not 
      reward making features good.  (In fact, taking extra care to make features good
      can be considered a bad thing.)  Another reason to make sure the usability
      goals are part of the feature criteria.


    • Scott Preece
      Hi, I think it s more about not squashing joy than about encouraging it. Most of us take a lot of pleasure in doing this software thing, and many look for
      Message 176 of 176 , Dec 1 10:54 AM
      • 0 Attachment

        I think it's more about not squashing joy than about encouraging it. Most of us take a lot of pleasure in doing this software thing, and many look for jobs that let them extend that pleasure by advancing efforts that interest them in one way or another. I suspect there may be some really effective leaders who can actually build an additional sense of joy around project accomplishments in their teams, but I think that's stretching it and that much of the potential for joy of work is personal and internal. It's more about enabling and not disabling joy than about creating it.

        Organizations, managers, process designers, and everyone else involved have infinite opportunities to make life miserable, so not killing joy is clearly a good thing to encourage. I'm just not sure how to state this in the form of the Manifesto's values statements. We value Joy over what? Most of the obvious choices, like regimentation, professionalism, achievement, speed, order, are either things that organizations would stoutly deny encouraging (like regimentation) or are things aren't inherently anti-joy (like professionalism). Does any organization consciously promote misery in its staff?

        Maybe it's best to assume that valuing joy is part of valuing people?


        ----- Original Message ----

        From: Ron Jeffries <ronjeffries@...>

        To: agile-usability@yahoogroups.com

        Sent: Saturday, December 1, 2007 4:31:23 AM

        Subject: Re: [agile-usability] Joy in work [was: interminable]

        Hello, Brian. On Sunday, November 11, 2007, at 2:34:38 PM, you


        > In fact, I'd go further. I claim that an error of the original

        > manifesto was that it left some values out that, as it happens,

        > should have been explicit. One of those is that work should be

        > joyful. Back in the first half of this decade, people on teams used

        > to tell me, "This is the best project I've ever worked on!" I'm

        > unhappy that what I hear today is more "my job doesn't suck as much

        > as it used to". We've let joy in work slip away in our effort to

        > appeal to more people.

        This is a tough one, for sure. I have guided my work life in large

        part from a joy focus, or at least by noticing, sometimes later than

        I should, that joy was absent, and moving to a place in the currents

        where more joy comes floating by. I would hope that everyone can

        find joy in what they do, though it seems to me that many never do.

        Despite the truth of the notion, it seems unlikely to "sell" to

        business people. This means that it will be "good business" for

        Agilist business people to downplay this and other humanistic

        values, so as to appeal to "hard-nosed" business people.

        I think that what might work in that regard is to find, describe,

        ultimately "prove" that working in ways that give more joy also

        gives better business results. This means that the "ways" in

        question have to be things to do that are not so much like "follow

        your bliss" and a lot like "make sure your people take the time to

        write unit tests because your product will reach an acceptable level

        of quality faster." This would need to be true, of course, and in

        fact I think it is. Then it needs to turn out that having and taking

        the time to write the tests provides an increment of joy to the

        programmers, which certainly can be the case.

        In any case ... it just seems darned hard to address these things,

        and it really could get in the way of at least some people's

        business focus on selling Agile. I'm very interested and not very

        certain what ought to be done.

        Lead us ...

        Ron Jeffries

        www.XProgramming. com

        I know we always like to say it'll be easier to do it now than it

        will be to do it later. Not likely. I plan to be smarter later than

        I am now, so I think it'll be just as easy later, maybe even easier.

        Why pay now when we can pay later?

        <!-- #ygrp-mkp{ border:1px solid #d8d8d8;font-family:Arial;margin:14px 0px;padding:0px 14px;} #ygrp-mkp hr{ border:1px solid #d8d8d8;} #ygrp-mkp #hd{ color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;margin:10px 0px;} #ygrp-mkp #ads{ margin-bottom:10px;} #ygrp-mkp .ad{ padding:0 0;} #ygrp-mkp .ad a{ color:#0000ff;text-decoration:none;} --> <!-- #ygrp-sponsor #ygrp-lc{ font-family:Arial;} #ygrp-sponsor #ygrp-lc #hd{ margin:10px 0px;font-weight:bold;font-size:78%;line-height:122%;} #ygrp-sponsor #ygrp-lc .ad{ margin-bottom:10px;padding:0 0;} --> <!-- #ygrp-mlmsg {font-size:13px;font-family:arial, helvetica, clean, sans-serif;} #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select, input, textarea {font:99% arial, helvetica, clean, sans-serif;} #ygrp-mlmsg pre, code {font:115% monospace;} #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family:Georgia; } #ygrp-text p{ margin:0 0 1em 0;} #ygrp-tpmsgs{
        font-family:Arial; clear:both;} #ygrp-vitnav{ padding-top:10px;font-family:Verdana;font-size:77%;margin:0;} #ygrp-vitnav a{ padding:0 1px;} #ygrp-actbar{ clear:both;margin:25px 0;white-space:nowrap;color:#666;text-align:right;} #ygrp-actbar .left{ float:left;white-space:nowrap;} .bld{font-weight:bold;} #ygrp-grft{ font-family:Verdana;font-size:77%;padding:15px 0;} #ygrp-ft{ font-family:verdana;font-size:77%;border-top:1px solid #666; padding:5px 0; } #ygrp-mlmsg #logo{ padding-bottom:10px;} #ygrp-vital{ background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;} #ygrp-vital #vithd{ font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:uppercase;} #ygrp-vital ul{ padding:0;margin:2px 0;} #ygrp-vital ul li{ list-style-type:none;clear:both;border:1px solid #e0ecee; } #ygrp-vital ul li .ct{ font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-right:.5em;} #ygrp-vital ul li .cat{ font-weight:bold;}
        #ygrp-vital a{ text-decoration:none;} #ygrp-vital a:hover{ text-decoration:underline;} #ygrp-sponsor #hd{ color:#999;font-size:77%;} #ygrp-sponsor #ov{ padding:6px 13px;background-color:#e0ecee;margin-bottom:20px;} #ygrp-sponsor #ov ul{ padding:0 0 0 8px;margin:0;} #ygrp-sponsor #ov li{ list-style-type:square;padding:6px 0;font-size:77%;} #ygrp-sponsor #ov li a{ text-decoration:none;font-size:130%;} #ygrp-sponsor #nc{ background-color:#eee;margin-bottom:20px;padding:0 8px;} #ygrp-sponsor .ad{ padding:8px 0;} #ygrp-sponsor .ad #hd1{ font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;} #ygrp-sponsor .ad a{ text-decoration:none;} #ygrp-sponsor .ad a:hover{ text-decoration:underline;} #ygrp-sponsor .ad p{ margin:0;} o{font-size:0;} .MsoNormal{ margin:0 0 0 0;} #ygrp-text tt{ font-size:120%;} blockquote{margin:0 0 0 4px;} .replbq{margin:4;} -->
      Your message has been successfully submitted and would be delivered to recipients shortly.