We’re about to have a meeting to plan to plan our next release.
No, that wasn’t a typo. The goal of this meeting is to define what our planning phase of the project will look like and how long it will last. The goal of the meeting is not, however, to put together any kind of plan for the project. That comes later. During the planning phase. Which we’re planning to plan in just a few minutes.
OK, I mean, it’s not like I don’t understand why we do this. In an organization of this size, it gets very expensive not to do things right the first time. So the Strategy and Planning department (yes, there’s a whole department for it) puts together guidelines for us to follow on how to manage projects so that they have the best chance of getting done right.
It’s just that it can really seem like overkill. And I know I annoy people around here when I make fun of it, but hell, I’m used to working in software startups, where an enhancement can be dreamed up over morning coffee, mocked up by lunch, and working in the production code by dinner. With maybe some functional specifications (for posterity’s sake) the following week or later, if anyone ever gets around to it.
I’m not saying that’s the best way to develop software, but man, there must be a happy medium.