In his keynote at XP Day Toronto 2007, Brian Marick cautioned against the team going too fast early in a project, because it sets up false expectations about the team’s long-term velocity. He said, in essence, that if your customers are really happy, then you’re probably going too fast. In a blog comment, Mike Wasserman wrote

It is statements like this that make me cringe and give XP a bad name.

I understand Mike’s concern, but I think his reaction points to a problem with most approaches to software development: teams are motivated to attempt to go more quickly than they are able to go. This appears to be simply the nature of business: shareholders (whether for a public or privately-held company) want growth, which comes from market dominance, which comes in part from speed to market. It seems rational, then, for the business to want to produce software (whether products or support for the rest of the business) as quickly as possible. The problem, though, is when a business plans to deliver software more quickly than possible given their current people. Typically, this causes teams to do one of two things: try to go too quickly and deliver poor software, or over-react and hold back their velocity in protest. Neither achieves the desired goal of sustained growth through maximum velocity over time. So what can we do?

One option is to timebox our overdrive period. If we truly need the software organization to sacrifice in the short term to “get over a hump”, then we owe them an explanation. Specifically, we should tell the software organization how long we intend them to work in overdrive, why we need them to do so, under what conditions the overdrive period will end and how we will compensate them for working in overdrive. If we do this, we greatly increases our chances of guarding our capital investment in our top people, a competitive advantage that I believe is largely ignored in today’s marketplace. Software people are reasonable people: if you tell them you need them to work 60-hour weeks for 4-6 months until revenue is up to $400k/month, after which time they’ll receive 4 paid weeks of vacation and the opportunity to reorganize their teams however they like, then they can make the decision whether to pitch in or not. If not, you can replace them with more willing people while the cost to replace them is lower. For the ones that stay on, they will most likely get behind you and push hard, which is exactly what you need at a time like this. To do otherwise is to create an army of people who only cash their paycheques during your biggest crunch and who leave the moment it’s over. I recognize that being this transparent is frightening, but as I have become more transparent as a businessman, I’ve been happy with the results.

Another option is to fix the problems that led to the overdrive situation in the first place. There are many reasons to need to deliver software more quickly than you’re capable of: an overzealous sales organization, poor communication between the software teams and salespeople, desperation due to long periods with low sales, and generally unplanned growth. This list is by no means exhaustive, but it’s enough for the current discussion. All these problems have a common source: the quest for growth by wishful thinking and not through planning. If your company intends to grow by some magical rate year over year, you need to have a plan that supports that growth, and if delivering software is a key component of achieving that growth, then you need an accurate picture of how quickly your software organization can deliver. Remember the lessons of the Theory of Constraints: the throughput of a system is bounded by the throughput of its slowest component. Not only is there no point in selling software you can’t deliver, but it actually hurts your business to try to do it, and from a number of angles: disloyal customers or customers who refuse to pay, driving good customers to your competition, higher employee turnover including your best people moving to the competition, and decreasing trust between the “front and back of the house”. If your organization can’t execute on your growth plan, then you need to consolidate your organization first, because hoping for the best is not a management strategy. Perhaps you need to invest in training, in more people, in different people, or perhaps you simply need to rein in your sales staff a little. Satisfy one customer, then two, then four, then 20. Even in industries where this seems impossible, it must be better than the alternative of abject failure to satisfy anyone.

So when Marick says, “don’t go too fast”, don’t take it to mean that we should slow down for its own sake; we need to slow down because otherwise the business will make unrealistic plans based on our unsustainable performance, and once they start to do that, it’s a ticking timebomb, and only a matter of time before the entire house of cards falls down.

Eight Years Later

It seems I’m not the only person with whom this point resonates. My most popular tweet remains this one:

Don’t limit your thinking on this point just to programmers writing code. This issue remains a serious one, as evidenced by my impulse to write “Do We Need A New Word For ‘Velocity’?”, which reminds project managers to, you know, manage the project by planning to capacity, rather than whipping the team in an effort to make them go faster than they can.