Slow Down; You Move Too Fast!

There’s a common misconception floating around in enterprise companies. They believe that software release/upgrade cycles have to be long. At one time, Microsoft was criticized for releasing major Windows updates too fast. (I know, hard to believe, isn’t it?) Why do they feel that way?

  • It’s expensive and time consuming to roll out new software releases.
  • It’s disruptive — user training, equipment upgrades, process changes, etc.
  • The user community doesn’t like it — too much hassle.

Clearly, trying to introduce agile software development into such a company will be a steep uphill climb — but there is hope.

Despite these widespread sentiments, there are large companies that have adopted regular, frequent, upgrade cycles and done it with minimal cost, disruption, and hassle. They do it by controlling the number of changes in each release.

Rather than two or three year release cycles that result in drastic changes in the software, they focus on release cycles of a few months. The magnitude of the changes is much smaller and thus easily managed.

A good example of this approach is

Background: is an enterprise, cloud-computing company. They started out with a CRM solution and have diversified into custom, cloud-based applications. In 2010, generated over $1.6B in revenue. They have over 92,000 customers worldwide.

When Salesforce releases a software upgrade, it’s a big deal. They have 23 production and sandbox instances. Each instance consists of multiple servers. Tens of thousands of users are impacted.

If Salesforce operated by conventional wisdom, they’d do a major release about every 5-10 years. I think they’d be out of business well before then. Their actual release cycle is 3 to 6 months — and they do it with minimal problems and little disruption to customers.

Fast doesn’t have to be disruptive.

There’s more to it than just keeping the number and scope of changes small. Here are some other things Salesforce does to make frequent releases a positive experience:

  • Maintain backward compatibility at the API level. Don’t break user customizations.
  • Make major new features optional. Don’t force customers to take something they don’t want.
  • Conduct beta testing for significant changes. Let customers try out a feature and offer feedback.
  • Provide plenty of training and documentation.

Of course, there are many other enterprise companies that operate with rapid release cycles. Google is certainly the most notable among them.

There is no point in adopting agile development techniques if your IT department is on a mission to slow down the pace of change. Work with them to identify pain points and find ways to address their concerns. Being enterprise agile is more than just daily stand-ups and short sprints.

How do you feel about rapid change?

Updated: March 27, 2011 — 10:51 pm