Making Sense of Agile and DevOps

There has been a tectonic shift in how software is developed. Terms like Agile, CI/CD, DevOps, BDD, and TDD are new additions to the IT vocabulary.

These new practices and related tools promise to significantly reduce the time and effort required to build, test, and deploy software. Leading companies modify their applications daily and regularly push updates to their customers. For example, Trip Advisor updates its mobile app every two weeks.

Many of these new terms have broad and sometimes overlapping meanings. Well-intentioned conversations sometimes end in disagreement because the practices are in flux. In a recent discussion, everyone agreed the DevOps Engineer played a vital role, but consensus ended there.

In this article, I will try to define some of these new terms and related practices:


The Agile movement offers an alternative to traditional Waterfall software development approaches. Agile is a set of values and principles and not a methodology. There are several methodologies that can be used—often together—that fall under the Agile umbrella.

The Agile Manifesto was codified in 2001 when 17 technology leaders gathered at the Snowbird Ski Resort in Utah. They crafted a set of four value statements with 12 supporting principles. The value statements were presented as a set of preferences:

  • Individuals and interactions over processes and tools;
  • Working software over comprehensive documentation;
  • Customer collaboration over contract negotiation; and
  • Responding to change over following a plan.

Agile fundamentally differs from Waterfall because, it:

  • Encourages integrated and collaborative project teams;
  • Promotes incremental development through multiple, quick releases; and
  • Acknowledges that software must change and adapt.


Scrum is one of the best-known Agile methodologies. It is an iterative and incremental development approach where the entire team works together to achieve the goal.

The scrum team is multi-disciplinary and includes all of the skills necessary to be successful. Team members tend to be generalists who rely on each other. The optimal team size is 7-11 people who are co-located in an open work environment. The scrum master is the team’s servant-leader who guides them through the processes and ceremonies.

The product owner is a critical team member and ensures the voice of the customer is central to the effort. The product owner defines a series of minimum viable product sets that deliver value incrementally. These product sets are built during development sprints that are typically two weeks long.

Requirements are documented as brief user stories that give context to the business objective. The stories are maintained in a prioritized list called the product backlog.

At the beginning of each sprint, the team conducts a planning session. Work in the backlog is sized and the team commits to completing the specified number of stories in that sprint. This commitment is important because it establishes team accountability.

After the sprint, the team demonstrates its work at a product showcase or stakeholder review. The team also conducts a retrospective to identify ways to improve its process.


Kanban is a system for visualizing work. It was developed by Toyota as a component to its lean manufacturing model.   Visually tracking work increases transparency into the process and identifies bottlenecks.

There are multiple points of view on Kanban; it can be:

  • Its own, standalone methodology;
  • A process to be used along with other Agile methodologies;
  • A stepping stone to Scrum; and/or
  • An evolution from Scrum.

The heart of the process is the Kanban board which tracks discrete work items through their process steps. Basic boards depict the work in three phases: backlog (future), doing, and done. More sophisticated boards decompose the work into more granular steps.

Experienced teams analyze throughput and use work-in-process limits to create a consistent flow. Reducing work-in-process limits and batch sizes often increases overall output.

The Kanban board is a perfect tool for facilitating project stand-up meetings. Teams provide brief updates on what has been completed, what is in process, and impediments or blockers.

As a standalone methodology, Kanban shares many of the principles of Scrum with small teams working through a prioritized backlog. However, some of the formality and rituals are relaxed:

  • Short delivery durations are emphasized, but a fixed sprint duration is not required;
  • The product owner and scrum master are not required roles; and
  • Sprint planning is less formalized since teams do not need to commit to a two-week delivery cycle.

BDD/TDD (Behavior and Test Driven Development)

Agile dispenses with the sequential Waterfall testing phases (e.g., unit, system, user, and integration testing). Rather, testing is driven by business objectives (BDD) and integrated into the development process (TDD). BDD/TDD have the following characteristics:

  • Business events drive the development of the test cases and are written along with the user stories;
  • Automated testing tools are used and tests are regularly executed, often daily;
  • Developers write automated test cases before writing the code (TDD); and
  • Errors are identified and corrected immediately.

Implementing BDD/TDD transforms the quality assurance process. Testing and development are integrated activities. The cost of quality is significantly reduced because errors are found closer to their source, testing is automated, and multiple test cycles are eliminated.


DevOps encompasses a broad set of capabilities, practices and tools that enable automated software delivery. DevOps is an area lacking clear consensus. Also, tool capabilities are ever improving and preferred solutions change frequently.

DevOps capabilities are often employed in tandem to create a continuous flow of software from the development to deployment, including:

  • Continuous integration (CI) of modified software into the code base;
  • Automated testing practices and tools that allow the software to be tested as it is developed;
  • Code quality scanning tools that inspect code for best practice coding patterns, security vulnerabilities, etc.;
  • Continuous delivery (CD) employs automated tools that significantly reduce the time and effort required to deploy software into production; and
  • Infrastructure as code or infrastructure as a service, which automates the delivery, configuration, and deployment of computing environments.

Building a DevOps framework requires selecting and integrating tools to create a seamless flow. Senior technical resources are needed to develop the blueprints and use-patterns. Project teams need to continually invest capacity to maintain these practices to realize the benefits.

Agile and DevOps offer tremendous potential to transform how software is developed and deployed. Adopting these practices also alters long-held practices in both business and technology organizations. Understanding the benefits as well as the impact on people, process, and technology are the first step on this exciting journey.

© 2017, Alan Zucker; Project Management Essentials, LLC.  To subscribe


Agile software development. (n.d.). Retrieved December 28, 2016, from

Continuous integration. (n.d.). Retrieved December 28, 2016, from

DevOps. (n.d.). Retrieved December 28, 2016, from

Kanban (development). (n.d.). Retrieved December 28, 2016, from

Scrum (software development). (n.d.). Retrieved December 28, 2016, from

Image Courtesy of:


One thought on “Making Sense of Agile and DevOps

Comments are closed.