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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.