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

Agile & User Experience: What are the common denominators?

Expand Messages
  • Dave Robertson
    Hello! First - apologies for cross postings to SIGIA and IxD ... My name is Dave Robertson, and although you can t see him, this is my partner, John (JJ)
    Message 1 of 9 , Dec 16, 2008
    • 0 Attachment

      Hello!

      First - apologies for cross postings to SIGIA and IxD ...

      My name is Dave Robertson, and although you can't see him, this is my partner, John (JJ) Johnston. We've been asked to deliver a presentation for friends of ThoughtWorks Canada in January (to which all of you are welcome to come, but more later). JJ is an agile guy who's interested in user experience and I'm the user experience guy who's interested in Agile.

       
      We've decided to make an argument that Agile and UX share a number of common values and that these values should form a foundation for better integration (rather than simply trying to mash together our respective techniques or chucking rocks at opposing sides).  

      Since we were approached in October, there's been a lot of fresh discussion about "agilux" here and on other lists.  Nielsen/Norman Group delivered their opinion on the topic and Cennydd Bowles made his call for a common future for the Agile and UX communities. But, as always, we still see emails on mailing lists asking questions like "How do we mash these things together?",  "Should we mash these things together?" and, most importantly - "How do we make this work better!?". It struck us that you might have an opinion about common values, so as part of our presentation, we'd like to hear and summarize this community's feelings about our theory, good or bad.

      To (hopefully) start the discussion, here are three questions:

      1. What role do you play in your projects? Is it as an analyst, a project manager, a developer, a designer, a researcher or something else?

      2. What "things" - goals, objectives, values, attitudes, philosophies - are most important to you when you do your job?

      3. If you've been engaged in projects that have been heavily influenced by agile and /or user experience, how has it influenced what you value in your work?

      Sincerest thanks!

      Dave & JJ


      Dave Robertson
      Principal Consultant, User Experience
      ThoughtWorks Canada
      Phone: 403.614.7946
      Yahoo! IM: dar_calgary@...

      Twitter: shoveller

      PS: Here are some details about that presentation. Feel welcome to register if you're planning to be in Toronto on January 20th or Calgary on January 22nd.

      http://www.thoughtworks.com/what-we-say/events/tech-briefing_ca.html  
    • George Dinwiddie
      Hi, Dave and John, I ve recently written a longer-winded reply at http://blog.gdinwiddie.com/2008/11/28/agile-usability/ and
      Message 2 of 9 , Dec 17, 2008
      • 0 Attachment
        Hi, Dave and John,

        I've recently written a longer-winded reply at
        http://blog.gdinwiddie.com/2008/11/28/agile-usability/ and
        http://blog.gdinwiddie.com/2008/12/08/more-on-agile-usability/

        Answers to your questions inline below:

        Dave Robertson wrote:
        >
        > To (hopefully) start the discussion, here are three questions:
        >
        > 1. What role do you play in your projects? Is it as an analyst, a
        > project manager, a developer, a designer, a researcher or something else?

        I'm an agile software development coach.

        > 2. What "things" - goals, objectives, values, attitudes, philosophies -
        > are most important to you when you do your job?

        Effectiveness is my goal. I help teams become more effective at
        creating valuable systems, with "valuable" defined by the organization
        producing the system. The tool I use most to enhance effectiveness is
        feedback--constant and pervasive feedback at all levels of the endeavor.
        This, to me, is the root of Agile development.

        > 3. If you've been engaged in projects that have been heavily influenced
        > by agile and /or user experience, how has it influenced what you value
        > in your work?

        I come from a software development background and I've worked with
        organizations that have a lot invested (time, manpower, money) in user
        experience work. I have seen dedicated user-experience departments
        assume that their role is to produce paper prototypes that then "just
        need to be implemented."

        Unfortunately, this is a lot like architects that don't code. They then
        lock themselves out of the numerous opportunities for feedback to help
        shape the code, and the user experience, to reach the best outcome.

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Dave Robertson
        Good morning, George Thanks for your response and for the additional reading. Just so that I m clear, are you suggesting that your primary impression of the UX
        Message 3 of 9 , Dec 18, 2008
        • 0 Attachment
          Good morning, George

          Thanks for your response and for the additional reading. Just so that
          I'm clear, are you suggesting that your primary impression of the UX
          practitioners that you work with is that they're not really properly
          invested in the development process?

          If so, what do they need to change about the way they work?

          Thanks!

          Dave


          > > 3. If you've been engaged in projects that have been heavily
          influenced
          > > by agile and /or user experience, how has it influenced what you
          value
          > > in your work?
          >
          > I come from a software development background and I've worked with
          > organizations that have a lot invested (time, manpower, money) in user
          > experience work. I have seen dedicated user-experience departments
          > assume that their role is to produce paper prototypes that then "just
          > need to be implemented."
          >
          > Unfortunately, this is a lot like architects that don't code. They
          then
          > lock themselves out of the numerous opportunities for feedback to help
          > shape the code, and the user experience, to reach the best outcome.
          >
          > - George
          >
          > --
          > ----------------------------------------------------------------------
          > * George Dinwiddie * http://blog.gdinwiddie.com
          > Software Development http://www.idiacomputing.com
          > Consultant and Coach http://www.agilemaryland.org
          > ----------------------------------------------------------------------
          >
        • George Dinwiddie
          ... Well, we re still experimenting with that. It would be nice it they were not a completely separate department from the software development. Changing this
          Message 4 of 9 , Dec 18, 2008
          • 0 Attachment
            Dave Robertson wrote:
            > Good morning, George
            >
            > Thanks for your response and for the additional reading. Just so that
            > I'm clear, are you suggesting that your primary impression of the UX
            > practitioners that you work with is that they're not really properly
            > invested in the development process?
            >
            > If so, what do they need to change about the way they work?

            Well, we're still experimenting with that.

            It would be nice it they were not a completely separate department from
            the software development. Changing this will, of course, take a very
            long time. There are only a few Agile teams in a very large, mostly
            "waterfall," mostly siloed organization.

            The good news is that one or more UX people get assigned to each Agile
            team. They have been extremely engaged in the process. They actively
            want to work well in that environment.

            The bad news is that there is plenty of room to get better. They still
            spend huge amounts of time creating Photoshop wireframes. Perhaps these
            are necessary for discussions within the UX department, but it's a lot
            more detail than generally needed by the developers. And while the UX
            folk doing all of this work to communicate the visual design to the
            developers, they're neglecting to convey the /concept/ behind the visual
            representation.

            And the unwarranted precision leads the developers astray. (Though
            perhaps they would go astray, anyway.) They spend a lot of time trying
            to exactly duplicate the wireframe in HTML/CSS/Javascript for all
            supported browsers. In doing so, they create very fragile code that
            frequently breaks when something else is modified. Or when a different
            browser is used.

            The wireframes frequently don't indicate how some exceptional condition
            is represented. The UX people are getting better and working this out
            in discussion with the developers, rather than going off and generating
            new wireframes.

            Sometimes the wireframes indicate things that are less than good for the
            user experience, like a button that triggers a popup if it shouldn't be
            pressed. This has since been changed, but was originally implemented
            and released this way because someone in UX had approved this design and
            the UX person on the team didn't have the authority to override that.

            Some of the things being specified are quite easy to generate in
            Photoshop, but very difficult to generate in HTML/CSS/Javascript for a
            wide variety of browsers. I feel certain that a user experience could
            be designed that is just as useful to the user, but much quicker and
            cheaper to implement. The visual designs are done without that
            feedback, however. (This is reminiscent of architectural designs
            specified by architects that don't code.)

            The developers are not a part of the user experience testing, either of
            Photoshop mockups prior to development or the application after
            development. They're not forbidden, but it's not brought to them. They
            would have to go well out of their way to get that information. And
            they generally don't, since they have release deadlines to meet. So
            that information generally only reaches the development room after much
            discussion in the UX department resulting in new wireframes.

            As you can see, there's much room for better collaboration between the
            UX people and the developers. It will take much time for people to
            learn how to accomplish that, and get used to it. And it proceeds
            slowly, in part, because they're so happy that things are working much
            better now than they have in the past. They don't yet see the remaining
            waste and how much better it /could/ be.

            - George

            P.S. I hope that you'll record the presentation.

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Dmitry Nekrasovski
            I don t have much to add to this discussion, except that pretty much all the UX-development collaboration challenges described by George apply in my
            Message 5 of 9 , Dec 19, 2008
            • 0 Attachment
              I don't have much to add to this discussion, except that pretty much
              all the UX-development collaboration challenges described by George
              apply in my organization as well. I would venture to guess that they
              are endemic to large organizations where UX and development are siloed
              and where both are still trying to "figure out this Agile thing".

              @George: I would be very interested to hear what strategies you use to
              deal with these (seemingly systemic) challenges.

              Dmitry

              On Fri, Dec 19, 2008 at 12:58 AM, George Dinwiddie
              <lists@...> wrote:
              > Dave Robertson wrote:
              >
              > Well, we're still experimenting with that.
              >
              > It would be nice it they were not a completely separate department from
              > the software development. Changing this will, of course, take a very
              > long time. There are only a few Agile teams in a very large, mostly
              > "waterfall," mostly siloed organization.
              >
              > The good news is that one or more UX people get assigned to each Agile
              > team. They have been extremely engaged in the process. They actively
              > want to work well in that environment.
              >
              > The bad news is that there is plenty of room to get better. They still
              > spend huge amounts of time creating Photoshop wireframes. Perhaps these
              > are necessary for discussions within the UX department, but it's a lot
              > more detail than generally needed by the developers. And while the UX
              > folk doing all of this work to communicate the visual design to the
              > developers, they're neglecting to convey the /concept/ behind the visual
              > representation.
              >
              > And the unwarranted precision leads the developers astray. (Though
              > perhaps they would go astray, anyway.) They spend a lot of time trying
              > to exactly duplicate the wireframe in HTML/CSS/Javascript for all
              > supported browsers. In doing so, they create very fragile code that
              > frequently breaks when something else is modified. Or when a different
              > browser is used.
              >
              > The wireframes frequently don't indicate how some exceptional condition
              > is represented. The UX people are getting better and working this out
              > in discussion with the developers, rather than going off and generating
              > new wireframes.
              >
              > Sometimes the wireframes indicate things that are less than good for the
              > user experience, like a button that triggers a popup if it shouldn't be
              > pressed. This has since been changed, but was originally implemented
              > and released this way because someone in UX had approved this design and
              > the UX person on the team didn't have the authority to override that.
              >
              > Some of the things being specified are quite easy to generate in
              > Photoshop, but very difficult to generate in HTML/CSS/Javascript for a
              > wide variety of browsers. I feel certain that a user experience could
              > be designed that is just as useful to the user, but much quicker and
              > cheaper to implement. The visual designs are done without that
              > feedback, however. (This is reminiscent of architectural designs
              > specified by architects that don't code.)
              >
              > The developers are not a part of the user experience testing, either of
              > Photoshop mockups prior to development or the application after
              > development. They're not forbidden, but it's not brought to them. They
              > would have to go well out of their way to get that information. And
              > they generally don't, since they have release deadlines to meet. So
              > that information generally only reaches the development room after much
              > discussion in the UX department resulting in new wireframes.
              >
              > As you can see, there's much room for better collaboration between the
              > UX people and the developers. It will take much time for people to
              > learn how to accomplish that, and get used to it. And it proceeds
              > slowly, in part, because they're so happy that things are working much
              > better now than they have in the past. They don't yet see the remaining
              > waste and how much better it /could/ be.
              >
              > - George
              >
              > P.S. I hope that you'll record the presentation.
              >
              > --
              > ----------------------------------------------------------
              > * George Dinwiddie * http://blog.gdinwiddie.com
              > Software Development http://www.idiacomputing.com
              > Consultant and Coach http://www.agilemaryland.org
              > ----------------------------------------------------------
              >
              >
            • George Dinwiddie
              ... Hi, Dmitry, Having a UX person in the room with the Product Owner (team, in this case), developers, and testers goes a LONG way to improving the situation.
              Message 6 of 9 , Dec 19, 2008
              • 0 Attachment
                Dmitry Nekrasovski wrote:
                > @George: I would be very interested to hear what strategies you use to
                > deal with these (seemingly systemic) challenges.

                Hi, Dmitry,

                Having a UX person in the room with the Product Owner (team, in this
                case), developers, and testers goes a LONG way to improving the
                situation. This enables lots of conversations. Another important point
                is that everybody on the team genuinely wants to do a good job and
                produce the best possible outcome.

                There are times when the UX person pairs with a developer working on the
                UI. Even when they don't, the developer will often ask a question about
                the UI design of a feature. We have the wireframes, and the stories
                described in Mingle, but these are treated as secondary to conversations
                with the PO and UX person. (Mingle, itself, is treated as secondary to
                the card wall.)

                - George

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • Cindy Lu
                George and Dmitry, It s very interesting to read your comments regarding the design process. I can understand your frustration. I have found it is more
                Message 7 of 9 , Dec 20, 2008
                • 0 Attachment
                  George and Dmitry,

                  It s very interesting to read your comments regarding the design process.  I can understand your frustration.

                  I have found it is more effective if you (or whoever wants to make the change) take initiatives and baby steps to make changes even though there is no agile process formally in place.  

                  In my organization, we use wiki to share the work including work scope, personas, scenarios, etc. We (user experience designers) create simple key user stories before we design.  We then review them with the entire team.  We use the stories to help the team to understand the work scope. We then do the conceptual design.  We post the design to wiki daily so everyone can comment on it.  We revise the design very often and very quickly.  By the time we finalize the design, the development team has reviewed it multiple times and has done the basic work for development. We share all the info with the dev team, including feedback from clients, end users, and business need changes, etc.  This process is not created by the organization.  It is initiated by our team and implemented project by project over time.  

                  If I were you, I would work with the project manager to set up working sessions with the user experience design and BA team.  I would review every BA documents and ask for design updates.  I would review them and provide constructive feedback.  Everyone wants to deliver quality work for your customers and end users.  You can only do this by working together.  

                  - Cindy


                  From: George Dinwiddie <lists@...>
                  To: agile-usability@yahoogroups.com
                  Sent: Friday, December 19, 2008 5:39:55 PM
                  Subject: Re: [agile-usability] Re: Agile & User Experience: What are the common denominators?

                  Dmitry Nekrasovski wrote:

                  > @George: I would be very interested to hear what strategies you use to
                  > deal with these (seemingly systemic) challenges.

                  Hi, Dmitry,

                  Having a UX person in the room with the Product Owner (team, in this
                  case), developers, and testers goes a LONG way to improving the
                  situation. This enables lots of conversations. Another important point
                  is that everybody on the team genuinely wants to do a good job and
                  produce the best possible outcome.

                  There are times when the UX person pairs with a developer working on the
                  UI. Even when they don't, the developer will often ask a question about
                  the UI design of a feature. We have the wireframes, and the stories
                  described in Mingle, but these are treated as secondary to conversations
                  with the PO and UX person. (Mingle, itself, is treated as secondary to
                  the card wall.)

                  - George

                  --
                  ------------ --------- --------- --------- --------- --------- -
                  * George Dinwiddie * http://blog. gdinwiddie. com
                  Software Development http://www.idiacomp uting.com
                  Consultant and Coach http://www.agilemar yland.org
                  ------------ --------- --------- --------- --------- --------- -


                • George Dinwiddie
                  Hi, Cindy, ... I m not sure that frustration describes my emotions. I m really excited to be working with UX people so amenable to working with an Agile
                  Message 8 of 9 , Dec 20, 2008
                  • 0 Attachment
                    Hi, Cindy,

                    Cindy Lu wrote:
                    > It s very interesting to read your comments regarding the design
                    > process. I can understand your frustration.

                    I'm not sure that frustration describes my emotions. I'm really excited
                    to be working with UX people so amenable to working with an Agile
                    software development team. This is still territory that is largely
                    uncharted, however. It's easy for me to see some things that are
                    sub-optimal. It is interesting to me, as a coach, to find ways to help
                    the participants, UX and Dev alike, work more collaboratively and
                    effectively.

                    > I have found it is more effective if you (or whoever wants to make the
                    > change) take initiatives and baby steps to make changes even though
                    > there is no agile process formally in place.

                    Yes, always a good approach to change. It takes time.

                    > In my organization, we use wiki to share the work including work scope,
                    > personas, scenarios, etc. We (user experience designers) create simple
                    > key user stories before we design. We then review them with the entire
                    > team. We use the stories to help the team to understand the work scope.
                    > We then do the conceptual design. We post the design to wiki daily so
                    > everyone can comment on it. We revise the design very often and very
                    > quickly. By the time we finalize the design, the development team has
                    > reviewed it multiple times and has done the basic work for development.
                    > We share all the info with the dev team, including feedback from
                    > clients, end users, and business need changes, etc. This process is not
                    > created by the organization. It is initiated by our team and
                    > implemented project by project over time.

                    That sounds like a wonderful initiative. Let me play devil's advocate a
                    bit, though. Why a wiki? Doesn't that require the developers (and
                    other interested parties) to check it to see if things have changed?
                    And aren't the developers mostly focused on writing some software at the
                    time? Is it easy for them to take the time away from their coding to
                    review the wiki for changes, and to write comments? How easy is it for
                    the developers to see just what's changed? Do they not get tired of
                    trying to discern the differences? While this helps you get "your work"
                    done, doesn't it detract from "their work?"

                    How much do you learn about their implementation via this mechanism? Do
                    you check the source code repository to see what changes are made in the
                    code with respect to the visual design? Do you alter your visual design
                    based on the difficulty or cost of implementing it? If so, is it based
                    on the perceived cost by a developer who thinks he'll be implementing it
                    in the future, or the cost actually being experienced by a developer
                    who's currently implementing it?

                    What is the amount of time between a design first being posted on the
                    wiki and a developer starting to implement it? Does the design continue
                    to be refined after the development starts on that piece? How long does
                    it take (shortest, average, and longest times) for the design on the
                    wiki to change in response to a comment left there?

                    I know this is a deluge of questions, and some are probably
                    unanswerable. Many probably seem like they are leading and unfair.
                    While they're meant to be provocative, they're not intended to be
                    accusatory. I'd be very interested in any answers you might have for
                    these questions. This /is/ an area that needs further exploration.

                    I'm sure that setting up the wiki has been beneficial to your
                    organization, but it still seems less than ideal, to me. It's primarily
                    one-way. It requires the developers to go out of their way to aid the
                    UX design, but not the UX designers to go out of their way to aid the
                    implementation. And it depends on written descriptions to communicate
                    back and forth--wouldn't it be faster to have a conversation? Wouldn't
                    misinterpretations get discovered and cleared up more easily in a
                    face-to-face interchange?

                    > If I were you, I would work with the project manager to set up working
                    > sessions with the user experience design and BA team. I would review
                    > every BA documents and ask for design updates. I would review them and
                    > provide constructive feedback. Everyone wants to deliver quality work
                    > for your customers and end users. You can only do this by working
                    > together.

                    We do better than set up working sessions. We expect the UX people to
                    generally be in the team room, along with the other Product Owner
                    proxies and the developers.

                    The BAs no longer produce large documents. They keep their notes on
                    each user story in Mingle, and can explain them (well, usually) to the
                    developers when asked. The UX people tack their wireframes up on the
                    wall. When a developer starts working on a screen, they can explain
                    them (well, usually), too.

                    The wireframes, though, are a bit like the long documents that the BAs
                    no longer produce. They take a lot of time, and they require a lot of
                    explanation to be complete and understood correctly. I think they serve
                    more purpose within the UX department than they do within the team room.

                    - George

                    --
                    ----------------------------------------------------------------------
                    * George Dinwiddie * http://blog.gdinwiddie.com
                    Software Development http://www.idiacomputing.com
                    Consultant and Coach http://www.agilemaryland.org
                    ----------------------------------------------------------------------
                  • William Pietri
                    ... I can t emphasize enough how much this has helped a number of my clients. A common behavior I see now, one I think is key making this work smoothly, is
                    Message 9 of 9 , Dec 23, 2008
                    • 0 Attachment
                      George Dinwiddie wrote:
                      > We do better than set up working sessions. We expect the UX people to
                      > generally be in the team room, along with the other Product Owner
                      > proxies and the developers.
                      >

                      I can't emphasize enough how much this has helped a number of my clients.

                      A common behavior I see now, one I think is key making this work
                      smoothly, is what one client has called "pixel pushing": Developers get
                      something to the 80% visually correct level on their own, often getting
                      feedback from designers along the way. Then, a developer and a designer
                      sit down to pair to implement the fine details of the design jointly.
                      They fluidly make a great number of small cost/benefit tradeoffs to find
                      approaches that are optimal not just for designers or developers alone,
                      but for them jointly.

                      William
                    Your message has been successfully submitted and would be delivered to recipients shortly.