Planning

I'm in the midst of a big planning project. (Actually, I'm in the midst of Heathrow. Long trips are good for making plans.)

I've never been a big fan of orthodox software planning. It's easy to build beautiful plans for the wrong product, and if it turns out you're building the wrong product, the plan is much worse than dead weight. If the plan is really good and really well done, its excellence makes it harder to see that you're wrong. (Really convincing but wrong plans can lead you and your customers astray, which can turn out well for you in the short run. See Ada and OpenDoc for examples)

We're juggling a lot of great ideas for Tinderbox, ranging from little cosmetic tweaks to entire new product families. For the last few months, I've been working from a simply priority list, which I keep in Tinderbox. That's great for the immediate development horizon.

What I'd like next, though, is a big (but detailed) roadmap of the next year or two of development -- a plan that's so easily changed that it won't tug on us to stick with bad ideas (and so miss new opportunities) simply because they were in the plan -- and it was such a good plan. That's another nice thing about Tinderbox: lots of tools for managing change.

Orthodox Agile Methodology would say that this plan is too much of a plan. But I've got a lot of feature cards in my hand, and a bunch of concepts that need to be broken down into feature cards. Even in the agile extreme of my attitude swing, I think that sometimes you need to lay the cards out and step back. Right?

But it's going to be a big map: we're going to need to find a very big wall to hang it on.