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.