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

Re: incrementing vs. iterating

Expand Messages
  • Jeff Patton
    ... step for ... The question for me - from an agile interaction design perspective is /where/ does the iteration occur?
    Message 1 of 21 , Aug 10, 2007
    • 0 Attachment
      <sorry - clicked send to soon....>

      --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@...> wrote:
      >
      > --- In agile-usability@yahoogroups.com, "Desilets, Alain"
      > <alain.desilets@> wrote:
      > >
      > > > I'd like it to be the "simplest thing I could possibly release."
      > >
      > > In my case, that releasable thing is always very different from what I
      > > initially envisaged, and the quick initial build is a necessary
      step for
      > > me to find out.
      >
      > That's _exactly_ what I mean by iterative development. And you'd be
      > surprised at how often in agile environments I've observed people
      > considering that a failure. And in particular people in the customer
      > or product owner role not letting a user story be written or
      > considered complete until it is exactly the way it should be at
      > release time - even if the story is played on iteration 1. (I suspect
      > my bias is showing through again.)

      The question for me - from an agile interaction design perspective is
      /where/ does the iteration occur? Outside of code in prototypes, or
      in code as working software?

      As I've been saying, I've seen an unusual resistance, particularly
      from those in a customer role, to iterating in the working software.
      This forces it to occur before. And for me is sometimes problematic.
      There's only so much I can learn from paper - and for my money higher
      fidelity prototyping quickly approaches diminishing returns when
      compared to working code (at least for the domains I often work in).
      But, when I say working code - I mean working code that's not much
      better than a prototype. I don't mean releasable working code. For
      some it may be crystal clear - for others it all seems to confusing
      and ad hoc to live with.

      Thanks,

      -Jeff
    • Desilets, Alain
      ... I m quite puzzled by that. I would think that a team that a team that opted for an Agile approach would consider reworking a story as a normal and
      Message 2 of 21 , Aug 10, 2007
      • 0 Attachment
        > > > I'd like it to be the "simplest thing I could possibly release."
        > >
        > > In my case, that releasable thing is always very different
        > from what I
        > > initially envisaged, and the quick initial build is a
        > necessary step
        > > for me to find out.
        >
        > That's _exactly_ what I mean by iterative development. And
        > you'd be surprised at how often in agile environments I've
        > observed people considering that a failure. And in
        > particular people in the customer or product owner role not
        > letting a user story be written or considered complete until
        > it is exactly the way it should be at release time - even if
        > the story is played on iteration 1. (I suspect my bias is
        > showing through again.)

        I'm quite puzzled by that.

        I would think that a team that a team that opted for an Agile approach
        would consider reworking a story as a normal and desirable thing. If
        anything, if you never need to rework a any stories, you are probably
        consitently overshooting and wasting money on gold plating.

        But it sounds like you have seen many teams where people (even including
        developpers by the sounds of things) interpret the need to rework a
        story as a sign that something was done wrong?

        Makes you wonder if those people really understand Agile development
        altogether.

        Alain
      • Desilets, Alain
        ... . Alain responds: Yes, I can imagine that. How do *developpers* feel about iterating in the working software? Another common bias is developpers who are
        Message 3 of 21 , Aug 10, 2007
        • 0 Attachment
          > Jeff wrote:
          >
          > The question for me - from an agile interaction design
          > perspective is /where/ does the iteration occur? Outside of
          > code in prototypes, or in code as working software?
          >
          > As I've been saying, I've seen an unusual resistance,
          > particularly from those in a customer role, to iterating in
          > the working software.
          > This forces it to occur before. And for me is sometimes problematic.
          > There's only so much I can learn from paper - and for my
          > money higher fidelity prototyping quickly approaches
          > diminishing returns when compared to working code (at least
          > for the domains I often work in).
          .

          Alain responds:

          Yes, I can imagine that. How do *developpers* feel about iterating in
          the working software?

          Another common bias is developpers who are against iterating outside of
          working software at all. Those are the ones who believe you should start
          coding as soon as you can write a couple stories on napkins. I see a lot
          more of that kind of bias myself.

          I think you need to do both, as you very justly point out.

          I'm a little puzzled by what you mean by this part of your post:

          > But, when I say working code - I mean working code that's not
          > much better than a prototype. I don't mean releasable
          > working code. For some it may be crystal clear - for others
          > it all seems to confusing and ad hoc to live with

          Do you mean that for example, it's OK to produce code that is buggy
          while you are iterating in software?

          My own experience is that it's better to write good quality code
          TDD-style all the time. Even when I am spiking code that is meant to be
          throw-away, I will do it TDD style because I truly feel it allows to
          move faster than if I just hack away. The easiest time to find and fix a
          bug is right at the moment when you introduce it.

          The same goes with refactoring. I don't think it's a good idea to
          accumulate a large design dept in your code while prototyping, and hope
          that once you are done iterating, you will be able to clean up the code.
          It's much easier to clean up as you go.

          I think what you mean by "not releasable" is code that is not function
          complete, or whose usability is embarassingly bad so that you would not
          dream to put it in front of an end-user (even a very sympathetic and
          understanding one). Is that correct?

          Alain
        • Jeff Patton
          ... I should also point out that I get called on to work with UX people new to agile - and one of their biggest concerns is that as well. They generally want
          Message 4 of 21 , Aug 10, 2007
          • 0 Attachment
            --- In agile-usability@yahoogroups.com, "Desilets, Alain"
            <alain.desilets@...> wrote:
            >
            > But it sounds like you have seen many teams where people (even including
            > developpers by the sounds of things) interpret the need to rework a
            > story as a sign that something was done wrong?
            >
            > Makes you wonder if those people really understand Agile development
            > altogether.

            I should also point out that I get called on to work with UX people
            new to agile - and one of their biggest concerns is that as well.
            They generally want more time to iterate their design so that it can
            be "more right" before it gets passed to developers as a "user story."
            And, in my opinion, they often want too much time to get it way too
            right.

            It's understandable since many of them have been conditioned by past
            experience that once they give it to development, not only does
            development often screw it up, but they rarely get another iteration
            to fix or improve it. It looks a little like post-traumatic-stress
            disorder. And, I think a lot of folks with years of experience in
            traditional software development suffer from it. Not just the UX
            people. That's why I think I see so much "incrementing" and so little
            "iterating."

            thanks,

            -Jeff
          • Desilets, Alain
            ... Yes, I can see how this kind of past experience would condition your get it right the first time reflexes. Do you find that as they work more and more on
            Message 5 of 21 , Aug 10, 2007
            • 0 Attachment
              > It's understandable since many of them have been conditioned
              > by past experience that once they give it to development, not
              > only does development often screw it up, but they rarely get
              > another iteration to fix or improve it. It looks a little
              > like post-traumatic-stress disorder. And, I think a lot of
              > folks with years of experience in traditional software
              > development suffer from it. Not just the UX people. That's
              > why I think I see so much "incrementing" and so little "iterating."

              Yes, I can see how this kind of past experience would condition your
              "get it right the first time" reflexes.

              Do you find that as they work more and more on a true agile environment
              they start relaxing more (assuming of course that developpers ARE
              responsive to their requests for changes)?

              One thing I do notice is that while agile developpers ARE open to
              changes in terms of adding new functionality or scenarios of use, they
              tend to be less open to changes in the kind of "details" that makes the
              difference between a barely usable system, and a system that is a
              pleasure to use. You know, things like: this should be a picklist
              instead of a text box type of thing. So maybe that kind of reflex is not
              completely uncalled for even in an agile context.

              Alain

              Oh, and I'll echo your thanks.
            • Desilets, Alain
              ... Actually, a better example is something like: The list of images that the user needs to pick from should be displayed as a list of thumbnail images with
              Message 6 of 21 , Aug 10, 2007
              • 0 Attachment
                > One thing I do notice is that while agile developpers ARE
                > open to changes in terms of adding new functionality or
                > scenarios of use, they tend to be less open to changes in the
                > kind of "details" that makes the difference between a barely
                > usable system, and a system that is a pleasure to use. You
                > know, things like: this should be a picklist instead of a
                > text box type of thing.

                Actually, a better example is something like: "The list of images that
                the user needs to pick from should be displayed as a list of thumbnail
                images with the file name as opposed to just a list of file names, so
                that the user does not have to guess or remember what the image is from
                its file name".

                Lots of developers (including some agile ones) would see that change as
                an unimportant detail whose implementation cost outweighs the gains in
                ease of use.

                Alain
              • Jeff Patton
                ... This reminds me of another weird dead-lock I often see. Developer wants to start work as soon as we have a few lines of text. Asks to know what the UI
                Message 7 of 21 , Aug 10, 2007
                • 0 Attachment
                  --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                  <alain.desilets@...> wrote:
                  >
                  > Yes, I can imagine that. How do *developpers* feel about iterating in
                  > the working software?
                  >
                  > Another common bias is developers who are against iterating outside of
                  > working software at all. Those are the ones who believe you should start
                  > coding as soon as you can write a couple stories on napkins. I see a lot
                  > more of that kind of bias myself.

                  This reminds me of another weird dead-lock I often see. Developer
                  wants to start work as soon as we have a few lines of text. Asks to
                  know what the UI should look like. Analyst or UI person hastily
                  sketches something. Developer is generally happy to refactor their
                  internal design to improve it -but screams "scope creep" or "bad
                  requirements" when the UI needs to change. Basically very willing to
                  iterate internal design, and very unwilling to iterate external design.

                  Again, understandable. They're more comfortable iterating over the
                  parts they understand - because I believe they can better understand
                  when they design is improving. Less willing to iterate over the parts
                  they can understand - because they can't tell if they are or aren't
                  making positive improvements.

                  > I'm a little puzzled by what you mean by this part of your post:
                  >
                  > > But, when I say working code - I mean working code that's not
                  > > much better than a prototype. I don't mean releasable
                  > > working code. For some it may be crystal clear - for others
                  > > it all seems to confusing and ad hoc to live with
                  >
                  > Do you mean that for example, it's OK to produce code that is buggy
                  > while you are iterating in software?

                  Nope - I mean that it's OK to produce software I wouldn't put in front
                  of the consumer. For instance I may leave field validation, some
                  optional fields, and some visual design elements out of the first
                  iteration - but definitely not out of the release.

                  > My own experience is that it's better to write good quality code
                  > TDD-style all the time. Even when I am spiking code that is meant to be
                  > throw-away, I will do it TDD style because I truly feel it allows to
                  > move faster than if I just hack away. The easiest time to find and fix a
                  > bug is right at the moment when you introduce it.

                  I separate quality of code from quality of user experience. So, while
                  I always expect code quality to be high, I'm iterating so that I can
                  improve quality of user experience. For instance my first version
                  with no validation, missing fields, and rough visual design may have
                  high quality code - but have a quality of user experience level I
                  can't live with.

                  The word "quality" is a tough one. To some it means no bugs. To
                  developers it might mean no bugs, and good maintainable design. To UX
                  people it applies to the quality experience. Of course all are right
                  and important.

                  > I think what you mean by "not releasable" is code that is not function
                  > complete, or whose usability is embarassingly bad so that you would not
                  > dream to put it in front of an end-user (even a very sympathetic and
                  > understanding one). Is that correct?

                  yup. I guess I mean non-releasable software.

                  -Jeff
                • Jeff Patton
                  ... Sadly that true Agile environment seems to be hard to find lately. As Agile has arrive at the other side of the chasm - I see lots of companies adopting
                  Message 8 of 21 , Aug 10, 2007
                  • 0 Attachment
                    --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                    <alain.desilets@...> wrote:
                    > Do you find that as they work more and more on a true agile environment
                    > they start relaxing more (assuming of course that developpers ARE
                    > responsive to their requests for changes)?

                    Sadly that "true" Agile environment seems to be hard to find lately.
                    As Agile has arrive at the other side of the chasm - I see lots of
                    companies adopting practices from Agile development, but keeping their
                    traditions software development lifecycle values firmly in place.
                    Even when developers are happy to make changes, the project manager
                    often pushes back after realizing that this will have impact on the
                    project plan.

                    It's tough to get everyone in a big team, particularly in large
                    organizations, to take their waterfall hat off.

                    -Jeff
                  • Desilets, Alain
                    ... This is very much in line about how I think about the code too. I make sure the code is good enough that I can send it out to test users. That means bug
                    Message 9 of 21 , Aug 10, 2007
                    • 0 Attachment
                      > > I'm a little puzzled by what you mean by this part of your post:
                      > >
                      > > > But, when I say working code - I mean working code that's
                      > not much
                      > > > better than a prototype. I don't mean releasable working
                      > code. For
                      > > > some it may be crystal clear - for others it all seems to
                      > confusing
                      > > > and ad hoc to live with
                      > >
                      > > Do you mean that for example, it's OK to produce code that is buggy
                      > > while you are iterating in software?
                      >
                      > Nope - I mean that it's OK to produce software I wouldn't put
                      > in front of the consumer. For instance I may leave field
                      > validation, some optional fields, and some visual design
                      > elements out of the first iteration - but definitely not out
                      > of the release.

                      This is very much in line about how I think about the code too.

                      I make sure the code is good enough that I can send it out to test
                      users. That means bug free, and doing something useful. But that does
                      not mean that it can always be deployed in a real use setting. For
                      example, often there is a new feature that I know it is too slow and
                      would crumble under the weight of the traffic.

                      Alain
                    • Desilets, Alain
                      ... There are two ways to read what you said. Interpretation 1: Teams that started using Agile in the early days and did it right are still doing it right.
                      Message 10 of 21 , Aug 10, 2007
                      • 0 Attachment
                        > --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                        > <alain.desilets@...> wrote:
                        > > Do you find that as they work more and more on a true agile
                        > > environment they start relaxing more (assuming of course that
                        > > developpers ARE responsive to their requests for changes)?
                        >
                        > Sadly that "true" Agile environment seems to be hard to find lately.
                        > As Agile has arrive at the other side of the chasm - I see
                        > lots of companies adopting practices from Agile development,
                        > but keeping their traditions software development lifecycle
                        > values firmly in place.
                        > Even when developers are happy to make changes, the project
                        > manager often pushes back after realizing that this will have
                        > impact on the project plan.
                        >
                        > It's tough to get everyone in a big team, particularly in
                        > large organizations, to take their waterfall hat off.

                        There are two ways to read what you said.

                        Interpretation 1: Teams that started using Agile in the early days and
                        did it right are still doing it right. It's the late adopters who are
                        having difficulty taking off their waterfall hat.

                        Interpreation 2: Even early adopters of Agile are now leaning back
                        towards a more waterfall approach.

                        I guess what you are seeing is interpretation 1, right? If so, I am not
                        that surprised, although I would have thought that agile was so
                        obviously effective that even late comers would "get it".

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