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

26865Re: The Scrum Release Plan Dilemma

Expand Messages
  • Petri Heiramo
    Feb 5, 2008
    • 0 Attachment
      Hi Tobias,

      > > Your comments sound like you feel there should be a "one size fits
      > all" planning process.
      > Well, no, but my original question was focused on one type of
      > planning that is taught on some CSM and Agile Planning courses, so
      > that sense, yes.

      I guess you can guess that I would focus on your words "one type of
      release planning" :).

      > I was interested if anyone could give real world
      > examples of when this technique added value. I only had one (off-
      > reply giving a real example. I am convinced the method was used,
      > however I am not convinced (yet) that it added value.

      That is a good question. I haven't seen a practical "by the book"
      example in our projects, either, but I don't claim intimate knowledge
      of all the projects. I know that some projects need to map their
      estimates (or even certain commitments) to biweekly releases in some
      projects. The plans may change, but they need to convey their current
      estimates to other teams in the larger ecosystem to manage
      dependencies between teams. The system is very similar to the book
      case, although the tools and the terminology they use doesn't match.

      > But more broadly, I do wonder whether the way release planning is
      > approached in Agile is (as Mark/woynam speculates in an earlier
      > response) a throwback to old project management "gotta figure it
      > think. It is time we began saying "I have no idea" more
      > and with more gusto and abandon. And then get on with building
      > software, right now.

      "I have no idea" should be used sparingly, because it's rarely the
      case. However, we should induce the correct kind of thinking ("this
      is just an estimate, we'll see what turns out and how things will
      change") in the people making the broader decisions. They need to
      understand that all they are seeing are educated guesses.

      Obviously, there are different kind of project environments. I know
      some very research oriented projects that have troubles making two-
      week plans; their plans change too much within one week as they learn
      new things. Some other projects can speculate things several months
      ahead. But regardless of the visibility, anything but "today" is not
      a commitment in Agile.

      > Your Now/Mañana suggestion is a good one, except that I would
      > probably throw away all the cards not in the Now pile. Any work
      > those cards probably adds no value.

      I'd just put them aside and bring them to the next meeting,
      saying "you had these ideas last time, let's do another mañana
      analysis and see what's important now." There are often valuable
      ideas in those cards, but they were just not relevant the last time
      (for example, features which build on other features are not relevant
      until the other features are built).

      > > If it's wasteful to you, stop doing it. :)
      > > But don't fall into trap of thinking that it's wasteful to
      > I'm not sure it is a trap to ask the question: "should we (or you)
      > doing this?" or even to make the statement: "this seems like a
      waste of
      > time... help me to see that it isn't." In Agile we should question
      > everything. We forget, I think, how deeply bad practices and
      > ways of thinking are ingrained in our psyches. Nothing should be
      > in the world of software process. Nothing.

      Nothing is sacred, but there are some good ideas that we might still
      find useful from the past. The questions you ask are very good to be
      made, but the answer is not always the same. But other than that, I
      agree with you wholeheartedly.


      Petri Heiramo, CSP
      SYSOPENDIGIA, Finland
    • Show all 17 messages in this topic