Borrowing The First 5 Minutes

Switching to Extreme Programming seems deceptively easy. As everyone will tell you, "just do it." Buy the book, train a bit, et voilà. In a sense, it is that simple. There's some bad news, though: the switch may not be the piece of cake you had in mind.

What's tough about XP is, the more you'd need it to get your project in a better shape, the harder it is to start doing it.

Among the sinking projects I've been given to see, the vast majority was spiraling full throttle down a vicious circle. The more pressure you're under to deliver, the less you care about the quality of the software you're releasing. Unfortunately, the less the quality is, the more rework you'll have to do. And of course, more rework means more schedule slippage, ergo more pressure to deliver the next bit. Here's the catch: changing your work process means that first, you'll have to slow down. You're learning, and it's going to be some while before you hit your stride. How could you do that? You're so late already. "That's great, but we don't have time for that." I've heard that sentence so many times as a coach that it's getting boring.

What are your choices, really? Be cool already, and take the time to experiment, learn, train, and share with your team? Or be in a hurry, accept your miserable fate and polish your resume for your next project? There must be a better alternative. Here's what I propose -- no matter how bad your current project seems to be, there's something you can do to improve its process, gradually up to the point where you may officially say you're fully agile.

1. Realize that your accepting pressure is a choice. There's always a point where you know better and realize that you're doing a crappy job. At that point, you can choose to refuse being miserable and commit yourself to work in a way that you're proud of.
   
   
2. Don't try to deny all the pressure at once. Don't try to change everything. Don't go on strike (well, this you may but don't say I told you). Instead, just work on one little improvement. Pair-work for 20 minutes (remember to pass the keyboard to your copilot from times to times). Write one test. Read a tutorial for 15 minutes. Yes, you're stealing time -- or no: you're borrowing time. Yes, you should be working tooth and nail on Bug #4917 instead. Don't tell anyone. Don't ask permission. Instead, give yourself the permission to improve the situation. And -- most importantly -- keep track of the time you're stealing.
   
   
3. Watch for improvement. If you're pair-working on solving a bug, track how much time less it took you to solve it (if you hadn't been keeping track of the mean time to solve a bug before, now is a good time to start). Keep track of time improvement. As soon as you have gained more time than you stole in the first place, celebrate. You're out of the vicious circle. Don't steal a lot. Be patient. The point isn't to win big, it is to repay your debt before the project is cancelled.
   
   
4. Use that excedent time you've gained and reinvest it. This is the crucial point. Now you have time to improve. You've earned that extra time the hard way, and nobody can order you what to do with it. It's yours. Use it wisely. At this point, you might need some help to guide you and tell you what to improve in priority. Maybe you're clever enough and you'll figure by yourself.
   
   
5. If you keep spiraling up, there's going to be a point where your managers will start noticing that it takes you significantly less time to do stuff. If they're not total abusers -- and there are not so many out there, oddly enough -- they'll congratulate you and will want to know what you've done differently. Don't tell them yet. Instead, negociate. Say you've been experimenting for a while, but you need to improve a bit more before being sure it works. Ask for some time to train yourself or some others in the team. Yes, "we don't have time." Make a point that it'll still be quicker than it used to be before you started your experiment. Maybe you can ask for half a day of training per week, if you can prove that you've narrowed mean feature development time from 5 days to 3. That's the key element in the negociation. You split the time you've gained in 2. Part of it benefits to your manager, part of it you reinvest.
   
   
6. When your process is stable enough or the client happy enough, celebrate again. This is the time you may start disclosing what it is you're doing. Chances are, either you'll be asked to spread the word and train others, or you'll have enough experience to claim and find a healthier organization to work for.

It's worked for me. It's worked for teams I've coached. How it's worked for you, I'd be delighted to hear about.