When DevOps and requirements gathering techniques collide

I'm an Agile product manager. What are the most important DevOps requirements to add to traditional requirements gathering techniques?

This is such a great question; one that hits at the core of why DevOps product thinking is important. Embracing a DevOps culture means emphasizing the collaboration across the entire lifecycle of product development (and delivery) -- from c-suite strategy teams, to product management planning, to software development and QA, to infrastructure teams, business intelligence and data science teams -- all of whom are involved in a continuous cycle of product delivery, learning and improvement.

As such, a good DevOps practice shifts Agile product thinking for any delivery away from the success of the 'feature' and towards the success of the entire system. This is at the heart of requirements gathering techniques.

In a traditional Agile process, requirements gathering techniques are somewhat limited in scope to what is required to achieve specific end-user goals through the implementation or improvement of specific features, such as new API calls, specific filters to a search form or even changes to capture new user data from a page interaction. For purposes of disambiguation, I propose calling these "Feature Requirements" (FRs).

A good DevOps practice shifts agile product thinking for any delivery away from the success of the 'feature' and towards the success of the entire system.

In a DevOps culture, we must proactively aim to add another set of requirements on top of the list of FRs, one which enumerates everything needed to handle this new feature in a production system at a level where the feature will be successful in front of customers. This is absolutely critical, yet is often forgotten or overlooked. We call this a list of "System Requirements" (SRs).

Some common SRs include:

1. Impact on dependent systems. Thinking through the impact to the entire system is the essence of DevOps. Especially when applications are built on service-oriented architectures, requirements for one feature may include dependencies on other systems.

   Dependency requirements have two forms: 1) making changes that can potentially impact another part of the application negatively or 2) changes must be made to some other part of the application before this feature can be implemented. Both instances often take teams by surprise and can be a huge letdown during live deployment.

2. Load time SLAs. Slow apps are a primary quality issue in user experience. For a user to take advantage of a new feature means that the app itself can handle the new feature in production and at scale.

   For example, large-scale websites that use heavy search and discovery algorithms are especially susceptible to issues of latency and load time. Likewise, prototypes may process and work well with small data sets, but fail at scale. Load time requirements, or service-level agreements (SLAs), allow product managers, engineers and infrastructure teams to have quantifiable targets (e.g., > 400 milliseconds) for loading and processing.

3. Analytics instrumentation. Far too often, I've seen products launched without a good way to measure success or failure. No feature can possibly contribute to a product strategy without instrumenting effective ways to measure impact, gather data to iterate and improve, and benchmark progress along the way. Without analytics or measurement, it's anybody's guess.
4. Automation. While this subject starts to move outside of my direct expertise, having lead development teams for awhile, I know how important automation is to the release process.

   In theory, we want the entire release automated. We do this to reduce risk (errors, conflicts) and increase speed. An "Infrastructure as Code" approach, which uses tools like Chef (Ruby) or Ansible (Python), is outside the range of this article. But automation is essential to DevOps goals of decreasing downtime and increasing reliability.

5. Scalability (especially of data) across all parts of the product. For some, scalability speaks to the heart of a DevOps philosophy.

   In every feature build, we must ask ourselves several questions: Are we considering the technical impact to a system upfront and continually? Are we using shared session states? Are we separating read vs. write connection strings and partitioning data efficiently? Can we scale our data on demand?

6. Documentation. Last, but not least, it is critical to write things down for future reference. All too often, time is not allotted for teams to capture relevant documentation, and any time saved is lost later when much more time is required to track down this information by hand.

   Not having documentation as a mandatory requirement is product feature thinking, not DevOps thinking.

   In order to achieve the goals inherent to a DevOps culture, any change to the system must come packaged with critical information, such as those above, and more, including all dependencies, expected UI states and user experience outcomes, API calls, config options and everything else that impacts the larger system.

From the perspective of DevOps, gathering system requirements alongside feature requirements is fundamental to the process of moving from a feature-centric Agile process to a comprehensive DevOps culture. Everything from dependencies and scalability to analytics and documentation must be considered and prioritized as part of the release lifecycle.