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

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

Expand Messages
  • 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 1 of 13 , Jun 1, 2001
    • 0 Attachment
      --- 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 2 of 13 , Jun 1, 2001
      • 0 Attachment
        --- 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 3 of 13 , Jun 2, 2001
        • 0 Attachment
          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 4 of 13 , Jun 2, 2001
          • 0 Attachment
            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 5 of 13 , Jun 2, 2001
            • 0 Attachment
              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 6 of 13 , Jun 2, 2001
              • 0 Attachment
                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 7 of 13 , Jun 2, 2001
                • 0 Attachment
                  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 8 of 13 , Jun 2, 2001
                  • 0 Attachment
                    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 9 of 13 , Jun 2, 2001
                    • 0 Attachment
                      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 10 of 13 , Jun 3, 2001
                      • 0 Attachment
                        ----- 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 11 of 13 , Jun 11, 2001
                        • 0 Attachment
                          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 12 of 13 , Jun 11, 2001
                          • 0 Attachment
                            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.