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

RE: [XP] Interesting Issue: Customer cares about design details.

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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.