|
What is
AgilePlanner?
This
guide is split into multiple parts - please click
next at the bottom of the page to go to next section.
This work is based on the book Agile Estimating and Planning (Mike Cohn 2006,
ISBN 0-13-147941-5)
I thought it was a good and clear book and it points out some of the things that
are easily missed. One of the biggest eye openers to me was this: There is
something called “too good” when it comes to planning. “Too good” in the sense
“too much detail”. To be honest I have always thought that the more detail the
better. Reading the book made me understand that I have been completely wrong.
Since we are dealing with a plan we must be humble enough and accept that the
real work we plan for will take on a life on its own once it is started. And we
must not limit the degrees of freedom needed to actually get the job done. A
plan should not contain too much detail. If it does, it gives a perception of
precision that we just do not have.
This false precision might not seem all that dangerous at first glance but it
is. It is bad for moral all over. It is bad for the developers since they feel
disconnected from the manager´s viewpoint as soon as the manager is out of sync
with the current state of the code and hence out of sync with reality.
It is bad for management since they believe that they have control that just is
not possible and management might resort to blaming the team for being unable to
follow the detailed plan that might have been impossible to follow after the
first few hours of work.
It is bad for the client that will get wrong and inconsistent information. All
in all I now believe that this false perception of precision is the main source
of development frustration and as such a big and unnecessary energy drain in
many development projects.
The other extreme, that is sometimes seen, is that we hardly have any details at
all. This too leads to frustration for all involved parties. The manager cannot
answer questions about cost and time. Developers cannot measure progress. And
since the client will not accept so little information on what is happening or
about to happen, the management soon resorts to wild guesses with very little
connection to what is really going on.
The perfect mix of information in the plan on what the result should be, when we
need the result and freedom to actually solve business problems with development
power is the mix we strive for.
We also need to know how to handle major changes to known requirements and new
requirements that we will come across along the way. In short we need be agile
in our planning; hence AgilePlanner.
The great thing about a book such as the
one by Cohn, is that it freezes a particular point of view and makes it
accessible for many people to share. I am not totally convinced that the
planning process that Cohn describes is the optimal in all senses, but I do
believe that it is good enough to really help in the process of building good
software. In the AgilePlanner tool I will adhere to the book as much as possible
because as far as I am concerned the book is my client. At this point I have no
ambition to improve or change the ideas provided by Cohn.
Why a tool at all? Most Agile-books tend to steer away from tools in favor of
manual methods like Whyte boards and post-it-stickers. I have always seen this
as a backlash of the many other legacy methods like waterfall derivates and
RUP-derivates that often come with an expensive toolbox that the management buy
since they think it is necessary and it will do “the trick”. In these cases the
developers are stuck with a method that does not work for software development
and with expensive tools that has given the management piece of mind that they
are on the right track. This is of course the road to disaster that only pure
development talent can fix.
I do not think that the Agile community is tool hostile, it is just that tools
are not the solution, the Agile approach is the solution. Tools are support. To
emphasize this I urge you to read and understand book Agile Estimating and
Planning before you start to use AgilePlanner, or at least read the five minute
guide to Agile estimating and planning I provide in a section below.
When I start work on AgilePlanner I do not have any tool, but since my goal is
to create the AgilePlanner according to Agile Methods I hope that I will have a
semi finished tool to use after the first iteration.
|