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

incrementing vs. iterating

Expand Messages
  • Jeff Patton
    I wanted to do a quick opinion poll... but to answer my question, I ll have to supply some context. Lately I ve been working hard to explain to people the
    Message 1 of 21 , Aug 8, 2007
    • 0 Attachment
      I wanted to do a quick opinion poll... but to answer my question, I'll
      have to supply some context.

      Lately I've been working hard to explain to people the difference
      between iterating and incrementing.

      By iterating I mean that I might design and/or build something,
      evaluate it, then adjust it, then evaluate it, then adjust it... keep
      doing that till I feel it's the best quality I can get - till I feel
      I've reached something I can live with. Basically the product becomes
      more refined - it likely becomes simpler, it may even shrink in size
      or complexity.

      By incrementing I mean I might design and/or build something, evaluate
      it, then add a little more, then evaluate it, then add a little
      more.... Basically the product grows and grows.

      I see many people say they're doing iterative development, but really
      they're incrementing. You'll see this in agile development when you
      play a user story and expect to "get it right" - not go back and play
      another story to refine it. In agile development environments that
      increment, they never seem to plan for iterative refinement of
      stories. The result is every time we want to we want to play a
      subsequent story to refine a previous one, we end up in a bit of a
      scuffle about what story needs to be removed from the release plan.
      Basically - the release plan was built with no intention of iterating
      - only incrementing.

      In my head increments are for releasing value to customers and
      end-users. Iterations are for building and refining until I've reach
      a quality level that I can release - or run out of time, budget, or
      stomach to spend more. Of course by iterating I mean a bit of a blend
      - iterate on stories till they're good, and incrementally add more
      stories till you reach something releasable.

      My bias is coming through clearly in the way I explain this - but try
      to ignore that. I've seen lots of environments where people increment
      and seem to deliver successfully.

      I'm curious which you do?

      And, the reason I ask is that heard from a few sources that
      incrementing might work best - especially where UI design is
      concerned. That is to say we work out the UI then hand over a user
      story as a completely worked through piece of UI to simply build. We
      don't plan on making changes after we build it. All the iteration was
      done by the UI people using prototypes or other means. Or, in yucky
      cases, iteration never occurred. We just settled on the first UI we
      came up with.

      Again - my bias is towards developing very simple UI in early
      iterations and refining it through iterative development. But this is
      a strategy that seems to make some twitchy. They seem to want the UI
      right on the first iteration they see it.

      Finally, my friend Alistair wrote a bit about his 3-card approach to
      injecting some iteration back into agile development:
      http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development

      Thanks,

      -Jeff
    • Jeff Patton
      ... http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development Actually, this is the link I meant:
      Message 2 of 21 , Aug 8, 2007
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@...> wrote:
        > Finally, my friend Alistair wrote a bit about his 3-card approach to
        > injecting some iteration back into agile development:
        >
        http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development

        Actually, this is the link I meant:
        http://alistair.cockburn.us/index.php/Three_cards_for_user_rights
      • June Kim
        Hi, Jeff, I think it is difficult to draw a clear line in reality between iterating and incrementing, since those two co-occur and complement each other
        Message 3 of 21 , Aug 9, 2007
        • 0 Attachment
          Hi, Jeff,

          I think it is difficult to draw a clear line in reality between
          iterating and incrementing, since those two co-occur and complement
          each other mostly.

          Thesedays I see the development of the system with the eye from
          developmental biology(and evo-devo), and more specifically,
          morphogenesis. (see also Christopher Alexander's recent quests at
          http://www.livingneighborhoods.org )

          In my recent projects, we made a system that's valuable to the
          customer(or user) from day 1. This is very important. Day 1. I really
          mean it. It was incrementally delivering more values to the
          user/customer and iteratively refining/developing the system(first you
          see a stubby stick coming out and after a while it develops into five
          small sticks budding out from it to form a primitive start of a hand)
          as a _whole_, in terms of "whole" in Alexandrian vocabulary. The
          results of the projects were great.

          I can't exactly say I was doing either iterating or incrementing, when
          I'm forced to choose one between the two. However, I know that I can
          confidently say that it was growing up.

          June Kim

          2007/8/9, Jeff Patton <jpatton@...>:
          > I wanted to do a quick opinion poll... but to answer my question, I'll
          > have to supply some context.
          >
          > Lately I've been working hard to explain to people the difference
          > between iterating and incrementing.
          >
          > By iterating I mean that I might design and/or build something,
          > evaluate it, then adjust it, then evaluate it, then adjust it... keep
          > doing that till I feel it's the best quality I can get - till I feel
          > I've reached something I can live with. Basically the product becomes
          > more refined - it likely becomes simpler, it may even shrink in size
          > or complexity.
          >
          > By incrementing I mean I might design and/or build something, evaluate
          > it, then add a little more, then evaluate it, then add a little
          > more.... Basically the product grows and grows.
          >
          > I see many people say they're doing iterative development, but really
          > they're incrementing. You'll see this in agile development when you
          > play a user story and expect to "get it right" - not go back and play
          > another story to refine it. In agile development environments that
          > increment, they never seem to plan for iterative refinement of
          > stories. The result is every time we want to we want to play a
          > subsequent story to refine a previous one, we end up in a bit of a
          > scuffle about what story needs to be removed from the release plan.
          > Basically - the release plan was built with no intention of iterating
          > - only incrementing.
          >
          > In my head increments are for releasing value to customers and
          > end-users. Iterations are for building and refining until I've reach
          > a quality level that I can release - or run out of time, budget, or
          > stomach to spend more. Of course by iterating I mean a bit of a blend
          > - iterate on stories till they're good, and incrementally add more
          > stories till you reach something releasable.
          >
          > My bias is coming through clearly in the way I explain this - but try
          > to ignore that. I've seen lots of environments where people increment
          > and seem to deliver successfully.
          >
          > I'm curious which you do?
          >
          > And, the reason I ask is that heard from a few sources that
          > incrementing might work best - especially where UI design is
          > concerned. That is to say we work out the UI then hand over a user
          > story as a completely worked through piece of UI to simply build. We
          > don't plan on making changes after we build it. All the iteration was
          > done by the UI people using prototypes or other means. Or, in yucky
          > cases, iteration never occurred. We just settled on the first UI we
          > came up with.
          >
          > Again - my bias is towards developing very simple UI in early
          > iterations and refining it through iterative development. But this is
          > a strategy that seems to make some twitchy. They seem to want the UI
          > right on the first iteration they see it.
          >
          > Finally, my friend Alistair wrote a bit about his 3-card approach to
          > injecting some iteration back into agile development:
          > http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development
          >
          > Thanks,
          >
          > -Jeff
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
        • Faith Peterson
          We have a Web-based enterprise digital asset management and workflow management system. Our release plans are incremental models. Within the increments, the
          Message 4 of 21 , Aug 9, 2007
          • 0 Attachment
            We have a Web-based enterprise digital asset management and workflow management system. Our release plans are incremental models. Within the increments, the best developers iteratively refine in collaboration with the designer, tester, and SME. Typically, we do most of our UI refinement in paper models of varying fidelity. We continue to refine during construction, but within an extremely narrow range.
             
            I'm not sure where UI is concerned if the two approaches are incompatible. I find myself wanting to get close pretty early to what the end result will need to be. An early, relatively detailed, paper model or throwaway prototype communicates the design vision, identifies technical risks and opportunities, enables us to get feedback on the proposed final UI while functional construction begins, and exposes design issues that will need some time to investigate. If there is some envisioned UI that turns out to be wrong-headed for whatever reason, we can learn this earlier than if we deferred working it out until later. And by elaborating to a reasonable level we can give the developers advance warning if we envision introducing some new interaction capability.
             
            That said, on a large, involved project I entirely agree that the earliest implementations can, maybe should, be crude - only as wonderful as necessary to confirm the data and functionality. A reasonably detailed model can help the team to talk about what that really means. Our first implementations are usually rough aesthetically and only partially functioning with some elements for position only.
             
            Some people use layers or overlays in their models to communicate the unfolding states of an RIA. I wonder if you could do the same with UI designs to model the anticipated iterations - this might especially help observers not to gack when they see the first rustic implementations. Does anyone do this?
             

             
            On 8/9/07, Jeff Patton <jpatton@...> wrote:

            Again - my bias is towards developing very simple UI in early
            iterations and refining it through iterative development. But this is
            a strategy that seems to make some twitchy. They seem to want the UI
            right on the first iteration they see it.

            Thanks,

            -Jeff


             

          • Desilets, Alain
            Sorry Jeff, but I re-read your post twice and I still don t get the distinction. Can you provide a concrete example of a particular story and what it might
            Message 5 of 21 , Aug 9, 2007
            • 0 Attachment
              Sorry Jeff, but I re-read your post twice and I still don't get the
              distinction.

              Can you provide a concrete example of a particular story and what it
              might mean to iterate vs increment over it?

              Alain

              > -----Original Message-----
              > From: agile-usability@yahoogroups.com
              > [mailto:agile-usability@yahoogroups.com] On Behalf Of Jeff Patton
              > Sent: August 9, 2007 1:04 AM
              > To: agile-usability@yahoogroups.com
              > Subject: [agile-usability] incrementing vs. iterating
              >
              > I wanted to do a quick opinion poll... but to answer my
              > question, I'll have to supply some context.
              >
              > Lately I've been working hard to explain to people the
              > difference between iterating and incrementing.
              >
              > By iterating I mean that I might design and/or build
              > something, evaluate it, then adjust it, then evaluate it,
              > then adjust it... keep doing that till I feel it's the best
              > quality I can get - till I feel I've reached something I can
              > live with. Basically the product becomes more refined - it
              > likely becomes simpler, it may even shrink in size or complexity.
              >
              > By incrementing I mean I might design and/or build something,
              > evaluate it, then add a little more, then evaluate it, then
              > add a little
              > more.... Basically the product grows and grows.
              >
              > I see many people say they're doing iterative development,
              > but really they're incrementing. You'll see this in agile
              > development when you play a user story and expect to "get it
              > right" - not go back and play another story to refine it. In
              > agile development environments that increment, they never
              > seem to plan for iterative refinement of stories. The result
              > is every time we want to we want to play a subsequent story
              > to refine a previous one, we end up in a bit of a scuffle
              > about what story needs to be removed from the release plan.
              > Basically - the release plan was built with no intention of iterating
              > - only incrementing.
              >
              > In my head increments are for releasing value to customers
              > and end-users. Iterations are for building and refining
              > until I've reach a quality level that I can release - or run
              > out of time, budget, or stomach to spend more. Of course by
              > iterating I mean a bit of a blend
              > - iterate on stories till they're good, and incrementally add
              > more stories till you reach something releasable.
              >
              > My bias is coming through clearly in the way I explain this -
              > but try to ignore that. I've seen lots of environments where
              > people increment and seem to deliver successfully.
              >
              > I'm curious which you do?
              >
              > And, the reason I ask is that heard from a few sources that
              > incrementing might work best - especially where UI design is
              > concerned. That is to say we work out the UI then hand over
              > a user story as a completely worked through piece of UI to
              > simply build. We don't plan on making changes after we build
              > it. All the iteration was done by the UI people using
              > prototypes or other means. Or, in yucky cases, iteration
              > never occurred. We just settled on the first UI we came up with.
              >
              > Again - my bias is towards developing very simple UI in early
              > iterations and refining it through iterative development.
              > But this is a strategy that seems to make some twitchy. They
              > seem to want the UI right on the first iteration they see it.
              >
              > Finally, my friend Alistair wrote a bit about his 3-card
              > approach to injecting some iteration back into agile development:
              > http://alistair.cockburn.us/index.php/Incremental_versus_itera
              > tive_development
              >
              > Thanks,
              >
              > -Jeff
              >
              >
              >
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
            • Mark Schraad
              Most designers are used to both iterating and incrementing. We have been doing it for decades and is what Constantine so elegantly called trial and error I
              Message 6 of 21 , Aug 9, 2007
              • 0 Attachment
                Most designers are used to both iterating and incrementing. We have been doing it for decades and is what Constantine so elegantly called 'trial and error' I believe.

                I interpret from Jeff's definition the differing element to be a use ready prototype. Is this correct?

                There is an oversite or management issue here that is dependent on the extreme adherence to time and very quick turnarounds. The problem comes in keeping standards high. Given a hard stop, it is pretty easy for designers and developers to output a 'good enough' for this iteration solution. It puts more pressure on (design and dev) management to oversee quality. The pressure to release sub par product early is substantial in most corporate environs.

                Additionally, the notion of working with a design attitude as opposed to decision attitude (Managing as Designing, R. Noland and F. Callopy) is often lost. A larger question in scrutinizing agile process might be, is good enough what we are really after?

                Mark





                2007/8/9, Jeff Patton <jpatton@acm.org>:
                > I wanted to do a quick opinion poll... but to answer my question, I'll
                > have to supply some context.
                >
                > Lately I've been working hard to explain to people the difference
                > between iterating and incrementing.
                >
                > By iterating I mean that I might design and/or build something,
                > evaluate it, then adjust it, then evaluate it, then adjust it... keep
                > doing that till I feel it's the best quality I can get - till I feel
                > I've reached something I can live with. Basically the product becomes
                > more refined - it likely becomes simpler, it may even shrink in size
                > or complexity.
                >
                > By incrementing I mean I might design and/or build something, evaluate
                > it, then add a little more, then evaluate it, then add a little
                > more.... Basically the product grows and grows.
                >
                > I see many people say they're doing iterative development, but really
                > they're incrementing. You'll see this in agile development when you
                > play a user story and expect to "get it right" - not go back and play
                > another story to refine it. In agile development environments that
                > increment, they never seem to plan for iterative refinement of
                > stories. The result is every time we want to we want to play a
                > subsequent story to refine a previous one, we end up in a bit of a
                > scuffle about what story needs to be removed from the release plan.
                > Basically - the release plan was built with no intention of iterating
                > - only incrementing.
                >
                > In my head increments are for releasing value to customers and
                > end-users. Iterations are for building and refining until I've reach
                > a quality level that I can release - or run out of time, budget, or
                > stomach to spend more. Of course by iterating I mean a bit of a blend
                > - iterate on stories till they're good, and incrementally add more
                > stories till you reach something releasable.
                >
                > My bias is coming through clearly in the way I explain this - but try
                > to ignore that. I've seen lots of environments where people increment
                > and seem to deliver successfully.
                >
                > I'm curious which you do?
                >
                > And, the reason I ask is that heard from a few sources that
                > incrementing might work best - especially where UI design is
                > concerned. That is to say we work out the UI then hand over a user
                > story as a completely worked through piece of UI to simply build. We
                > don't plan on making changes after we build it. All the iteration was
                > done by the UI people using prototypes or other means. Or, in yucky
                > cases, iteration never occurred. We just settled on the first UI we
                > came up with.
                >
                > Again - my bias is towards developing very simple UI in early
                > iterations and refining it through iterative development. But this is
                > a strategy that seems to make some twitchy. They seem to want the UI
                > right on the first iteration they see it.
                >
                > Finally, my friend Alistair wrote a bit about his 3-card approach to
                > injecting some iteration back into agile development:
                > http://alistair.cockburn.us/index.php/Incremental_versus_iterative_development
                >
                > Thanks,
                >
                > -Jeff
                >


              • White, Jeff
                I took it to mean this: say you know upfront some product you re working on will have 5 features. Those 5 features could be built incrementally - 1 sprint for
                Message 7 of 21 , Aug 9, 2007
                • 0 Attachment

                  I took it to mean this: say you know upfront some product you’re working on will have 5 features. Those 5 features could be built incrementally – 1 sprint for feature 1, etc. That doesn’t mean that each feature was subjected to iterative design – design, test, refine, test, refine, etc.

                   

                  Jeff

                   

                  >>  

                  Sorry Jeff, but I re-read your post twice and I still don't get the
                  distinction.

                  Can you provide a concrete example of a particular story and what it
                  might mean to iterate vs increment over it?

                  Alain

                  >>

                  .


                • Desilets, Alain
                  ... In other words: incremental = one complete and finished feature at a time iterative = start with version 0.1 of a set of features, and improve them as a
                  Message 8 of 21 , Aug 9, 2007
                  • 0 Attachment
                     >  I took it to mean this: say you know upfront some product you’re working on will have 5 features. Those 5 features 
                     >  could be  built incrementally – 1 sprint for feature 1, etc. That doesn’t mean that each feature was subjected to iterative  
                     >  design – design, test, refine, test, refine, etc. 
                     
                    In other words:


                    (Message over 64 KB, truncated)
                  • Jeff Patton
                    Clearly I ve asked the wrong group. You re all too smart to simply do one or the other – or to be unaware of which you re doing. I hear everyone saying
                    Message 9 of 21 , Aug 10, 2007
                    • 0 Attachment
                      Clearly I've asked the wrong group. You're all too smart to simply do
                      one or the other – or to be unaware of which you're doing. I hear
                      everyone saying they do both – and alternate between each at different
                      times and for different reasons.

                      June: iterating and incrementing are too combined to pick apart.
                      Emphasis on organic growth. Great Alexander reference. June thinks
                      on a higher plane than I do. ;-)

                      Faith: This is where I think ICD/IxD/Ux people run into trouble with
                      some Agle folk who have the bias for delivering index cards with "as a
                      shmo I want manage widgets so that I can…" stories written on them.
                      These clearly defer interaction design till late – and consequently
                      defer iterating UI to immediately before construction – and defer
                      iterating the /whole/ UI till after some construction – till after we
                      see it together as working code rather than as a prototype.

                      I really your the layering suggestion. I'll try this. When
                      delivering /rough/ UI I always need to explain – using big hand
                      gestures – how things will eventually look once we confirm this bit is
                      good. Using an overlay to show a possible visual design would help.
                      I hate premature elaboration. ;-)

                      Mark: The comments that stick in my head are around the tension
                      between quick turn around and keeping quality standards high, and "is
                      good enough what we're really after?" You sorta get at the heart of
                      what I'm talking about. Of course most people want things as good as
                      they can be. For commercial software, certainly better than
                      competitors'. And, "good enough" is both a subjective and relative
                      term. Many people's "good enough" is my "stinky sub-standard."

                      For me quality is something I iterate toward both in prototypes and
                      later in code. Early iterations would clearly be too rough to release
                      to users – later iterations – the one's before the release – I'd
                      expect quality to be very high. Basically I want to start with
                      stories that are "not good enough" and keep adding stories till I get
                      to "really really good." You're observation is correct that in many
                      agile environments they use stories that are "good enough" and
                      continue with those all the way through – never building to anything
                      better than "good enough." And when you add a pile of just "good
                      enough" stories together, you often end up with "not so good" – the
                      whole being less than the sum of its parts.

                      So, on your comment regarding scrutinizing agile process and asking is
                      "good enough what really after?" – I'd encourage you to scrutinize the
                      agile /practitioners/ a little harder. As I practice Agile, I usually
                      fish for something better than good enough.

                      Alain: I think you get what I'm saying – and like everyone else you
                      don't easily separate the two strategies. You're "do the simplest
                      thing that could possible work" comment is a good one. That was a
                      mantra I used to hear a lot years ago – and less so today. Don't know
                      why, or if I've been hanging around in the wrong circles lately. But,
                      when I do hear it – it's with developers talking about code – not the
                      people writing user stories using it as a strategy for putting simple
                      stories in first and following them up with stories that improve those
                      stories.

                      The simplest thing that could possibly work at iteration 1 is
                      different than the simplest thing that could possibly work at
                      incremental release 1. By that I mean on iteration 1 I might want a
                      simple story that helps me learn something about what I eventually
                      need – "the simplest thing I could possibly learn from". The quality
                      may be too low to release – but, it'll help me learn. By the last
                      iteration of the release, I'd like the user experience to be high.
                      I'd like it to be the "simplest thing I could possibly release."

                      Thanks everyone for commenting.

                      -Jeff
                    • Desilets, Alain
                      ... Actually, this mantra was originally coined in the context of code, not UI. But I think it applies to both. Note that the mantra does not say to Stop
                      Message 10 of 21 , Aug 10, 2007
                      • 0 Attachment
                        > Alain: I think you get what I'm saying - and like everyone
                        > else you don't easily separate the two strategies. You're
                        > "do the simplest thing that could possible work" comment is a
                        > good one. That was a mantra I used to hear a lot years ago -
                        > and less so today. Don't know why, or if I've been hanging
                        > around in the wrong circles lately. But, when I do hear it -
                        > it's with developers talking about code - not the people
                        > writing user stories using it as a strategy for putting
                        > simple stories in first and following them up with stories
                        > that improve those
                        > stories.

                        Actually, this mantra was originally coined in the context of code, not
                        UI. But I think it applies to both.

                        Note that the mantra does not say to "Stop after the simplest thing...".
                        It just says start with that and re-evaluate from there.

                        I find having quickly a minimal working version of a feature helps me
                        identify the pressure points that matter most.

                        > The simplest thing that could possibly work at iteration 1 is
                        > different than the simplest thing that could possibly work at
                        > incremental release 1. By that I mean on iteration 1 I might
                        > want a simple story that helps me learn something about what
                        > I eventually need - "the simplest thing I could possibly
                        > learn from".

                        I like that. It exactly captures what I was talking about above.

                        > 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.

                        Alain
                      • Jeff Patton
                        ... 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
                        Message 11 of 21 , Aug 10, 2007
                        • 0 Attachment
                          --- 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.)

                          thanks,

                          -Jeff
                        • Jeff Patton
                          ... step for ... The question for me - from an agile interaction design perspective is /where/ does the iteration occur?
                          Message 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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.