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

Interesting Issue: Customer cares about design details.

Expand Messages
  • Ron Jeffries
    I m cross-posting this to xp and scrum lists, as I m interested in both sides ideas. This is a real situation. Names have been changed to protect the
    Message 1 of 28 , Nov 3, 2008
    • 0 Attachment
      I'm cross-posting this to xp and scrum lists, as I'm interested in
      both sides' ideas. This is a real situation. Names have been changed
      to protect the innocent.

      We have a Scrum-style contract programming project, using two week
      iterations. The customer is remote from the team and meets with them
      at iteration end/begin time. The team are relatively new to
      programming and to Scrum. The customer is also new to Scrum and has
      serious doubts about it.

      The customer is concerned about the design of the eventual code, as
      they intend to adopt it and maintain it. Accordingly they are asking
      to be given the code to review at the end of each iteration. They
      plan to request design changes based on that review. The review, of
      course, will take some time.

      So what will happen is that iteration n+1 will start, and then the
      customer will come in halfway through the iteration with design
      changes and will want them done "immediately".

      Now in fact I suspect that the customer is right to want to keep an
      eye on the design, as the code will eventually be theirs, and they
      have no real reason to believe that a good design will evolve. Since
      the team is new to iterative (and somewhat new to programming) there
      is valid reason to want to review the design in my opinion as well.

      Now if I were coaching this project I would be thinking along these
      lines:

      - educate the customer better in how to do iterative development;
      - set expectations that design change stories are ok, but that
      - all stories are injected only at the beginning of the iteration;
      - shorten the iteration;
      - increase design review within the team to reduce changes;
      - make cost of jerking around more visible to the customer;
      - try to speed up customer design review, perhaps with more drops.

      And all this I'd be doing iteratively as I listened to what people
      said and observed what they do. As it happens, I'm not there, and no
      one with any deep experience in Agile is there. I can advise by
      email and maybe some of the parties involved are on these lists. If
      so, they might just listen, or they might chime in.

      My basic view is that the customer is right to care about design,
      and can't fix the remoteness issue in a timely fashion. I assert
      that this breaks a lot of principles that really matter, and places
      the project at higher risk than we would like.

      (This is, by the way, a fundamental truth that Scrum people like
      Mike Dwyer face every day: if you do not do this stuff "right", it
      increases some risks substantially. Some are increased essentially
      to probability one. Most of the advice we hear about projects done
      this way is, in effect, "well, deal with it." I don't find that
      helpful for projects like this, and I think it encourages more
      projects like this to happen. So I'm hoping to see some real,
      useful, pragmatic advice here from the "Scrum in the Real World"
      folks.)

      My purpose here is to get some discussion going, to see if other
      ideas come up and just generally to hear what people have to say. I
      will of course answer questions if I can and will surely comment in
      that way that I have. And maybe some team members will show up as
      well.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      Reason is and ought only to be the slave of the passions. -- David Hume
    • Brad Stiles
      ... Might there be reasons for the changes in design, other than they don t trust that an iterative process can produce a good design? Are they worried about
      Message 2 of 28 , Nov 3, 2008
      • 0 Attachment
        > The customer is concerned about the design of the eventual code, as
        > they intend to adopt it and maintain it. Accordingly they are asking
        > to be given the code to review at the end of each iteration. They
        > plan to request design changes based on that review. The review, of
        > course, will take some time.

        Might there be reasons for the changes in design, other than they
        don't trust that an iterative process can produce a "good" design?
        Are they worried about optimization? Do they have some standards or
        requirements which they haven't communicated before this? Do they
        expect the code to be used for other projects after this one is done?

        Or is it simply the skepticism?

        Brad
      • lior friedman
        Hi Ron, An interesting scenario. I think you are right here and customer does have valid reasons to get involved in the design details. The only thing that
        Message 3 of 28 , Nov 3, 2008
        • 0 Attachment
          Hi Ron,



          An interesting scenario. I think you are right here and customer does have
          valid reasons to get involved in the design details.

          The only thing that strikes me out of place is the "immediate" part. Why
          does design changes must be done immediately?



          What I would try to do, is get the customer changes in iteration n+1 but
          schedule them as candidates for iteration n+2.

          Which means that effectively the customer will see his requests being
          applied only at the end of that iteration.



          The risk in doing so involve that the customer changes might effect the work
          done in iteration n+1, but I'm sure that if someone on the team will look
          into the changes that can be minimized.



          The up side of scheduling them as regular stories for iteration n+2 is:

          1) The team wont get disrupted.

          2) (and this is a nasty side effect that might be good or not) I think
          that like any refactoring work I've faced, the "value" of these will be
          dwarfed when stacked against "real" business stories. I have a feeling that
          if you manage to get the customer to prioritize them normally at the start
          of the iteration a lot of them would just go away. Again I'm not sure if
          this is good or bad but I think that the dev team will like that.



          On the long run I think that it will be important to make sure that the
          design change request issued by the review will decrease, either by making
          sure the programmers learn what is expected by the specific customer, or by
          the customer learning to trust the development team design.

          I would be prepared however for some clashes at the start that will need to
          be settled (design issues do have the tendency to become a matter of ego
          from time to time).



          Hope this helps



          Lior Friedman
          Agile Consultant - AUT/TDD Expert | Email: lfriedmal@...
          <mailto:lior@...> | Blog <http://imistaken.blogspot.com/>







          [Non-text portions of this message have been removed]
        • Seyit Caglar Abbasoglu
          So what will happen is that iteration n+1 will start, and then the ... If Iterations are short enough and if we can replace at the next iteration with
          Message 4 of 28 , Nov 3, 2008
          • 0 Attachment
            So what will happen is that iteration n+1 will start, and then the
            > customer will come in halfway through the iteration with design
            > changes and will want them done "immediately".
            >
            If Iterations are short enough and if we can replace "at the next iteration"
            with "immediately", an agile team aiming quailty test coverage and simple
            design wouldn't have much problems in this situation.

            The biggest problem might be when the customer says "Let's use X pattern
            here since we'll need it later". So one of the priorities must be teaching
            YAGNI to the customer, and make them feel confident about it.


            [Non-text portions of this message have been removed]
          • Chet Hendrickson
            Hello Ron, I first thought is, How do we keep this from turning into a game of bring me a rock ? I believe it is proper for the customer to have these
            Message 5 of 28 , Nov 3, 2008
            • 0 Attachment
              Hello Ron,

              I first thought is, "How do we keep this from turning into a game of bring me a rock"?

              I believe it is proper for the customer to have these concerns. I am concerned when I see an out sourced project in which the customer doesn't have these concerns. The issue is one of turning the concern into user stories.

              chet

              Monday, November 3, 2008, 7:58:38 AM, you wrote:

              > I'm cross-posting this to xp and scrum lists, as I'm interested in
              > both sides' ideas. This is a real situation. Names have been changed
              > to protect the innocent.

              > We have a Scrum-style contract programming project, using two week
              > iterations. The customer is remote from the team and meets with them
              > at iteration end/begin time. The team are relatively new to
              > programming and to Scrum. The customer is also new to Scrum and has
              > serious doubts about it.

              > The customer is concerned about the design of the eventual code, as
              > they intend to adopt it and maintain it. Accordingly they are asking
              > to be given the code to review at the end of each iteration. They
              > plan to request design changes based on that review. The review, of
              > course, will take some time.

              > So what will happen is that iteration n+1 will start, and then the
              > customer will come in halfway through the iteration with design
              > changes and will want them done "immediately".

              > Now in fact I suspect that the customer is right to want to keep an
              > eye on the design, as the code will eventually be theirs, and they
              > have no real reason to believe that a good design will evolve. Since
              > the team is new to iterative (and somewhat new to programming) there
              > is valid reason to want to review the design in my opinion as well.

              > Now if I were coaching this project I would be thinking along these
              > lines:

              > - educate the customer better in how to do iterative development;
              > - set expectations that design change stories are ok, but that
              > - all stories are injected only at the beginning of the iteration;
              > - shorten the iteration;
              > - increase design review within the team to reduce changes;
              > - make cost of jerking around more visible to the customer;
              > - try to speed up customer design review, perhaps with more drops.

              > And all this I'd be doing iteratively as I listened to what people
              > said and observed what they do. As it happens, I'm not there, and no
              > one with any deep experience in Agile is there. I can advise by
              > email and maybe some of the parties involved are on these lists. If
              > so, they might just listen, or they might chime in.

              > My basic view is that the customer is right to care about design,
              > and can't fix the remoteness issue in a timely fashion. I assert
              > that this breaks a lot of principles that really matter, and places
              > the project at higher risk than we would like.

              > (This is, by the way, a fundamental truth that Scrum people like
              > Mike Dwyer face every day: if you do not do this stuff "right", it
              > increases some risks substantially. Some are increased essentially
              > to probability one. Most of the advice we hear about projects done
              > this way is, in effect, "well, deal with it." I don't find that
              > helpful for projects like this, and I think it encourages more
              > projects like this to happen. So I'm hoping to see some real,
              > useful, pragmatic advice here from the "Scrum in the Real World"
              > folks.)

              > My purpose here is to get some discussion going, to see if other
              > ideas come up and just generally to hear what people have to say. I
              > will of course answer questions if I can and will surely comment in
              > that way that I have. And maybe some team members will show up as
              > well.

              > Ron Jeffries
              > www.XProgramming.com
              > www.xprogramming.com/blog
              > Reason is and ought only to be the slave of the passions. -- David Hume




              --
              Best regards,
              Chet mailto:lists@...

              [Non-text portions of this message have been removed]
            • Steven Gordon
              In similar situations I have asked the customer to assign one of their own most trusted software engineers to be an active developer on the project. I would
              Message 6 of 28 , Nov 3, 2008
              • 0 Attachment
                In similar situations I have asked the customer to assign one of their
                own most trusted software engineers to be an active developer on the
                project. I would make the case that doing so would:
                - be less disruptive to the delivery of value than so many external
                code reviews,
                - end up being less expensive in terms of hours than so many external
                code reviews,
                - be at least as effective in assuring good design, since promiscuous
                pair programming would mean that the developer would actively work on
                every part of the design and code,
                - pay off in greater productivity due to the extra working developer, and
                - would provide a knowledgeable internal oracle to whatever team
                eventually maintains the software.

                Steven Gordon

                On Mon, Nov 3, 2008 at 5:58 AM, Ron Jeffries
                <ronjeffries@...> wrote:
                > I'm cross-posting this to xp and scrum lists, as I'm interested in
                > both sides' ideas. This is a real situation. Names have been changed
                > to protect the innocent.
                >
                > We have a Scrum-style contract programming project, using two week
                > iterations. The customer is remote from the team and meets with them
                > at iteration end/begin time. The team are relatively new to
                > programming and to Scrum. The customer is also new to Scrum and has
                > serious doubts about it.
                >
                > The customer is concerned about the design of the eventual code, as
                > they intend to adopt it and maintain it. Accordingly they are asking
                > to be given the code to review at the end of each iteration. They
                > plan to request design changes based on that review. The review, of
                > course, will take some time.
                >
                > So what will happen is that iteration n+1 will start, and then the
                > customer will come in halfway through the iteration with design
                > changes and will want them done "immediately".
                >
                > Now in fact I suspect that the customer is right to want to keep an
                > eye on the design, as the code will eventually be theirs, and they
                > have no real reason to believe that a good design will evolve. Since
                > the team is new to iterative (and somewhat new to programming) there
                > is valid reason to want to review the design in my opinion as well.
                >
                > Now if I were coaching this project I would be thinking along these
                > lines:
                >
                > - educate the customer better in how to do iterative development;
                > - set expectations that design change stories are ok, but that
                > - all stories are injected only at the beginning of the iteration;
                > - shorten the iteration;
                > - increase design review within the team to reduce changes;
                > - make cost of jerking around more visible to the customer;
                > - try to speed up customer design review, perhaps with more drops.
                >
                > And all this I'd be doing iteratively as I listened to what people
                > said and observed what they do. As it happens, I'm not there, and no
                > one with any deep experience in Agile is there. I can advise by
                > email and maybe some of the parties involved are on these lists. If
                > so, they might just listen, or they might chime in.
                >
                > My basic view is that the customer is right to care about design,
                > and can't fix the remoteness issue in a timely fashion. I assert
                > that this breaks a lot of principles that really matter, and places
                > the project at higher risk than we would like.
                >
                > (This is, by the way, a fundamental truth that Scrum people like
                > Mike Dwyer face every day: if you do not do this stuff "right", it
                > increases some risks substantially. Some are increased essentially
                > to probability one. Most of the advice we hear about projects done
                > this way is, in effect, "well, deal with it." I don't find that
                > helpful for projects like this, and I think it encourages more
                > projects like this to happen. So I'm hoping to see some real,
                > useful, pragmatic advice here from the "Scrum in the Real World"
                > folks.)
                >
                > My purpose here is to get some discussion going, to see if other
                > ideas come up and just generally to hear what people have to say. I
                > will of course answer questions if I can and will surely comment in
                > that way that I have. And maybe some team members will show up as
                > well.
                >
                > Ron Jeffries
                > www.XProgramming.com
                > www.xprogramming.com/blog
                > Reason is and ought only to be the slave of the passions. -- David Hume
                >
              • Ron Jeffries
                Hello, Brad. On Monday, November 3, 2008, at 5:18:03 AM, you ... I don t know these things. Reading between the lines, I get skepticism, but my better side
                Message 7 of 28 , Nov 3, 2008
                • 0 Attachment
                  Hello, Brad. On Monday, November 3, 2008, at 5:18:03 AM, you
                  wrote:

                  >> The customer is concerned about the design of the eventual code, as
                  >> they intend to adopt it and maintain it. Accordingly they are asking
                  >> to be given the code to review at the end of each iteration. They
                  >> plan to request design changes based on that review. The review, of
                  >> course, will take some time.

                  > Might there be reasons for the changes in design, other than they
                  > don't trust that an iterative process can produce a "good" design?
                  > Are they worried about optimization? Do they have some standards or
                  > requirements which they haven't communicated before this? Do they
                  > expect the code to be used for other projects after this one is done?

                  > Or is it simply the skepticism?

                  I don't know these things. Reading between the lines, I get
                  skepticism, but my better side suggests that there is room for
                  plenty of discussion and understanding here.

                  Ron Jeffries
                  www.XProgramming.com
                  www.xprogramming.com/blog
                  Master your instrument, master the music,
                  and then forget all that *!xy!@ and just play. -- Charlie Parker
                • Keith Ray
                  How having that customer pair with the team on coding and testing? Sent from my iPhone On Nov 3, 2008, at 4:58 AM, Ron Jeffries
                  Message 8 of 28 , Nov 3, 2008
                  • 0 Attachment
                    How having that customer pair with the team on coding and testing?

                    Sent from my iPhone

                    On Nov 3, 2008, at 4:58 AM, Ron Jeffries
                    <ronjeffries@...> wrote:

                    > I'm cross-posting this to xp and scrum lists, as I'm interested in
                    > both sides' ideas. This is a real situation. Names have been changed
                    > to protect the innocent.
                    >
                    > We have a Scrum-style contract programming project, using two week
                    > iterations. The customer is remote from the team and meets with them
                    > at iteration end/begin time. The team are relatively new to
                    > programming and to Scrum. The customer is also new to Scrum and has
                    > serious doubts about it.
                    >
                    > The customer is concerned about the design of the eventual code, as
                    > they intend to adopt it and maintain it. Accordingly they are asking
                    > to be given the code to review at the end of each iteration. They
                    > plan to request design changes based on that review. The review, of
                    > course, will take some time.
                    >
                    > So what will happen is that iteration n+1 will start, and then the
                    > customer will come in halfway through the iteration with design
                    > changes and will want them done "immediately".
                    >
                    > Now in fact I suspect that the customer is right to want to keep an
                    > eye on the design, as the code will eventually be theirs, and they
                    > have no real reason to believe that a good design will evolve. Since
                    > the team is new to iterative (and somewhat new to programming) there
                    > is valid reason to want to review the design in my opinion as well.
                    >
                    > Now if I were coaching this project I would be thinking along these
                    > lines:
                    >
                    > - educate the customer better in how to do iterative development;
                    > - set expectations that design change stories are ok, but that
                    > - all stories are injected only at the beginning of the iteration;
                    > - shorten the iteration;
                    > - increase design review within the team to reduce changes;
                    > - make cost of jerking around more visible to the customer;
                    > - try to speed up customer design review, perhaps with more drops.
                    >
                    > And all this I'd be doing iteratively as I listened to what people
                    > said and observed what they do. As it happens, I'm not there, and no
                    > one with any deep experience in Agile is there. I can advise by
                    > email and maybe some of the parties involved are on these lists. If
                    > so, they might just listen, or they might chime in.
                    >
                    > My basic view is that the customer is right to care about design,
                    > and can't fix the remoteness issue in a timely fashion. I assert
                    > that this breaks a lot of principles that really matter, and places
                    > the project at higher risk than we would like.
                    >
                    > (This is, by the way, a fundamental truth that Scrum people like
                    > Mike Dwyer face every day: if you do not do this stuff "right", it
                    > increases some risks substantially. Some are increased essentially
                    > to probability one. Most of the advice we hear about projects done
                    > this way is, in effect, "well, deal with it." I don't find that
                    > helpful for projects like this, and I think it encourages more
                    > projects like this to happen. So I'm hoping to see some real,
                    > useful, pragmatic advice here from the "Scrum in the Real World"
                    > folks.)
                    >
                    > My purpose here is to get some discussion going, to see if other
                    > ideas come up and just generally to hear what people have to say. I
                    > will of course answer questions if I can and will surely comment in
                    > that way that I have. And maybe some team members will show up as
                    > well.
                    >
                    > Ron Jeffries
                    > www.XProgramming.com
                    > www.xprogramming.com/blog
                    > Reason is and ought only to be the slave of the passions. -- David
                    > Hume
                    >
                    >
                    > ------------------------------------
                    >
                    > To Post a message, send it to: extremeprogramming@...
                    >
                    > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                    >
                    > ad-free courtesy of objectmentor.comYahoo! Groups Links
                    >
                    >
                    >
                  • Ron Jeffries
                    Hello, Keith. On Monday, November 3, 2008, at 7:29:39 AM, you ... Not co-present. Ron Jeffries www.XProgramming.com www.xprogramming.com/blog Speak the
                    Message 9 of 28 , Nov 3, 2008
                    • 0 Attachment
                      Hello, Keith. On Monday, November 3, 2008, at 7:29:39 AM, you
                      wrote:

                      > How having that customer pair with the team on coding and testing?

                      Not co-present.

                      Ron Jeffries
                      www.XProgramming.com
                      www.xprogramming.com/blog
                      Speak the affirmative; emphasize your choice
                      by utterly ignoring all that you reject. -- Ralph Waldo Emerson
                    • Ron Jeffries
                      Hello, Steven. This would of course be good. I don t think it s going to happen: the relationship is probably not like that. In any case I d like us to assume
                      Message 10 of 28 , Nov 3, 2008
                      • 0 Attachment
                        Hello, Steven.

                        This would of course be good. I don't think it's going to happen:
                        the relationship is probably not like that. In any case I'd like us
                        to assume that a bit longer ...

                        Thanks,

                        R

                        On Monday, November 3, 2008, at 7:20:14 AM, you wrote:

                        > In similar situations I have asked the customer to assign one of their
                        > own most trusted software engineers to be an active developer on the
                        > project. I would make the case that doing so would:
                        > - be less disruptive to the delivery of value than so many external
                        > code reviews,
                        > - end up being less expensive in terms of hours than so many external
                        > code reviews,
                        > - be at least as effective in assuring good design, since promiscuous
                        > pair programming would mean that the developer would actively work on
                        > every part of the design and code,
                        > - pay off in greater productivity due to the extra working developer, and
                        > - would provide a knowledgeable internal oracle to whatever team
                        > eventually maintains the software.



                        Ron Jeffries
                        www.XProgramming.com
                        www.xprogramming.com/blog
                        Without practice, no emergence. -- Dougen Zenji
                      • Mike Coon
                        Hey Ron Given the various constraints - new programmers, new to Scrum, separated team, concerned customer. I might try to do a design workshop where the
                        Message 11 of 28 , Nov 3, 2008
                        • 0 Attachment
                          Hey Ron

                          Given the various constraints - new programmers, new to Scrum, separated
                          team, concerned customer. I might try to do a design workshop where the
                          customer has the opportunity to discuss design philosophy with the team -
                          and even set some arbitrary seeming criteria for design - violations of the
                          criteria must be defended and agreed upon.
                          Having the team go in blind to the design preferences of the customer
                          (assuming they are going in blind) sets them up to be judged and criticized
                          for a simple difference of taste, and risks a lot of churn as you describe
                          in the original posting.

                          What XP practices are being used if any?

                          Mike

                          On Mon, Nov 3, 2008 at 10:36 AM, Ron Jeffries
                          <ronjeffries@...>wrote:

                          > Hello, Steven.
                          >
                          > This would of course be good. I don't think it's going to happen:
                          > the relationship is probably not like that. In any case I'd like us
                          > to assume that a bit longer ...
                          >
                          > Thanks,
                          >
                          > R
                          >
                          >
                          > On Monday, November 3, 2008, at 7:20:14 AM, you wrote:
                          >
                          > > In similar situations I have asked the customer to assign one of their
                          > > own most trusted software engineers to be an active developer on the
                          > > project. I would make the case that doing so would:
                          > > - be less disruptive to the delivery of value than so many external
                          > > code reviews,
                          > > - end up being less expensive in terms of hours than so many external
                          > > code reviews,
                          > > - be at least as effective in assuring good design, since promiscuous
                          > > pair programming would mean that the developer would actively work on
                          > > every part of the design and code,
                          > > - pay off in greater productivity due to the extra working developer, and
                          > > - would provide a knowledgeable internal oracle to whatever team
                          > > eventually maintains the software.
                          >
                          > Ron Jeffries
                          > www.XProgramming.com
                          > www.xprogramming.com/blog
                          > Without practice, no emergence. -- Dougen Zenji
                          >
                          >
                          >



                          --
                          http://mikeonitstuff.net/ New Blog
                          http://mikeonitstuff.com/ Old Blog
                          http://mikeonbikes.blogspot.com/


                          [Non-text portions of this message have been removed]
                        • Dale Emery
                          Hi Ron, So what will happen is that iteration n+1 will start, and then the customer ... I notice a few things to appreciate about this customer. First, the
                          Message 12 of 28 , Nov 3, 2008
                          • 0 Attachment
                            Hi Ron,

                            So what will happen is that iteration n+1 will start, and then the customer
                            > will come in halfway through the iteration with design changes and will want
                            > them done "immediately".


                            I notice a few things to appreciate about this customer.

                            First, the customer is responding not to speculative fears about what code
                            the team might write, but to actual code as written. This implies that the
                            customer is willing to work on the design iteratively rather than demanding
                            BDUF. That suggests a certain amount of trust in the development team, a
                            trust that is based on very little experience. That's worth noting. And
                            the customer is giving specific feedback quickly.

                            Second, the customer is issuing not complaints, but specific design
                            changes. Each design change gives the team an opportunity to learn
                            something new about the customer's important design criteria. I would want
                            the team to have a conversation with the customer to understand what
                            benefits the customer sees in each design change, so that the team can learn
                            to attend to those benefits on their own during the normal course of
                            development, and can deliver code that satisfies those concerns earlier.

                            Expressing these appreciations will help the customer to know that the team
                            cares about the customer's concerns. and will continue to improve how it
                            attends to those concerns.

                            Dale

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


                            [Non-text portions of this message have been removed]
                          • Steven Campbell
                            Try it for an iteration, and see what happens. The likelihood is nothing, i.e. the customer does not really have time to do code reviews. On Mon, Nov 3, 2008
                            Message 13 of 28 , Nov 3, 2008
                            • 0 Attachment
                              Try it for an iteration, and see what happens. The likelihood is
                              nothing, i.e. the customer does not really have time to do code
                              reviews.

                              On Mon, Nov 3, 2008 at 6:58 AM, Ron Jeffries
                              <ronjeffries@...> wrote:
                              > I'm cross-posting this to xp and scrum lists, as I'm interested in
                              > both sides' ideas. This is a real situation. Names have been changed
                              > to protect the innocent.
                              >
                              > We have a Scrum-style contract programming project, using two week
                              > iterations. The customer is remote from the team and meets with them
                              > at iteration end/begin time. The team are relatively new to
                              > programming and to Scrum. The customer is also new to Scrum and has
                              > serious doubts about it.
                              >
                              > The customer is concerned about the design of the eventual code, as
                              > they intend to adopt it and maintain it. Accordingly they are asking
                              > to be given the code to review at the end of each iteration. They
                              > plan to request design changes based on that review. The review, of
                              > course, will take some time.
                              >
                              > So what will happen is that iteration n+1 will start, and then the
                              > customer will come in halfway through the iteration with design
                              > changes and will want them done "immediately".
                              >
                              > Now in fact I suspect that the customer is right to want to keep an
                              > eye on the design, as the code will eventually be theirs, and they
                              > have no real reason to believe that a good design will evolve. Since
                              > the team is new to iterative (and somewhat new to programming) there
                              > is valid reason to want to review the design in my opinion as well.
                              >
                              > Now if I were coaching this project I would be thinking along these
                              > lines:
                              >
                              > - educate the customer better in how to do iterative development;
                              > - set expectations that design change stories are ok, but that
                              > - all stories are injected only at the beginning of the iteration;
                              > - shorten the iteration;
                              > - increase design review within the team to reduce changes;
                              > - make cost of jerking around more visible to the customer;
                              > - try to speed up customer design review, perhaps with more drops.
                              >
                              > And all this I'd be doing iteratively as I listened to what people
                              > said and observed what they do. As it happens, I'm not there, and no
                              > one with any deep experience in Agile is there. I can advise by
                              > email and maybe some of the parties involved are on these lists. If
                              > so, they might just listen, or they might chime in.
                              >
                              > My basic view is that the customer is right to care about design,
                              > and can't fix the remoteness issue in a timely fashion. I assert
                              > that this breaks a lot of principles that really matter, and places
                              > the project at higher risk than we would like.
                              >
                              > (This is, by the way, a fundamental truth that Scrum people like
                              > Mike Dwyer face every day: if you do not do this stuff "right", it
                              > increases some risks substantially. Some are increased essentially
                              > to probability one. Most of the advice we hear about projects done
                              > this way is, in effect, "well, deal with it." I don't find that
                              > helpful for projects like this, and I think it encourages more
                              > projects like this to happen. So I'm hoping to see some real,
                              > useful, pragmatic advice here from the "Scrum in the Real World"
                              > folks.)
                              >
                              > My purpose here is to get some discussion going, to see if other
                              > ideas come up and just generally to hear what people have to say. I
                              > will of course answer questions if I can and will surely comment in
                              > that way that I have. And maybe some team members will show up as
                              > well.
                              >
                              > Ron Jeffries
                              > www.XProgramming.com
                              > www.xprogramming.com/blog
                              > Reason is and ought only to be the slave of the passions. -- David Hume
                              >
                              >



                              --
                              Steve Campbell
                              http://blog.perfectapi.com/
                            • Ron Jeffries
                              Hello, lior. On Monday, November 3, 2008, at 5:37:28 AM, you ... Yes, certainly interrupting the sprint is fundamentally dumb. Scheduling them as stories
                              Message 14 of 28 , Nov 3, 2008
                              • 0 Attachment
                                Hello, lior. On Monday, November 3, 2008, at 5:37:28 AM, you
                                wrote:

                                > The up side of scheduling them as regular stories for iteration n+2 is:

                                > 1) The team wont get disrupted.

                                > 2) (and this is a nasty side effect that might be good or not) I think
                                > that like any refactoring work I've faced, the "value" of these will be
                                > dwarfed when stacked against "real" business stories. I have a feeling that
                                > if you manage to get the customer to prioritize them normally at the start
                                > of the iteration a lot of them would just go away. Again I'm not sure if
                                > this is good or bad but I think that the dev team will like that.

                                Yes, certainly interrupting the sprint is fundamentally dumb.
                                Scheduling them as stories should, as you suggest, help the customer
                                see the relative value, or lack of it, of futzing with the design.

                                Ron Jeffries
                                www.XProgramming.com
                                www.xprogramming.com/blog
                                It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
                              • Ron Jeffries
                                Hello, Mike. On Monday, November 3, 2008, at 8:05:15 AM, you ... Yes, excellent idea! Rather than shoot and miss, let s find out what the target is before we
                                Message 15 of 28 , Nov 3, 2008
                                • 0 Attachment
                                  Hello, Mike. On Monday, November 3, 2008, at 8:05:15 AM, you
                                  wrote:

                                  > Given the various constraints - new programmers, new to Scrum, separated
                                  > team, concerned customer. I might try to do a design workshop where the
                                  > customer has the opportunity to discuss design philosophy with the team -
                                  > and even set some arbitrary seeming criteria for design - violations of the
                                  > criteria must be defended and agreed upon.
                                  > Having the team go in blind to the design preferences of the customer
                                  > (assuming they are going in blind) sets them up to be judged and criticized
                                  > for a simple difference of taste, and risks a lot of churn as you describe
                                  > in the original posting.

                                  Yes, excellent idea! Rather than shoot and miss, let's find out what
                                  the target is before we shoot.

                                  > What XP practices are being used if any?

                                  I don't know in detail. Kind of pairing, kind of iterative, kind of
                                  TDD, kind of acceptance tests. I'm guessing I'd give them between a
                                  30 and 50 out of 100. But I really don't know.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  www.xprogramming.com/blog
                                  Sorry about your cow ... I didn't know she was sacred.
                                • Ron Jeffries
                                  Hello, Dale. Very interesting ... I m not /sure/ I believe those things, though I would appreciate them if I did. Makes me want to determine whether they are
                                  Message 16 of 28 , Nov 3, 2008
                                  • 0 Attachment
                                    Hello, Dale.

                                    Very interesting ... I'm not /sure/ I believe those things, though I
                                    would appreciate them if I did. Makes me want to determine whether
                                    they are true ... or help them to become true.

                                    Thanks!

                                    R

                                    On Monday, November 3, 2008, at 10:27:52 AM, you wrote:

                                    > I notice a few things to appreciate about this customer.

                                    > First, the customer is responding not to speculative fears about what code
                                    > the team might write, but to actual code as written. This implies that the
                                    > customer is willing to work on the design iteratively rather than demanding
                                    > BDUF. That suggests a certain amount of trust in the development team, a
                                    > trust that is based on very little experience. That's worth noting. And
                                    > the customer is giving specific feedback quickly.

                                    > Second, the customer is issuing not complaints, but specific design
                                    > changes. Each design change gives the team an opportunity to learn
                                    > something new about the customer's important design criteria. I would want
                                    > the team to have a conversation with the customer to understand what
                                    > benefits the customer sees in each design change, so that the team can learn
                                    > to attend to those benefits on their own during the normal course of
                                    > development, and can deliver code that satisfies those concerns earlier.

                                    > Expressing these appreciations will help the customer to know that the team
                                    > cares about the customer's concerns. and will continue to improve how it
                                    > attends to those concerns.



                                    Ron Jeffries
                                    www.XProgramming.com
                                    www.xprogramming.com/blog
                                    He who will not apply new remedies must expect old evils. -- Francis Bacon
                                  • Ron Jeffries
                                    Hello, Steven. On Monday, November 3, 2008, at 10:48:46 AM, you ... Ron Jeffries www.XProgramming.com www.xprogramming.com/blog But the attitude of faith is
                                    Message 17 of 28 , Nov 3, 2008
                                    • 0 Attachment
                                      Hello, Steven. On Monday, November 3, 2008, at 10:48:46 AM, you
                                      wrote:

                                      > Try it for an iteration, and see what happens. The likelihood is
                                      > nothing, i.e. the customer does not really have time to do code
                                      > reviews.

                                      :) Very interesting and quite possibly true!

                                      Ron Jeffries
                                      www.XProgramming.com
                                      www.xprogramming.com/blog
                                      But the attitude of faith is to let go, and become open to
                                      truth, whatever it might turn out to be. -- Alan Watts
                                    • Jeff Grigg
                                      ... Personally, I think that the idea that the customer will review the code and suggest changes is great. One customer who saw my TDD code on a test problem
                                      Message 18 of 28 , Nov 3, 2008
                                      • 0 Attachment
                                        --- Ron Jeffries <ronjeffries@...> wrote:
                                        > We have a Scrum-style contract programming project, using
                                        > two week iterations. [...]

                                        Personally, I think that the idea that the customer will review the
                                        code and suggest changes is great. One customer who saw my TDD code
                                        on a test problem said that it was the best code they'd ever seen.
                                        Another, assigned to review code, asked for permission to skip all
                                        my code (IE: not review it) because it was of such high quality they
                                        couldn't think of any way to improve it. (However, I could think of
                                        ways of improving both problems, and I'm sure many on this list
                                        could too. ;-)

                                        > [...] the customer will come in halfway through the iteration
                                        > with design changes and will want them done "immediately".

                                        Abort the scrum. Start a new scrum.
                                        Those are the rules.

                                        Or, one could accept that the scrums are a week long, rather than
                                        two. ;->

                                        In any case, user-specified architectural requirements are stories.
                                        They need to be estimated, and they take space in the iteration.
                                        They force out other stories, if they're top priority.


                                        > - increase design review within the team to reduce changes;

                                        This is good, but it may be difficult to predict what the customer
                                        will want. ;->

                                        > - make cost of jerking around more visible to the customer;

                                        Yes.

                                        > - try to speed up customer design review, perhaps with
                                        > more drops.

                                        That could be a good idea. Submit "stories" to them, for code
                                        review, as they're completed, for example.


                                        (All of these are just my ideas. Maybe they'll work for you. ;-)
                                      • Jeff Grigg
                                        ... P.S. I m assuming here that the customer-requested (demanded) architectural improvements would not be needed to resolve code smells. If the customer s
                                        Message 19 of 28 , Nov 3, 2008
                                        • 0 Attachment
                                          --- "Jeff Grigg" <jeffgrigg@...> wrote:
                                          > In any case, user-specified architectural requirements
                                          > are stories. They need to be estimated, and they take
                                          > space in the iteration.

                                          P.S. I'm assuming here that the customer-requested (demanded)
                                          architectural improvements would not be needed to resolve code smells.

                                          If the customer's changes resolve code smells, then they wouldn't be
                                          stories; it's work the team "should have done" already. But if the
                                          customer's changes violate YAGNI, then they're user stories, not bug
                                          fixes or refactorings.
                                        • D. André Dhondt
                                          ... If the customer has specific feedback (i.e., a design change), why should we be the ones to put up resistance to it? I thought that being able to
                                          Message 20 of 28 , Nov 4, 2008
                                          • 0 Attachment
                                            >...iteration n+1 will start, and then the
                                            >customer will come in halfway through the
                                            > iteration with design changes and will
                                            > want them done "immediately

                                            If the customer has specific feedback (i.e., a design change), why should we
                                            be the ones to put up resistance to it? I thought that being able to
                                            incorporate feedback was a good, _agile_, thing. Take those suggestions,
                                            write up a story card (even if it's in technical lingo--the focus for story
                                            cards is that they need to be written in a way the customer understands, and
                                            if the customer is technical--this is easy!), estimate it, then ask the
                                            customer to trade that card with something else in this iteration. It may
                                            be difficult to know, day to day, what the iteration will look like as a
                                            whole, but as long as the customer is willing to wait until a natural
                                            breaking point (a pair finishes a story card) before this new
                                            design-change-story is started, there won't be much lost effort. I'd also
                                            encourage the client to review in smaller chunks, to get more feedback
                                            sooner, so that we minimize the churn.

                                            On Mon, Nov 3, 2008 at 1:58 PM, Ron Jeffries
                                            <ronjeffries@...>wrote:

                                            > I'm cross-posting this to xp and scrum lists, as I'm interested in
                                            > both sides' ideas. This is a real situation. Names have been changed
                                            > to protect the innocent.
                                            >
                                            > We have a Scrum-style contract programming project, using two week
                                            > iterations. The customer is remote from the team and meets with them
                                            > at iteration end/begin time. The team are relatively new to
                                            > programming and to Scrum. The customer is also new to Scrum and has
                                            > serious doubts about it.
                                            >
                                            > The customer is concerned about the design of the eventual code, as
                                            > they intend to adopt it and maintain it. Accordingly they are asking
                                            > to be given the code to review at the end of each iteration. They
                                            > plan to request design changes based on that review. The review, of
                                            > course, will take some time.
                                            >
                                            > So what will happen is that iteration n+1 will start, and then the
                                            > customer will come in halfway through the iteration with design
                                            > changes and will want them done "immediately".
                                            >
                                            > Now in fact I suspect that the customer is right to want to keep an
                                            > eye on the design, as the code will eventually be theirs, and they
                                            > have no real reason to believe that a good design will evolve. Since
                                            > the team is new to iterative (and somewhat new to programming) there
                                            > is valid reason to want to review the design in my opinion as well.
                                            >
                                            > Now if I were coaching this project I would be thinking along these
                                            > lines:
                                            >
                                            > - educate the customer better in how to do iterative development;
                                            > - set expectations that design change stories are ok, but that
                                            > - all stories are injected only at the beginning of the iteration;
                                            > - shorten the iteration;
                                            > - increase design review within the team to reduce changes;
                                            > - make cost of jerking around more visible to the customer;
                                            > - try to speed up customer design review, perhaps with more drops.
                                            >
                                            > And all this I'd be doing iteratively as I listened to what people
                                            > said and observed what they do. As it happens, I'm not there, and no
                                            > one with any deep experience in Agile is there. I can advise by
                                            > email and maybe some of the parties involved are on these lists. If
                                            > so, they might just listen, or they might chime in.
                                            >
                                            > My basic view is that the customer is right to care about design,
                                            > and can't fix the remoteness issue in a timely fashion. I assert
                                            > that this breaks a lot of principles that really matter, and places
                                            > the project at higher risk than we would like.
                                            >
                                            > (This is, by the way, a fundamental truth that Scrum people like
                                            > Mike Dwyer face every day: if you do not do this stuff "right", it
                                            > increases some risks substantially. Some are increased essentially
                                            > to probability one. Most of the advice we hear about projects done
                                            > this way is, in effect, "well, deal with it." I don't find that
                                            > helpful for projects like this, and I think it encourages more
                                            > projects like this to happen. So I'm hoping to see some real,
                                            > useful, pragmatic advice here from the "Scrum in the Real World"
                                            > folks.)
                                            >
                                            > My purpose here is to get some discussion going, to see if other
                                            > ideas come up and just generally to hear what people have to say. I
                                            > will of course answer questions if I can and will surely comment in
                                            > that way that I have. And maybe some team members will show up as
                                            > well.
                                            >
                                            > Ron Jeffries
                                            > www.XProgramming.com
                                            > www.xprogramming.com/blog
                                            > Reason is and ought only to be the slave of the passions. -- David Hume
                                            >
                                            >
                                            >



                                            --
                                            D. André Dhondt
                                            mobile: 001 33 671 034 984


                                            [Non-text portions of this message have been removed]
                                          • Craig Davidson
                                            Hi Ron, Would it help for the Customer to write the Coding Standard? With that in mind could it then become possible for the Customer s Design issues to be
                                            Message 21 of 28 , Nov 4, 2008
                                            • 0 Attachment
                                              Hi Ron,

                                              Would it help for the Customer to write the Coding Standard?
                                              With that in mind could it then become possible for the Customer's
                                              Design issues to be build as automated tests (e.g. in the Java world
                                              we could build something with: PMD, CheckStyle, FindBugs, etc).
                                              Any "differences of opinion" could then be tracked on a "design
                                              quality" burn-down chart to track the on-going design issues.

                                              While it wouldn't resolve those differences of opinion, it would make
                                              identifying and tracking them easier for all parties - until
                                              confidence and trust settled things down.

                                              Cheers,

                                              Craig

                                              2008/11/3 Ron Jeffries <ronjeffries@...>:
                                              > I'm cross-posting this to xp and scrum lists, as I'm interested in
                                              > both sides' ideas. This is a real situation. Names have been changed
                                              > to protect the innocent.
                                              >
                                              > We have a Scrum-style contract programming project, using two week
                                              > iterations. The customer is remote from the team and meets with them
                                              > at iteration end/begin time. The team are relatively new to
                                              > programming and to Scrum. The customer is also new to Scrum and has
                                              > serious doubts about it.
                                              >
                                              > The customer is concerned about the design of the eventual code, as
                                              > they intend to adopt it and maintain it. Accordingly they are asking
                                              > to be given the code to review at the end of each iteration. They
                                              > plan to request design changes based on that review. The review, of
                                              > course, will take some time.
                                              >
                                              > So what will happen is that iteration n+1 will start, and then the
                                              > customer will come in halfway through the iteration with design
                                              > changes and will want them done "immediately".
                                              >
                                              > Now in fact I suspect that the customer is right to want to keep an
                                              > eye on the design, as the code will eventually be theirs, and they
                                              > have no real reason to believe that a good design will evolve. Since
                                              > the team is new to iterative (and somewhat new to programming) there
                                              > is valid reason to want to review the design in my opinion as well.
                                              >
                                              > Now if I were coaching this project I would be thinking along these
                                              > lines:
                                              >
                                              > - educate the customer better in how to do iterative development;
                                              > - set expectations that design change stories are ok, but that
                                              > - all stories are injected only at the beginning of the iteration;
                                              > - shorten the iteration;
                                              > - increase design review within the team to reduce changes;
                                              > - make cost of jerking around more visible to the customer;
                                              > - try to speed up customer design review, perhaps with more drops.
                                              >
                                              > And all this I'd be doing iteratively as I listened to what people
                                              > said and observed what they do. As it happens, I'm not there, and no
                                              > one with any deep experience in Agile is there. I can advise by
                                              > email and maybe some of the parties involved are on these lists. If
                                              > so, they might just listen, or they might chime in.
                                              >
                                              > My basic view is that the customer is right to care about design,
                                              > and can't fix the remoteness issue in a timely fashion. I assert
                                              > that this breaks a lot of principles that really matter, and places
                                              > the project at higher risk than we would like.
                                              >
                                              > (This is, by the way, a fundamental truth that Scrum people like
                                              > Mike Dwyer face every day: if you do not do this stuff "right", it
                                              > increases some risks substantially. Some are increased essentially
                                              > to probability one. Most of the advice we hear about projects done
                                              > this way is, in effect, "well, deal with it." I don't find that
                                              > helpful for projects like this, and I think it encourages more
                                              > projects like this to happen. So I'm hoping to see some real,
                                              > useful, pragmatic advice here from the "Scrum in the Real World"
                                              > folks.)
                                              >
                                              > My purpose here is to get some discussion going, to see if other
                                              > ideas come up and just generally to hear what people have to say. I
                                              > will of course answer questions if I can and will surely comment in
                                              > that way that I have. And maybe some team members will show up as
                                              > well.
                                              >
                                              > Ron Jeffries
                                              > www.XProgramming.com
                                              > www.xprogramming.com/blog
                                              > Reason is and ought only to be the slave of the passions. -- David Hume
                                              >
                                              >
                                              > ------------------------------------
                                              >
                                              > To Post a message, send it to: extremeprogramming@...
                                              >
                                              > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                              >
                                              > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                              >
                                              >
                                              >
                                              >
                                            • Jeff Grigg
                                              ... Would metrics, like code coverage be helpful? ... It might be good to run tools like these (PMD, CheckStyle, FindBugs) and see what the customer and the
                                              Message 22 of 28 , Nov 4, 2008
                                              • 0 Attachment
                                                --- "Craig Davidson" <craigmdavidson@...> wrote:
                                                > Would it help for the Customer to write the Coding Standard?

                                                Would metrics, like code coverage be helpful?

                                                > [...] the Customer's Design issues [...] as automated tests
                                                > (e.g. in the Java world we could build something with: PMD,
                                                > CheckStyle, FindBugs, etc).

                                                It might be good to run tools like these (PMD, CheckStyle, FindBugs)
                                                and see what the customer and the team think of them. (Sometimes I
                                                think PMD has a split personality disorder: It complains about
                                                something being X, then when I change it, it complains about the
                                                thing not being X. The good point is that it points out some things
                                                to think about. The bad point is pointy-haired-bosses who demand
                                                that all the "warnings" be cleared.)

                                                > Any "differences of opinion" could then be tracked on a "design
                                                > quality" burn-down chart to track the on-going design issues.

                                                This could be good.
                                              • Ricardo Mayerhofer
                                                If possible, I would include in the concept of done , having the design reviewed by the customer. So no story is done done until reviewed. This is good
                                                Message 23 of 28 , Nov 4, 2008
                                                • 0 Attachment
                                                  If possible, I would include in the concept of "done", having the design
                                                  reviewed by the customer. So no story is done done until reviewed.
                                                  This is good because the team gets rapid feedback and makes easy to know
                                                  wheter the review process is a bottleneck and if it impacts teams velocity.

                                                  I think with constant feedback the team will learn how to better meet
                                                  customers' design expectation.

                                                  Ron Jeffries escreveu:
                                                  > I'm cross-posting this to xp and scrum lists, as I'm interested in
                                                  > both sides' ideas. This is a real situation. Names have been changed
                                                  > to protect the innocent.
                                                  >
                                                  > We have a Scrum-style contract programming project, using two week
                                                  > iterations. The customer is remote from the team and meets with them
                                                  > at iteration end/begin time. The team are relatively new to
                                                  > programming and to Scrum. The customer is also new to Scrum and has
                                                  > serious doubts about it.
                                                  >
                                                  > The customer is concerned about the design of the eventual code, as
                                                  > they intend to adopt it and maintain it. Accordingly they are asking
                                                  > to be given the code to review at the end of each iteration. They
                                                  > plan to request design changes based on that review. The review, of
                                                  > course, will take some time.
                                                  >
                                                  > So what will happen is that iteration n+1 will start, and then the
                                                  > customer will come in halfway through the iteration with design
                                                  > changes and will want them done "immediately".
                                                  >
                                                  > Now in fact I suspect that the customer is right to want to keep an
                                                  > eye on the design, as the code will eventually be theirs, and they
                                                  > have no real reason to believe that a good design will evolve. Since
                                                  > the team is new to iterative (and somewhat new to programming) there
                                                  > is valid reason to want to review the design in my opinion as well.
                                                  >
                                                  > Now if I were coaching this project I would be thinking along these
                                                  > lines:
                                                  >
                                                  > - educate the customer better in how to do iterative development;
                                                  > - set expectations that design change stories are ok, but that
                                                  > - all stories are injected only at the beginning of the iteration;
                                                  > - shorten the iteration;
                                                  > - increase design review within the team to reduce changes;
                                                  > - make cost of jerking around more visible to the customer;
                                                  > - try to speed up customer design review, perhaps with more drops.
                                                  >
                                                  > And all this I'd be doing iteratively as I listened to what people
                                                  > said and observed what they do. As it happens, I'm not there, and no
                                                  > one with any deep experience in Agile is there. I can advise by
                                                  > email and maybe some of the parties involved are on these lists. If
                                                  > so, they might just listen, or they might chime in.
                                                  >
                                                  > My basic view is that the customer is right to care about design,
                                                  > and can't fix the remoteness issue in a timely fashion. I assert
                                                  > that this breaks a lot of principles that really matter, and places
                                                  > the project at higher risk than we would like.
                                                  >
                                                  > (This is, by the way, a fundamental truth that Scrum people like
                                                  > Mike Dwyer face every day: if you do not do this stuff "right", it
                                                  > increases some risks substantially. Some are increased essentially
                                                  > to probability one. Most of the advice we hear about projects done
                                                  > this way is, in effect, "well, deal with it." I don't find that
                                                  > helpful for projects like this, and I think it encourages more
                                                  > projects like this to happen. So I'm hoping to see some real,
                                                  > useful, pragmatic advice here from the "Scrum in the Real World"
                                                  > folks.)
                                                  >
                                                  > My purpose here is to get some discussion going, to see if other
                                                  > ideas come up and just generally to hear what people have to say. I
                                                  > will of course answer questions if I can and will surely comment in
                                                  > that way that I have. And maybe some team members will show up as
                                                  > well.
                                                  >
                                                  > Ron Jeffries
                                                  > www.XProgramming.com
                                                  > www.xprogramming.com/blog
                                                  > Reason is and ought only to be the slave of the passions. -- David Hume
                                                  >
                                                  >
                                                  > ------------------------------------
                                                  >
                                                  > To Post a message, send it to: extremeprogramming@...
                                                  >
                                                  > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                                  >
                                                  > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                                  >
                                                  >
                                                  >
                                                  >
                                                • Ron Jeffries
                                                  Hello, Jeff. On Monday, November 3, 2008, at 8:32:04 PM, you ... Yes. I think no one really does that tho ... ... I d like them to go to 1 week anyway ... ...
                                                  Message 24 of 28 , Nov 4, 2008
                                                  • 0 Attachment
                                                    Hello, Jeff. On Monday, November 3, 2008, at 8:32:04 PM, you
                                                    wrote:

                                                    > Abort the scrum. Start a new scrum.
                                                    > Those are the rules.

                                                    Yes. I think no one really does that tho ...

                                                    > Or, one could accept that the scrums are a week long, rather than
                                                    > two. ;->

                                                    I'd like them to go to 1 week anyway ...

                                                    > In any case, user-specified architectural requirements are stories.
                                                    > They need to be estimated, and they take space in the iteration.
                                                    > They force out other stories, if they're top priority.

                                                    Yes ...

                                                    Ron Jeffries
                                                    www.XProgramming.com
                                                    www.xprogramming.com/blog
                                                    Will Turner: This is either madness or brilliance.
                                                    Captain Jack Sparrow: It's remarkable how often those two traits coincide.
                                                  • Ron Jeffries
                                                    Hello, D.. On Tuesday, November 4, 2008, at 12:23:31 AM, you ... It could work. I think it s a bug to be always allowing the iteration to get changed tho. Ron
                                                    Message 25 of 28 , Nov 4, 2008
                                                    • 0 Attachment
                                                      Hello, D.. On Tuesday, November 4, 2008, at 12:23:31 AM, you
                                                      wrote:

                                                      > If the customer has specific feedback (i.e., a design change), why should we
                                                      > be the ones to put up resistance to it? I thought that being able to
                                                      > incorporate feedback was a good, _agile_, thing. Take those suggestions,
                                                      > write up a story card (even if it's in technical lingo--the focus for story
                                                      > cards is that they need to be written in a way the customer understands, and
                                                      > if the customer is technical--this is easy!), estimate it, then ask the
                                                      > customer to trade that card with something else in this iteration. It may
                                                      > be difficult to know, day to day, what the iteration will look like as a
                                                      > whole, but as long as the customer is willing to wait until a natural
                                                      > breaking point (a pair finishes a story card) before this new
                                                      > design-change-story is started, there won't be much lost effort. I'd also
                                                      > encourage the client to review in smaller chunks, to get more feedback
                                                      > sooner, so that we minimize the churn.

                                                      It could work. I think it's a bug to be always allowing the
                                                      iteration to get changed tho.

                                                      Ron Jeffries
                                                      www.XProgramming.com
                                                      www.xprogramming.com/blog
                                                      The fact that we know more today, and are more capable today,
                                                      is good news about today, not bad news about yesterday.
                                                    • Ron Jeffries
                                                      Hello, Craig. On Tuesday, November 4, 2008, at 2:27:02 AM, you ... Might be worth a try. I don t know what the client s real concern is. If I had concern it
                                                      Message 26 of 28 , Nov 4, 2008
                                                      • 0 Attachment
                                                        Hello, Craig. On Tuesday, November 4, 2008, at 2:27:02 AM, you
                                                        wrote:

                                                        > Would it help for the Customer to write the Coding Standard?
                                                        > With that in mind could it then become possible for the Customer's
                                                        > Design issues to be build as automated tests (e.g. in the Java world
                                                        > we could build something with: PMD, CheckStyle, FindBugs, etc).
                                                        > Any "differences of opinion" could then be tracked on a "design
                                                        > quality" burn-down chart to track the on-going design issues.

                                                        > While it wouldn't resolve those differences of opinion, it would make
                                                        > identifying and tracking them easier for all parties - until
                                                        > confidence and trust settled things down.

                                                        Might be worth a try. I don't know what the client's real concern
                                                        is. If I had concern it would be things that a coding standard can't
                                                        cover, but I'd really have to talk with them, which is not in the
                                                        cards.

                                                        Ron Jeffries
                                                        www.XProgramming.com
                                                        www.xprogramming.com/blog
                                                        Agility might be said to be about encountering
                                                        all the problems so early and so often that the
                                                        effort to fix them is less than the pain of enduring them.
                                                      • Ilja Preuß
                                                        ... Reminds me of the Bring me a rock schedule game: http://www.jrothman.com/weblog/2005/04/schedule-game-3-bring-me-rock.html Cheers, Ilja
                                                        Message 27 of 28 , Nov 5, 2008
                                                        • 0 Attachment
                                                          2008/11/3 Mike Coon <mcoon1961@...>:
                                                          > Given the various constraints - new programmers, new to Scrum, separated
                                                          > team, concerned customer. I might try to do a design workshop where the
                                                          > customer has the opportunity to discuss design philosophy with the team -
                                                          > and even set some arbitrary seeming criteria for design - violations of the
                                                          > criteria must be defended and agreed upon.
                                                          > Having the team go in blind to the design preferences of the customer
                                                          > (assuming they are going in blind) sets them up to be judged and criticized
                                                          > for a simple difference of taste, and risks a lot of churn as you describe
                                                          > in the original posting.

                                                          Reminds me of the "Bring me a rock" schedule game:
                                                          http://www.jrothman.com/weblog/2005/04/schedule-game-3-bring-me-rock.html

                                                          Cheers, Ilja
                                                        • J. B. Rainsberger
                                                          I wanted to get my thoughts out first, so I replied before reading everyone else s reply. Sorry about that. On 2008-11-03, at 05:58 , Ron Jeffries wrote:
                                                          Message 28 of 28 , Nov 8, 2008
                                                          • 0 Attachment
                                                            I wanted to get my thoughts out first, so I replied before reading
                                                            everyone else's reply. Sorry about that.

                                                            On 2008-11-03, at 05:58 , Ron Jeffries wrote:

                                                            <snip />
                                                            > So what will happen is that iteration n+1 will start, and then the
                                                            > customer will come in halfway through the iteration with design
                                                            > changes and will want them done "immediately".
                                                            >
                                                            <snip />
                                                            > My basic view is that the customer is right to care about design,
                                                            > and can't fix the remoteness issue in a timely fashion. I assert
                                                            > that this breaks a lot of principles that really matter, and places
                                                            > the project at higher risk than we would like.
                                                            >

                                                            I agree that the customer is right to care about the design; however,
                                                            unless the customer is prepared to put someone on the team to monitor
                                                            the design, then the customer needs to accept (not just understand)
                                                            that his decision reduces almost to zero the team's ability to produce
                                                            new features at a consistent pace. If the customer can live with that,
                                                            then if we wants us to stand in the corner on our head and cluck like
                                                            a chicken, it's his money.

                                                            Of course, if I got to wave my magic wand, the customer would tell the
                                                            programmers what he expects from their design and we would stop
                                                            pretending this was an evolutionary design project, but admit that
                                                            it's a bastardized version of the so-called "Surgical Team" approach.
                                                            What I call the "Kitchen Stories" project: some smart person sits atop
                                                            a highchair in the corner and dictates the design to the rest.
                                                            Evolutionary design might be a mistake here, and I would owe it to
                                                            myself to explore that.

                                                            When a manager tries to control the team's design process, I usually
                                                            ask the manager whether he'll write code with the team. When he
                                                            answers "yes", I ask him to take the role of Technical Lead of the
                                                            team. When he answers "no", I tell him that his input into our design
                                                            process is welcome, but he has no decision-making powers until he
                                                            writes code with us. It has worked well enough so far. I could
                                                            cavalierly recommend extending this principle to the customer, but
                                                            that might be higher risk than the risk of the current situation as is.

                                                            In summary, I would tell the customer that I don't know how to respond
                                                            in a timely fashion to his mid-iteration demands for design change
                                                            while maintaining a predictable pace of delivery. I might offer to
                                                            help him find a team capable of doing that, if he needed that help.
                                                            ----
                                                            J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                                                            Your guide to software craftsmanship
                                                            JUnit Recipes: Practical Methods for Programmer Testing
                                                            2005 Gordon Pask Award for contributions to Agile Software Practice
                                                          Your message has been successfully submitted and would be delivered to recipients shortly.