Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron


  • Way of thinking
  • Job title
  • Set of tools
  • Automation
  • An outgrowth of Agile development

What has changed?

  • Benefits of agile development also useful for operations
  • Changes in operating environments are occurring more frequently due to security and cost considerations
  • Difficult to predict how software will perform at scale
  • Continual delivery

Process Model Characteristics

  • Heavyweight vs. Lightweight
  • Planning vs. Doing
  • Efficiency (skillset, personnel, time to market)
  • Single vs. Multiple passes
  • Role of Maintenance
  • View of Evolution

Waterfall Model

  • Heavyweight, single-pass, strong planning-based approach
  • The "Big Bang" approach described in Head First book exhibits similar characteristics
  • Extreme amounts of time spent on planning compared to implementation
  • Each phase is completed and verified before the start of another phase
  • Personnel become experts in individual phases
  • Formal artifacts required for each step
  • Feedback to the previous step

Traditional Operations Environment

  • Complete requirements are gathered before starting any part of the project
  • Large updates, changes
  • Measuring productivity by "bugs fixed", e.g., tickets/issues closed
  • Large initial investment in resources (hardware, software, personnel) before any results
  • Manager-directed teams
  • What does this sound like?


  • Idea: It is difficult to determine requirements without a running system, so build a prototype to get the requirements
  • "Build one to throw away"
  • Develop the first version cheaply: Very high-level languages, fewer features (particularly non-functional requirements of speed, robustness, quality)
  • Heavyweight, two-pass approach with more feedback
  • Good idea, but not good enough. It is still necessary to gather all requirements during the prototype
  • Another issue: perception of a prototype as a completed system

Agile Methods

  • Lightweight, doing (vs. planning), multiple pass, evolutionary approach
  • Strongly iterative and evolutionary
  • "World is fundamentally chaotic", "Change is inevitable", "Deliver value to the customer"

Agile Manifesto

  • Individuals and interactions are more important than processes and tools
  • Working software is more important than comprehensive documentation
  • Customer collaboration is more important than contract negotiation
  • Responding to change is more important than following a plan

Agile Operations

  • Welcome change in requirements/functions
  • Deliver working software frequently with new functionality
  • Self-organizing teams
  • Developers work directly with other parts of the company
  • Measure progress by the amount of functionality

Reality for Development

  • Companies are already following an agile (e.g., iterative) process
  • Companies think they are following an agile (e.g., iterative) process
  • Companies want to be following an agile (e.g., iterative) process

Reality for Operations

  • Few companies are already following an agile (e.g., iterative) process for operations
  • Some companies would like to convert to an agile (e.g., iterative) process for operations
  • Most companies are following a waterfall (e.g., non-iterative) process for operations


  • Many operations processes grew out of an ad-hoc approach
  • Many operators do not have a formal background that would even include agile
  • Operation tends to be managed (and follow) what the rest of the company does, which tends not to be agile
  • Operators are often trained in fields where agile is not discussed
  • Resistance to change and change is more difficult in operations, e.g., threatens jobs