Amplify Agile With DevOps

by Sean D. Mack and Christopher Lee

Overview

Agile and DevOps may seem like different movements, but if you look at their goals, you find that they are strikingly similar. Look at the value Agile and DevOps deliver. That is, look at the “why” of DevOps, and look at the “why” of Agile. When you look closer you discover that the goals of both are to get value to the customer quicker and to change to market demands more quickly. DevOps takes the principles introduced in Agile and extends them beyond code check-in to deployment and operations.

As the goals of Agile and DevOps align, it is not surprising to find significant overlap in the practices that surround them. In many ways, the intersection of DevOps and Agile relates to a culture of collaboration and modern technical practices and processes which emerge from that culture. We see this in processes such as Continuous Testing and Small Batch Sizes which help ensure the rapid delivery of working products to the customer. We see this in the efforts to make work visible, exposing workflow and system telemetry to accelerate the flow of value to the customer. And we see the overlap of Agile and DevOps in the focus on collaboration and the need to build small and cohesive teams with shared responsibility and a broader understanding of all the parts which are involved in product delivery.

The goals of Agile and DevOps align and, therefore, many of the principles align. Neither of these are about velocity, they are focused on delivering customer value. This is not about delivering more features, it is about delivery of the right value-added features to your end customer as quickly and efficiently as possible. DevOps takes Agile concepts and extends them beyond the build, so you can amplify Agile by implementing DevOps practices.

What is DevOps? What is Agile?

Before we begin to look at the relationship between DevOps and Agile it is important to first have a common understanding of what these terms mean. While there are many definitions they can both fundamentally be understood as a set of principles from which engineering culture and practices can be derived.

Agile, which has been around longer than DevOps, is arguably more mature in its definition, which was codified in the Agile Manifesto written in February of 2001. This manifesto sets out the following values:

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

Agile has evolved throughout the years beyond the Agile Manifesto. Modern Agile considers different aspects beyond the post-1990s Agile Manifesto small software team’s environment. In modern times, we are often scaling for both enterprises and/or startups where we are building a culture of experimentation, a learning organization, improving employee retention, delivering customer and business value rather than just velocity, and designing for psychological safety, which is key to high-performing teams.

While there have been attempts at a DevOps manifesto, there is no single manifesto that has yet to gain the sort of widespread acceptance which the Agile Manifesto has. As a general concept, DevOps values collaboration with a specific focus on cross-functionality between Development and Operations teams and responsibility for both aspects. Anthony Gardiner, Agile Coach, says, “I test, I code, I deploy, I get up on the weekend and fix the bug — I make my code better so I don't have to get up on the weekend.” DevOps can be thought of as a method of delivering value to the customer focused on collaboration and small batch sizes. DevOps focuses on continuous integration, automating everything, continuously testing, and continuously delivering.

Gardiner says, “DevOps is a movement or philosophy based entirely around the removal of silos in the process of deploying software 'over the wall'. It’s about creating one cross-functional team responsible for the code in development, deployment and production.”

While there is no single definition, Gene Kim, Kevin Behr, and George Spafford introduced the concept of the “Three Ways” of DevOps in their seminal novel, The Phoenix Project. These three ways stand at the core of many DevOps practices.

Kim later expanded on these in the DevOps Handbook which he co-authored with Jez Humble and Patrick Debois.

These three ways are composed of:

The first way - System Thinking

emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this can be as large as a division or as small as an individual contributor.

The second way - Amplify Feedback Loops

creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.

The third way - Culture of Continual Experimentation and Learning

creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery.

It is important to note that the definitions of Agile and DevOps are often confusing because they have been co-opted as marketing terms and twisted in the process. These definitions are further confused because companies claiming to be practicing Agile and DevOps tend to have the tooling and ceremonies in place, or in the case of Scrum, implementation of the rules without the mindset or organizational culture change. Or perhaps without executive management's willingness to transform.

History

Dating back to the 1990s, Agile has been in existence for much longer than DevOps which took root almost 20 years later. However, both of these sets of principles share roots in Lean manufacturing which dates back as far as the 1940s. It is no wonder we see similarities in these two today. While popularity of DevOps continues to grow, Agile has been and remains, more widely-known than DevOps. Google Trends indicates approximately three times as many searches for the term “Agile” as for the term “DevOps.”

The roots of Agile can be traced back to Lean processes of the 1940s which included Kanban, a method for visualizing the flow of work that was part of the Toyota Production system. Theory of constraints was developed later on as well. However, the Agile approach to software development really took flight in the 1990s when a group of software developers became frustrated with the highly regimented processes involved in Waterfall development methodologies. These often led software projects which took many months and even years only to result in failure. In the 1980s and 1990s, several iterative software development methodologies were created as alternative approaches to the waterfall approach including Extreme Programming (XP) and Kanban. In 1995, the Scrum practice for Agile development was introduced. Then, at the famous meeting at a Snowbird Mountain Retreat in 2001, a group of thought leaders gathered together to develop the Agile Manifesto. Agile has continued to grow and develop throughout today with many different variations and practices evolving from the original Manifesto including Modern Agile. While Agile sets down the overall principles there are many common ways to practice the Agile principles with Scrum and Kanban being two of the most popular.

DevOps is a much more recent set of principles which has roots in some of the same concepts from Lean manufacturing. The term “DevOps” was first introduced in 2009 when Patrick Debois launched the “Devopsdays” event in Ghen, Belgium. The concept took hold and the first US Devopsdays was held the first year. In 2013, leaders Gene Kim (author), Kevin Behr (author), and George Spafford (author) penned their book, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, which presented many of the underpinning concepts that make up DevOps today. DevOps has continued to grow and in 2014 we saw the increased expansion of DevOps into enterprise environments marked by the launch of the DevOps Enterprise Summit. Today, DevOps continues to grow and develop hand-in-hand with Agile.

Culture of Collaboration

One of the core commonalities between Agile and DevOps is their emphasis on building a culture of collaboration. Both of these look at ways to break down silos and increase shared accountability. By breaking down silos, DevOps and Agile reduce handoffs to increase the velocity of delivery to the customer. Agile primarily focused on the inclusion of Quality Assurance while DevOps takes this concept of collaboration and extends it to the Operations teams.

In Agile, we see the culture of collaboration baked right into the core tenets of the Agile Manifesto. The very first of which is, “Individuals and interactions over processes and tools,” paying obvious tribute to the need to work together rather than create defined terms or processes for handoffs. In addition, the third principle, “Customer collaboration over contract negotiation,” stresses the need to extend this collaboration beyond the development teams and to the customers as well.

Susan McIntosh, Agile coach, emphasizes the collaborative mindset of Agile in her article “What Exactly is the Agile Mindset?” stating, “An Agile mindset is the set of attitudes supporting an Agile working environment. These include respect, collaboration, improvement and learning cycles, pride in ownership, focus on delivering value, and the ability to adapt to change. This mindset is necessary to cultivate high-performing teams, who in turn deliver amazing value for their customers.”

There are many practices for enabling collaboration within Agile. Practices like pair programming, mobbing, and swarming all allow larger teams to work together to develop software. These depart from the concept of development as a task done alone by a solitary programmer. In addition, Agile works to seamlessly integrate QA into the process as an integral part of the team responsible for delivering working code each iteration. Ron Lichty, Interim VP Enginering says, "I would add integrating product management into teams via the product owner role in scrum. There was a long history of PdMs throwing requirements “over the wall” to developers not a lot different from developers throwing code “over the wall” to testers!" Ron Jeffries writes about 3Cs Revisited and his approach to handling stories in Extreme Programming. Atlassian suggests keeping requirements lean by downsizing PRDs with a one page dashboard.

Many of the underpinning concepts of DevOps are built around the idea of collaboration as well. In fact, the very foundation can be traced to a reaction against the separation of Development, Operations, and QA. The recognition that these separate silos give rise to conflicting interests, increased handoffs, and loss of value is one of the underpinnings of the DevOps movement.

Martin Fowler, Chief Scientist at Thoughtworks, noted the crucial role that collaboration plays in DevOps stating, “The primary characteristic of DevOps culture is increased collaboration between the roles of development and operations…There should be no silos between Development and Operations. Handover periods and documentation are a poor substitute for working together on a solution from the start. It is helpful to adjust resourcing structures to allow operations staff to get involved with teams early. Having the developers and operations staff co-located will help them to work together.”

There are many ways in which this collaboration can be accomplished in DevOps and extended beyond the development and QA process. One of the key ways to build a culture of collaboration is to develop shared goals between all teams involved in the delivery of value to the customer. By designing goals that are shared between Development, Operations, and QA, you can align the company on a clear purpose and drive focus on the customer need and end delivery.

Another way DevOps encourages collaboration is by integrating operations activities into sprints. This can be done by including operations team members in the sprint or, even better, ensuring all sprint team members share operations responsibility. It is also beneficial to include operational tasks as part of the backlog. In this way, you drive a shared focus for many of the tasks associated with operating an application that are often overlooked in feature focused teams. Often referred to as the “ilities,” these operational tasks may include things like maintainability, scalability, and security. By building a shared focus on building and running applications and services, DevOps drives collaboration between teams to deliver applications that are more secure and stable.

Beyond delivery of features and “ilities” it is common practice in high-functioning DevOps organizations to give teams that are delivering products responsibilities for maintaining these products. Once stability of the system has been proven it is handed over to another team for maintenance. Other companies include development teams as part of the pager rotation for operational issues. This creates shared responsibility and reinforces the shared goals and accountability.

Ultimately, DevOps is not a job. It is not a role and it is not any one person or team’s responsibility. DevOps is, at its core, about collaboration and, in this way, it aligns with the principles codified in the Agile manifesto.

Small Batch Sizes and Short Cycle Time

Small batch sizes and short cycle time are key to Agile. By reducing the size of the change to a system, Agile gets value to the customer more rapidly. This rapid deployment also allows for rapid feedback, allowing the customers or users to quickly see what has been developed and allow the team to adjust course rapidly if necessary. This stands in stark contrast to waterfall methodologies, where customers might wait months or even years to see a deliverable and, only then, determine if it is what they wanted or needed. DevOps takes the concept of small batch sizes and extends it with Continuous Integration and Continuous Deployment (CI/CD). CI/CD provides a toolchain to allow teams to accelerate the value to customer cutting the cycle down further from weeks to days and even hours.

Small batch sizes are key to Lean which originated in the 1930’s and provided some of the core foundations for both Agile and DevOps. Lean focuses on eliminating waste and reducing batch sizes to accomplish this. This decreases the amount of work in process and therefore the amount of inventory waiting for the next stage of processing.

This concept is echoed in the core principles of Agile which states “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” There are many benefits to small batch sizes and shorter cycle times. Small batch sizes, reduced queues, reduced transaction costs, and fast feedback loops can make variability an asset instead of a liability. According to Don Reinertsen, in order for product development to add value, there will inevitably be an uncertainty in outcomes. We shouldn’t seek to minimize failure but embrace variability. We can reduce uncertainty by learning efficiently and generating information inefficiently (by doing so, we maximize variability in the outcomes). Noah Cantor, Virtual CTO, emphasizes the impact of shorter feedback loops stating, “There's a lot of academic research and industry research which shows that the longer a feedback cycle takes, the less people can learn from it. The contrapositive is also true — the shorter the feedback cycle, the more people can learn from it.”

There are many ways to ensure you have small batch sizes and lower cycle time within Agile. One of the most fundamental approaches is to split user stories into pieces that fit neatly within an iteration. There are many ways to reduce story size. One key way to reduce story size is to split features into individual user stories or tasks.

When slicing and splitting user stories it is important to ensure you do not create component teams, but rather, stick to feature teams. Slice user stories vertically rather than horizontally. That is, look at end-to-end features rather than a specific tier of an application.

Small batch sizes and short cycle time are key for DevOps as well. Gene Kim, Jez Humble, and Patrick Debois spend a good deal of time on it in The DevOps Handbook. This concept is clearly illustrated in the first way of DevOps which focuses on increasing flow of product from left to right. By using tools from Lean such as value stream mapping, it is possible to identify bottlenecks and remove them to increase the flow of value to customers.

In addition, these shorter cycle times are key to the second and third ways of DevOps. As in Agile, shorter cycle times means that value is being delivered to customer quicker and the team can, therefore, get faster feedback. This enables experimentation allowing teams to quickly release features or changes to the customers and quickly adapt based on feedback.

One of the keys to shortened cycle time and smaller batch cycles in DevOps is the continuous integration (CI) and continuous deployment (CD) pipeline. This is one of the reasons CI/CD is such a key element of DevOps. With continuous integration, changes are continuously merged and verified so that the overall product is always potentially shippable. Continuous Deployment ensures that products are always in a deployable state allowing value to be delivered to customers at any time. These two practices take the rapid development and delivery initially introduced in Agile methods like Scrum and two-week releases cycles and cut it down further to daily or even hourly. At Velocity in 2009, John Alspaw and Paul Hammond delivered their talk, "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr" which kicked off many of the CI/CD concepts now embedded in DevOps. Today companies such as Netflix, Google, Amazon, are deploying thousands of times a day.

Making Work Visible

Visibility is another key element in both DevOps and Agile. For Agile practices such as Scrum and Kanban, this often takes the form of boards to share information. DevOps leverages these practices but also extends them to share information about how systems are performing at any given time. This can take the form of information radiators, big visible dashboards and shared dashboards.

While the Agile Manifesto does not dictate the need to make work visible the concepts underpin the practices which do. The Manifesto emphasizes “Individuals and interactions” and “Customer collaboration over contract negotiation” and “Responding to change over following a plan,” all three of which are enhanced by making work visible.

Agile developed the concept of “information radiators” which were large charts located near the Agile development team showing progress of the work through the development cycle. Alistair Cockburn coined the term “information radiator” in 2000, and introduced it in his 2001 book, Agile Software Development.

Dominica DeGrandis speaks about this in her book, Making Work Visible: Exposing Time Theft to Optimize Work & Flow. She clearly illustrates how, by making work visible we can easily identify bottlenecks and improve the flow of work through the system.

The practices of Scrum and Kanban leverage boards to show work tickets which flow through a series of steps defined as columns on the top of the board. By providing a method for teams to visualize work, they enable teams to work together. These boards also aid in quickly identifying bottlenecks.

This concept clearly aligns with Gene Kim’s first principle of DevOps, enabling flow. Scrum and Kanban boards are often employed by DevOps teams to make their work visible. Working together, development, and operations can use these to ensure that all work is being tracked. In addition, by integrating operational and security practices on the Agile team they can ensure that work tickets are included for non-functional work. This non-functional work may include work to make systems more maintainable, secure, or stable, requirements frequently neglected by functionally focused teams.

The second way of DevOps focusing on amplifying feedback loops and broadcasting operational information is a great way to do exactly this. This can include Scrum boards but it can also include real-time data on system performance, user experience, and the performance of the code and infrastructure underlying that performance. These radiators can include large monitors posted at strategic locations throughout the building.

The DevOps Handbook devotes a whole chapter to the subject of telemetry. In their chapter “Create Telemetry to Enable Seeing and Solving Problems”, they write, “Our goal is to radiate this information to the rest of the organization, ensuring that anyone who wants information about any of the services we are running can get it…By making telemetry fast, easy to get, and sufficiently centralized, everyone in the value stream can share a common view of reality.”

At Pearson Education, a publishing company with a strong focus on online education, a program was implemented called “Monitors Everywhere.” In this program, each team had a shared monitor and they were tasked with displaying key data relevant to their team. This data ranged from code commit frequency to database locks, to number of customer calls to the helpdesk depending on the team.

Etsy, the craft eCommerce company well known for its DevOps thought leadership has also done a lot of work in the space of making work visible. In his famous blog post, “Measure Anything, Measure Everything” Ian Malpass wrote, “If Engineering at Etsy has a religion, it’s the Church of Graphs. If it moves, we track it.” In fact, when Etsy moved into their new eco-friendly offices they even had a sensor and report for the levels in the rainwater cistern on the roof of the building. This yielded many benefits and helped enable the continuous deployment methods that Etsy championed. Patrick McDonnell spoke about the benefits of monitoring deployment data in The DevOps Handbook stating, “By doing this, we could more quickly see any unintended deployment side effects. We even started putting TV screens all around the office so that everyone could see how our services were performing.”

Continuous Learning

Both Agile and DevOps also have continuous learning ingrained in their core principles. In Agile, this concept is part of the Agile manifesto and is evident in key practices such as retrospectives. In DevOps, it is part of The Third Way of DevOps as implemented in practices such as blameless incident postmortems.

The Agile Manifesto emphasizes “Responding to change over following a plan” and, as such, builds in a tenet which emphasizes the need to adapt. In that adaption is the assumption that teams are reflecting and improving. With the continual short cycles of Agile, teams are able to review how things are progressing and make rapid adjustments both to the product they are delivering and the process they are using to deliver it. In addition, the Manifesto tenet of “Customer collaboration over contract negotiation” implies tight feedback loops, listening, and learning from customer feedback. In Agile, product teams can rapidly deliver functionality to customers and quickly learn from real-world feedback and usage of those features to allow them to quickly adjust course.

DevOps also emphasizes continuous learning. The Third Way of DevOps focuses on continuous learning. On the IT Revolution website, Kim writes, “The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery.”

Both Agile and DevOps have practices which codify the spirit of continuous learning and continuous experimentation. In Scrum, retrospectives are built into the process to ensure that the team takes time to reflect on every iteration, learn from mistakes and celebrate successes. Retrospectives are meetings where the team reflects on the previous iteration and looks for areas of improvement. Teams discuss what went well, what did not go well, and enumerate areas for improvement. In this way, the retrospective practice builds continuous learning and continuous improvement into Agile.

Sprint demonstrations are another great example of continuous learning within Agile processes. Many Agile teams conduct demonstrations of the sprint deliverables at the end of each iteration. These allow team members to learn from each other and better understanding all the pieces of the product. Sprint demonstrations also enable rapid feedback from project stakeholders who join the sprint demonstration. This practice provides the team an opportunity to reflect on successes, learn from each other, and provide constructive feedback to continue to grow and learn.

In DevOps, principles of continual experimentation and continuous learning are emphasized through practices such as incident postmortems. John Allspaw helped launch the concept of the blameless postmortem now a common component of DevOps practice. In his blog post on the Etsy blog, Code as Craft, he writes, “By investigating mistakes in a way that focuses on the situational aspects of a failure’s mechanism and the decision-making process of individuals proximate to the failure, an organization can come out safer than it would normally be if it had simply punished the actors involved as a remediation.” Allspaw emphasizes that the most important thing to come out of a post mortem is not a set of actions which can be taken but, rather, organizational learning.

At Etsy they did not just look at incidents without blame, they actually celebrated failure. One of the reasons for celebrating failure is that the people who make the errors are actually some of the best engineers. These people are the ones who are making the most changes and driving innovation for the business. Therefore, it becomes important not just to limit blame but actually to instill in the culture habits which celebrate failures as opportunities for learning. Etsy does this with their Three Armed Sweater award. A prestigious award among Etsy alum handed out by the CTO to celebrate the largest failure of the year. By instilling habits such as blameless postmortems and celebrations of failure, DevOps can encourage a culture which is open to discussing failure and continually learning and growing.

Embedded Specialization and the Rise of the “Full Stack” Engineer

In many ways, the embedding of QA into the product team in Agile methodologies parallels the need to embed operations within the development team in DevOps. In waterfall, many organizations were divided in separate development and QA teams. The QA and Development teams were also often driven by competing goals with the QA team focused on the quality of software and the development team focused on the speed of delivery of features. This division is not unlike the organizational division of development and operations. In these organizations, development and operations were also driven by separate goals with operations focused on stability while development focuses on feature velocity. As Agile developed and matured it became increasingly evident that QA had to be engaged throughout the entire development process. Beyond that, quality needed to be part of everyone’s job. In order to avoid lengthy hand-offs and separate QA cycles, Agile integrated QA into the team. Similarly, we are now seeing a movement within DevOps to engage the operations team or, operational thinking, throughout the entire development lifecycle.

There are many different organizational structures used to build cross-functional teams. Some organizations no longer have a separate QA team but embed QA in every team’s responsibility. Other companies have a dedicated QA person on each team. Other companies have a dedicated QA team that serves as a standard bearer to ensure QA practices and tools are aligned across the organization. However it is organized, the clear delineation of duties needed to be eroded in order to truly integrate QA into part of the delivery cycle of each team.

In the same way, we are seeing the erosion of specialization within operations and the rise of the full stack engineer. The demand for full-stack engineers has been increasing steadily since 2012 as evidenced by increasing calls for Full Stack Engineering positions. In the same way that Agile teams recognized the need to integrate QA into everyone's job, we are now seeing an increasing need to integrate operations. For small, Agile teams, it is often not possible to have a dedicated network engineer, database engineer, and storage engineer, so the solution is to find someone with a solid understanding of all of these components as well as applications.

The parallels between the integration of QA into the development team and the integration of operations allow us to take lessons learned from organizing development and QA teams for Agile delivery. Ultimately, the goal is to reduce handoffs by eliminating specialist teams and incorporating the roles and responsibilities into the main team. This leads to the “You build it, you run it mentality” where you must embed quality and maintainability into software development and engineering.

Key Differences

While Agile and DevOps have significant alignment, it is important to note that they do differ in their focus. Agile focuses primarily on the building of applications while DevOps extends this focus to include building and operating applications. DevOps takes many of the concepts of Agile and extends these beyond the build process and into production. It is this extension which defines the real differences.

So, if there are differences, they are primarily a matter of focus. Martin Corbett, Agile Coach, says “Agile is focused on breaking down work to deliver maximum value as quickly as possible to further customer outcomes, whereas DevOps focuses on items that take the code beyond build to deployment such as Continuous Deployment.” In addition, Agile focuses on building working software and collaboration between Development and QA, while DevOps focuses on collaboration between Development, QA, AND Operations.

While many look for differences between Agile and DevOps, the reality is that these two methodologies have very similar goals and similar underpinning principles and ultimately have more similarities than differences.

DevOps as an Extension of Agile

In many ways, DevOps can be seen as an extension of Agile and even a natural evolution of Agile. In waterfall, there is a clear hand-off (it is enforced by the process). Agile, as a continuous process, requires a new approach and DevOps helps with the implementation of this approach.

In order to do small batch releases central to Lean and Agile best practices, you need to find a way to reduce handoffs and make releasing to production seamless and easy. Out of this necessity naturally flow many of the DevOps practices. The concept of the full stack engineer popularized in DevOps is a natural answer to this need. To reduce handoffs engineers must be conscious of all portions of the system so that any member of the team can understand and integrate QA, security, and operational requirements without handing off to other teams. Similarly, cross-functional teams must become the norm so that small, self-contained team can deliver fully functional products without additional hand-offs to operations teams.

In addition, the continuous flow of Agile requires some level of build and deployment automation. Much of this is delivered in the CI/CD practices and tools of DevOps. CI/CD is required to allow rapid deployment of fully tested and fully functional code to the customers. So, again it is easy to see CI/CD as a natural evolution necessitated by Agile practices. These practices have continued to develop taking the release cycle time even further reducing from weeks to days and even hours.

Thinking about this from another perspective, it is very difficult to get code out the door in a week or two weeks, if you have a two week QA cycle which can only begin after development is complete. Similarly, it is very hard to get code out the door in a week or two if you have to wait a week for Change Approvals and release resources or, in worse cases, wait months for hardware purchasing and installation. It is very hard to be Agile if you have many handoffs. It is very hard to be Agile if you have a long, cumbersome change management process. It is very hard to be Agile if you have a long burdensome release process. How can you do two-week iterations and have a two-month release process? The obvious answer to this is DevOps.

This is not to say that you cannot implement Agile without DevOps. Agile was around long before DevOps and there are certainly Agile teams that do not follow many of the DevOps practices. As Noah Cantor states, “You can do Agile practices and DevOps practices without each other. What you can't do is employ Agile principles, or DevOps principles, as they are too similar to separate.” It is not that they are inseparable only that Agile is a natural predecessor and motivating influence for DevOps.

Conclusion

Lean has always been a core of DevOps and just as Agile grew out of Lean, so did DevOps, so it should not be a surprise that these two have a significant amount in common. In the 2015 State of DevOps, the authors state, “When you apply lean management practices to technology — limiting work in process (WIP); introducing visual displays to monitor quality, productivity and WIP; and using monitoring data to help inform decisions — you get results. The culture becomes more generative and performance-oriented; people experience less stress in the workplace; and IT performance improves.” 

DevOps takes the concepts established in Agile and extends them beyond code deployment. DevOps takes these concepts and applies them to the management of applications and services. By leveraging the principles of Agile, DevOps amplifies them increasing the benefits already recognized by organizations using Agile.

And it is not to say do DevOps for DevOps's sake, or to do DevOps because you are doing Agile. DevOps implementation has been shown to yield results. The 2017 State of DevOps report showed that high performing DevOps teams have 46x more frequent deployments 440x faster lead time 5x lower change failure rate and 96x faster mean time to recover (MTTR). These numbers are understated in organizations with mature DevOps practices.

As we look at each of the areas where Agile and DevOps overlap, where DevOps amplifies practices of Agile we hope you can take some concrete steps to drive your evolution in your organization. One of the most crucial steps in building collaboration is the development of shared goals. With shared goals, you can ensure that Development, Operations, QA are all aligned and working towards the same end.

Small batch sizes offer another great opportunity to drive DevOps practices to accelerate your organization. In processes such as Scrum or Kanban, look to integrate operations tasks and operations thinking into your work. If you are doing Scrum, you might also look to consider Kanban as well which can be more easily adapted to operational processes.

Whatever method you are using for small batch delivery you may also want to ensure that you are using the same systems to track work across your teams. By unifying your tracking system you can ensure that you are not creating backlogs and are really reflecting all planned and unplanned work. This can also enable you to more easily make your work visible. A key tenet of Agile, we can extend the concept of making work visible to show operations work as well as the work of the systems operations and support structures. Organizations can take great strides forward by implementing information radiators to share this information across teams.

As you look at building a more collaborative culture you can also ensure you are instilling best practices around continuous learning and experimentation. There are excellent open source tools such as Chaos Monkey which can help you insert errors so that you can force failures, learn from them, and build more resilient systems. As part of this you must also ensure you are building a culture which embraces every failure as an opportunity for organizational learning. Building rituals into your culture such as blameless postmortems, hackathons, and failure awards can be a great way to instill a culture of learning and experimentation.

There are organizational implications to the overlaps that we have discussed in this paper. The inclusion of QA in Agile and Operations in DevOps means that we must begin to build cross-functional teams and develop people with a wide breadth of knowledge. This overlap has evolved with the concept of the “full stack engineer.” While the idea that everyone knows everything may not be realistic, we can certainly strive to ensure that everyone on the team has shared responsibility and goals involving quality and operations and, if they are responsible for these things, are also learning.

There are many ways to take the principles of Agile and extend them using DevOps, but one of the most important is the alignment of organizational cultures. If teams are fundamentally not aligned on the goals the team approach codified in Agile will not be able to be extended beyond deployment into operations. One of the best ways to do this is by ensuring alignment of goals and objectives. If all of the technical delivery teams are aligned on the same vision, goals, and objectives you will immediately begin to break down silos between these organizations. If we can begin to break down organizational silos through Agile and extend this effort through DevOps, we will take steps to ensure we have truly high-performing organizations.