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

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

Expand Messages
  • 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 1 of 10 , Jun 9, 2008
      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

      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
      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.