oship-dev team mailing list archive

[Tim <timothywayne.cook@xxxxxxxxx>]

Interesting article.

Sent to you by Tim via Google Reader: Release Planning & the Early
Warning System via Agile & Business by noreply@xxxxxxxxxxx (Joe Little)
on 9/3/10
Building complex innovative products is, of course, hard.

So, in that context, what is the purpose of Release Planning in
Scrum/Agile?

We will not provide a complete explanation here, but we will give a few
key ideas.

1. A consensus view of the 'same' elephant. We want all the team
members to see the whole product and to start to see the same whole
product. We think this is typically the most valuable thing.

2. Think first, but not think too much. This is a neat trick -- getting
some people to think enough before they start, and also helping others
not get stuck in 'analysis paralysis'.

I find that many people want to know 'perfectly' a certain set of
information before they start. Meaning: They want to wait and study too
long. I find this seeking for 'perfection' is mis-guided. It typically
does not include enough consideration of what it costs us not to
know 'X' before we start. (If the cost could be real high, then slowing
down to learn 'X' makes more sense).

I think each team should have a good fight about how much to 'study'
before starting to Sprint.

3. Establishing a project plan, with a date estimate for the first
release and a cost estimate. In most organizations, something like this
is usually needed. My experience is that, aside from the discussions
about risks and impediments, this is usually the least valuable output.
But it establishes a starting point for improvement. So, for several
reasons, it is necessary.

4. Establishing an Early Warning System. I was just working with a
large client who has a big, multi-team and multi-year effort. Some on
the team think they will get done 'early'. And some think they will
be 'late' as usual (this is said from my own personal experience that
most waterfall projects are late...and this organization is just
transitioning from waterfall).

In this case particularly, the group (everyone in the group) needs an
early warning system that can tell them whether they are likely to hit
the date or not. (A date and a high-level scope has been defined, but
the detailed requirements are undefined.) For example, the earlier the
group knows there is a problem, the earlier it can take
counter-measures to address the problem.

So, the Release Planning sets up the ideas (velocity, story points to
be completed, Business Value of the features, etc) that go into the
Release Plan. And the Release Plan, with its implied 'ideal velocity',
can become the Early Warning System.

Since, in this case, the Chief Product Owner is leading this effort,
this gives him great incentive to get the whole group to do
professional Release Planning now. So that, for example, refactoring of
the Release Plan will take less effort later. So, the CPO needs to
explain and explain again why the whole group wants a good Release Plan
sooner rather than later. (Only if they want to do it, will they do it
well.) Not an easy job. Do-able, but not easy. Especially for beginning
Product Owners.
Subscribe in a reader

Things you can do from here:
- Subscribe to Agile & Business using Google Reader
- Get started using Google Reader to easily keep up with all your
favorite sites