DevOps and Agile

Key Considerations for DevOps and Agile to Coexist for Expedited Delivery

18 April 2014


DevOps and Agile complement each other to deploy working functionality into production faster. This article focuses on a subset of DevOps philosophy in the context of Agile development and highlights the key considerations for DevOps and Agile to coexist for expedited delivery.

Introduction

In an IT organization, the operations team (Ops) provides the direct interface between IT and the business/end user. Often, Ops is the first point of contact for the end-user community. An Ops organization would usually include the group that takes over the completed "deployables" from the development (Dev) team and puts them into production, as well as the team that provides "Level-1" support to the business.

The Ops team has to be efficient and knowledgeable so they can provide quality service to the business -- efficient from the standpoint of releasing the completed executables to production quickly, and knowledgeable in terms of being able to understand user queries and provide the right response.

The need for DevOps

Often, when the Dev team creates the solution, the functional requirements are given full attention but deployment and support requirements are not comprehensive. This leads to surprises during application deployment, production support, and disaster recovery. If such instances repeat, business perceives IT as less responsive and unpredictable.

In an Agile scenario, the development team produces working functionality at the end of every sprint. However, the completed functionality would have to wait until the release date arrives. Even on the release date, if the Ops team is not prepared for integration and deployment or business is not ready to go live with the new functionality, there will be release delays. Shorter time to market -- a key benefit of Agile -- is not fully realized. This scenario is illustrated below:

ravi-1.jpg

DevOps is a model that is being adopted by many IT organizations to address the scenarios described above.

DevOps: A perspective

DevOps is a philosophy under which the business teams, development teams, and the operations organization collaborate on a continuous basis to make sure that IT solutions are available to business on time and that they run without disruption. It calls for automation, collaboration, cultural change, and an organizational structure that is less complex and is easy to navigate. It addresses the people, process, and tools, as well as the technology dimensions needed to secure this collaboration and sync up the different stakeholders to move functionality to production faster.

Agile and DevOps

DevOps enables realization of the benefits of faster delivery of functionality achieved through Agile. The following sections describe the key considerations for this enablement:

Continuous involvement of the Ops team
A fundamental requirement of DevOps is that the Ops team is continuously engaged with the development team throughout the life cycle of solution development. Ops should participate right from the visioning stage to understand the business vision, the epics, and the release time lines. They should also contribute to determining the solution's technical and schedule feasibility.

From the visioning stage through the development stage, the Ops team should provide the necessary inputs to the development team in order for them to build and validate the Ops-related requirements. An illustrative model of involvement and some examples of the Ops inputs are shown below.

ravi-2.jpg

Product owner
The product owner (PO) is the face of the business for the development team. The PO has a vision for the product and has a complete insight into the functional requirements that must be met. However, if the nonfunctional requirements (NFRs) are not well understood and articulated by the PO, the development team will not be able to take them into account while creating the architecture and building the final solution.

The IT team and business leadership should equip the PO with the basic appreciation of NFRs, along with the requirements related to technical aspects such as the following:
  • Deployment and support platforms
  • Their availability and limitations
  • Dependency on vendor partners on infrastructure maintenance
  • Third-party interfaces/applications needed for the final solutions
The PO is not expected to be an expert in these areas but should be able to foresee such requirements and communicate these to the appropriate stakeholders in IT and the business.

Product backlog
Typically a product backlog focuses on epics and stories related to the functional requirements. The PO and the Dev team are well trained to brainstorm, break down epics, and document the functional requirements. However, often the NFRs are not well specified in the backlog. In addition to the functional requirements, the backlog should describe items such as the following:
  • Performance requirements
  • Tech requirements related to deployment and support
  • Requirements to develop the guidelines for rapid rollback and roll forward
  • Security/firewall requirements

Ops representation in the team
The Agile development team is cross-functional and self-organizing. Should this team then include an Ops person too? Maybe -- this depends on how cross-skilled the team members are. Typically in a start-up IT organization, some of the developers or testers would also be responsible for deployment and Level-3 (bug fixing) support. In such cases the requirements related to deployment and support would be well discussed in planning and review meetings.

However, in large organizations, operations would need a large team dedicated to take over completed code from multiple Dev teams and deploy them. In such cases, job rotation could be a useful proposition. That is, some of the developers could play the Ops role for certain period of time, and some of the Ops team members with the right aptitude could be made part of the Dev team for a certain period of time. This way the Ops side would be well represented during the development cycle.

Definition of Done
Another key lever to involve Ops in the development cycle is to weave in Ops-related aspects in the Definition of Done. Along with the standard coding, testing, and documentation elements, validation of the code in the deployment platform (e.g., a mock production box), specific support instructions as part of the documentation, and a dry run of these instructions should also be included in the Definition of Done. Here again the inputs from the Ops team are crucial.

Sprint planning and daily stand-up
Sprint backlog planning and daily stand-ups should pay attention to the Ops needs while prioritizing backlog items and discussing progress. The sprint backlog should include specific line items related to securing the necessary tech platforms for mock deployment and other such coordination activities. It is a good idea to include the Ops team during sprint planning and in selected daily stand-ups where the team would discuss Ops aspects. Any dependency on infrastructure providers and system integrators should be considered at this stage using inputs from the Ops team.

Sprint review
When the Ops team is continuously involved in the development cycle, it goes without saying that they should be part of the sprint review as well. The Dev team should demonstrate the Ops-related features of the solution. Clearly, all sprint reviews may not include Ops-related features. However, if the Ops team is part of the demos, they have an opportunity to see what is coming up and provide inputs for the subsequent sprints to improve the product and include Ops requirements as well. Here again, if one or more of the Dev team members represent Ops, it is easy to get this alignment. If Ops is a separate team, the Dev team has to make sure to get the Ops team for product demos.

Scrum of Scrums
When multiple Scrum teams work on a solution, the integration of the output of each team has to be carefully planned and executed. Each Scrum team should take into account the Ops requirements and build features in alignment with the requirements. The product owners should have a view of the final product, how it will be developed through multiple Scrum teams, and where and how it will be deployed. They should involve the Ops teams to provide specific inputs for each Scrum team. At Scrum of Scrum events, the POs should come together and validate that the Scrum teams in fact include these in their plans and demos.

Plan alignment
DevOps and Agile complement each other well and help the business and release teams plan the annual release calendar. With continuous engagement and collaboration with the development team, the Ops team gets to know which functionality will be coming out when. With that insight, and using the sprint completion pattern, the Dev and Ops teams should be able to predict with reasonable accuracy the potential release dates. Eventually they should strive to align the release schedule with the sprint plans. And when this alignment happens, the support team would be able to move completed functionality to production faster and at shorter intervals -- and a key benefit of Agile is realized!

Metrics
To measure how DevOps would help faster releases, a few leading and lagging indicators such as the following could be used. Industry statistics demonstrate that organizations using DevOps and Agile are able to make multiple releases to production in a single day.
  • Release date adherence percentage
  • Percentage increase in the number of releases
  • Time taken for release to production
  • Defects attributable to platform/support requirements
  • Percentage of NFRs met

Conclusion

When Agile and DevOps come together, the IT organization can see tangible outcomes. This article has focused on a very specific Agile sprint view to implement DevOps. However, DevOps is much larger and involves multiple dimensions including business, IT, and vendor stakeholders.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.8 (4 ratings)

Comments

Krishna Kumar C, CSM, 6/27/2014 2:28:04 AM
Ravishankar, very good article. Currently we are trying DevOps model for one of the engagement. These thoughts are very useful.

Also, my view is that all the Ops (Operational) requirements must be converted into Ops User Stories (especially Deployment tasks, as they are very important for Ops team), that way Team delivers Ops expectations without missing them
Ravishankar N, CSM, 7/1/2014 1:52:47 AM
Thank Krishna Kumar - I am happy that you found these thoughts useful.

I have in fact covered the point on Ops requirements as user stories. Please see the paragraph 'Product Backlog'. The ops requirements should be part of the product backlog and should be supported by Sprint Backlog task items.

You must Login or Signup to comment.