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

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

Expand Messages
  • 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 1 of 28 , Nov 3 5:38 AM
      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 2 of 28 , Nov 3 6:49 AM
        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 3 of 28 , Nov 3 7:20 AM
          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 4 of 28 , Nov 3 7:28 AM
            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 5 of 28 , Nov 3 7:29 AM
              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 6 of 28 , Nov 3 7:35 AM
                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 7 of 28 , Nov 3 7:36 AM
                  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 8 of 28 , Nov 3 8:05 AM
                    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 9 of 28 , Nov 3 10:27 AM
                      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 10 of 28 , Nov 3 10:48 AM
                        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 11 of 28 , Nov 3 6:15 PM
                          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 12 of 28 , Nov 3 6:20 PM
                            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 13 of 28 , Nov 3 6:32 PM
                              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 14 of 28 , Nov 3 6:33 PM
                                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 15 of 28 , Nov 3 8:32 PM
                                  --- 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 16 of 28 , Nov 3 8:36 PM
                                    --- "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 17 of 28 , Nov 4 12:23 AM
                                      >...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 18 of 28 , Nov 4 2:27 AM
                                        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 19 of 28 , Nov 4 6:35 AM
                                          --- "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 20 of 28 , Nov 4 9:32 AM
                                            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 21 of 28 , Nov 4 6:33 PM
                                              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 22 of 28 , Nov 4 6:35 PM
                                                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 23 of 28 , Nov 4 6:38 PM
                                                  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 24 of 28 , Nov 5 2:24 AM
                                                    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 25 of 28 , Nov 8 4:09 PM
                                                      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.