July 13, 2010
Getting Your Team to Take Short-Cuts
I had already looked at our process and had evaluated our use of best practices and our quality. We were following XP well, so if you subscribe to XP being a good set of best practices, we had that covered. Our development speed was average for enterprise software vendors using Java/Swing. But our quality was best in class. I am basing my evaluation mainly on the work of Capers Jones' recent books and metrics gathered from the team's history. That's about as objective as I could get. I also considered what I know of the industry and other groups, a more subjective measure. From what I've seen since, that team's velocity was actually quite good. To get the performance boost, there was only one thing left to do.
You may be able to get a short boost of speed at the expense of incurring technical debt, or, more technical debt than normal as your case may be. But to do that, to get a short boost in the rate of delivered features, you’ve got to paint a good picture of the situation to development. Why? Because you’ve got to get them to understand the seriousness of the situation and give them a vision of how long or how much or how many of what is needed so that they can buy-in to changing their habits and their preferred, ingrained and natural method of working. Saying "preferred way of working" makes this sound like a choice. A team's preferred way of working is indeed a preference, but it isn't much of a choice. It's a compulsion. You must realize when you demand speed, when you ask the team to take short-cuts, you are asking them to work-differently. You are asking them to work in an unnatural manner.
To illustrate: You are most likely right handed. Pick up your pen with your left hand and write a long letter to your spouse or your mom. Get the picture? The unnatural is difficult to achieve.