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.
When do you plan to plan to plan the release? 🙂
LMAO – we crack jokes about the development methodology all the time. The sad part about it is that no one has any idea whats going on. The process we are using, loosely based on Karl Wiegers Process Impact, is nothing but an old fashioned manufacturing planning process. Its completely absurd to plan and estimate software projects in a pipe-line manner like you would plan building a car or an airplane. The want to break code modules down like parts of a widget. Its insane. I keep trying to explain to people that we are wasting piles of money and time, but they won’t listen (and I have my theories as to why). So now when we have these idiotic planning meetings I sit back and let the PMs and the BAs make up numbers and when the project doesn’t even remotely fall in line with the project plan I just say, “Hey, those are your numbers, not mine.”
Also, here is a great new phrase I’ve been throwing around a lot lately:
I can’t own that. Thats great stuff. When people are blowing stuff up and servers are crashing and data is getting corrupted and the managers come to me in a panic I say, “I can’t own that.” I got to say it this morning and it was pure joy 🙂
amen.
i’m tired of participating in “brainstorming” meetings and then be held accountable for every idea that popped out of me. that is the opposite of how brainstorming should be handled. “so, about that idea, give me a due date for that now.”
ummmm, dude, lay off.
so this time, i’m not opening my mouth. i’ve learned.
I guess that was what the PM was doing when she set up the plan planning meeting yesterday. 🙂
I’d never heard that the Wiegers methodology was based on manufacturing process. In a former life, I was intimately involved with manufacturing process; I know how different it is from software development.
So now when we have these idiotic planning meetings I sit back and let the PMs and the BAs make up numbers and when the project doesn’t even remotely fall in line with the project plan I just say, “Hey, those are your numbers, not mine.”
Gee, you sound like a dream to work with. Remind me to avoid you like the plague if I’m ever reassigned. 😉
if you are unable to meet a deadline, and the PM knows what the stumbling block was, you still get pegged for not meeting a damn deadline set forth by a PM who knows nothing about what it takes to get anything working well.
i’m using that phrase ASAP!
Yeah, the “brainstorming” thing is greatly misunderstood around these parts, it seems. And what you’re describing is fundamentally what’s flawed with work here: so much of it is seat-of-the-pants, but we’re supposed to be producing reams of documentation supporting our “work processes.” Well, guess what? It doesn’t work both ways.
Great icon, btw.
Didn’t Wiegers used to work for some giant aerospace company like boeing or lockheed? I could be wrong… either way, the process we use is nuts.
I am a dream to work with! 😀 My projects always come in on schedule and under budget 🙂
Software development in general is “greatly misunderstood around these parts”. :/
Whats really fun is to produce all those reams of documentation and not actually produce any work product. You could spend weeks filling out paperwork for all the various departments and never actually produce the END PRODUCT.
I hadn’t heard that he worked for Boeing or Lockheed or whatever, but you’re probably right. I just know that in the “In Search of Excellent Requirements” class, they talked about some SRS that was bound into books and ended up being, like, twelve feet long. Literally.
That is what happens when you follow all of this to its natural conclusion.
We’re trying to find a way to balance that all out this time around. If you have any suggestions, I’d love to hear ’em.