|
I’ve been working with a couple of new teams this week that
are transitioning to an agilish (yes, I did say agilish) process. What has
really struck me this week is how the entire software development industry is
still marooned on Gilligan’s Island when it comes to drafting a plan that
simply and effectively communicates what we are about to develop. Yes we’ve
been on the island forty years. Yes, the whole industry … well, percentage-wise
just about everyone if we cut off the decimal places and round up. No, I don’t
know where everyone fits or how they eat.
What sort of plan strands you on a tropical island for forty
years in a bad 60’s sitcom? The sort of plan that starts with Select Project Manager,
Select Tech Lead, Select Project Team, Hold Kick-Off Meeting and ends with Transition
to Maintenance Team, Archive Project Documentation, and Hold Project
Retrospective. Typically, this kind of plan can be up to eight levels deep, weaves
in and out and fakes left and right like a pro running back, has plenty of
tasks and subtasks estimated at either twenty days or zero days, and amazingly manages
in five hundred lines or more to omit any mention of the actual functionality that
is purportedly under development.
The type of plan that is mostly likely to drop you and a
million of your dearest friends on a once-deserted island is a plan that is actually
indecipherable even to the person who supposedly authored it. This is, of
course, because the author lifted the majority of the plan from someone else’s
plan--which may well have been equally indecipherable. And, I would argue, it
is this practice of copying pre-baked plans that is the single biggest reason
that we are still hanging out with Gilligan. We’re not just copying the plan
from the PM three cubes down, we’re ripping
the corporate-recommended Starter Plan Template off the shared drive,
guestimating ourselves into a schedule and a budget (which is, of course, an
activity best done alone), and actually forgetting to ever fold in the effort
for the tech-stuff-that-we-don’t-really-understand-anyway before taking the
plan up to the board and getting it approved. Of course the board is going to
approve the plan. It’s over a thousand tasks and they can’t follow it so it
must be good. But they’ll argue us down on the budget and that’s ok since all
the estimates were inflated anyway. Seriously.
I’ve seen too many teams start with these complicated plans
based on what some other project did or what the company PMO recommends. They
half-heartedly throw their own work into the plan and the project really does
get approved and no one looks at the plan ever again because it didn’t make any
real sense in the first place but they can swear that they really did plan the
project before they threw that plan away. I’ve seen this happen again and
again, and at this very moment I’m convinced that a significant part of the
problem is that teams try to start the planning process with a pre-baked plan.
And more times than not that’s a half-baked pre-baked plan.
How do we get off the island? With a simple plan. And a
simple plan should start ONLY with a short list of the separate and distinct
bits of functionality that need to be developed. Call ‘em features,
deliverables, components, chunks or whatever you like. Maybe there are six
items on the list. Maybe there are two dozen. It’s somewhat dependant on the
size and nature of the project. The list should not include any of the other
noise associated with a software project, like failure testing, UAT,
deployment, etc. The items on the list should make sense to everyone on the team,
the team’s management and the customer. Everyone should agree that each item
belongs on the list and that nothing is missing. After everyone agrees on the
initial list then start adding details and estimates to the items on the list,
and feel free to change the list as the team learns new things or a better way
to group the work that needs to be done.
This list, once fully estimated, makes a simple and
excellent starter plan. In the past, I’ve called this list a Feature Catalog. Truly
agile teams will need nothing more than this to begin a project. Teams
following agilish processes, however, may now need to build a heavier plan
around this simple plan, folding in the discovery, documentation, sign-off, UAT
and deployment activities that are customary in larger companies and on larger
projects. But as long as we start with a simple plan, and we carefully build
the heavier plan around it, we will end up with a blueprint that can be flexed
and followed to build a system that will one day carry our project team home.
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
Blogs 
