Long, long, ago ...
If your life has been like mine, you have had this experience: you’re working away, doing good work as far as you know, when they suddenly change the priorities and your project is stopped. Sometimes the stoppage is permanent, sometimes they plan to start the project again later. I suppose that sometimes they actually do!
When this happens, everyone loses. The user doesn’t get his software, the company has excreted currency down a rodent’s burrow, and the programmers’ time is wasted. Lose, lose, lose.
What’s to be done about this? We can’t control them, can we? We can’t disobey. We’re out of luck!
Don’t despair. Long, long ago, in a galaxy far, far away, a wise being gave us the solution: “Do or do not. There is no try.”
What Yoda was telling us was only to undertake projects that will be finished long before they can be cancelled. Simple enough advice, with one little problem: we can’t predict which projects will be cancelled, can we? Well, OK, I admit it: we can’t. But we can do something almost as good: “Do” only projects that cannot be cancelled, and “do not” do projects that can be cancelled. There is a way to accomplish that, almost perfectly:
That’s right: small releases. When they ask you to do a project that is big enough to possibly get cancelled, break it down into a series of projects so small that they can’t possibly be cancelled. Do them one at a time, finish each one, ship it, move on to the next.
How small is small enough? That’s up to you. Maybe three months, possibly six. If you are working for a really slow organization, maybe even a year.
But why push it that direction? The real question is how small can you go, and still ship something of value. That size, I’d suggest, can be driven down to as little as a couple of weeks. XP teams do that all the time. I’ll bet even your organization can’t stop many projects in only two weeks from the get-go.
Whatever the cycle is, gear yourselves to live well inside it.
Do, or do not.
And if you do – do it now!