Select Page

Back in the fall of 2006, I held a meeting with the senior technical managers of the company to kick off a total quality management effort. While Sunbelt had historically shipped some great products, we all felt we could do better, in terms of how we develop products.
Scrum12388
One of the effects of this effort was to move the development organization to the Agile method. (If you’re not familiar with Agile, you can read an overview of it here, but we started by having the teams watch Ken Schwaber’s outstanding talk at Google. I would highly recommend the video if you want to learn about the subject of Agile, Scrum, etc.)

I was originally trained in in the classic “waterfall” model (basically, the standard linear method of specification, development and testing), and I knew there were real problems with it. I was thrilled to see us move to this model.

One of the key tenets of the Agile method is to break projects down into small, manageable parts, referred to as iterations. Agile’s Scrum method is a way of managing these iterations, where they are referred to as Sprints. Simply stated, you break a project down into multiple Sprints, each lasting two to four weeks. Each Sprint has its own burn-down chart, showing the Sprint’s status. (The image to the left, courtesy of Wikipedia, is a diagram of the Scrum process.)

Next to my office is a small conference room. One of the first things I noticed was little meetings occurring in the mornings. These were a Scrum meetings. Each team would work through their sprints, with a burn down chart displayed on a large screen projector. During each Sprint, the burn-down chart shows how well the team is “burning down” through features or bugs. Once the chart goes to zero, that part of the project is done. Meetings are held daily each morning.

I rapidly noticed a difference. Happier, more productive developers, better products, more teamwork, and so on.

We’ve released a number of new versions of our products using this method. However, our upcoming VIPRE is our first major new release that has been developed using Agile.

VIPRE may look simple, but underneath, it’s actually an enormously complex product, with almost 50 subsystems all working in concert. Architectural design was key, as was managing the entire development process.

All of the key components were developed separately, and then were assembled together over a couple of days, much as an aircraft is assembled from its various components. What was quite amazing was the speed of assembly — it’s not normal to have a product of this complexity come together into one whole as quickly as it did. After assembly, it was in a brief alpha phase, and was deemed solid enough to go into beta.

Here’s what’s interesting: In the classic model of software development, you basically have this fight toward the end of every release, where product management, sales and marketing try to negotiate a release date, while QA and dev fight tooth and nail not to release. (Actually, you have fights all the time about all types of things — watch Ken’s video above for an idea as to what goes on. It’s highly educational about what happens behind-the-scenes in a typical software company. Just thank God that software companies don’t make airplanes.)

With Agile, however, we have burn down charts which is the religion. Here’s one of the burn down charts for VIPRE, showing the product’s final Sprint, its beta period. It’s from the 15th of April, and is un-edited:

Vipreburndown12388

The green line is open bugs. The blue line is bugs that are fixed, but need to be verified as such (by QA). And the red is the combination of the green and blue.

The red line is our religion. We look at that line and can rapidly predict how the development process is going, and when we’re going to be able to ship. When the red line gets to zero, that’s a point referred to as “zero bug bounce” (“ZBB”) The next version is then release candidate. Then, ideally, release.

This chart, along with a number of others, gets delivered to the team and senior management every single day. We all can get an immediate read as to how the process is going.

Moving to Agile is one of a number of changes we made here at Sunbelt to continue to improve both our organization, and our products. I’d rank it as one of the best things we’ve ever done as a company.

Alex Eckelberry