26865Re: The Scrum Release Plan Dilemma
- Feb 5, 2008Hi Tobias,
> > Your comments sound like you feel there should be a "one size fitsrelease
> 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, soin
> 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 worldline)
> examples of when this technique added value. I only had one (off-
> reply giving a real example. I am convinced the method was used,That is a good question. I haven't seen a practical "by the book"
> however I am not convinced (yet) that it added value.
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 isout"
> 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" morefrequently,
> and with more gusto and abandon. And then get on with buildinggood
> 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 wouldwith
> 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. :)everyone
> > 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 awaste of
> time... help me to see that it isn't." In Agile we should questionoutdated
> everything. We forget, I think, how deeply bad practices and
> ways of thinking are ingrained in our psyches. Nothing should besacred
> 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
- << Previous post in topic Next post in topic >>