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

Re: [agile-usability] A crash course on Agile programming / organization?

Expand Messages
  • Julian Boot
    Petteri, it sounds like usability is important to you. It sounds like its not as important in the developers eyes. This is a common type of problem. What is
    Message 1 of 19 , Sep 8, 2004
      Petteri, it sounds like usability is important to you. It sounds like
      its not as important in the developers eyes. This is a common type of
      problem.

      What is the real priority of usability for the project? Is your value
      for usability shared by the whole team? Is it shared by the sponsor
      for the project? If there is not a common understanding of what's
      important on the project, individuals have a tendency to focus on
      their own tasks and treat them as holy.

      Usability can be considered a type of quality. And on all projects
      competes with time, budget and scope for attention. If you are
      representing the sponsor's value of usability, then you should try and
      get him or her to share their priorities with the rest of the team.

      A Big Visible Chart on the wall that says

      1. Time
      2. Usability
      3. Features
      4. Budget

      might be one way to go. Just having a disucssion with the team and
      the sponsor about what tradeoffs can be made that would lead to a
      successful project/product would be good as well.

      -J




      ----- Original Message -----
      From: Petteri Hiisilä <petteri.hiisila@...>
      Date: Fri, 03 Sep 2004 14:05:28 +0300
      Subject: [agile-usability] A crash course on Agile programming / organization?
      To: agile-usability@yahoogroups.com

      Hugh Beyer wrote:


      From: Dave Cronin [mailto:dave@...]
      Sent: Wednesday, September 01, 2004 7:04 PM
      To: agile-usability@yahoogroups.com
      Subject: RE: [agile-usability] Re: [XP] XP and Big Interaction DesignUpFront

      Yeah, I meant those examples as anecdotal, not necessarily universal. I
      entirely agree that it depends a lot on the complexity of the project
      and the skill level of the developer as to how much work can effectively
      be done before the initial requirements are defined.

      I am certainly not opposed in theory to development getting work done in
      parallel. What I have had difficulty with in the past is work getting
      done which precludes us from doing the right thing with the product
      design.

      And yes, it doesn't take a rocket-scientist to figure out that if you're
      building a Web application that you can get to work on your login and
      sessioning model, and if you know what you're doing, odds are your work
      will be able to accommodate whatever the interaction model is agreed to
      be best. (Especially if you're an agile developer who doesn't mind
      re-writing a little code;)

      And this may well be the key. If your development team is telling you
      they can't do what you want because they've locked in the architecture
      they ain't agile, and all the pair programming in the world won't
      make them so.
      Dear Hugh & the rest,

      In our organization the code and technical architecture gets a "holy"
      status pretty quickly. It's not that I ask our developers to change it
      often. I do it very rarely, and for very good reasons. Like once or
      twice in a year or something.

      But since the code is holy, they generally refuse to "refactor" it,
      and I have to spend a lot of time and nerves convincing them with with
      n+1 reasons why this really is important. If there's a smallest hole
      in my arguments, they won't change anything, and I'll have to try to
      put some "lipstick on the pig" to have at least some usability.
      Developers end up happy, but end users don't, and the lost sales
      almost always happens.

      "The holy code effect" usually happens, when I'm called in too late,
      when the coding has already been started, but they lack a common goal
      and need me to give them focus and stable requirements.

      Our organization isn't agile. It is ... what's the opposite of agile?-)

      If an agile team doesn't build this kind of automatic psychological
      stone-wall against any code changes, I want to work with a team like
      that.

      How can I get them to be one? Or is it even possible?

      Could someone recommend me a crash-course book or website into the
      world of agile programming or agile organization? I'm open for
      information now :)

      Peace and love,
      Petteri

      --
      Petteri Hiisilä
      Palveluarkkitehti / Interaction Designer /
      Alma Media Interactive Oy / NWS /
      +358505050123 / petteri.hiisila@...

      "I know what I believe. I will continue to believe
      what I believe and what I believe - I believe what
      I believe is right."

      - George W. Bush



      Yahoo! Groups Sponsor


      ________________________________
      Yahoo! Groups Links

      To visit your group on the web, go to:
      http://groups.yahoo.com/group/agile-usability/

      To unsubscribe from this group, send an email to:
      agile-usability-unsubscribe@yahoogroups.com

      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



      --
      julian boot
      jules8007 at pobox.com
    • William Pietri
      ... That could be part of the problem. People generally optimize for things that happen frequently. Of course, if you just ask them arbitrarily to change
      Message 2 of 19 , Sep 8, 2004
        On Fri, 2004-09-03 at 04:05, Petteri Hiisilä wrote:
        > In our organization the code and technical architecture gets a "holy"
        > status pretty quickly. It's not that I ask our developers to change it
        > often. I do it very rarely, and for very good reasons. Like once or
        > twice in a year or something.

        That could be part of the problem. People generally optimize for things
        that happen frequently.

        Of course, if you just ask them arbitrarily to change things more often,
        they'll just get mad at you. Instead, you could find a reason why
        changing things frequently is necessary. E.g.,

        * You have to do user testing each week, and want to put that
        knowledge to work immediately.
        * You need to respond to the competition frequently.
        * You want to keep ahead of the competition, forcing them to
        respond to you.
        * The sooner you get the first version out the door, the sooner
        revenue comes in, so you must do monthly releases.
        * You are doing something very innovative, and need to try lots of
        small experiments to find out what works in the real world.

        It's best to pick some reason that's in line with a recent problem or a
        corporate goal, so that everybody recognizes the necessity and
        management will help push.

        > Developers end up happy, but end users don't, and the lost sales
        > almost always happens.

        It's good to investigate why resisting change makes these developers
        happy. As Alain pointed out, it could be because they don't know how to
        make it easy to make changes. Good tests are a huge help, and modern
        development tools (including easy code navigation, good VCS integration,
        and automated refactoring) are also important.

        Another possibility is that they don't have any understanding of or
        reason to care about the users. I've seen way too many organizations
        where developers never meet end users, never see their work being used,
        and never deal with the consequences of shoddy workmanship. Good
        solutions to this problem include:

        * Show developers video highlights of usability studies.
        * Let developers observe actual use.
        * Get developers and users together in a casual setting (e.g.,
        over drinks).
        * Get developers using the product themselves.
        * Have developers conduct surveys of users.
        * Make sure developers stick with the same chunk of code for a
        couple of releases.
        * Make developers do tech support from time to time.

        If, instead of just hearing it from you, the developers can see for
        themselves that there's a usability problem, getting them to accept
        change will be much easier.


        > If an agile team doesn't build this kind of automatic psychological
        > stone-wall against any code changes, I want to work with a team like
        > that.

        Yeah, my experience is that product designers really come to love it. On
        my main project right now the product designer frequently makes minor
        improvements to the UI, generally a month or two after we built it the
        first time. At first he was really hestitant; he was afraid we'd yell at
        him. But 80% of the time the answer is, "Yes, right away!" The rest of
        the time we say, "Yes, but it will cost you N points."

        Either way, we developers have faith that he's making the best choices
        he knows how, and he's confident that we're building a great product the
        fastest way we can think of. The fact that we are always finding ways to
        improve things isn't a problem, it's a source of satisfaction.

        William
      • Petteri Hiisilä
        Great answer William. Thanks! I ll be thinking about this for a while. Actually I already did. Here it comes. ... Were in a middle of a change towards
        Message 3 of 19 , Sep 9, 2004
          Great answer William. Thanks! I'll be thinking about this for a while. Actually I already did. Here it comes.

          :)

          Were in a middle of a change towards goal-directed development. An agile development would be a very good complement.

          I'd see my dream role like this:

          1. I'd start by doing the basic research stuff. As quickly as possible. From a few days (simple consumer product) to a few weeks for an enterprise application. This is indispensable to be sure, that our product vision is the right one, plus to get insight into real user problems and goals. That is, to get rid of guesswork on human needs. (The developers do their basic research during these days/weeks.)

          2. I create a stable UI framework, on which "user stories" are easy to build on for the rest of the project. No need to change that later. That's a blueprint (bitmap), not code. (The developers create their basic technical architecture drawings, or whatever medium they want to use during these days.)

          3. I'll be the "customer representative" of the team. But I don't give just story cards. I give bitmap-based prototypes of the next things that we should build. Or a white board drawing. Or a story. The medium can well be a card. That way they can be sorted together.

          4. The team will sort the story cards in such a way, that we get maximum user benefit with minimum coding effort. That's a ratio that can be "calculated" together with ID and developer insight.

          5. While the developers code and the testers test, I'll be preparing cards for next week's meeting! And also work with developers to solve practical UI issues, that didn't come up in the meeting.

          --> In this method the customer can still accept the results in, say, a weekly meetings, but we don't have to ask her to be a part of something, that she might not be comfortable with.

          --> We don't lose time. We still get the benefits of Agile development, while significantly raising the changes of success with real end users.

          --> The customer can control more projects at the same time and get more done. And do more business, and be happier.

          Now, what's better than that!-)

          Criticism, questions and modifications welcome.

           - Petteri

          -- 
          Petteri Hiisilä
          Palveluarkkitehti / Interaction Designer /
          Alma Media Interactive Oy / NWS /
          +358505050123 / petteri.hiisila@...

          "The unbroken spirit
          Obscured and disquiet
          Finds clearness this trial demands"
           - Dream Theater

          William Petri wrote:
          On Fri, 2004-09-03 at 04:05, Petteri Hiisilä wrote:
          > In our organization the code and technical architecture gets a "holy"
          > status pretty quickly. It's not that I ask our developers to change it
          > often. I do it very rarely, and for very good reasons. Like once or
          > twice in a year or something.

          That could be part of the problem. People generally optimize for things
          that happen frequently.

          Of course, if you just ask them arbitrarily to change things more often,
          they'll just get mad at you. Instead, you could find a reason why
          changing things frequently is necessary. E.g.,

                * You have to do user testing each week, and want to put that
                  knowledge to work immediately.
                * You need to respond to the competition frequently.
                * You want to keep ahead of the competition, forcing them to
                  respond to you.
                * The sooner you get the first version out the door, the sooner
                  revenue comes in, so you must do monthly releases.
                * You are doing something very innovative, and need to try lots of
                  small experiments to find out what works in the real world.

          It's best to pick some reason that's in line with a recent problem or a
          corporate goal, so that everybody recognizes the necessity and
          management will help push.

          > Developers end up happy, but end users don't, and the lost sales
          > almost always happens.

          It's good to investigate why resisting change makes these developers
          happy. As Alain pointed out, it could be because they don't know how to
          make it easy to make changes. Good tests are a huge help, and modern
          development tools (including easy code navigation, good VCS integration,
          and automated refactoring) are also important.

          Another possibility is that they don't have any understanding of or
          reason to care about the users. I've seen way too many organizations
          where developers never meet end users, never see their work being used,
          and never deal with the consequences of shoddy workmanship. Good
          solutions to this problem include:

                * Show developers video highlights of usability studies.
                * Let developers observe actual use.
                * Get developers and users together in a casual setting (e.g.,
                  over drinks).
                * Get developers using the product themselves.
                * Have developers conduct surveys of users.
                * Make sure developers stick with the same chunk of code for a
                  couple of releases.
                * Make developers do tech support from time to time.

          If, instead of just hearing it from you, the developers can see for
          themselves that there's a usability problem, getting them to accept
          change will be much easier.


          > If an agile team doesn't build this kind of automatic psychological
          > stone-wall against any code changes, I want to work with a team like
          > that.

          Yeah, my experience is that product designers really come to love it. On
          my main project right now the product designer frequently makes minor
          improvements to the UI, generally a month or two after we built it the
          first time. At first he was really hestitant; he was afraid we'd yell at
          him. But 80% of the time the answer is, "Yes, right away!"  The rest of
          the time we say, "Yes, but it will cost you N points."

          Either way, we developers have faith that he's making the best choices
          he knows how, and he's confident that we're building a great product the
          fastest way we can think of. The fact that we are always finding ways to
          improve things isn't a problem, it's a source of satisfaction.

          William




        • Hal Taylor
          I m jumping in mid-thread here, so forgive me if I ve missed context... William makes some excellent points here. I would add only: - you say you only make
          Message 4 of 19 , Sep 9, 2004
            I'm jumping in mid-thread here, so forgive me if I've missed context...

            William makes some excellent points here. I would add only:

            - you say you only make change requests once or twice a year; does
            that mean that they've amassed six months of code at the point that
            they're getting this feedback? Code tends to develop a lot of inertia.
            One thing that agile processes and usability would seem to have in
            common is a recognition of this factor, and the desire to influence a
            project in the early stages. If you involve usability/product design
            feedback early on, you're (more) likely to avoid having to make
            changes later, when they're more difficult.

            What sort of development process is presently in place? What do you do
            for prototyping, interface/interaction review and iteration? I think
            the (typically) iterative nature of agile processes should lend itself
            well to incorporation of feedback from prototypes.

            - Hal

            On Fri, 2004-09-03 at 04:05, Petteri Hiisilä wrote:
            > In our organization the code and technical architecture gets a "holy"
            > status pretty quickly. It's not that I ask our developers to change it
            > often. I do it very rarely, and for very good reasons. Like once or
            > twice in a year or something.
          • Petteri Hiisilä
            Yeah, I d like to see a project manager or a product manager take care of stuff like this. Too often I m the only one who has any major interest about user
            Message 5 of 19 , Sep 10, 2004
              Yeah,

              I'd like to see a project manager or a product manager take care of stuff like this. Too often I'm the only one who has any major interest about user satisfaction. It takes a business stakeholder to decide, what's important. I've got my own work to do. Running upstream is a huge turnoff for my ability to design.

              But many of the managers don't even see that huge lost opportunity. Feature-driven product is so much weaker to competition, than a goal-driven product.

              I believe that every IT manager in the world should understand this. Otherwise they might up walking blind for the rest of their career, while the competition keeps their eyes open and passes into distance.

              Understand what? Why high tech products drive us (people) crazy and how to restore the sanity.
              http://www.amazon.com/exec/obidos/tg/detail/-/0672326140/qid=1094820864/sr=8-1/ref=pd_cps_1/104-8498455-7665502?v=glance&s=books&n=507846

               - Petteri

              -- 
              Petteri Hiisilä
              Palveluarkkitehti / Interaction Designer /
              Alma Media Interactive Oy / NWS /
              +358505050123 / petteri.hiisila@...

              "I was told there's a miracle for each day that I try"
               - John Petrucci



              Julian Boot wrote:
              Petteri, it sounds like usability is important to you.  It sounds like
              its not as important in the developers eyes.  This is a common type of
              problem.

              What is the real priority of usability for the project?  Is your value
              for usability shared by the whole team?  Is it shared by the sponsor
              for the project?  If there is not a common understanding of what's
              important on the project, individuals have a tendency to focus on
              their own tasks and treat them as holy.

              Usability can be considered a type of quality.  And on all projects
              competes with time,  budget and scope for attention.  If you are
              representing the sponsor's value of usability, then you should try and
              get him or her to share their priorities with the rest of the team.

              A Big Visible Chart on the wall that says

              1. Time
              2. Usability
              3. Features
              4. Budget

              might be one way to go.  Just having a disucssion with the team and
              the sponsor about what tradeoffs can be made that would lead to a
              successful project/product would be good as well.

              -J




              ----- Original Message -----
              From: Petteri Hiisilä <petteri.hiisila@...>
              Date: Fri, 03 Sep 2004 14:05:28 +0300
              Subject: [agile-usability] A crash course on Agile programming / organization?
              To: agile-usability@yahoogroups.com

              Hugh Beyer wrote:


              From: Dave Cronin [mailto:dave@...]
              Sent: Wednesday, September 01, 2004 7:04 PM
              To: agile-usability@yahoogroups.com
              Subject: RE: [agile-usability] Re: [XP] XP and Big Interaction DesignUpFront

              Yeah, I meant those examples as anecdotal, not necessarily universal. I
              entirely agree that it depends a lot on the complexity of the project
              and the skill level of the developer as to how much work can effectively
              be done before the initial requirements are defined.

              I am certainly not opposed in theory to development getting work done in
              parallel. What I have had difficulty with in the past is work getting
              done which precludes us from doing the right thing with the product
              design.

              And yes, it doesn't take a rocket-scientist to figure out that if you're
              building a Web application that you can get to work on your login and
              sessioning model, and if you know what you're doing, odds are your work
              will be able to accommodate whatever the interaction model is agreed to
              be best. (Especially if you're an agile developer who doesn't mind
              re-writing a little code;) 
               
              And this may well be the key. If your development team is telling you
              they can't do what you want because they've locked in the architecture
              they ain't agile, and all the pair programming in the  world won't
              make them so.
                Dear Hugh & the rest,

              In our organization the code and technical architecture gets a "holy"
              status pretty quickly. It's not that I ask our developers to change it
              often. I do it very rarely, and for very good reasons. Like once or
              twice in a year or something.

              But since the code is holy, they generally refuse to "refactor" it,
              and I have to spend a lot of time and nerves convincing them with with
              n+1 reasons why this really is important. If there's a smallest hole
              in my arguments, they won't change anything, and I'll have to try to
              put some "lipstick on the pig" to have at least some usability.
              Developers end up happy, but end users don't, and the lost sales
              almost always happens.

              "The holy code effect" usually happens, when I'm called in too late,
              when the coding has already been started, but they lack a common goal
              and need me to give them focus and stable requirements.

              Our organization isn't agile. It is ... what's the opposite of agile?-)

              If an agile team doesn't build this kind of automatic psychological
              stone-wall against any code changes, I want to work with a team like
              that.

              How can I get them to be one? Or is it even possible?

              Could someone recommend me a crash-course book or website into the
              world of agile programming or agile organization? I'm open for
              information now :)

              Peace and love,
              Petteri

              --
              Petteri Hiisilä
              Palveluarkkitehti / Interaction Designer /
              Alma Media Interactive Oy / NWS /
              +358505050123 / petteri.hiisila@...

              "I know what I believe. I will continue to believe
              what I believe and what I believe - I believe what
              I believe is right."

              - George W. Bush



              Yahoo! Groups Sponsor


              ________________________________
              Yahoo! Groups Links

              To visit your group on the web, go to:
              http://groups.yahoo.com/group/agile-usability/
               
              To unsubscribe from this group, send an email to:
              agile-usability-unsubscribe@yahoogroups.com
               
              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



              --
              julian boot
              jules8007 at pobox.com




              -- 
              Petteri Hiisilä
              Palveluarkkitehti / Interaction Designer /
              Alma Media Interactive Oy / NWS /
              +358505050123 / petteri.hiisila@...
              
              "I was told there's a miracle for each day that I try"
               - John Petrucci
              
              
            • Chris Pehura
              To get things to become important to people usually involves selling yourself in the process. When you re excited about it, that usually rubs off on the
              Message 6 of 19 , Sep 10, 2004
                To get things to become important to people usually involves selling yourself in the process. When you're excited about it, that usually rubs off on the decision makers. But this sort of thing takes a lot of mental and emotional investment, especially when you're swimming up stream. Does eventual work if your excitement is genuine.
                 
                 -----Original Message-----
                From: Petteri Hiisilä [mailto:petteri.hiisila@...]
                Sent: Friday, September 10, 2004 8:02 AM
                To: agile-usability@yahoogroups.com
                Subject: Re: [agile-usability] A crash course on Agile programming / organization?

                Yeah,

                I'd like to see a project manager or a product manager take care of stuff like this. Too often I'm the only one who has any major interest about user satisfaction. It takes a business stakeholder to decide, what's important. I've got my own work to do. Running upstream is a huge turnoff for my ability to design.

                But many of the managers don't even see that huge lost opportunity. Feature-driven product is so much weaker to competition, than a goal-driven product.

                I believe that every IT manager in the world should understand this. Otherwise they might up walking blind for the rest of their career, while the competition keeps their eyes open and passes into distance.

                Understand what? Why high tech products drive us (people) crazy and how to restore the sanity.
                http://www.amazon.com/exec/obidos/tg/detail/-/0672326140/qid=1094820864/sr=8-1/ref=pd_cps_1/104-8498455-7665502?v=glance&s=books&n=507846

                 - Petteri

                -- 
                Petteri Hiisilä
                Palveluarkkitehti / Interaction Designer /
                Alma Media Interactive Oy / NWS /
                +358505050123 / petteri.hiisila@...

                "I was told there's a miracle for each day that I try"
                 - John Petrucci



                Julian Boot wrote:
                Petteri, it sounds like usability is important to you.  It sounds like
                its not as important in the developers eyes.  This is a common type of
                problem.

                What is the real priority of usability for the project?  Is your value
                for usability shared by the whole team?  Is it shared by the sponsor
                for the project?  If there is not a common understanding of what's
                important on the project, individuals have a tendency to focus on
                their own tasks and treat them as holy.

                Usability can be considered a type of quality.  And on all projects
                competes with time,  budget and scope for attention.  If you are
                representing the sponsor's value of usability, then you should try and
                get him or her to share their priorities with the rest of the team.

                A Big Visible Chart on the wall that says

                1. Time
                2. Usability
                3. Features
                4. Budget

                might be one way to go.  Just having a disucssion with the team and
                the sponsor about what tradeoffs can be made that would lead to a
                successful project/product would be good as well.

                -J




                ----- Original Message -----
                From: Petteri Hiisilä <petteri.hiisila@...>
                Date: Fri, 03 Sep 2004 14:05:28 +0300
                Subject: [agile-usability] A crash course on Agile programming / organization?
                To: agile-usability@yahoogroups.com

                Hugh Beyer wrote:


                From: Dave Cronin [mailto:dave@...]
                Sent: Wednesday, September 01, 2004 7:04 PM
                To: agile-usability@yahoogroups.com
                Subject: RE: [agile-usability] Re: [XP] XP and Big Interaction DesignUpFront

                Yeah, I meant those examples as anecdotal, not necessarily universal. I
                entirely agree that it depends a lot on the complexity of the project
                and the skill level of the developer as to how much work can effectively
                be done before the initial requirements are defined.

                I am certainly not opposed in theory to development getting work done in
                parallel. What I have had difficulty with in the past is work getting
                done which precludes us from doing the right thing with the product
                design.

                And yes, it doesn't take a rocket-scientist to figure out that if you're
                building a Web application that you can get to work on your login and
                sessioning model, and if you know what you're doing, odds are your work
                will be able to accommodate whatever the interaction model is agreed to
                be best. (Especially if you're an agile developer who doesn't mind
                re-writing a little code;) 
                 
                And this may well be the key. If your development team is telling you
                they can't do what you want because they've locked in the architecture
                they ain't agile, and all the pair programming in the  world won't
                make them so.
                  Dear Hugh & the rest,

                In our organization the code and technical architecture gets a "holy"
                status pretty quickly. It's not that I ask our developers to change it
                often. I do it very rarely, and for very good reasons. Like once or
                twice in a year or something.

                But since the code is holy, they generally refuse to "refactor" it,
                and I have to spend a lot of time and nerves convincing them with with
                n+1 reasons why this really is important. If there's a smallest hole
                in my arguments, they won't change anything, and I'll have to try to
                put some "lipstick on the pig" to have at least some usability.
                Developers end up happy, but end users don't, and the lost sales
                almost always happens.

                "The holy code effect" usually happens, when I'm called in too late,
                when the coding has already been started, but they lack a common goal
                and need me to give them focus and stable requirements.

                Our organization isn't agile. It is ... what's the opposite of agile?-)

                If an agile team doesn't build this kind of automatic psychological
                stone-wall against any code changes, I want to work with a team like
                that.

                How can I get them to be one? Or is it even possible?

                Could someone recommend me a crash-course book or website into the
                world of agile programming or agile organization? I'm open for
                information now :)

                Peace and love,
                Petteri

                --
                Petteri Hiisilä
                Palveluarkkitehti / Interaction Designer /
                Alma Media Interactive Oy / NWS /
                +358505050123 / petteri.hiisila@...

                "I know what I believe. I will continue to believe
                what I believe and what I believe - I believe what
                I believe is right."

                - George W. Bush



                Yahoo! Groups Sponsor


                ________________________________
                Yahoo! Groups Links

                To visit your group on the web, go to:
                http://groups.yahoo.com/group/agile-usability/
                 
                To unsubscribe from this group, send an email to:
                agile-usability-unsubscribe@yahoogroups.com
                 
                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



                --
                julian boot
                jules8007 at pobox.com




                -- 
                Petteri Hiisilä
                Palveluarkkitehti / Interaction Designer /
                Alma Media Interactive Oy / NWS /
                +358505050123 / petteri.hiisila@...
                
                "I was told there's a miracle for each day that I try"
                 - John Petrucci
                
                

              • Jeff Patton
                ... a holy ... it ... and ... n+1 ... my ... some ... end up ... happens. ... late, ... goal ... agile?-) Rigid. Unadaptaple. Unflexible. ... like that.
                Message 7 of 19 , Sep 10, 2004
                  --- In agile-usability@yahoogroups.com, Petteri Hiisilä
                  <petteri.hiisila@a...> wrote:
                  > In our organization the code and technical architecture gets
                  a "holy"
                  > status pretty quickly. It's not that I ask our developers to change
                  it
                  > often. I do it very rarely, and for very good reasons. Like once or
                  > twice in a year or something.
                  >
                  > But since the code is holy, they generally refuse to "refactor" it,
                  and
                  > I have to spend a lot of time and nerves convincing them with with
                  n+1
                  > reasons why this really is important. If there's a smallest hole in
                  my
                  > arguments, they won't change anything, and I'll have to try to put
                  some
                  > "lipstick on the pig" to have at least some usability. Developers
                  end up
                  > happy, but end users don't, and the lost sales almost always
                  happens.
                  >
                  > "The holy code effect" usually happens, when I'm called in too
                  late,
                  > when the coding has already been started, but they lack a common
                  goal
                  > and need me to give them focus and stable requirements.
                  >
                  > Our organization isn't agile. It is ... what's the opposite of
                  agile?-)

                  Rigid. Unadaptaple. Unflexible.

                  >
                  > If an agile team doesn't build this kind of automatic psychological
                  > stone-wall against any code changes, I want to work with a team
                  like that.
                  >
                  > How can I get them to be one? Or is it even possible?

                  I've been out of touch for a few weeks and catching up on posts.
                  This one stopped me. I can see there's lots of responses, so I
                  suspect I'm repeating what others might have already said. But, this
                  is a really cool note. I find myself in the odd place of agreeing
                  with the points of view of folks like Petteri and simultaneously
                  agreeing with folks like Ron Jeffries. Both sides of this discussion
                  have a huge amount to offer each other. I believe it's safe to say
                  that both misunderstand each others points of view - at least a
                  little. And that both lack common vocabulary to find the huge common
                  ground they're standing on.

                  I'm in sitting this evening at a conference for Patterns people
                  called PLoP. The conference is filled with rocket-science-smart
                  people. 8 feet from me drinking red wine is Ward Cunningham - the
                  inventor of the Wiki. Wednesday I was listening to hardcore patterns
                  people explain to me how the context of the pattern needs to be
                  squarely targeted at the audience the pattern serves. -That to write
                  an effective pattern you need to know a lot about the person who will
                  read it and how you expect them to use it. For the user centered
                  designers, this may sound like a pretty familiar point of view.

                  I think think the agile development community and interaction
                  designers share goals. I'm not always so sure that the rank and file
                  development community share those same goals. [I could be wrong.] I
                  responded to this message because I think Petteri in his message
                  figured out at least one difference between agile and other
                  developers. That's pretty neat.

                  Thanks everyone for participating in this list.

                  -Jeff
                • William Pietri
                  ... I m glad you found it useful. ... Ok! Bear in mind that my comments below imagine that you have some good agile developers involved, at least to start the
                  Message 8 of 19 , Sep 10, 2004
                    On Thu, 2004-09-09 at 01:38, Petteri Hiisilä wrote:
                    > Great answer William. Thanks! I'll be thinking about this for a while.

                    I'm glad you found it useful.

                    > Actually I already did. Here it comes.

                    Ok! Bear in mind that my comments below imagine that you have some good
                    agile developers involved, at least to start the team. But generally, it
                    sounds like what you describe is what user-focused agile shops are
                    already doing.

                    > 1. I'd start by doing the basic research stuff. As quickly as
                    > possible. From a few days (simple consumer product) to a few weeks for
                    > an enterprise application. This is indispensable to be sure, that our
                    > product vision is the right one, plus to get insight into real user
                    > problems and goals. That is, to get rid of guesswork on human needs.
                    > (The developers do their basic research during these days/weeks.)

                    This seems like a reasonable research period, but I wouldn't even bring
                    the developers in until you're mostly past this stage. Then as soon as
                    you can find a week's worth of development, I'd pull in exactly two
                    developers and get them started.

                    That can come before much in the way of UI is designed. Stories like
                    "Guest views home page," or "User installs application," will trigger a
                    lot of infrastructural work. While developers are futzing with their
                    machines, setting up appropriate servers, and picking third-party
                    packages (e.g., servlet containers, web servers, build tools,
                    installers, version control systems, et cetera and ad nauseam), you'll
                    have time for more research.

                    > 2. I create a stable UI framework, on which "user stories" are easy to
                    > build on for the rest of the project. No need to change that later.
                    > That's a blueprint (bitmap), not code.

                    With an agile team, you'll have an opportunity to see how much of this
                    work, normally done in a lump, you can leave 'til later. I expect you'll
                    be pleasantly surprised.

                    But I agree that before doing too much UI work, it's worth writing out
                    all the story cards you can think of, prioritizing them, and then having
                    a notion of how the broad strokes of the UI architecture will go.

                    > (The developers create their basic technical architecture drawings, or
                    > whatever medium they want to use during these days.)

                    > 3. I'll be the "customer representative" of the team. But I don't give
                    > just story cards. I give bitmap-based prototypes of the next things
                    > that we should build. Or a white board drawing. Or a story. The medium
                    > can well be a card. That way they can be sorted together.

                    FYI, a story card is just a token that represents further communication.
                    All of my story cards have 8 words or less, and most of them are 5 or
                    less. All of them have a subject (one of our identified roles) and a
                    verb. One way to think of them is as the leaf bullet points in a product
                    plan.

                    My typical process is that once we get to a story card, unless the UI is
                    obvious, we sketch out an interface in the most convenient medium.
                    Whether that's HTML, whiteboard, paper prototype, Photoshop file, or
                    simple handwaving depends mainly on whatever adequately communicates
                    enough information. One problem I encounter with professional UI
                    designers as customers is that they often want to make the communication
                    prettier than it needs to be to get the point across.

                    > 4. The team will sort the story cards in such a way, that we get
                    > maximum user benefit with minimum coding effort. That's a ratio that
                    > can be "calculated" together with ID and developer insight.

                    Yes. As you probably know by now from an XP book, the XP approach is for
                    the developers to estimate the cards and for the customer to sort them.
                    The criterion is not always user benefit, though; for companies it's
                    more often revenue maximization. Generally these are aligned, but not
                    always. For example, there are many people who would benefit from a
                    swift kick, but few of them are willing to pay for it.

                    > 5. While the developers code and the testers test, I'll be preparing
                    > cards for next week's meeting! And also work with developers to solve
                    > practical UI issues, that didn't come up in the meeting.

                    Yes. If your product is UI-focused, it's best to have at least one
                    programmer with strong UI skills, both in the coding sense and the
                    usability sense. That will let you focus more on the big product
                    picture, so that developers don't have to bug you about what to you will
                    feel like niggling details.

                    William
                  • Ron Jeffries
                    ... I ve noticed that ... :) Ron Jeffries www.XProgramming.com Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head. It is, as
                    Message 9 of 19 , Sep 10, 2004
                      On Saturday, September 11, 2004, at 12:03:48 AM, William Pietri wrote:

                      > For example, there are many people who would benefit from a
                      > swift kick, but few of them are willing to pay for it.

                      I've noticed that ... :)

                      Ron Jeffries
                      www.XProgramming.com
                      Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
                      of his head. It is, as far as he knows, the only way of coming downstairs,
                      but sometimes he feels that there really is another way, if only he could
                      stop bumping for a moment and think of it. And then he feels that perhaps
                      there isn't. -- A. A. Milne
                    • Dale Emery
                      Hi Chris, ... I ve found that #1 is usually enough to motivate a team. I ve helped dozens of teams diagram what they re currently doing. Every time, before
                      Message 10 of 19 , Sep 14, 2004
                        Hi Chris,

                        > Steps I do to establish buy in for workflow changes are
                        > 1. formalize the current workflow (usually use diagrams
                        > dependent on what the team considers useful)
                        > 2. establish metrics for each activity for each component
                        > (based on historic numbers)
                        > 3. make it very visible to the team, and keep asking for
                        > feedback
                        > 4. ask for team's permission to make it visible to their
                        > direct manager, and keep asking for permission right up the
                        > food chain.

                        I've found that #1 is usually enough to motivate a team. I've
                        helped dozens of teams diagram what they're currently doing.
                        Every time, before they've described much of what they're doing,
                        the team sees lots of ways to make improvements. Simply
                        describing the current process /as a team/ makes certain kinds of
                        flaws so glaringly obvious that the team wants to jump
                        immediately into fixing them. The motivation to change the
                        process is usually so strong that it's a struggle to finish
                        describing the current way.

                        Dale

                        --
                        Dale Emery, Consultant
                        Collaborative Leadership for Software People
                        Web: http://www.dhemery.com
                        Weblog: http://www.dhemery.com/cwd

                        The most serious charge which can be brought against New England
                        is not Puritanism but February. --Joseph Wood Krutch
                      • Mike Dwyer
                        Dale; I have found that Mary Poppendeck s book Lean Manufacturing has several great ways to not only map the team, but also map the entire Agile Food Chain.
                        Message 11 of 19 , Sep 14, 2004

                          Dale;

                          I have found that Mary Poppendeck’s book “Lean Manufacturing” has several great ways to not only map the team, but also map the entire Agile Food Chain.  People (team members, leadership, management, as well as administration) buy in because it is so transparent.  It is also a good starting point for budget and Sprint planning, as it makes visible the functional value of many ‘non functional’ tasks that can be hard to move up in priority and funding.

                           

                          -----------------------------------------

                          Mike Dwyer

                          Program Manager – Information Technology

                          American Healthways

                          -----Original Message-----
                          From: Dale Emery [mailto:dale@...]
                          Sent:
                          Tuesday, September 14, 2004 4:20 AM
                          To: agile-usability@yahoogroups.com
                          Subject: Re: [agile-usability] A crash course on Agile programming / organization?

                           

                          Hi Chris,

                          > Steps I do to establish buy in for workflow changes are
                          > 1. formalize the current workflow (usually use diagrams
                          > dependent on what the team considers useful)
                          > 2. establish metrics for each activity for each component
                          > (based on historic numbers)
                          > 3. make it very visible to the team, and keep asking for
                          > feedback
                          > 4. ask for team's permission to make it visible to their
                          > direct manager, and keep asking for permission right up the
                          > food chain.

                          I've found that #1 is usually enough to motivate a team.  I've
                          helped dozens of teams diagram what they're currently doing.
                          Every time, before they've described much of what they're doing,
                          the team sees lots of ways to make improvements.  Simply
                          describing the current process /as a team/ makes certain kinds of
                          flaws so glaringly obvious that the team wants to jump
                          immediately into fixing them.  The motivation to change the
                          process is usually so strong that it's a struggle to finish
                          describing the current way.

                          Dale

                          --
                          Dale Emery, Consultant
                          Collaborative Leadership for Software People
                          Web:    http://www.dhemery.com
                          Weblog: http://www.dhemery.com/cwd

                          The most serious charge which can be brought against New England
                          is not Puritanism but February. --Joseph Wood Krutch



                        • Chris Pehura
                          Dale Agreed, had some of those positive experiences myself. Step 1 is only needed. Also worked with teams that were very adversarial. (One experience is easily
                          Message 12 of 19 , Sep 14, 2004
                            Dale
                             
                            Agreed, had some of those positive experiences myself. Step 1 is only needed.
                            Also worked with teams that were very adversarial.
                            (One experience is easily comparable to a bunch of hungry dogs going for a single bone.)
                            For teams like that, and others with heavy political undertoe, I use the other steps.
                             
                            Chris
                            -----Original Message-----
                            From: Dale Emery [mailto:dale@...]
                            Sent: Tuesday, September 14, 2004 3:20 AM
                            To: agile-usability@yahoogroups.com
                            Subject: Re: [agile-usability] A crash course on Agile programming / organization?

                            Hi Chris,

                            > Steps I do to establish buy in for workflow changes are
                            > 1. formalize the current workflow (usually use diagrams
                            > dependent on what the team considers useful)
                            > 2. establish metrics for each activity for each component
                            > (based on historic numbers)
                            > 3. make it very visible to the team, and keep asking for
                            > feedback
                            > 4. ask for team's permission to make it visible to their
                            > direct manager, and keep asking for permission right up the
                            > food chain.

                            I've found that #1 is usually enough to motivate a team.  I've
                            helped dozens of teams diagram what they're currently doing.
                            Every time, before they've described much of what they're doing,
                            the team sees lots of ways to make improvements.  Simply
                            describing the current process /as a team/ makes certain kinds of
                            flaws so glaringly obvious that the team wants to jump
                            immediately into fixing them.  The motivation to change the
                            process is usually so strong that it's a struggle to finish
                            describing the current way.

                            Dale

                            --
                            Dale Emery, Consultant
                            Collaborative Leadership for Software People
                            Web:    http://www.dhemery.com
                            Weblog: http://www.dhemery.com/cwd

                            The most serious charge which can be brought against New England
                            is not Puritanism but February. --Joseph Wood Krutch


                          • Chris Pehura
                            One time there was this project always missing it s deadlines. Reason was no visibility for all tasks and activities. They would make visible bug fixes, but
                            Message 13 of 19 , Sep 14, 2004
                              One time there was this project always missing it's deadlines. Reason was no visibility for all tasks and activities. They would make visible bug fixes, but not maintenance to cleanup architecture. Once all tasks were made transparent, the deadlines were adjusted and easily met.
                               
                              This all started a few years back when the execs questioned the department "it was already built, why are you building it again?". Rather than answering the question, the department hid activities.
                              -----Original Message-----
                              From: Mike Dwyer [mailto:mdwyer@...]
                              Sent: Tuesday, September 14, 2004 7:48 AM
                              To: agile-usability@yahoogroups.com
                              Subject: RE: [agile-usability] A crash course on Agile programming / organization?

                              Dale;

                              I have found that Mary Poppendeck’s book “Lean Manufacturing” has several great ways to not only map the team, but also map the entire Agile Food Chain.  People (team members, leadership, management, as well as administration) buy in because it is so transparent.  It is also a good starting point for budget and Sprint planning, as it makes visible the functional value of many ‘non functional’ tasks that can be hard to move up in priority and funding.

                               

                              -----------------------------------------

                              Mike Dwyer

                              Program Manager – Information Technology

                              American Healthways

                              -----Original Message-----
                              From: Dale Emery [mailto:dale@...]
                              Sent:
                              Tuesday, September 14, 2004 4:20 AM
                              To: agile-usability@yahoogroups.com
                              Subject: Re: [agile-usability] A crash course on Agile programming / organization?

                               

                              Hi Chris,

                              > Steps I do to establish buy in for workflow changes are
                              > 1. formalize the current workflow (usually use diagrams
                              > dependent on what the team considers useful)
                              > 2. establish metrics for each activity for each component
                              > (based on historic numbers)
                              > 3. make it very visible to the team, and keep asking for
                              > feedback
                              > 4. ask for team's permission to make it visible to their
                              > direct manager, and keep asking for permission right up the
                              > food chain.

                              I've found that #1 is usually enough to motivate a team.  I've
                              helped dozens of teams diagram what they're currently doing.
                              Every time, before they've described much of what they're doing,
                              the team sees lots of ways to make improvements.  Simply
                              describing the current process /as a team/ makes certain kinds of
                              flaws so glaringly obvious that the team wants to jump
                              immediately into fixing them.  The motivation to change the
                              process is usually so strong that it's a struggle to finish
                              describing the current way.

                              Dale

                              --
                              Dale Emery, Consultant
                              Collaborative Leadership for Software People
                              Web:    http://www.dhemery.com
                              Weblog: http://www.dhemery.com/cwd

                              The most serious charge which can be brought against New England
                              is not Puritanism but February. --Joseph Wood Krutch




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