Process improvement is a tricky mistress. Usually it’s sufficient to feel that something can be done better, but often, especially for larger organizations or folks looking for higher CMMI rankings, it’s necessary to quantify improvements in terms of measurable effects. There is a cost to process improvement; every hour spent beefing up process is an hour less spent doing "real" work. And if you optimize out the wrong processes it could seriously damper development. The key is to determine the most cost-effective changes and only execute those process improvements.
Return on investment analysis is one way to understand cost-effectiveness (PDF), but I've found this technique conceptually difficult to apply to software. How much is quality worth? How do you put a dollar amount on developer happiness? What’s a line of code worth to you? It’s enough to make your head spin, but a good friend of mine,
Kenny, once gave me some great advice that helps me keep things straight.
You've got to know when to hold ‘em
When you've got a process that works, keep using it. It’s a great feeling and there isn’t much better than finding a process that works well for you and your team. When you finally settle on a process that works it can lead to a boon of productivity. If you’re disciplined enough to capture data, use it to prove that your processes are actually working. If you aren't the data type you’ll have to rely on heuristics and intuition and the best heuristic I've found is the KA Index. The KA Index is a subjective measure of how much your team Kicks Ass. The best processes are the ones that make you awesome - fewer defects discovered in the field, better predictions of when you’ll finish tasks, fewer fires to fight - all of these are "gut measurable" data points indicating that your process is probably working.
Your gut can get you far but eventually you’ll need data to convince your boss to make the investment. I can highly recommend the
Personal Software Process if you’re interested in learning how to use data to objectively measure your processes.
Know when to fold ‘em
When you've got a process that isn’t working, drop it. Data can be used here too if you’re collecting it. If you’re not, I’ve found
carefully examining process affordances to be helpful in uncovering bum processes but affordances can be extremely subtle. The trick when giving up a process is to quit strategically - not too early, before you might see benefits, and not too late, after you’re experiencing severe problems. (
The Dip by Seth Godin is an excellent, short read on this subject.) The other thing to look out for is the cost of dropping the process. Even if your process is terrible, if worse habits fill the process vacuum you could be worse off.
Know when to walk away
Once you’ve decided to abandon a problem process it usually pays to gently transition to something else. Changing processes can be expensive between learning curve, tool changes, and the requisite burn-in period when trying out something new. If your bum process is only killing your team slowly, take a little time to read up on a replacement and avoid setting yourself up for failure. For example, when my team switched to Scrum, we finished the iteration we were in when we decided to make the switch before making drastic changes to our operating procedures.
Know when to run
If your process is absolutely killing you, drop it. Immediately. When considering this route I recommend a thorough impact analysis including some back-of-the-envelope ROI calculations. Changing a horse mid race will be expensive, I've seen it happen enough times in the DoD to know that you will pay dearly in the short term, but if the long term costs justify the change and you’re willing to go through the pain, do not hesitate to make the change.
Never Count your money when you’re sitting at the table
Generally I've found that processes out of a book need a few iterations of development before I’m able to understand how they really work and how I’m supposed to use them. If you’re following an established process (XP, Scrum, TSP,
ACDM, and so on), then try to follow it to the letter before tailoring it. Most processes have built in mechanisms for changing them once you've gained some experience and by all means, tailor once you know something doesn't work.
There’ll be time enough for counting when the dealings done
Postmortems are one of the most powerful tools in your silver toolbox. No matter how the project goes down, always take the time to reflect on what happened, why, and what you should have done so you can use that knowledge next time. Personally, I hate the idea "lessons learned" and much prefer recommendations for next time. "Lessons learned" implies that you've learned the lesson and no further action is required but this is hardly the right attitude for effective software process improvement.
Every process is a winner and every process is a loser
So every software engineer knows that the secret to surviving, is knowing what to throw away and knowing what to keep. And in the right hands, the right process can be a savior while under the wrong circumstances the same process might kill a project. I can’t offer any concrete advice other than to not be afraid of data, listen to your instincts, and look back on what you’ve done.
Comments
Post a Comment