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

Re: [agile-usability] Running Tested Features

Expand Messages
  • 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 1 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 2 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 3 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.