26868Re: [scrumdevelopment] Re: The Scrum Release Plan Dilemma
- Feb 5, 2008Tobias, this is a very good topic. Another complicating circumstance in some environments is when the development is not internal or for a single customer. In these settings, the release plan has value for the other parts of the organization (marketing, sales, services, support, etc) as they know what they need by when, for example, services people will need skill around Platform X since it will be supported in Release Y. Not all of those groups "signed up for Agile" but are still having to adapt to the new ways the development groups are delivering.
michaelOn Tue, Feb 5, 2008 at 7:53 AM, Tobias Mayer <tobyanon@...> wrote:
Hi PetriHaha. Yes, you are right. bad choice of words. We always have ideas (not necessarily good ones). Perhaps it is simpler and more honest to simply say "I don't know".
> "I have no idea" should be used sparingly, because it's rarely the case.
Thanks for your thoughts on this topic.
--- In email@example.com, "Petri Heiramo" <petri.heiramo@...> wrote:
>> 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 release
> > planning that is taught on some CSM and Agile Planning courses, so in
> > 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-line)
> > 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 out"
> > think. It is time we began saying "I have no idea" more frequently,
> > and with more gusto and abandon. And then get on with building good
> > 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 with
> > 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 outdated
> > ways of thinking are ingrained in our psyches. Nothing should be sacred
> > 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
- << Previous post in topic Next post in topic >>