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

Re: [agile-usability] Help needed - defining software development process - lon

Expand Messages
  • PaulOldfield1@aol.com
    (responding to Esther) ... I m of the opinion that most attempts at agile that fail do so not because the team are not discovering the problems that need
    Message 1 of 8 , Dec 9, 2006
    • 0 Attachment
      (responding to Esther)

       
      > 2. If we could only include one thing from the usability world in
      > our as agile as possible process, what should it be?

      I'm of the opinion that most attempts at agile that fail do so not
      because the team are not discovering the problems that need
      fixing, but because they are unable to make informed decisions
      on what change would be a change for the better.
       
      If one starts off doing XP; that is, doing one's honest best to
      follow all the practices as per the book; this practice set
      already has such a degree of synergy that it is hard to change
      anything without the change being for the worse.
       
      So, the one thing, if you can only choose one thing, would be
      a person who knows what they ought to be doing and why,
      and has had experience in the agile world so knows the
      practices and where they would be appropriate.  If you're
      already reading this list, I doubt that usability will be the
      biggest problem you will have to deal with in getting a new
      process up and running effectively and efficiently.
       
      Paul Oldfield
    • Larry Constantine
      Ron Jeffries has an interview on InfoQ (http://www.infoq.com/interviews/jeffries-running-tested-features) that is nothing short of brilliant in its elegance in
      Message 2 of 8 , Dec 11, 2006
      • 0 Attachment
        Ron Jeffries has an interview on InfoQ
        (http://www.infoq.com/interviews/jeffries-running-tested-features) that is
        nothing short of brilliant in its elegance in making the case for an agile
        development process based on the concept of "running tested features." It is
        so persuasively focused that one can hardly imagine anyone ever doing things
        any other way. (I personally think the visitor comments are overly harsh and
        unappreciative of the intelligence of Ron's restatement.)

        Apropos to this list, Ron's interview made clearer than ever to me what has
        too long been a sort of disconnect between us. In a wonderful bit of verbal
        prestidigitation Ron attributes to the business and product owners the
        ability and responsibility to "know" what features are needed both initially
        and as the software develops. Which, as we know, is precisely the problem.
        To always be able to deliver useful and usable software at every cycle, one
        must know not only what features are actually needed by users but what is
        the minimum set of these to comprise a first delivered working solution.
        Such insight into the support needs for specific roles within actual human
        activities is non-trivial and does not spring Athena-like from the head of
        the local Zeus. If it is to be trusted, it comes from the very research,
        analysis, modeling, and yes, design efforts that are so often dismissed by
        managers (and some methodologists) who want to make programming and testing
        the whole story.

        Anyway, I found myself mentally amending Ron's talk and diagrams to take
        into account what happens when the features that are being correctly
        implemented by an agile process based on "running tested features" but in
        which the features are the wrong ones incorrectly prioritized and
        inappropriately organized because there was no upfront process, agile or
        otherwise, to pin down the nature of genuine user needs within the
        activities to be supported. The developers can still win--they deliver what
        is asked at the pace projected and promised--but the product and project is
        still a failure because of a different form of hidden "negative features,"
        namely all the stuff that is not needed or incomplete or just outright wrong
        from the end-user perspective.

        --Larry Constantine, IDSA
      • Ron Jeffries
        Hello, Larry. On Monday, December 11, 2006, at 5:06:38 PM, you ... Thank you for those very kind words, Larry. I consider praise from you to be high praise
        Message 3 of 8 , Dec 12, 2006
        • 0 Attachment
          Hello, Larry. On Monday, December 11, 2006, at 5:06:38 PM, you
          wrote:

          > Ron Jeffries has an interview on InfoQ
          > (http://www.infoq.com/interviews/jeffries-running-tested-features) that is
          > nothing short of brilliant in its elegance in making the case for an agile
          > development process based on the concept of "running tested features." It is
          > so persuasively focused that one can hardly imagine anyone ever doing things
          > any other way. (I personally think the visitor comments are overly harsh and
          > unappreciative of the intelligence of Ron's restatement.)

          Thank you for those very kind words, Larry. I consider praise from
          you to be high praise indeed.

          > Apropos to this list, Ron's interview made clearer than ever to me what has
          > too long been a sort of disconnect between us. In a wonderful bit of verbal
          > prestidigitation Ron attributes to the business and product owners the
          > ability and responsibility to "know" what features are needed both initially
          > and as the software develops. Which, as we know, is precisely the problem.

          Indeed, it is. Once a team gets to the point where they can deliver
          features more or less at will, it becomes harshly visible that
          "which features" is the real question ... and often a much more
          difficult one than "just" learning how to build software on demand
          that actually works ... though that's difficult enough for me!

          > To always be able to deliver useful and usable software at every cycle, one
          > must know not only what features are actually needed by users but what is
          > the minimum set of these to comprise a first delivered working solution.

          Yes ... though I would say that in general, while we might not be
          able to tell the tens from the nines, and the ones from the twos
          when it comes to feature "value", we can probably tell the big ones
          from the little ones, which means that the product is more likely to
          be "pretty darn good" rather than "really terrible".

          I would also mention that although the final responsibility rests
          with the customer / product owner, the full resources of the team
          are available to help figure out what's important and what's not.
          Though I run into a lot of teams that need improvement -- that is,
          after all, my work -- I haven't ever run into one that was entirely
          clueless. So all I'm saying is that we aren't necessarily doomed.

          > Such insight into the support needs for specific roles within actual human
          > activities is non-trivial and does not spring Athena-like from the head of
          > the local Zeus. If it is to be trusted, it comes from the very research,
          > analysis, modeling, and yes, design efforts that are so often dismissed by
          > managers (and some methodologists) who want to make programming and testing
          > the whole story.

          While doing these things well requires people of skill, I've
          encountered many products that are better than just "good enough",
          so while your remarks here, Larry, are a good case for staffing for
          these skills, and including practices to apply them well ... I'd say
          it's "very valuable" but not "absolutely essential".

          > Anyway, I found myself mentally amending Ron's talk and diagrams to take
          > into account what happens when the features that are being correctly
          > implemented by an agile process based on "running tested features" but in
          > which the features are the wrong ones incorrectly prioritized and
          > inappropriately organized because there was no upfront process, agile or
          > otherwise, to pin down the nature of genuine user needs within the
          > activities to be supported. The developers can still win--they deliver what
          > is asked at the pace projected and promised--but the product and project is
          > still a failure because of a different form of hidden "negative features,"
          > namely all the stuff that is not needed or incomplete or just outright wrong
          > from the end-user perspective.

          I think this is an overly dark view. We see "agile" projects succeed
          all the time, without a high incidence of what you're describing
          here as "failure".

          Of course I could just be lucky ...

          Ron Jeffries
          www.XProgramming.com
          Reason is and ought only to be the slave of the passions. -- David Hume
        • June Kim
          ... Ron, I want to learn the secret for your constant success. Really. I have a kind of sympathy with Larry. I have seen a few teams, which believed they were
          Message 4 of 8 , Dec 12, 2006
          • 0 Attachment
            2006/12/13, Ron Jeffries <ronjeffries@...>:
            > Hello, Larry. On Monday, December 11, 2006, at 5:06:38 PM, you
            > wrote:
            >
            > > Ron Jeffries has an interview on InfoQ
            > > (http://www.infoq.com/interviews/jeffries-running-tested-features) that is
            > > nothing short of brilliant in its elegance in making the case for an agile
            > > development process based on the concept of "running tested features." It is
            > > so persuasively focused that one can hardly imagine anyone ever doing things
            > > any other way. (I personally think the visitor comments are overly harsh and
            > > unappreciative of the intelligence of Ron's restatement.)
            >
            > Thank you for those very kind words, Larry. I consider praise from
            > you to be high praise indeed.
            >
            > > Apropos to this list, Ron's interview made clearer than ever to me what has
            > > too long been a sort of disconnect between us. In a wonderful bit of verbal
            > > prestidigitation Ron attributes to the business and product owners the
            > > ability and responsibility to "know" what features are needed both initially
            > > and as the software develops. Which, as we know, is precisely the problem.
            >
            > Indeed, it is. Once a team gets to the point where they can deliver
            > features more or less at will, it becomes harshly visible that
            > "which features" is the real question ... and often a much more
            > difficult one than "just" learning how to build software on demand
            > that actually works ... though that's difficult enough for me!
            >
            > > To always be able to deliver useful and usable software at every cycle, one
            > > must know not only what features are actually needed by users but what is
            > > the minimum set of these to comprise a first delivered working solution.
            >
            > Yes ... though I would say that in general, while we might not be
            > able to tell the tens from the nines, and the ones from the twos
            > when it comes to feature "value", we can probably tell the big ones
            > from the little ones, which means that the product is more likely to
            > be "pretty darn good" rather than "really terrible".
            >
            > I would also mention that although the final responsibility rests
            > with the customer / product owner, the full resources of the team
            > are available to help figure out what's important and what's not.
            > Though I run into a lot of teams that need improvement -- that is,
            > after all, my work -- I haven't ever run into one that was entirely
            > clueless. So all I'm saying is that we aren't necessarily doomed.
            >
            > > Such insight into the support needs for specific roles within actual human
            > > activities is non-trivial and does not spring Athena-like from the head of
            > > the local Zeus. If it is to be trusted, it comes from the very research,
            > > analysis, modeling, and yes, design efforts that are so often dismissed by
            > > managers (and some methodologists) who want to make programming and testing
            > > the whole story.
            >
            > While doing these things well requires people of skill, I've
            > encountered many products that are better than just "good enough",
            > so while your remarks here, Larry, are a good case for staffing for
            > these skills, and including practices to apply them well ... I'd say
            > it's "very valuable" but not "absolutely essential".
            >
            > > Anyway, I found myself mentally amending Ron's talk and diagrams to take
            > > into account what happens when the features that are being correctly
            > > implemented by an agile process based on "running tested features" but in
            > > which the features are the wrong ones incorrectly prioritized and
            > > inappropriately organized because there was no upfront process, agile or
            > > otherwise, to pin down the nature of genuine user needs within the
            > > activities to be supported. The developers can still win--they deliver what
            > > is asked at the pace projected and promised--but the product and project is
            > > still a failure because of a different form of hidden "negative features,"
            > > namely all the stuff that is not needed or incomplete or just outright wrong
            > > from the end-user perspective.
            >
            > I think this is an overly dark view. We see "agile" projects succeed
            > all the time, without a high incidence of what you're describing
            > here as "failure".
            >
            > Of course I could just be lucky ...
            >
            > Ron Jeffries
            > www.XProgramming.com
            > Reason is and ought only to be the slave of the passions. -- David Hume
            >

            Ron, I want to learn the secret for your constant success. Really.

            I have a kind of sympathy with Larry.

            I have seen a few teams, which believed they were agile and did their
            best to be agile very eagerly and dilligently, succeeded as a
            development team but failed as a part of the whole business. The level
            they achieved technically(speed of building features, the quality of
            the code and tests, and etc) was very admirable, even the culture of
            the team was so powerful and healthy(compare the team with another
            team next to it, you would see heaven and hell) but after a couple of
            months their product has vanished from the market, their team
            disappeared.

            Why does this happen from time to time? Sometimes people want to feel
            safe by ignoring bigger pictures. You could use focusing on running
            tested features to make that fake safety. I have seen some teams which
            lack the explicit guidance of avoiding those pitfalls.

            For a project to succeed(in a longer term), what we need, as I think,
            is much more than the running tested features. I don't know if RTF has
            the generativity for bigger success that Alexander speaks of.
            Strategy, usability, marketing, development and all(the WHOLE team)
            have to align well. It is not easy for me and I am trying very hard to
            get better every month and week.

            Recently I read a blog post with similar point.
            http://www.artima.com/weblogs/viewpost.jsp?thread=183405 Valuing
            Outcomes over Features. I agree.

            Larry mentioned in his original post some upfront process, agile or
            not. I think a kind of small upfront exploration and setting-up is
            beneficial many times, and more important than that is continously
            adjusting the direction on the road and trying to see bigger pictures.
            For example, I have done light-weight user research upfront and then
            iteratively a la Alias, which is usually done before the project start
            or after the project(to justify the project) conventionally.

            June
          • Mark Schraad
            I am new to this board, but not new to team building and tckling wicked problems. I might have a couple of things to offer here: 1) Features Benefits
            Message 5 of 8 , Dec 13, 2006
            • 0 Attachment
              I am new to this board, but not new to team building and tckling wicked problems. I might have a couple of things to offer here:

              1) Features > Benefits > Outcomes (this chane reaction is prevalent in the marketplace as well as process.

              2) Culture beats Strategy every time in organizations - particularly small stressful, high output groups.

              Mark



              >Why does this happen from time to time? Sometimes people want to feel
              >safe by ignoring bigger pictures. You could use focusing on running
              >tested features to make that fake safety. I have seen some teams which
              >lack the explicit guidance of avoiding those pitfalls.
              >
              >For a project to succeed(in a longer term), what we need, as I think,
              >is much more than the running tested features. I don't know if RTF has
              >the generativity for bigger success that Alexander speaks of.
              >Strategy, usability, marketing, development and all(the WHOLE team)
              >have to align well. It is not easy for me and I am trying very hard to
              >get better every month and week.
              >
              >Recently I read a blog post with similar point.
              >http://www.artima.com/weblogs/viewpost.jsp?thread=183405 Valuing
              >Outcomes over Features. I agree.
              >
            • Ron Jeffries
              Hello, June. On Tuesday, December 12, 2006, at 10:16:14 PM, you ... I d have to view such a team to have an idea what happened. Certainly it is possible to
              Message 6 of 8 , Dec 13, 2006
              • 0 Attachment
                Hello, June. On Tuesday, December 12, 2006, at 10:16:14 PM, you
                wrote:

                >> I think this is an overly dark view. We see "agile" projects succeed
                >> all the time, without a high incidence of what you're describing
                >> here as "failure".
                >>
                >> Of course I could just be lucky ...
                >>
                >> Ron Jeffries
                >> www.XProgramming.com
                >> Reason is and ought only to be the slave of the passions. -- David Hume
                >>

                > Ron, I want to learn the secret for your constant success. Really.

                > I have a kind of sympathy with Larry.

                > I have seen a few teams, which believed they were agile and did their
                > best to be agile very eagerly and dilligently, succeeded as a
                > development team but failed as a part of the whole business. The level
                > they achieved technically(speed of building features, the quality of
                > the code and tests, and etc) was very admirable, even the culture of
                > the team was so powerful and healthy(compare the team with another
                > team next to it, you would see heaven and hell) but after a couple of
                > months their product has vanished from the market, their team
                > disappeared.

                > Why does this happen from time to time? Sometimes people want to feel
                > safe by ignoring bigger pictures. You could use focusing on running
                > tested features to make that fake safety. I have seen some teams which
                > lack the explicit guidance of avoiding those pitfalls.

                I'd have to view such a team to have an idea what happened.
                Certainly it is possible to have a bad product idea, or to have
                insufficient capital to market it, or a lot of other things.

                When it comes to product quality, both in reliability, in
                appropriateness of features, and (perhaps a bit less) in usability,
                Agile projects have everyone who is part of the project fully
                engaged, or they should have.

                So if a truly Agile project gets in trouble, the most likely reason
                is that no one involved had an appropriate clue. No process will fix
                that.

                > For a project to succeed(in a longer term), what we need, as I think,
                > is much more than the running tested features. I don't know if RTF has
                > the generativity for bigger success that Alexander speaks of.
                > Strategy, usability, marketing, development and all(the WHOLE team)
                > have to align well. It is not easy for me and I am trying very hard to
                > get better every month and week.

                The features you CHOOSE have to be good. The point of RTF is that it
                is the core of Agile and the core "API" that allows business people
                to steer the project. They still have to steer it well, but at least
                they CAN steer it.

                > Recently I read a blog post with similar point.
                > http://www.artima.com/weblogs/viewpost.jsp?thread=183405 Valuing
                > Outcomes over Features. I agree.

                I agree also, but I find the notion unactionable. Yes, we have to
                value the outcome. But we can only create the outcome by
                implementing some set of features. Therefore we have to choose the
                right features, that will get us the outcome.

                To me, that's not news ... it's a restatement of the need for
                product planning. I wasn't aware that anyone actually thought you
                could just implement a random set of features and be successful. If
                some people do think that, they need more help than I can provide.

                > Larry mentioned in his original post some upfront process, agile or
                > not. I think a kind of small upfront exploration and setting-up is
                > beneficial many times, and more important than that is continously
                > adjusting the direction on the road and trying to see bigger pictures.
                > For example, I have done light-weight user research upfront and then
                > iteratively a la Alias, which is usually done before the project start
                > or after the project(to justify the project) conventionally.

                I'm all for doing as much research and consideration as one finds
                valuable. I observe that sooner or later you need to get down to
                building something, and that RTF is a good way to build things,
                because it is flexible and measurable.

                Ron Jeffries
                www.XProgramming.com
                What is your dream? And knowing this, what have you
                done to work towards realizing it today? -- Les Brown
              • Jon Kern
                The other key aspect of RTF is perhaps what it is *not*: Running Untested Features RUF is a common approach i see in poor attempts at iterative development
                Message 7 of 8 , Dec 16, 2006
                • 0 Attachment
                  The other key aspect of RTF is perhaps what it is *not*:

                  Running Untested Features

                  RUF is a common approach i see in poor attempts at iterative development
                  <g>. It's close (oxymoronic) brethren is:

                  Running Unimplemented Features

                  This ends up alienating the "client" in the process. Because, as the
                  team declares victory when the iteration ends (largely due to the
                  earth's unassailable rotation), and they "demo" the new features or show
                  the lack of features, the clients get tired of having their time wasted.

                  But many "clients" or management will consider this a failure of agile
                  approach. When process is the least of these folks' problems...

                  jon
                  blog: http://technicaldebt.com



                  Ron Jeffries said the following on 12/13/06 6:57 PM:
                  >
                  > Hello, June. On Tuesday, December 12, 2006, at 10:16:14 PM, you
                  > wrote:
                  >
                  > >> I think this is an overly dark view. We see "agile" projects succeed
                  > >> all the time, without a high incidence of what you're describing
                  > >> here as "failure".
                  > >>
                  > >> Of course I could just be lucky ...
                  > >>
                  > >> Ron Jeffries
                  > >> www.XProgramming.com
                  > >> Reason is and ought only to be the slave of the passions. -- David Hume
                  > >>
                  >
                  > > Ron, I want to learn the secret for your constant success. Really.
                  >
                  > > I have a kind of sympathy with Larry.
                  >
                  > > I have seen a few teams, which believed they were agile and did their
                  > > best to be agile very eagerly and dilligently, succeeded as a
                  > > development team but failed as a part of the whole business. The level
                  > > they achieved technically(speed of building features, the quality of
                  > > the code and tests, and etc) was very admirable, even the culture of
                  > > the team was so powerful and healthy(compare the team with another
                  > > team next to it, you would see heaven and hell) but after a couple of
                  > > months their product has vanished from the market, their team
                  > > disappeared.
                  >
                  > > Why does this happen from time to time? Sometimes people want to feel
                  > > safe by ignoring bigger pictures. You could use focusing on running
                  > > tested features to make that fake safety. I have seen some teams which
                  > > lack the explicit guidance of avoiding those pitfalls.
                  >
                  > I'd have to view such a team to have an idea what happened.
                  > Certainly it is possible to have a bad product idea, or to have
                  > insufficient capital to market it, or a lot of other things.
                  >
                  > When it comes to product quality, both in reliability, in
                  > appropriateness of features, and (perhaps a bit less) in usability,
                  > Agile projects have everyone who is part of the project fully
                  > engaged, or they should have.
                  >
                  > So if a truly Agile project gets in trouble, the most likely reason
                  > is that no one involved had an appropriate clue. No process will fix
                  > that.
                  >
                  > > For a project to succeed(in a longer term), what we need, as I think,
                  > > is much more than the running tested features. I don't know if RTF has
                  > > the generativity for bigger success that Alexander speaks of.
                  > > Strategy, usability, marketing, development and all(the WHOLE team)
                  > > have to align well. It is not easy for me and I am trying very hard to
                  > > get better every month and week.
                  >
                  > The features you CHOOSE have to be good. The point of RTF is that it
                  > is the core of Agile and the core "API" that allows business people
                  > to steer the project. They still have to steer it well, but at least
                  > they CAN steer it.
                  >
                  > > Recently I read a blog post with similar point.
                  > > http://www.artima.com/weblogs/viewpost.jsp?thread=183405
                  > <http://www.artima.com/weblogs/viewpost.jsp?thread=183405> Valuing
                  > > Outcomes over Features. I agree.
                  >
                  > I agree also, but I find the notion unactionable. Yes, we have to
                  > value the outcome. But we can only create the outcome by
                  > implementing some set of features. Therefore we have to choose the
                  > right features, that will get us the outcome.
                  >
                  > To me, that's not news ... it's a restatement of the need for
                  > product planning. I wasn't aware that anyone actually thought you
                  > could just implement a random set of features and be successful. If
                  > some people do think that, they need more help than I can provide.
                  >
                  > > Larry mentioned in his original post some upfront process, agile or
                  > > not. I think a kind of small upfront exploration and setting-up is
                  > > beneficial many times, and more important than that is continously
                  > > adjusting the direction on the road and trying to see bigger pictures.
                  > > For example, I have done light-weight user research upfront and then
                  > > iteratively a la Alias, which is usually done before the project start
                  > > or after the project(to justify the project) conventionally.
                  >
                  > I'm all for doing as much research and consideration as one finds
                  > valuable. I observe that sooner or later you need to get down to
                  > building something, and that RTF is a good way to build things,
                  > because it is flexible and measurable.
                  >
                  > Ron Jeffries
                  > www.XProgramming.com
                  > What is your dream? And knowing this, what have you
                  > done to work towards realizing it today? -- Les Brown
                  >
                  >
                • Adrian Howard
                  ... [snip] Kinda related to this is the problem I ve seen with some usability folk considering their work done when they ve handed over the wireframes / PSDs /
                  Message 8 of 8 , Dec 16, 2006
                  • 0 Attachment
                    On 16 Dec 2006, at 15:01, Jon Kern wrote:

                    > The other key aspect of RTF is perhaps what it is *not*:
                    >
                    > Running Untested Features
                    >
                    > RUF is a common approach i see in poor attempts at iterative
                    > development
                    > <g>. It's close (oxymoronic) brethren is:
                    >
                    > Running Unimplemented Features
                    [snip]

                    Kinda related to this is the problem I've seen with some usability
                    folk considering their work done when they've handed over the
                    wireframes / PSDs / whatever. The developers then get blamed when
                    when the end product doesn't match the fantasy product :-)

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