project plans...

Hi there.

i've been asked to provide a project plan for a project that begins next
month. i would like to perform the project in an agile manner and i think
i've got plenty of resources to  get that going however when it comes to the
problem of laying out an acceptable project plan to a non-agile person i'm
at a loss. what i want to do is to give a detail description of the first
iteration but then how do i represent subsequent iterations where what i
dont know is what will be completed?

any thoughts or references would be greatly appreciated.

regards,
Patrick McGovern

On Tue, 21 Dec 2004 09:49:38 -0500, "Yin Yang" <pjm0@hotmail.com> wrote:

>Hi there.
>
>i've been asked to provide a project plan for a project that begins next
>month. i would like to perform the project in an agile manner and i think
>i've got plenty of resources to  get that going however when it comes to th
e
>problem of laying out an acceptable project plan to a non-agile person i'm
>at a loss. what i want to do is to give a detail description of the first
>iteration but then how do i represent subsequent iterations where what i
>dont know is what will be completed?
>
>any thoughts or references would be greatly appreciated.

To my mind, if the project has been approved, and you want to do it in an
Agile way, you should simply pick which Agile approach to use (I've used XP
and like it), retain a coach familliar with the approach, gather a team (at
least the core of a team), and start.

Spending a month creating a plan is not Agile.  In the first month, a lot of
coding might or might not get done, but at least the core of a team should b
e
exploring the hard parts of problem domain by writing code spikes, and start
providing cost estimates for stories.  Without that, whatever "plan" you hav
e
is not very trustworthy from an Agile perspective.

If management is asking for a 1-month planning period -before- approval,
suggest that the risk/benefit ratio is better to simply start with an Agile
process right away, and cancel the project in a month if the cost estimates
seem too high for the benefit to be gained.

"Yin Yang" <pjm0@hotmail.com> wrote in message
news:cq9d53$jfv$1@trsvr.tr.unisys.com...
> Hi there.
>
> i've been asked to provide a project plan for a project that begins next
> month. i would like to perform the project in an agile manner and i think
> i've got plenty of resources to  get that going however when it comes to
> the
> problem of laying out an acceptable project plan to a non-agile person i'm
> at a loss. what i want to do is to give a detail description of the first
> iteration but then how do i represent subsequent iterations where what i
> dont know is what will be completed?
>
> any thoughts or references would be greatly appreciated.

Lay it out using the assumed velocity and in descending order
by business value. Emphasize that this is a _tentative_ plan and
will change as the team establishes a baseline velocity and as
the backlog of stories changes.

Also provide a lighter weight tracking mechanism such as
a burn-down chart or a burn-up chart. There's a good chance
that whoever's asking for the detailed plan will see that it
doesn't do them any real good, since the basic issue is
whether you're going to be able to deliver the agreed on
functionality by the agreed on release date. A burn-down
chart is very good for that.

John Roth


>
> regards,
> Patrick McGovern
>
>

Steve Jorgensen wrote:

> If management is asking for a 1-month planning period -before-
> approval, suggest that the risk/benefit ratio is better to simply
> start with an Agile process right away, and cancel the project in a
> month if the cost estimates seem too high for the benefit to be
> gained.

Or just do the 1-month planning period by

- gathering as many of the developers that will be part of the latter team
as possible,
- gather User Stories to do a Release Plan,
- do Architectural Spikes where it seems to be appropriate, and then
- do as many Iterations as fit into the remaining time, to get a first rough
idea of your later velocity.

See
[url]http://www.agilemodeling.com/essays/agileModelingXPLifecycle.htm#ExplorationPhase[
/url]
and the appropriate chapters of "Planning Extreme Programming".

Cheers, Ilja

There are a few important aspects to agile project planning
* Feature-driven development, often using index cards
* Iterative project structure
* Aggressive scope management (time-boxing)
* Intense communication with the customer

We are looking for beta testers for a tool we are developing for agile
project management.  We have two local firms that have been using
ProjectCards for a number of months and have found it helpful.

In ProjectCards, you start by breaking down the features in the "Themes
View".  You can dynamically classify your cards / features / user
stories and build a "vision" of what your product should be.

Then you set up your release/iteration schedule and start dragging the
cards into them.  If you have set your velocity, the tool will let you
know when an iteration is full.  Once your initial iteration plan is
established, you can generate an html report to communicate with your
non-agile manager.  For the development team we print out the stories on
index cards.

The key is that your plan has to be very flexible, while you keep very
strict on the iteration cycle.  You will find yourself regularly
splitting cards into the parts that can be done now, and the parts that
will be deferred to a later iteration to permit you to work on something
that will produce more business value right away.

The first part of the ProjectCards users' guide distills what we have
learned about Agile Project Management, and may be a good starting
point.   http://www.projectcards.com/resources.php to download it.

If you're interested in being part of the beta test, go to
http://www.projectcards.com/beta.php

I've been reading "Agile Project Management" by Highsmith.  It has a lot
of good background information, but I don't find that it will help
somebody get started.  I think it would be good reading after you have
tried your hand a bit.

The Extreme Programming series of books are quicker reads and give a
good overview.

Graham Astles
http://www.projectcards.com

Patrick,

> i've got plenty of resources to  get that going however when it comes to t
he
> problem of laying out an acceptable project plan to a non-agile person i'm
> at a loss.

My suggestion: sit down with the non-agile person in question and ask
them what an acceptable project plan would look like, and why. Further
questions which you may use to guide the conversation:

* Is the activity of planning useful in itself, or only the document ?
* If the latter, what features of a plan make it a useful document ?
* If the former, what distinguishes useful planning from useless ?

Laurent