Going Agile

Friday, November 17, 2006

A funny

Just yesterday the QA team did a postmortem on our project. While I don't know that the list of complaints was ordered, here is number one (emphasis mine):

The specifications ... arrived after development was nearly complete. If the specifications had been locked down earlier, the Development team would have had more time to implement the requirements correctly, and the QA team would have been able to provide better test coverage. The specifications should be clearly defined and reviewed before the development phase begins, instead of being written “after the fact.”

Complaint? That's a badge of honor. Let's repeat that first line one more time because it's so juicy. "The specifications ... arrived after development was nearly complete." We were so efficient with this development process that we had the product code complete prior to the functional specifications being stabilized.

Holy crap! By a show of hands, how many people's bosses would complain to a scenario like this:

Boss: We're working on that spec. Few more things from the customer and we'll be ready to hand it to you.
Worker Bee: OK. I'll start as soon as I get it.

(two weeks later)
Boss: Got the first draft done. We just need it reviewed and signed off on.
WB: Great. I'm working on a few other things, but I'll start as soon as I get it.

(three weeks later)
Boss: Customer had some last minute changes. As soon as upper management signs off and we get customer approval it'll be solid.
WB: That's good news. We don't want to change the code mid-way because the customer changed their mind on the product.

...

(five weeks later)
Boss: OK. We finally got sign off from everyone. Here's the final first version. Any more changes we'll file change requests for. You can go ahead and get started.
WB: Finally. That's great. I finished writing the entire product to spec last week.

Friday, November 03, 2006

Two Beer Lunch

Nothing caps a long week like a two beer lunch. Except maybe an afternoon espresso.

Thursday, November 02, 2006

Letting people have your way

Yes, my worst fears were confirmed yesterday. All that talk about "improving process" and new functional specs was indicative of the project management gestapo trying to reassert their "control" over product development. They scheduled a meeting on my out-of-office day (not on purpose) so the bulk of the people who are actually running the project and are already informed and communicating could sit around a table for an hour while they bloviated about change request forms and control process.

What I wanted to say was "Look, you inept fucktards, just because you finally finished making that other project take twice as long to complete as it should have doesn't mean you need to impose your Change Request Tyranny on us." Obviously that wouldn't go over too well, so I refrained.

The reality is they're about five months late to the party.
News Flash: We already shipped the product. The film is in the can.

So anyway, they want to start having weekly status meetings. Why? Because they consider themselves too busy/important to attend the sprint planning meetings and demos. While I refrained from telling them what I really thought of that idea, I did make clear that I would not be participating. Not exactly the most effective tack, tho.

My grandfather had a great saying about how to be successful. He used to say you need to "Let people have your way." Much later in life I actually get it. Now I need to back off and play the game where I show them how what we're doing actually is exactly what they are asking for and try to make them think they came up with the idea. God how tedious. The next time I re-engineer an organization's development group I'm going to ask for a whole lot more money. This stuff is too exhausting.