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

Re: New Member Introduction - Jim Jarrett, Usability Manager, Rockwell Automatio

Expand Messages
  • james.jarrett
    Thanks for the welcome. I agree that staying close to users and user experts is necessary (for all projects) and encouraged for agile projects. My biggest
    Message 1 of 176 , Oct 20, 2007
    • 0 Attachment
      Thanks for the welcome. I agree that staying close to users and user
      experts is necessary (for all projects) and encouraged for agile
      projects. My biggest challenge is that, as a company, our culture has
      only recently started to try and get access to real users (some
      product groups have worked at it for over a decade and the difference
      is palpable).

      Unfortunately, if a SCRUM doesn't include people who know good UCD
      techniques, it tends to build tools that the team *thinks* are cool
      and usable - for themselves. Thus my fear of tools by engineers for
      engineers.

      My challenge is to 1) train folks how to do UCD - with agility, 2)
      bring in resources that have those skills to apply on those projects,
      and 3) continue to promote true understanding of our customers, users,
      and stakeholders across the whole organization.

      Concretely, this is what I am striving for on these pilots:
      - put UI guidelines in place to cover the basics + domain-specific
      challenging areas
      - put people on SCRUMs with UI skills, directly working in the sprints
      - feed the backlog with user studies such as contextual inquiry
      providing good user stories and context (parallel to the sprints)
      - evaluate the outputs of the sprints using usability techniques
      (cognitive walk-throughs, formative usability testing, and the
      occasional heuristic review); the outputs of the evaluations also feed
      the backlog

      Any comments or recommendations on that basic strategy?

      --- In agile-usability@yahoogroups.com, William Pietri <william@...>
      > > I don't want agile to lead us to building yet more "tools
      > > built by engineers for engineers" that have poor usability and end-
      > > user productivity.
      >
      > But if I sit right near the user experts, if I deliver new things a few
      > times a week, and if we release to real users as often as possible,
      then
      > it's much easier for me to keep users foremost in my mind. And not just
      > in my mind: we can keep serving the users as the focus of the project.
      >
      >
      > So welcome, and don't hesitate to ask for advice if things don't feel
      > right to you.
      >
      > 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/
      >
    • 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, 2007
      • 0 Attachment
        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 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?

        regards,
        scott


        ----- 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

        wrote:



        > 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.