Treat Your Change Requests like Your Deposit Bottles
For those of you who don't know what deposit bottles are all about, check out this old Seinfeld clip:
http://www.youtube.com/watch?v=TEpDBQ_Ww6k
So how do deposit bottles relate to change requests? Nobody returns their bottles as soon as they are done with them, so don't release your changes as soon as you finish them. But wait--isn't reacting quickly to all change requests the responsive thing to do? Well, yes... But remember that things are constantly changing. And nobody likes change, let alone constant change.
And the other extreme? I was returning my one re-usable bag of bottles the other day and saw someone with several shopping carts full of bags of bottles. Must have run out of room under the porch to store more (hopefully it wasn't the result of the weekend's festivities). That would be a metaphor for storing up change requests for way too long. You'd be explaining all the changes to your users for days, just like it will take several days for that guy to put all his bottles into the return machine.
So what's the right mix, and what do you do in the meantime? Well, you have to touch that database anyway, so why don't you leave it better than you found it? Any hard-coded server names? Recently, I found a formula agent from R3 days. It had that old
fldName := fldName
stuff all over it. It also checked to see if it was running on OS/2! A few deletes and a much better agent. Nobody sees those changes, but you won't have to go back in there for another 10 years, just because you got a new server.
Maybe you could run a spell check... Here's a fun one: Search the 8.5.1 client help contents for lotuscript with one "s." Just sayin' - it can happen to anyone.
How often to release new code? There's something magical about the number 7, so try releasing seven changes at a time. And tell them I told you to.
Category best practices change management
| Permalink |
|
|
|
|
|
