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

Re: [XP] How much planning do we need to do?

Expand Messages
  • Ron Jeffries
    ... What if instead of rejecting it, the boss said, OK, that s good, now what I d like is ... X , resulting in a new story? After all, s/he said I don t
    Message 1 of 10 , Jun 2, 2008
    • 0 Attachment
      Hello, Pat. On Monday, June 2, 2008, at 7:33:04 AM, you wrote:

      > How much planning is too much/too little? I understand that there are
      > a lot of variables that go into answering this. I'll give details of
      > my team's particular situation and hopefully spur good discussion.

      > We're experiencing problems that I believe are due to our planning
      > process. At the beginning of the iteration we sit down with my boss
      > (who plays the customer role) to come up with new stories and to
      > review the prioritization of existing stories.

      > The key problem we have is that we get a lot of stories rejected. I'd
      > say about a third of the stories we do get rejected and need
      > additional work. I believe that it's because we don't develop a deep
      > enough shared understanding with the customer's needs. We're finding
      > it pretty difficult to do though. A very common convo/situation goes
      > like the following:

      > Customer: "I want to show a list of locations where events were
      > previously scheduled."
      > Dev: "Okay. Maybe a grid with the location name and address?"
      > C: "Yeah, that sounds good. And let's embed the Google Map view also"
      > D: "Great. Let's do a quick sketch to see what it might look like."
      > C: "I don't really care what it looks like. Anything will be fine"
      > *we go to work, mark the story delivered. at the end of the
      > iteration, customer rejects it saying it doesn't look right*

      What if instead of rejecting it, the boss said, "OK, that's good,
      now what I'd like is ... X", resulting in a new story?

      After all, s/he said "I don't really care what it looks like," so it
      is clearly passing that test.

      So I'd take the boss aside and ask to have a story that meets the
      criteria accepted and a new story created. That's probably the best
      way to go with regard to look and feel anyway.

      Or ...

      What if when a new thing like this comes along, you do a first story
      called "make the initial version" and a second story called "clean
      up the initial version"?

      Or ...

      What if you drew the GUI on paper or mocked it up before doing the
      work, and showed it to the boss?

      Or ...

      What if you said "OK, let's be sure we understand what you want,"
      went to the whiteboard, and drew up a really stupid example of the
      screen requested, and said "Like that?" If the boss says Yes, then
      leave the picture up and point to it when they go to reject. If the
      boss says No, improve the sketch.

      BTW, this is not planning, it's designing, as this example should
      make clear.


      Of these, my favorite is the first because the boss did say it
      didn't matter. So they should say "OK, and what I'd like next is
      ... X." Then it wouldn't be rejection.

      > This is really frustrating from a developer standpoint. One issue is
      > that it just doesn't feel good to have our work constantly rejected.
      > How much that counts or should count, I don't know. More importantly,
      > it screws with our planning. If we've completed a story, but then
      > have to allocate time in the next iteration to fix problems with it,
      > then we push back things that were planned for that iteration. I
      > think that's okay in small amounts, but it makes our planning less
      > useful because we can't accurately estimate what we'll be able to get
      > to.

      Things planned for the next iteration? There is nothing planned for
      the next iteration except what the customer asks for. If the
      customer asks for more work on last week's story, so be it.

      Managing the work into iterations is the boss's job. Your paragraph
      above makes it sound to me as if somehow the plan belongs to you
      (the developers?) rather than the boss.

      > The first obvious thing to do is to explain to the customer the
      > problems this causes. We've said in the past that we'd like to do
      > some deeper planning because we don't like having the stories
      > rejected. The customer said it wasn't a really big deal to him that
      > we'd deliver a story and that he'd reject it, with specific items to
      > find.

      Customer is probably right. If it doesn't bother them, so be it. But
      ask for another word.

      It comes to me that both sides may be thinking that you are supposed
      to take a story and complete everything about that story in one
      iteration. That's not the case. A story is what you commit to do in
      one iteration. If you do it, that story is done. If you don't like
      how it looks or want to add a subtotal to it, then that is a new
      story.

      > I've pointed out that it hurts our productivity because it
      > requires us to switch contexts a couple days after the fact. I
      > haven't said that it messes up our planning, because I hadn't really
      > thought of it until I wrote this message. I'm not sure what impact
      > that will have, as my boss doesn't seem to find XP-style planning
      > particularly valuable. He appears to feel that everything needs to
      > get done, and it doesn't really matter in what order.

      IMO, that may be due to not understanding the impact of change. On
      the other hand, XP planning is not about getting things right the
      first time, it is about getting them right finally.

      Are you estimating stories and laying them down roughly on the
      calendar (Release Plan)? Does the boss really have no deadline in
      mind?

      > I believe all of this is hurting the team's productivity. I'm having
      > a tough time getting into the customer's head and framing my concerns
      > in a way that really matters to him.

      I don't understand either.

      Maybe it's not really affecting anything. Maybe it takes X time to
      get the first version and Y time to clean it up. Maybe the

      > Finally, I think there's a stigma against doing too much planning.
      > We're doing about 3 hours of planning a week, which I don't consider
      > to be very much. So I realize this would vary a great deal from
      > project to project, but what is an "average" time to spend planning in
      > a week?

      You didn't say how big your team was. I would think 3 hours a week
      would be OK but not impressively low for most teams.

      But again, I don't think you're asking for planning. I think you may
      be worried about design.

      Ron Jeffries
      www.XProgramming.com
      Fear is the mindkiller. --Bene Gesserit Litany Against Fear
    • Jason McIntosh
      Acceptance Criteria like others have mentioned. That seems key. I m guessing it s pretty common for a customer to say oh it doesn t matter and then when
      Message 2 of 10 , Jun 2, 2008
      • 0 Attachment
        Acceptance Criteria like others have mentioned. That seems key. I'm
        guessing it's pretty common for a customer to say "oh it doesn't matter" and
        then when they get something turn around and say "oh gosh, that's not
        right!". Have that conversation up front. Even if they say "it doesn't
        matter". See if the team can give a quick idea as to what it will
        look/behave like. Just take it the next step, rather than having things
        unsaid, just ask "if the team does that. Will that satisfy this story?".

        It seems like you're missing the final piece of a story conversation : what
        does this story look like when it's completed. What makes this story "done"
        in the customer's mind.

        On Mon, Jun 2, 2008 at 7:05 AM, Ron Jeffries <ronjeffries@...>
        wrote:

        > Hello, Pat. On Monday, June 2, 2008, at 7:33:04 AM, you wrote:
        >
        > > How much planning is too much/too little? I understand that there are
        > > a lot of variables that go into answering this. I'll give details of
        > > my team's particular situation and hopefully spur good discussion.
        >
        > > We're experiencing problems that I believe are due to our planning
        > > process. At the beginning of the iteration we sit down with my boss
        > > (who plays the customer role) to come up with new stories and to
        > > review the prioritization of existing stories.
        >
        > > The key problem we have is that we get a lot of stories rejected. I'd
        > > say about a third of the stories we do get rejected and need
        > > additional work. I believe that it's because we don't develop a deep
        > > enough shared understanding with the customer's needs. We're finding
        > > it pretty difficult to do though. A very common convo/situation goes
        > > like the following:
        >
        > > Customer: "I want to show a list of locations where events were
        > > previously scheduled."
        > > Dev: "Okay. Maybe a grid with the location name and address?"
        > > C: "Yeah, that sounds good. And let's embed the Google Map view also"
        > > D: "Great. Let's do a quick sketch to see what it might look like."
        > > C: "I don't really care what it looks like. Anything will be fine"
        > > *we go to work, mark the story delivered. at the end of the
        > > iteration, customer rejects it saying it doesn't look right*
        >
        > What if instead of rejecting it, the boss said, "OK, that's good,
        > now what I'd like is ... X", resulting in a new story?
        >
        > After all, s/he said "I don't really care what it looks like," so it
        > is clearly passing that test.
        >
        > So I'd take the boss aside and ask to have a story that meets the
        > criteria accepted and a new story created. That's probably the best
        > way to go with regard to look and feel anyway.
        >
        > Or ...
        >
        > What if when a new thing like this comes along, you do a first story
        > called "make the initial version" and a second story called "clean
        > up the initial version"?
        >
        > Or ...
        >
        > What if you drew the GUI on paper or mocked it up before doing the
        > work, and showed it to the boss?
        >
        > Or ...
        >
        > What if you said "OK, let's be sure we understand what you want,"
        > went to the whiteboard, and drew up a really stupid example of the
        > screen requested, and said "Like that?" If the boss says Yes, then
        > leave the picture up and point to it when they go to reject. If the
        > boss says No, improve the sketch.
        >
        > BTW, this is not planning, it's designing, as this example should
        > make clear.
        >
        > Of these, my favorite is the first because the boss did say it
        > didn't matter. So they should say "OK, and what I'd like next is
        > ... X." Then it wouldn't be rejection.
        >
        > > This is really frustrating from a developer standpoint. One issue is
        > > that it just doesn't feel good to have our work constantly rejected.
        > > How much that counts or should count, I don't know. More importantly,
        > > it screws with our planning. If we've completed a story, but then
        > > have to allocate time in the next iteration to fix problems with it,
        > > then we push back things that were planned for that iteration. I
        > > think that's okay in small amounts, but it makes our planning less
        > > useful because we can't accurately estimate what we'll be able to get
        > > to.
        >
        > Things planned for the next iteration? There is nothing planned for
        > the next iteration except what the customer asks for. If the
        > customer asks for more work on last week's story, so be it.
        >
        > Managing the work into iterations is the boss's job. Your paragraph
        > above makes it sound to me as if somehow the plan belongs to you
        > (the developers?) rather than the boss.
        >
        > > The first obvious thing to do is to explain to the customer the
        > > problems this causes. We've said in the past that we'd like to do
        > > some deeper planning because we don't like having the stories
        > > rejected. The customer said it wasn't a really big deal to him that
        > > we'd deliver a story and that he'd reject it, with specific items to
        > > find.
        >
        > Customer is probably right. If it doesn't bother them, so be it. But
        > ask for another word.
        >
        > It comes to me that both sides may be thinking that you are supposed
        > to take a story and complete everything about that story in one
        > iteration. That's not the case. A story is what you commit to do in
        > one iteration. If you do it, that story is done. If you don't like
        > how it looks or want to add a subtotal to it, then that is a new
        > story.
        >
        > > I've pointed out that it hurts our productivity because it
        > > requires us to switch contexts a couple days after the fact. I
        > > haven't said that it messes up our planning, because I hadn't really
        > > thought of it until I wrote this message. I'm not sure what impact
        > > that will have, as my boss doesn't seem to find XP-style planning
        > > particularly valuable. He appears to feel that everything needs to
        > > get done, and it doesn't really matter in what order.
        >
        > IMO, that may be due to not understanding the impact of change. On
        > the other hand, XP planning is not about getting things right the
        > first time, it is about getting them right finally.
        >
        > Are you estimating stories and laying them down roughly on the
        > calendar (Release Plan)? Does the boss really have no deadline in
        > mind?
        >
        > > I believe all of this is hurting the team's productivity. I'm having
        > > a tough time getting into the customer's head and framing my concerns
        > > in a way that really matters to him.
        >
        > I don't understand either.
        >
        > Maybe it's not really affecting anything. Maybe it takes X time to
        > get the first version and Y time to clean it up. Maybe the
        >
        > > Finally, I think there's a stigma against doing too much planning.
        > > We're doing about 3 hours of planning a week, which I don't consider
        > > to be very much. So I realize this would vary a great deal from
        > > project to project, but what is an "average" time to spend planning in
        > > a week?
        >
        > You didn't say how big your team was. I would think 3 hours a week
        > would be OK but not impressively low for most teams.
        >
        > But again, I don't think you're asking for planning. I think you may
        > be worried about design.
        >
        > Ron Jeffries
        > www.XProgramming.com
        > Fear is the mindkiller. --Bene Gesserit Litany Against Fear
        >
        >
        >


        [Non-text portions of this message have been removed]
      • William Wake
        I m a little unclear on the situation - your boss says do something like this and then he rejects the result, or is it that the end customers are rejecting
        Message 3 of 10 , Jun 2, 2008
        • 0 Attachment
          I'm a little unclear on the situation - your boss says "do something
          like this" and then he rejects the result, or is it that the end
          customers are rejecting it?

          I'd really like to recommend Jeff Patton's article on incremental vs.
          iterative design:
          <http://agileproductdesign.com/blog/dont_know_what_i_want.html>

          I'd also consider - "who's got the problem?" It seems that the boss is
          happy, the customers are happy, but the developers are not?

          This weekend, I heard someone say something on the lines of "When
          developers change their minds about the design, they call it
          refactoring; when customers do it they call it fickle."

          Alistair Cockburn has a nice view of this too - explicitly planning
          stories as three rounds:
          http://alistair.cockburn.us/index.php/Three_cards_for_user_rights

          So, it's certainly possible that there are things going on that should
          be improved on the customer side, but another possibility is that your
          developers have unrealistic expectations about the difficulty of
          specifying work, and that you're actually blessed with a customer that
          "gets it" and doesn't resent the need for iteration.

          (I'm reminded of an exercise: give one person a set of blocks,
          arranged in a design of some sort. Another person sits facing away
          with the same set of blocks (not having seen the arrangement). The
          first person tells the person how to arrange them ("the spec"). Then
          you might have a round where you let the specifier see what happened,
          and try to give a spec to fix it. And finally have a round where the
          specifier comes over to work directly with the builder ("move this
          here").)

          > So I realize this would vary a great deal from
          > project to project, but what is an "average" time to spend planning in
          > a week?
          5-10% is what I use as a guideline, and you're in that range.

          --Bill Wake www.xp123.com

          On Mon, Jun 2, 2008 at 7:33 AM, Pat Maddox <pergesu@...> wrote:
          > The key problem we have is that we get a lot of stories rejected. I'd
          > say about a third of the stories we do get rejected and need
          > additional work. I believe that it's because we don't develop a deep
          > enough shared understanding with the customer's needs. We're finding
          > it pretty difficult to do though.

          --
          Bill Wake William.Wake@... www.xp123.com
        • Steven Gordon
          Pat, It seems to me that this customer does not really know what they want until the see something concrete. The good news is that the customer knows this and
          Message 4 of 10 , Jun 2, 2008
          • 0 Attachment
            Pat,

            It seems to me that this customer does not really know what they want
            until the see something concrete. The good news is that the customer
            knows this and is not upset with the waste and slowness that results
            from their inability to know what they really want.

            Since the customer needs something concrete delivered in order to
            figure out what they want, more detailed planning will only waste more
            work before getting the customer something concrete to react to.

            My suggestion is to do less instead of doing more. If your iterations
            were half as long and your stories were sliced half as thick, you
            would waste about half as much work before discovering what the
            customer really wants. In your example, perhaps just do the grid with
            text and links in order to get something to the customer as quickly as
            possible for feedback. Then harness the feedback the next iteration
            to do what the customer has discovered that they really want.

            Steven Gordon

            On Mon, Jun 2, 2008 at 4:33 AM, Pat Maddox <pergesu@...> wrote:
            > How much planning is too much/too little? I understand that there are
            > a lot of variables that go into answering this. I'll give details of
            > my team's particular situation and hopefully spur good discussion.
            >
            > We're experiencing problems that I believe are due to our planning
            > process. At the beginning of the iteration we sit down with my boss
            > (who plays the customer role) to come up with new stories and to
            > review the prioritization of existing stories.
            >
            > The key problem we have is that we get a lot of stories rejected. I'd
            > say about a third of the stories we do get rejected and need
            > additional work. I believe that it's because we don't develop a deep
            > enough shared understanding with the customer's needs. We're finding
            > it pretty difficult to do though. A very common convo/situation goes
            > like the following:
            >
            > Customer: "I want to show a list of locations where events were
            > previously scheduled."
            > Dev: "Okay. Maybe a grid with the location name and address?"
            > C: "Yeah, that sounds good. And let's embed the Google Map view also"
            > D: "Great. Let's do a quick sketch to see what it might look like."
            > C: "I don't really care what it looks like. Anything will be fine"
            > *we go to work, mark the story delivered. at the end of the
            > iteration, customer rejects it saying it doesn't look right*
            >
            > This is really frustrating from a developer standpoint. One issue is
            > that it just doesn't feel good to have our work constantly rejected.
            > How much that counts or should count, I don't know. More importantly,
            > it screws with our planning. If we've completed a story, but then
            > have to allocate time in the next iteration to fix problems with it,
            > then we push back things that were planned for that iteration. I
            > think that's okay in small amounts, but it makes our planning less
            > useful because we can't accurately estimate what we'll be able to get
            > to.
            >
            > The first obvious thing to do is to explain to the customer the
            > problems this causes. We've said in the past that we'd like to do
            > some deeper planning because we don't like having the stories
            > rejected. The customer said it wasn't a really big deal to him that
            > we'd deliver a story and that he'd reject it, with specific items to
            > find. I've pointed out that it hurts our productivity because it
            > requires us to switch contexts a couple days after the fact. I
            > haven't said that it messes up our planning, because I hadn't really
            > thought of it until I wrote this message. I'm not sure what impact
            > that will have, as my boss doesn't seem to find XP-style planning
            > particularly valuable. He appears to feel that everything needs to
            > get done, and it doesn't really matter in what order.
            >
            > I believe all of this is hurting the team's productivity. I'm having
            > a tough time getting into the customer's head and framing my concerns
            > in a way that really matters to him.
            >
            > Finally, I think there's a stigma against doing too much planning.
            > We're doing about 3 hours of planning a week, which I don't consider
            > to be very much. So I realize this would vary a great deal from
            > project to project, but what is an "average" time to spend planning in
            > a week?
            >
            > Pat
          • J. B. Rainsberger
            ... A true story. The last time this happened to a team I worked with, they had being demoing their work every two weeks on Friday afternoon. They told me they
            Message 5 of 10 , Jun 2, 2008
            • 0 Attachment
              On Jun 2, 2008, at 06:33 , Pat Maddox wrote:
              > Customer: "I want to show a list of locations where events were
              > previously scheduled."
              > Dev: "Okay. Maybe a grid with the location name and address?"
              > C: "Yeah, that sounds good. And let's embed the Google Map view also"
              > D: "Great. Let's do a quick sketch to see what it might look like."
              > C: "I don't really care what it looks like. Anything will be fine"
              > *we go to work, mark the story delivered. at the end of the
              > iteration, customer rejects it saying it doesn't look right*
              >
              A true story.

              The last time this happened to a team I worked with, they had being
              demoing their work every two weeks on Friday afternoon. They told me
              they had this same problem: too much rework when the customer saw it.
              I asked them if they could get feedback every week instead, and they
              tried that for a few months and it helped. Then I suggested they try
              Wednesday morning and Friday afternoon. That worked, too. Within four
              or five months they increased feedback fourfold. I don't know about
              their final results, but I imagine the fact that they increased the
              frequency of the demos twice (possibly more) tells me that they found
              it useful.

              Take care.
              ----
              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
            • Pat Maddox
              On Mon, Jun 2, 2008 at 5:05 AM, Ron Jeffries ... This is true, but he doesn t accept the story because he doesn t feel that it s complete. Perhaps the
              Message 6 of 10 , Jun 5, 2008
              • 0 Attachment
                On Mon, Jun 2, 2008 at 5:05 AM, Ron Jeffries
                <ronjeffries@...> wrote:
                > Hello, Pat. On Monday, June 2, 2008, at 7:33:04 AM, you wrote:
                >
                >> How much planning is too much/too little? I understand that there are
                >> a lot of variables that go into answering this. I'll give details of
                >> my team's particular situation and hopefully spur good discussion.
                >
                >> We're experiencing problems that I believe are due to our planning
                >> process. At the beginning of the iteration we sit down with my boss
                >> (who plays the customer role) to come up with new stories and to
                >> review the prioritization of existing stories.
                >
                >> The key problem we have is that we get a lot of stories rejected. I'd
                >> say about a third of the stories we do get rejected and need
                >> additional work. I believe that it's because we don't develop a deep
                >> enough shared understanding with the customer's needs. We're finding
                >> it pretty difficult to do though. A very common convo/situation goes
                >> like the following:
                >
                >> Customer: "I want to show a list of locations where events were
                >> previously scheduled."
                >> Dev: "Okay. Maybe a grid with the location name and address?"
                >> C: "Yeah, that sounds good. And let's embed the Google Map view also"
                >> D: "Great. Let's do a quick sketch to see what it might look like."
                >> C: "I don't really care what it looks like. Anything will be fine"
                >> *we go to work, mark the story delivered. at the end of the
                >> iteration, customer rejects it saying it doesn't look right*
                >
                > What if instead of rejecting it, the boss said, "OK, that's good,
                > now what I'd like is ... X", resulting in a new story?
                >
                > After all, s/he said "I don't really care what it looks like," so it
                > is clearly passing that test.

                This is true, but he doesn't accept the story because he doesn't feel
                that it's complete. Perhaps the ultimate source of our frustration is
                that this causes a bit of conflict - he rejects stories on the basis
                that they're incomplete, but the developers feel like there's an
                unfair game being played. We can't seem to elicit acceptance
                criteria, so how do we have a chance at fulfilling them?


                > So I'd take the boss aside and ask to have a story that meets the
                > criteria accepted and a new story created. That's probably the best
                > way to go with regard to look and feel anyway.

                This sounds good to me, though I think it conflicts with our process.
                We're doing two-week release cycles (we're a web app in alpha stage),
                so I think a lot of the rejections come up because we've passed the
                expressed acceptance criteria, but the feature perhaps isn't
                releasable.


                > Or ...
                >
                > What if when a new thing like this comes along, you do a first story
                > called "make the initial version" and a second story called "clean
                > up the initial version"?
                >
                > Or ...
                >
                > What if you drew the GUI on paper or mocked it up before doing the
                > work, and showed it to the boss?
                >
                > Or ...
                >
                > What if you said "OK, let's be sure we understand what you want,"
                > went to the whiteboard, and drew up a really stupid example of the
                > screen requested, and said "Like that?" If the boss says Yes, then
                > leave the picture up and point to it when they go to reject. If the
                > boss says No, improve the sketch.

                We've asked to do this, he doesn't seem interested in participating.
                What if we did it asynchronously? After the planning meeting, the
                devs would do sketches of the UI and workflow, then send them off to
                him. This would relieve some of the pressure of making decisions on
                the spot.


                > BTW, this is not planning, it's designing, as this example should
                > make clear.

                When should these little customer-developer design sessions take place?


                > Of these, my favorite is the first because the boss did say it
                > didn't matter. So they should say "OK, and what I'd like next is
                > ... X." Then it wouldn't be rejection.
                >
                >> This is really frustrating from a developer standpoint. One issue is
                >> that it just doesn't feel good to have our work constantly rejected.
                >> How much that counts or should count, I don't know. More importantly,
                >> it screws with our planning. If we've completed a story, but then
                >> have to allocate time in the next iteration to fix problems with it,
                >> then we push back things that were planned for that iteration. I
                >> think that's okay in small amounts, but it makes our planning less
                >> useful because we can't accurately estimate what we'll be able to get
                >> to.
                >
                > Things planned for the next iteration? There is nothing planned for
                > the next iteration except what the customer asks for. If the
                > customer asks for more work on last week's story, so be it.

                We've got a backlog of several iterations. We try to keep the current
                iteration as stable as possible, and allow for change in the backlog.

                Anyway, at this point we tend to know quite a bit about what the next
                iteration will look like. The problem is that sometimes my boss will
                be frustrated that a couple stories might be pushed back from it. We
                get frustrated because we feel like we've been unfairly committed to
                that plan, and it got pushed back because current stories were pushed
                back due to failing unknown acceptance criteria.


                > Managing the work into iterations is the boss's job. Your paragraph
                > above makes it sound to me as if somehow the plan belongs to you
                > (the developers?) rather than the boss.
                >
                >> The first obvious thing to do is to explain to the customer the
                >> problems this causes. We've said in the past that we'd like to do
                >> some deeper planning because we don't like having the stories
                >> rejected. The customer said it wasn't a really big deal to him that
                >> we'd deliver a story and that he'd reject it, with specific items to
                >> find.
                >
                > Customer is probably right. If it doesn't bother them, so be it. But
                > ask for another word.
                >
                > It comes to me that both sides may be thinking that you are supposed
                > to take a story and complete everything about that story in one
                > iteration. That's not the case. A story is what you commit to do in
                > one iteration. If you do it, that story is done. If you don't like
                > how it looks or want to add a subtotal to it, then that is a new
                > story.
                >
                >> I've pointed out that it hurts our productivity because it
                >> requires us to switch contexts a couple days after the fact. I
                >> haven't said that it messes up our planning, because I hadn't really
                >> thought of it until I wrote this message. I'm not sure what impact
                >> that will have, as my boss doesn't seem to find XP-style planning
                >> particularly valuable. He appears to feel that everything needs to
                >> get done, and it doesn't really matter in what order.
                >
                > IMO, that may be due to not understanding the impact of change. On
                > the other hand, XP planning is not about getting things right the
                > first time, it is about getting them right finally.
                >
                > Are you estimating stories and laying them down roughly on the
                > calendar (Release Plan)? Does the boss really have no deadline in
                > mind?

                We just got a deadline earlier this week. For the past 6 months
                though, there have been no deadlines. I'm hoping that this deadline
                will lead to more thought regarding prioritization.


                >> I believe all of this is hurting the team's productivity. I'm having
                >> a tough time getting into the customer's head and framing my concerns
                >> in a way that really matters to him.
                >
                > I don't understand either.
                >
                > Maybe it's not really affecting anything. Maybe it takes X time to
                > get the first version and Y time to clean it up. Maybe the
                >
                >> Finally, I think there's a stigma against doing too much planning.
                >> We're doing about 3 hours of planning a week, which I don't consider
                >> to be very much. So I realize this would vary a great deal from
                >> project to project, but what is an "average" time to spend planning in
                >> a week?
                >
                > You didn't say how big your team was. I would think 3 hours a week
                > would be OK but not impressively low for most teams.
                >
                > But again, I don't think you're asking for planning. I think you may
                > be worried about design.

                I asked this inline above, but I'd like to mention it again here to
                ensure we discuss it. What time relative to planning should we be
                doing these design sessions? Particularly the ones that are used to
                develop a shared understanding between customer and developers.

                Pat
              • George Dinwiddie
                ... Hi, Pat. Bring me a rock. -- ... * George Dinwiddie * http://blog.gdinwiddie.com Software Development
                Message 7 of 10 , Jun 5, 2008
                • 0 Attachment
                  Pat Maddox wrote:
                  > This is true, but he doesn't accept the story because he doesn't feel
                  > that it's complete. Perhaps the ultimate source of our frustration is
                  > that this causes a bit of conflict - he rejects stories on the basis
                  > that they're incomplete, but the developers feel like there's an
                  > unfair game being played. We can't seem to elicit acceptance
                  > criteria, so how do we have a chance at fulfilling them?

                  Hi, Pat. Bring me a rock.

                  --
                  ----------------------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------------------
                • Ron Jeffries
                  ... Yes. I m suggesting agreeing with the boss that while he may want changes, those will be treated as a new story for tracking purposes. We could talk
                  Message 8 of 10 , Jun 9, 2008
                  • 0 Attachment
                    Hello, Pat. On Thursday, June 5, 2008, at 7:56:52 PM, you wrote:

                    >> After all, s/he said "I don't really care what it looks like," so it
                    >> is clearly passing that test.

                    > This is true, but he doesn't accept the story because he doesn't feel
                    > that it's complete. Perhaps the ultimate source of our frustration is
                    > that this causes a bit of conflict - he rejects stories on the basis
                    > that they're incomplete, but the developers feel like there's an
                    > unfair game being played. We can't seem to elicit acceptance
                    > criteria, so how do we have a chance at fulfilling them?

                    Yes. I'm suggesting agreeing with the boss that while he may want
                    changes, those will be treated as a "new story" for tracking
                    purposes. We could talk about why that's a good idea but one might
                    get the convention followed by just asking.

                    >> So I'd take the boss aside and ask to have a story that meets the
                    >> criteria accepted and a new story created. That's probably the best
                    >> way to go with regard to look and feel anyway.

                    > This sounds good to me, though I think it conflicts with our process.
                    > We're doing two-week release cycles (we're a web app in alpha stage),
                    > so I think a lot of the rejections come up because we've passed the
                    > expressed acceptance criteria, but the feature perhaps isn't
                    > releasable.

                    I'm not clear on how that conflicts with your process. Perhaps you
                    are using a different definition of "releasable" than I would, which
                    is, roughly, "This is complete enough so that it does what the
                    customer originally asked for, and it is solid enough and robust
                    enough to shipped harmlessly." If the customer has changed their
                    mind, they might decide not to release it and to ask for something
                    else or in addition. That's fine: at the end of the next iteration
                    we'll have that, also "releasable".

                    >> What if you said "OK, let's be sure we understand what you want,"
                    >> went to the whiteboard, and drew up a really stupid example of the
                    >> screen requested, and said "Like that?" If the boss says Yes, then
                    >> leave the picture up and point to it when they go to reject. If the
                    >> boss says No, improve the sketch.

                    > We've asked to do this, he doesn't seem interested in participating.
                    > What if we did it asynchronously? After the planning meeting, the
                    > devs would do sketches of the UI and workflow, then send them off to
                    > him. This would relieve some of the pressure of making decisions on
                    > the spot.

                    Might work. Do you think he is troubled by making decisions on the
                    spot? Why then is he willing to make them later, when the work is
                    done?

                    I might take a serious look at how much actual rework there is to a
                    story. If there wasn't much rework -- and I'd think we could
                    minimize that by working from sketch to good art -- maybe we just
                    should get over it. However, showing how long stories hang in the
                    air, not being worked on, waiting for better specs, might be
                    interesting ...

                    >> BTW, this is not planning, it's designing, as this example should
                    >> make clear.

                    > When should these little customer-developer design sessions take place?

                    Perhaps prior to the real planning meeting. Is anyone working with
                    the boss ahead of time to help him prepare? Might be worth doing ...

                    >> Things planned for the next iteration? There is nothing planned for
                    >> the next iteration except what the customer asks for. If the
                    >> customer asks for more work on last week's story, so be it.

                    > We've got a backlog of several iterations. We try to keep the current
                    > iteration as stable as possible, and allow for change in the backlog.

                    Who is "we"? I would think that the backlog belongs to the boss. If
                    so, then when the boss sees that he is affecting his own backlog,
                    I'd expect him to learn.

                    Are the team, perhaps, working to the original backlog expectation,
                    not "requiring" the boss to remove things from it when there is more
                    to do than was originally seen? If so, I'd suggest not doing that.

                    The development team's job is to say how much work can be done in
                    any given iteration. The boss's job, as customer, is to decide which
                    work, within that limit.

                    > Anyway, at this point we tend to know quite a bit about what the next
                    > iteration will look like. The problem is that sometimes my boss will
                    > be frustrated that a couple stories might be pushed back from it. We
                    > get frustrated because we feel like we've been unfairly committed to
                    > that plan, and it got pushed back because current stories were pushed
                    > back due to failing unknown acceptance criteria.

                    Yes. Stop doing that. It is impossible, as well as frustrating, to
                    commit to work when we don't know how long it will take. That is
                    not the "XP way" as I understand it. It is certainly not the way
                    that I recommend be it XP or not.

                    >>> I've pointed out that it hurts our productivity because it
                    >>> requires us to switch contexts a couple days after the fact. I
                    >>> haven't said that it messes up our planning, because I hadn't really
                    >>> thought of it until I wrote this message. I'm not sure what impact
                    >>> that will have, as my boss doesn't seem to find XP-style planning
                    >>> particularly valuable. He appears to feel that everything needs to
                    >>> get done, and it doesn't really matter in what order.

                    Well, then he's right. But if he thinks things have to get done by a
                    particular date, then he has to recognize his part of the job, which
                    is to choose what to have done by that date, and what to have after
                    the date. The team's job is to make the impact of his choices as
                    clear as it can be.

                    > We just got a deadline earlier this week. For the past 6 months
                    > though, there have been no deadlines. I'm hoping that this deadline
                    > will lead to more thought regarding prioritization.

                    If by "deadline" we mean "delivery date", excellent. If we mean
                    "date by which an unknown amount of work has to be done or
                    development will have screwed up," there is work to do. As you
                    correctly perceive, that work is prioritization.

                    > I asked this inline above, but I'd like to mention it again here to
                    > ensure we discuss it. What time relative to planning should we be
                    > doing these design sessions? Particularly the ones that are used to
                    > develop a shared understanding between customer and developers.

                    As a rule, those conversations take long enough, and may need think
                    time in between enough, to suggest that they should be held during
                    the iteration prior to the story coming in as scheduled. I prefer to
                    have as many people involved in those chats as possible, and accept
                    that it may not be efficient or comfortable to have the entire team
                    appear to be ganging up on the boss.

                    Ron Jeffries
                    www.XProgramming.com
                    We cannot solve our problems with the same thinking we used when we created them.
                    -- Albert Einstein
                  Your message has been successfully submitted and would be delivered to recipients shortly.