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

RE: [XP] XP and radical GUI change (UCD revisited)

Expand Messages
  • Blum, Robert
    ... [snip-a-lot] ... It is , in a way, the customer s problem, yes. But remember the developers are there to advise him. It is the developers job to _interact_
    Message 1 of 13 , Jun 1, 2001
      > From: azami@... [mailto:azami@...]
      [snip-a-lot]
      > So, how _does_ XP deal with this? I've done a story, then another
      > story, and so on, and now this dialog is overloaded so I
      > split it into
      > tabs, yada, yada, yada, and the UI just keeps getting more complex,
      > when maybe it would be simpler if the dialog didn't exist at all.
      >
      > Who identifies this as a problem? Who looks for a solution?
      > Where is
      > the UI redesign decision made, and where is it designed?
      >
      > I'm inclined to say it's the customer's problem and not addressed by
      > XP.

      It is , in a way, the customer's problem, yes. But remember the developers
      are there to advise him. It is the developers job to _interact_ with the
      customer. That interaction has to start before a story is even created. If I
      as a developer see a new story, I'll bring it up to the customer.

      It's up to him to include it in the story list - but now he knows about it.

      > To prevent this, the customer ought to be (or retain) a
      > top-notch UI designer.

      Or you need one on the development team. Or you bring in a consultant from
      time to time.

      > But I still worry that in this regard XP may
      > lose sight of the forest for the trees - the customer says
      > "make these
      > screens load faster", and we do so without encouragement to ask, "are
      > these screens really even needed?"

      'Courage' is the key word here. The developers have the right to question
      _any_ technical decision. 'Make this faster' is pretty technical already.

      If you allow developers to question _any_ story if they have a valid reason,
      you might see even more improvements. XP assumes that developers are purely
      technical, and customers are purely business. Mostly, that is _not_ the
      case. So I think it would be good to allow people to contribute to the other
      party's work. Just make sure they cannot make decisions for the other side.

      > My fear is that the things that make radical code redesign possible -
      > simplicity, refactoring, pairing, etc - are less available and less
      > helpful when it comes to radical UI redesign. In code, developers
      > just notice and say, "hey, the design would be a lot simpler
      > this way"
      > and do it. Is there some equivalent for "hey, the UI would be a lot
      > simpler this way"?

      Yep. You just notice and bring it up with the customer. The difference to
      code is that changing the UI actually incurs cost on the business side.
      (People have to relearn)

      Plus, it's hard to have a functionality-preserving refactoring of a U/I. So
      there's more impact on the business side.

      IMHO, the U/I is 'between' business and development. Both sides should know
      it and care about it.

      One way around this is to just expose all the business logic through some
      sort of interface. The customer then is responsible for getting somebody to
      do a U/I that has _no_ business logic whatsoever. Shallow. In XP terms,
      'could not possibly break'.

      Whatever approach you take, there's always the same underlying assumption. A
      U/I is fundamentally different from 'code'. This means it might need a
      different process. Maybe XP is not even applicable. (Heresy!) (Nota bene:
      The XP _values_ are still applicable. Just not the process)

      Bye,
      Robert
    • carrie@sextant.com
      ... Having both teams responsible for looking out for rational UI design ideas certainly makes sense, but it seems that this review might happen rather
      Message 2 of 13 , Jun 1, 2001
        --- In extremeprogramming@y..., "Blum, Robert" <rblum@m...> wrote:
        Having both teams responsible for looking out for rational UI design
        ideas certainly makes sense, but it seems that this review might
        happen rather haphazardly in some situations. In addition to having
        versatile programming & customer teams (and sometimes instead of),
        it's been my experience that it's a good idea to have at least one
        person who is responsible for doing periodic reviews of design &
        process flow-- this person should be extremely open to input from
        both teams as well as re-evaluating the design ideas herself on a
        regular basis. In our case, this person is the Project Manager,
        however I could see this being a senior designer as well.

        This person identifies potential issues, comes up with a possible
        solution, and also goes to the team to see if others have solutions
        as well. With a small team (yay, XP!), this sort of back-and-forth
        communication and idea-sharing is actually possible. However, having
        one person responsible for asking the questions (or bringing others'
        questions out in the open) is an important first step in this process.

        > > From: azami@s... [mailto:azami@s...]
        > [snip-a-lot]
        > > So, how _does_ XP deal with this? I've done a story, then
        another
        > > story, and so on, and now this dialog is overloaded so I
        > > split it into
        > > tabs, yada, yada, yada, and the UI just keeps getting more
        complex,
        > > when maybe it would be simpler if the dialog didn't exist at all.
        > >
        > > Who identifies this as a problem? Who looks for a solution?
        > > Where is
        > > the UI redesign decision made, and where is it designed?
        > >
        > > I'm inclined to say it's the customer's problem and not addressed
        by
        > > XP.
        >
        > It is , in a way, the customer's problem, yes. But remember the
        developers
        > are there to advise him. It is the developers job to _interact_
        with the
        > customer. That interaction has to start before a story is even
        created. If I
        > as a developer see a new story, I'll bring it up to the customer.
        >
        > It's up to him to include it in the story list - but now he knows
        about it.
        >
        > > To prevent this, the customer ought to be (or retain) a
        > > top-notch UI designer.
        >
        > Or you need one on the development team. Or you bring in a
        consultant from
        > time to time.
        >
        > > But I still worry that in this regard XP may
        > > lose sight of the forest for the trees - the customer says
        > > "make these
        > > screens load faster", and we do so without encouragement to
        ask, "are
        > > these screens really even needed?"
        >
        > 'Courage' is the key word here. The developers have the right to
        question
        > _any_ technical decision. 'Make this faster' is pretty technical
        already.
        >
        > If you allow developers to question _any_ story if they have a
        valid reason,
        > you might see even more improvements. XP assumes that developers
        are purely
        > technical, and customers are purely business. Mostly, that is _not_
        the
        > case. So I think it would be good to allow people to contribute to
        the other
        > party's work. Just make sure they cannot make decisions for the
        other side.
        >
        > > My fear is that the things that make radical code redesign
        possible -
        > > simplicity, refactoring, pairing, etc - are less available and
        less
        > > helpful when it comes to radical UI redesign. In code,
        developers
        > > just notice and say, "hey, the design would be a lot simpler
        > > this way"
        > > and do it. Is there some equivalent for "hey, the UI would be a
        lot
        > > simpler this way"?
        >
        > Yep. You just notice and bring it up with the customer. The
        difference to
        > code is that changing the UI actually incurs cost on the business
        side.
        > (People have to relearn)
        >
        > Plus, it's hard to have a functionality-preserving refactoring of a
        U/I. So
        > there's more impact on the business side.
        >
        > IMHO, the U/I is 'between' business and development. Both sides
        should know
        > it and care about it.
        >
        > One way around this is to just expose all the business logic
        through some
        > sort of interface. The customer then is responsible for getting
        somebody to
        > do a U/I that has _no_ business logic whatsoever. Shallow. In XP
        terms,
        > 'could not possibly break'.
        >
        > Whatever approach you take, there's always the same underlying
        assumption. A
        > U/I is fundamentally different from 'code'. This means it might
        need a
        > different process. Maybe XP is not even applicable. (Heresy!) (Nota
        bene:
        > The XP _values_ are still applicable. Just not the process)
        >
        > Bye,
        > Robert
      • dmitry@yahoo.com
        ... having ... others ... process. As I understand it, on an XP team the above-mentioned things are generally the responsibility of the coach. XPE talks about
        Message 3 of 13 , Jun 1, 2001
          --- In extremeprogramming@y..., carrie@s... wrote:
          > This person identifies potential issues, comes up with a possible
          > solution, and also goes to the team to see if others have solutions
          > as well. With a small team (yay, XP!), this sort of back-and-forth
          > communication and idea-sharing is actually possible. However,
          having
          > one person responsible for asking the questions (or bringing
          others'
          > questions out in the open) is an important first step in this
          process.

          As I understand it, on an XP team the above-mentioned things are
          generally the responsibility of the coach. XPE talks about the coach
          seeing long-term refactoring goals and communicating them to the
          team, so perhaps the same could be true for long-term UI design goals.

          Dmitry
        • Ron Jeffries
          ... Many, perhaps most XP teams work without a coach. (I think this is risky, because XP is less obvious than it seems, but still it happens.) Many other teams
          Message 4 of 13 , Jun 2, 2001
            Responding to dmitry@... (01:33 AM 6/2/2001 +0000):
            > > From carrie ...
            > > This person identifies potential issues, comes up with a possible
            > > solution, and also goes to the team to see if others have solutions
            > > as well. With a small team (yay, XP!), this sort of back-and-forth
            > > communication and idea-sharing is actually possible. However,
            >< having one person responsible for asking the questions (or bringing
            > > others' questions out in the open) is an important first step in this
            > > process.
            >
            >As I understand it, on an XP team the above-mentioned things are
            >generally the responsibility of the coach. XPE talks about the coach
            >seeing long-term refactoring goals and communicating them to the
            >team, so perhaps the same could be true for long-term UI design goals.

            Many, perhaps most XP teams work without a coach. (I think this is risky,
            because XP is less obvious than it seems, but still it happens.)

            Many other teams just designate someone as coach. (This, too, is risky,
            since the individual is coaching a game s/he has never played, but still it
            happens.)

            The ultimate responsibility is that everyone on the team must raise
            whatever issues they see. And everyone on the team must see to it that
            issues get raised and that they will be listened to openly, however and
            whenever they are raised.

            The coach, if you have a good and experienced one, often does raise issues
            that s/he sees or that s/he has heard "on the grapevine", but this is just
            an aid. The team needs to agree early on that they all tell the truth as
            they see it, that fear can be discussed, and that open discussion of how to
            improve their process is an ongoing and desirable activity.

            The values of Communication and Feedback are at the core here. A team
            cannot improve without feedback, not all of which will be pleasant to hear.
            And to get that feedback will require communication, which is just as much
            about hearing as it is about talking.

            So it's not just up to the coach. It is up to management, and to every team
            member, both to speak the truth, and to make it possible for everyone's
            truth to be heard, even when it may be expressed in less than perfect
            ways. Yes, the coach can help. But it's everyone's job, from day one, to
            speak the truth, and to welcome it in all its forms.

            Regards,

            Ronald E Jeffries
            http://www.XProgramming.com
            http://www.objectmentor.com
          • Brad Appleton
            What to people consider the difference to be between coaching vs mentoring? What behaviors and responsibilities are different for a coach than for a mentor?
            Message 5 of 13 , Jun 2, 2001
              What to people consider the difference to be between coaching
              vs mentoring? What behaviors and responsibilities are different
              for a coach than for a mentor? Which ones are the same?

              --
              Brad Appleton <bradapp@...> http://www.bradapp.net/
              "And miles to go before I sleep." -- Robert Frost
            • Gareth Reeves
              How about this... A coach has a stake in the team or project, he or she is as much accountable for the success of the project as anyone else (and maybe even
              Message 6 of 13 , Jun 2, 2001
                How about this...

                A coach has a stake in the team or project, he or she is as much accountable
                for the success of the project as anyone else (and maybe even more so). A
                mentor is someone who is there to teach.

                I dont know... its just the first thing that came into my head. Merriam
                Webster gives Coach as a synonym of Mentor.

                Gareth
              • Brad Appleton
                ... The above would suggest to me that it is presumed that the Coach is part of the team but the mentor is not. Lets assume I m talking about someone that is a
                Message 7 of 13 , Jun 2, 2001
                  On Sat, Jun 02, 2001 at 12:35:35PM -0500, Gareth Reeves wrote:
                  > A coach has a stake in the team or project, he or she is as much accountable
                  > for the success of the project as anyone else (and maybe even more so). A
                  > mentor is someone who is there to teach.

                  The above would suggest to me that it is presumed that the
                  Coach is part of the team but the mentor is not. Lets assume
                  I'm talking about someone that is a member of the team, and
                  is in a leadership position. And suppose they want to make a
                  deliberate choice as to their primary leadership style between
                  coach versus mentor. (So there should be no implied difference
                  in that persons "stake" or "accountability" based upon their
                  leadership style. They will have the exact same amount of it
                  either way).

                  Now assuming the above - what is the difference between being
                  a coach versus being a mentor, and what is the same. Try to
                  describe it in terms of outwardly observable behavior, and
                  motivation/intent. Are they both trying to grow something? Are
                  they both trying to grow the same thing? Does one focus more
                  on different things to "grow" than the other?

                  The first thing that pops into my head is that a coach is
                  always associated with a team, and is usually motivated to
                  cultivate teamwork and synergistic collaboration toward an
                  overall end-goal of the team or project.

                  Whereas I tend to think of a mentor as someone more focused
                  on growing skills & knowledge in other individuals, but not
                  necessarily as a collaborative team (more individualized).

                  But that is just me. I want to hear others thoughts!
                  --
                  Brad Appleton <bradapp@...> http://www.bradapp.net/
                  "And miles to go before I sleep." -- Robert Frost
                • Ron Jeffries
                  ... Help me understand the question. If we knew the difference on any given day, and any given event occurred, would our behavior vary depending on which flag
                  Message 8 of 13 , Jun 2, 2001
                    Responding to Brad Appleton (12:16 PM 6/2/2001 -0500):
                    >What to people consider the difference to be between coaching
                    >vs mentoring? What behaviors and responsibilities are different
                    >for a coach than for a mentor? Which ones are the same?

                    Help me understand the question. If we knew the difference on any given
                    day, and any given event occurred, would our behavior vary depending on
                    which flag we were sailing under?

                    Regards,



                    Ronald E Jeffries
                    http://www.XProgramming.com
                    http://www.objectmentor.com
                  • William Wake
                    I think of mentoring as being only one of the things a coach does. If I m trying to teach people to recognize a code smell, or test first, etc. (where I m
                    Message 9 of 13 , Jun 2, 2001
                      I think of mentoring as being only one of the things a coach does.

                      If I'm trying to teach people to recognize a code smell, or test first, etc.
                      (where I'm relatively expert and they're relatively not) I feel like I'm
                      mentoring; I expect them to learn something.

                      But a coach does other things that aren't targeted at teaching. If I see the
                      standup meeting takes too long, and say "let's try to keep it to ten minutes
                      sharp," my primary purpose is to shorten the meetings. Not that I mind if
                      somebody learns something, but that's secondary.

                      --
                      Bill Wake William.Wake@... www.xp123.com

                      _________________________________________________________________
                      Get your FREE download of MSN Explorer at http://explorer.msn.com
                    • Gareth Reeves
                      I agree with you Bill, but this is hard. What happens if the goal of the mentoring is to teach the team that short stand up meetings are better in certain
                      Message 10 of 13 , Jun 2, 2001
                        I agree with you Bill, but this is hard.

                        What happens if the goal of the mentoring is to teach the team that short
                        stand up meetings are better in certain situations. Is it then mentoring or
                        coaching?

                        Gareth
                      • Eric Hodges
                        ... From: Larry Constantine To: Sent: Sunday, June 03, 2001 12:02 AM Subject: RE: [XP] XP
                        Message 11 of 13 , Jun 3, 2001
                          ----- Original Message -----
                          From: "Larry Constantine" <72067.2631@...>
                          To: <extremeprogramming@yahoogroups.com>
                          Sent: Sunday, June 03, 2001 12:02 AM
                          Subject: RE: [XP] XP and radical GUI change (UCD revisited)


                          >
                          > This matter is one of the things separating our approach from many others.
                          > We think programmers can and should learn this stuff and have been
                          teaching
                          > them for years. And, there is still space in our upcoming seminar. :-)

                          Amen and thanks. I was in the audience at a session you did at SD in the
                          mid 90s. At least I think it was you. :-)

                          It got me interested in usage centered design. I read up on it and started
                          doing it at work. It was very educational.

                          Recently I was working on a small app that was allowed to grow organically.
                          The only structure was imposed from code level refactorings, with no attempt
                          to impose order from "above". It turned into a framework for viewing
                          mathematical thingamajigs, and the user interface got very, very busy for a
                          while. I moved the various controls into groups, refactored a bit, found
                          out that a bunch of them were mutually exclusive, put those on tabbed panes,
                          etc. The GUI got small. The options became obvious. The tabbed panes
                          mapped to mathematical thingamajig classes in the model. Not only did the
                          GUI get smaller, the code got smaller.

                          That's a good reason to develop generalists. If you pass projects between
                          programmers and GUI designers I doubt you'll see that sort of feedback.
                        • urs.keller@computer.org
                          Brad, You might like to have a look at the paper Choosing a Consulting Role (see ChoosingAConsultingRole.pdf in the file section. The paper describes nine
                          Message 12 of 13 , Jun 11, 2001
                            Brad,
                            You might like to have a look at the paper "Choosing a Consulting
                            Role" (see ChoosingAConsultingRole.pdf in the file section. The paper
                            describes nine consulting roles. The roles differ in their
                            responsibility for project results and responsibility for client
                            growth.

                            Urs


                            PS: Sorry for the other e-mail.

                            --- In extremeprogramming@y..., Brad Appleton <bradapp@e...> wrote:
                            [snip]
                            > Now assuming the above - what is the difference between being
                            > a coach versus being a mentor, and what is the same. Try to
                            > describe it in terms of outwardly observable behavior, and
                            > motivation/intent. Are they both trying to grow something? Are
                            > they both trying to grow the same thing? Does one focus more
                            > on different things to "grow" than the other?
                            [snip]
                          • urs.keller@computer.org
                            Brad, You might like to have a look at the paper Choosing a Consulting Role (see ChoosingAConsultingRole.pdf in the file section. The paper describes nine
                            Message 13 of 13 , Jun 11, 2001
                              Brad,
                              You might like to have a look at the paper "Choosing a Consulting
                              Role" (see ChoosingAConsultingRole.pdf in the file section. The paper
                              describes nine consulting roles. The roles differ in their
                              responsibility for project results and responsibility for client
                              growth.

                              Urs


                              PS: Sorry for the other e-mail.

                              --- In extremeprogramming@y..., Brad Appleton <bradapp@e...> wrote:
                              [snip]
                              > Now assuming the above - what is the difference between being
                              > a coach versus being a mentor, and what is the same. Try to
                              > describe it in terms of outwardly observable behavior, and
                              > motivation/intent. Are they both trying to grow something? Are
                              > they both trying to grow the same thing? Does one focus more
                              > on different things to "grow" than the other?
                              [snip]
                            Your message has been successfully submitted and would be delivered to recipients shortly.