Agile software development has been the subject of much discussion over the past two decades, although I expect the roots of Agile can be traced much further back. Thrust into prominence during the Internet boom of the mid-90s, Agile promised faster development cycles, improved developer morale, and created a means for fast response to changing requirements.

I’ve been in the tech industry long enough to be well aware that most things are over-hyped. However, in my experience, Agile methodologies not only work, but in an organization with the right characteristics, Agile methodologies work like magic.

When I was fortunate enough to land at Axcient a year ago, it was clear that the Axcient engineering team is a perfect match for Agile:

  • Less than 100 developers
  • Very senior developers
  • Every developer under one roof

While many different variations of Agile have been created over the years, the core principles that resonate with me are quite consistent:

  • Minimal upfront planning
  • Collaboration over documentation
  • Frequent releases
  • Early QA involvement
  • Architect-written code

For startup or early stage companies, the Agile model that has consistently worked best is the release train model. As the name implies, releases ship on fixed six-week intervals. While I have experimented with release cycles as short as two weeks, six weeks seems to be the optimum interval, organized as follows:

1 week planning -> 4 weeks development -> 1 week QA testing

This is the model we’re running on here at Axcient, and once again Agile has worked its magic. The developers spend less time in meetings and more time writing code. Morale is up because the team gets a break every four weeks and the pace is easily sustainable. Code quality is first-rate and fixes find their way to the field every six weeks, which contributes to a very stable code base.

While the advantages to our software development team are readily apparent, Agile has also garnered the support of the sales and marketing teams. The product marketing team can adjust the product roadmap on six week intervals and the sales team has something new to touch customers with every six weeks. Even in the rare case where a planned feature misses a train, the next release is only six weeks away; this keeps angst levels very low relative to missing a feature on a quarterly or semi-annual release.

Agile software development methodologies can present unique challenges as well.  Stay tuned, as I plan to address these in my next blog post!

jpeebles