David Brian Ward | February 13, 2012

Release Frequency and the Adoption of Agile Practices

When software releases become ever more frequent, the traditional pipeline of discrete development disciplines (everything from requirements, architecture, design, coding, testing, integration, infrastructure engineering, release, operations, support, etc.) collapses into today’s converged “DevOps” paradigm.  Agile practices are, of course, a big part of the DevOps paradigm.

An interesting talk by Kent Beck correlates the frequency of software releases with the adoption of specific Agile-development best practices.  Beck’s observations mirror our own experiences, so I’ll share them here.

When a business moves from annual to quarterly releases, we begin seeing the following changes in development management:

  • Automated acceptance testing replaces manual testing;
  • Continuous integration builds replaces build/integration as a discrete project phase;
  • Ongoing code refactoring replaces deferring requirements into next year’s release.

When a business moves from quarterly to monthly releases, managers will:

  • Start making the development managers responsible for coding, integration & testing, eliminating separate QA & build/integration teams;
  • Hold daily stand-up meetings instead of weekly or bi-weekly project meetings;
  • Cope with changing requirements via verbal and on-line agile methods, and stop processing interdepartmental change requests;
  • Put project plans and design artifacts on wikis or whiteboards, and stop producing long, edited, or off-line documents.

(No surprise that the quarterly and monthly thresholds are associated with widespread adoption of Agile practices.)

When a business reaches the monthly to weekly release threshold, managers will:

  • Manage products to a zero-bug list daily, because there is no longer any time to accumulate or delay bug fixes into the next release;
  • Eliminate separate QA, build & integration management structures;
  • Eliminate separate patch releases;
  • Employ temporary code branches while parallel refactoring takes place;
  • Deploy “keystone” releases, where foundational code is released first, and dependent UI code later on;
  • Deploy releases that include live, two-way migration of back-end data and front-end client code, because the customer can no longer perform any upgrade tasks;
  • Perform continuous beta testing with key customer participation, and stop performing up-front usability testing ahead of development.

Finally, when you reach the weekly to daily release threshold, engineering teams will:

  • “Immunize” code by building in testability and using assertions, or other self-validating programming techniques;
  • Perform rolling deployments across subsets of the user base;
  • Perform “release experiments” in lieu of testing;
  • Fold the Operations organization into the development organization;
  • Eliminate meetings entirely in lieu of online/real-time communications.

At the weekly and daily level, we also observe that instead of simply saying “we must build-in quality”, it is now a business necessity to build-in quality, for the simple reason that there is now almost no time to test at all, even with full automation!

How has your Agile management adoption correlated with these frequencies?  We’d love to hear from you. Contact Us.

David Brian Ward
David Brian Ward

David Brian Ward’s career spans 30 years of experience as an entrepreneur and leader of software innovation and implementation at firms large and small. Mr. Ward founded Telegraph Hill in 2010 with the goal of providing leading edge software development and technical management teams leveraging open source technologies to fast-growing companies grappling with technical, data and security debt.

Next Post

Leave a Reply


Great layout to depict the behavior transformation as Agile methods are adopted. As I discuss in a recent “Leveraged, Unconstrained Triangle” webinar on how PMs must adopt Agile and DevOps to become far more capable PMs, we must always remember a term I coin as “customer consumption capacity”. That is, how often can your target customers consume your output. In many cases, this barrier becomes the limiting factor in continuous delivery.

    Good point. I make the distinction between companies that are “driven-by software” vs those that are “driven-to” software.
    Your comment is apropos that latter group.

I hzve been absent for a while, but now I remember why I used to love this
site. Thanks, I’ll try annd check back more frequently.
Howw frequently you update your webb site?

    The blog is updated frequently and the site quarterly