In an ideal world, implementing DevOps practices and Agile methodologies would be the key building blocks organizations need to realize rapid, high-quality releases.

  

The ability to iterate on a product with a high volume, velocity and level of quality is the ultimate goal of the modern enterprise; every CEO wants a faster time to market. But keeping business practices agile is much easier said than done. The term “agile” is broad. While The Agile Manifesto does a good job of defining the concept, there are myriad technical and non-technical aspects to the idea. At the end of the day, simply saying you are “agile” isn’t some silver bullet that delivers faster cycle times, a better product and more satisfied users.

 

Instead, success with Agile methodologies means thinking more critically about how they are deployed and if your current DevOps practices are strong enough to support that strategy.

 

What is Agility, Really?

 

In practice, agility is a complex combination of things, perhaps best understood by what it’s not. Being agile with a product is not simply thinking about how fast you can complete a collection of features. Yes, it’s great when the backlog becomes smaller, faster. But Agile, when applied correctly, is really about having a true understanding of the user’s business problem and a real idea of their envisioned, desired outcome—and what it might take to achieve that outcome.

 

This requires a shift in thinking when it comes to the product backlog. Too often, backlogs are viewed vertically, meaning features are built that may not have independent value. As a result, release efforts grow in development effort and elapsed time, limiting the ability to quickly release in small, incremental stages. As an example, consider search functionality as a feature set. On its own, search isn’t necessarily an independently valuable feature. What are users searching for? Why do they need this information and what are they doing with the results? A vertical view of agility fails to ask these questions and focuses only on the myopic feature set at hand. Consequently, even the most mature Agile practices are limited in what they can accomplish. Who really cares if you can get a feature out of the backlog quickly if it doesn’t matter to users?

 

Agile thinking should instead be applied horizontally; the user’s journey is the center of everything. What do they need to accomplish? What are they unable to do now and how quickly can we give them that ability? In the search example, this means thinking beyond simply building a search function and instead developing a new product release that eases a specific pain point of users. Quick and iterative changes based on direct user feedback is the goal.

 

So Where Does DevOps Come In?

 

Agile is hardly a foreign concept for software engineers—86 percent use an Agile methodology (such as scrum) day to day. But the tools, processes and practices of DevOps need to be honed constantly to support iterative development, testing and release of code.

 

As with the development of any product, software developers have much to gain from building and testing functionality in small, iterative releases. Smaller tests allow for more intensive studies of accuracy and problem-solving before allowing an entire organization to rely on a solution. While these pilots may not be fully rolled out, the teams involved must be integrated to include voices from a variety of stakeholders, including but not limited to:

 

 
• Architecture

 

• Experience design

 

• Development

 

• Security

 

• Quality assurance

 

• Operations

 

 

Teams must also keep these DevOps best practices front-of-mind when developing a software solution:

 

 
• Employ microservices. A solution built from these separately deployable services that perform specific business functions is much easier to scale out or expand. Microservices also remove single points of failure (SPOFs) by preventing issues in one area of an application from affecting others.

 

• Blend continuous integration (CI) and continuous delivery (CD). These two DevOps strategies support each other in much the same way as integrated human teams that consider stakeholder needs. While CI automates the build and testing processes, CD automates the deployment cycle from development to production. The automation behind both results in a vastly increased deployment frequency.

 

• Use infrastructure-as-code. Modern cloud platforms allow for infrastructure to be software-defined. This allows DevOps practitioners to bring best practices from the field of software engineering to bear against systems challenges. Think about the new features AWS announced for CloudFormation this year, for example: configuration drift detection, dynamic references, macros (functions with iteration support) and linters. All of these are in support of treating infrastructure orchestration as a software engineering activity, allowing DevOps teams to use one common set of tools and practices.

 

• Refine observability. As architecture becomes ever more complex, the practices of monitoring and logging are evolving. No longer can you independently monitor the uptime of a server and simply log OS and app issues. Application performance management (APM) becomes paramount, measuring aspects of the user experience as they flow through the app, as does identifying and publishing relevant business metrics. The distributed nature of microservices and the various cloud services enabling them, demand new tooling to measure potential bottlenecks in the form of distributed tracing. And the DevOps best practice of “hands-off production” (e.g. no shell or attachment access) means you’ll need to provide real-time visibility into the health and inner workings of your application via log shipping, adding your centralized logging solution into the critical path of application troubleshooting.

 

• Focus on communication. This is perhaps the most beneficial point for your team and should not be overlooked. The cross-functional, collaborative teams supported by both Agile and DevOps culture break down traditional silos and unite members around a common goal. Formal structures around these teams should start early and continue through retrospectives to assess and celebrate everything you’ve accomplished in a short time. You’re not working in a vacuum, and this project isn’t the only one your team will ever produce. Keeping careful records of successes, failures and areas for improvement will only make your work more efficient and Agile in the future.

 

 

Agile is the perfect process for the modern tech landscape—releasing quickly in small bites that are then perfected based on customer feedback. In living up to that ideal, teams who turn to Agile in managing their projects shouldn’t take a set-it-and-forget-it approach to their processes. Instead, bolstered by DevOps tools, culture and practices, they should embrace the ongoing refinement and reflection required to support both customer needs and business goals.