In my last entry, I talked about our adoption of the ‘agile’ development process. After a year of impressive work by our development team transitioning to it, we are in many ways still in the early stages of realizing the benefits. A recent example really drove home this realization.

A few months ago we released a new version of our IMail/ICS messaging line. It was a major release, with substantial enhancements, including a brand new web interface. This integrated with IIS for the first time on the back end. Unfortunately, we failed to anticipate all of the configuration issues that we would encounter in the field, and as a result, the number and length of tech support calls rose quickly. (Although the problems stemmed from configuration of Microsoft’s IIS, the problem was entirely ours. We decided to make use of IIS, and thus assumed responsibility for it as though we had written it ourselves.)

These configuration issues caused real pain for our customers and placed a major load on our tech support staff, who worked long hours with impressive dedication to resolve issues for customers. Adding tech support staff helped some, but didn’t keep customers from encountering the issues in the first place, and call volumes and wait times were still high. We were in a bind, and had to determine what to do.

Because of ‘agile’, the answer was straightforward. We decided to focus development on doing whatever it took to eliminate the configuration issues, whether that involved clearer instructions, more helpful and informative on-screen explanations or software that anticipated and avoided the types of problems that customers ran into. The issues were complex, and it would take several months to adequately address them, so we decided to put out a series of monthly releases until we heard from technical support that customers were no longer encountering these types of problems. We’re now two releases and over two months into that process, and the results are substantial. The number and length of calls has dropped with each monthly release. Although we’re going to continue this series of quick releases to make further improvements, it’s nice to hear that customers are starting to tell other customers to upgrade to the new release because it’s stable and offers impressive new capabilities.

Why was ‘agile’ integral to our ability to do this? After all, software companies have had urgent needs to respond to issues in the field for as long as there has been software. The difference is in the response time. With ‘agile’, the entire development team, which includes developers, testers, tech support, and those writing documentation and help, all work together to ensure that at any time, with a few weeks notice, they can put out a well coordinated release. Because the team was already geared up for ‘agile’, they have been able to take on this cycle of rapid releases and drive real benefits for customers in the short term.

We misjudged the complexity of users’ environments, and that led to pain for our customers. The important lesson for us is that our ability to react and focus resources on such problems is a new and growing strength. We will utilize that strength to reinforce the theme that has led to our growth over the past fifteen years - the quality of our software is at the core of the value we provide to our customers. Also, what it takes to provide that quality as a mid-sized software company is entirely different from what it takes for a small start-up. To adapt, it requires process innovation. We’re excited about the transformation our development team has made, the benefits it’s having for our customers, and the impact it will have in the future as we continue to refine our new approach to producing high-quality, practical software that simplifies the lives of IT professionals.

Posted by Roger Greene
digg this add to del.icio.us add to My Web Furl this page

Trackback Pings

TrackBack URL for this entry:
http://156.21.1.19/mt-tb.cgi/993