Jody Stocks is the Director of Software Engineering for OpenSRS. He leads our Agile development teams to provide high-quality software solutions in support of provisioning and managing our wholesale products.

Back in 2006/2007 those of us involved in development work at OpenSRS realized that we had a problem: our standard development process (define business requirements, do a complete spec, then develop – this is called the “waterfall” method) just wasn’t working for the kinds of projects we were taking on in the new marketplace. Sure, it was fine for doing TLD landrushes, registry compliance, and other small things. But we were getting bogged down whenever we did bigger things like email migrations, new products, and new user interfaces. Here’s why:

1. Writing a specification took a really long time because we were expecting them to be complete and detailed. So specifications were treated as “written in stone” because changes, even creative and intelligent ones, looked like delays.
2. Since specifications were meant to be “complete”, they were also large, making estimation quite difficult. Estimates took a long time to produce and were often wildly off even with unrealistic amounts of padding.
3. This meant we had a large number of projects going at once. Developers had to split their time among many projects and were mostly estimating, not coding.
4. Project timeframes became more and more extended, increasing the likelihood that the specifications (and even the requirements) would have to change. After all, the Internet changes quickly!

End result: it was tough to predict when developers would finish something that could be released. Priorities kept changing to try to force particular things to finish, which often made things worse.

So we started looking for a different way to do things. At a gut level it felt like we needed to break work up into smaller and more easily controlled pieces, and it also felt like the drive to fully document a specification was holding us back. Gut feeling, some research along these lines, and the previous work experience of our new Principal Engineer all led us to a type of development process called “Agile”.

An Agile development process has the following key features:

• Developers are broken into teams of 2-5 developers. Each team works on one project at a time. Teams stay together and learn how to work and communicate efficiently with each other.
• The team takes on all work for the project (QA, product management, development, sys admin and rollout, documentation, etc.). The team is not dependent on outside deliverables or people.
• Teams define and explicitly commit to a set of tasks to be done in a short period of time (e.g. 2 weeks). This is not a specification – it’s a set of simple goals for the team to meet (e.g. “enable Storefront users to purchase ccTLD domains”).
• This committed set of tasks does not change during the work period.
• Team members carry out QA, product management review, and user acceptance testing as pieces of development are completed.
• All work done in that period of time is demonstrated at the end of the period for the business client.

By working this way, the project is built iteratively via short, controlled deliverables with lots of feedback built in. Of course for anyone who was around back in the 80s this sounds like “Rapid Application Development” (RAD) – similar concept, new name.

Here at OpenSRS, we use a variant of Agile development called “Scrum”, in which:

• Team members sit together.
• There is a short daily stand-up meeting (a “scrum”) where each team member shares what they did the previous day, what they are working on now, and what roadblocks they have encountered.
• There is a “scrum master” who is responsible for organizing tasks, removing roadblocks, and other “managerial” work.
• Our work is broken into two week “sprints”.

We have found that adopting this process allows us to focus our efforts far more efficiently. It enables our developers to focus on a small number of tasks in a short period of time and to get rapid feedback from QA and product management about what works and what doesn’t. Every two weeks we can evaluate our progress, and we can also change direction if necessary without having to update and review heavy documentation artifacts. This allows us to make good predictions about how much work is left.

Our developers will tell you that they find this a much more satisfying and productive way to work.

We definitely feel we are on the right track. Of course no process is ever perfect, and we continue to tweak and refine this one as we learn more and more about how Scrum works and how it fits best into the work we do for our Resellers. I’d love to hear about your experiences with development processes and see if the things you have learned could help us, too.

More information:

• OpenSRS Principal Engineer Rick Yazwinski talks about Agile development in this short video
• The Agile Manifesto
• An Overview of Scrum
• Scrum in Five Minutes (450k PDF)

Special thanks to Flickr users Michael O’Connor and John Shardlow for making their photos available under a Creative Commons license