When businesses demand more frequent software changes, the traditional pipeline of discrete development disciplines (requirements, followed by  architecture, design, coding, testing, integration, infrastructure engineering, release, operations, support, etc.) becomes unworkable.

A talk by Kent Beck a couple years back connects the frequency of software releases with the use of specific Agile-development best practices.  Beck’s observations mirror our own experiences over the past five years as well.

Year to Quarterly

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

  • Automated acceptance testing increasingly replaces manual testing.
  • Continuous integration replaces build/integration as a distinct project phase.
  • Ongoing code refactoring replaces deferring requirements into a following year’s release.
Quarterly to monthly — Agile Practices

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

  • Development managers start to become responsible for coding, integration & testing; begin eliminating separate teams for each.
  • 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 creating long or off-line documents.


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

Monthly to weekly — DevOps Culture

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 time to delay bug fixes into the next release.
  • Eliminate separate QA, build & integration management structures.
  • Eliminate separate patch releases except in emergencies.
  • 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 there’s no longer time for upgrade tasks.
  • Perform continuous beta testing with key customer participation, and stop performing up-front usability testing ahead of development.
Weekly to daily or multiple times per day

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

  • “Immunize” code by building in testability 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.
  • Increasingly 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, for business software of any complexity.

How has your Agile practice adoption correlated with these frequencies?