process_cropLast week I wrote this post about the upcoming release of SI5.5. Since then I have been thinking about the process by which we have arrived at this release. While this release started some 5 months ago, putting in practice the process that guided us began almost 18 months ago.

I became CTO in June of 2007. We had just shipped SI 5.0 and all agreed that we needed to examine how we functioned as a team as well as how we worked with other teams and our customers. The team got together and agreed that we could do a better job. We needed a process that supported the particular composition of our team and enabled us to rapidly deliver valuable, well designed, and well tested solutions to our customers. We also needed to better utilize the tools we had, and find new tools, that would help us to better communicate requirements, track work, and share information company wide.

We decided that we would adopt a development methodology called Agile. Agile isn’t so much a defined process as it is a way of thinking about how to develop software. There are a number of different specific processes out there but the basic underlying concepts are pretty much the same. I’m not going to go into the particulars of Agile, but the particular process we have adopted, Scrum, has two important aspects that I would like to share. Scrum is a process that dictates performing small, manageable, and iterative units of work which result in software that is ready to ship. Scrum also dictates regular post-mortem which are used as a tool to improve the process.

What I like about Scrum is that it understands that you cant fully implement a new process out of the box. There is no turn-key for making your team or businessmore successful on day one. Instead, Agile methodologies recognize that you reach efficiency over many iterations. By working, reviewing, and altering over enough iterations you will eventually arrive at a process that supports the goals you have set. In addition, Agile methods scale extremely well. Once you have arrived at a successful process, that process can be easily re-deployed enabling you to complete more projects across many teams.

Like any other business, the development team needed tools to help manage all the information that goes into a software release. My team uses two important tools: a Microsoft development platform called VSTS to track daily work (requirements, tasks, bugs, source code, etc) and a wiki that we use to document feature requirements. Its a shame that Microsoft has such a notorious reputation for its end-user software. While I have my own list of complaints, Microsoft has some of its most capable engineers working on tools that enable developers to be more productive. I am such a fan of VSTS that I have often used it as an example of how we can make our software better. By taking advantage of these tools we were able to more effectively track our work as well as manage and share information.

I am sharing all this information because it occurred to me that by focusing on small units of work, working in short manageable iterations that resulted in a completed project, reflecting on what worked and what didn’t, and then doing it all over again keeping what worked and throwing out what didn’t; we were able to build a process that not only could handle more work, but could deliver better solutions faster. It didn’t, however, happen overnight.

In August of last year we made a decision to change course. This change came suddenly and we were looking at a short timeline in which to deliver. The result of that course correction is SI5.5, a release I can confidently say is the best this company has ever shipped. The whole reason we were able to get to this point, is because we spent almost a year before hand working on our process and learning how to best use the tools at our disposal. Once SI5.5 ships, I will gather the team together and we will post-mortem this release. I am certain there are things we will change and things we will keep. But, going forward we have done the work and spent the time required to create processes that have made our team more productive, our software better, and I believe, delivered on our objective to help our customers run more successful businesses.