Accelerating Organizational Agility and IT Velocity with DevOps and Change-Enabled Release Teams

Accelerating Organizational Agility and IT Velocity with DevOps and Change-Enabled Release Teams

Life moves fast, as do business operations; technology changes move even faster. Meeting these challenges requires being agile and providing strong value to your organization and customers. In addition to delivering fast results through changes and enhancements, value is also added by eliminating technology debt through continuous improvements such as reducing or eliminating outages, eliminating duplication, improving quality, and reducing negative impacts to business processes in functional areas. The coupling of the Change Enablement in the ITIL and DevOps can help you go faster, increase focus on the customer and business outcomes, reduce the ransomware threat by better securing your applications, and save money. By leveraging ITIL Change Enablement with DevOps, your organization can become more competitive by supporting your digital transformation program.

What Is DevOps?

DevOps can be defined as the methodology of applying manufacturing lean practices (LEAN) to the information technology (IT) value stream. The value stream includes any actions taken—by IT, in this case—that add value to the customer's request, from the initial ask to the perceived and realized value of the end product. Manufacturing lean practices were originally developed by Toyota Motors and later widely adopted by government agencies and private industry. With LEAN practices, engineering, development, and operations focus on the flow of the product throughout the entire process.1 In the DevOps world, we apply this focus to the complete value stream supporting our application(s) and consider the entire platform to be the product.2

DevOps practices can also be applied to many disciplines that have nothing to do with writing code, such as IT hardware moves and upgrades.3 The application platform can be anywhere but is frequently in the public cloud and consists of the hardware, software (equally commercial and open source), people, and business processes that develop, deploy, and support the practice of DevOps. DevOps is not limited to application developers. In fact, DevOps-enabled organizations include Exxon, JPMorgan Chase, UC Berkeley, and GE, which benefit by flattening their IT cultures and implementing the toolsets, with the end results being shorter deployment times, higher-quality outcomes, and reduced costs.

DevOps is not constrained to application developers. In fact, DevOps enabled organizations include the likes of Exxon, JP Morgan CHASE, UC Berkeley, and GE.

Today's economy has evolved into one driven by information. The information created by the consumers of technology is an increasingly vital asset that is essential for all businesses to both acquire new customers and retain existing ones. A siloed IT organization impedes the vital flow of this information and is a significant risk to effective decision-making, from executives to frontline employees. Information flowing freely through communication, collaboration, and automation tools has helped tear down silo thinking within organizations and flatten the culture between development, quality assurance, and operations within a DevOps-enabled organization. The removal of this impediment empowers decision-making at all organizational levels.4

With DevOps, organizations of all types move faster and become more competitive when compared to their non-DevOps-enabled peers. Products with improved quality, security, and features are deployed with greater velocity versus the old ways of developing, testing, deploying, and supporting new releases. DevOps-enabled organizations are twice as likely to increase customer acquisition, 3.4 times more likely to increase market share, and 2.4 times more likely to increase profits.5 The net effect for these organizations is often an increase in top-line revenue growth and a decrease in bottom-line costs, thus improving margins and increasing opportunities for further increases of market share.6

LEADERSHIP TAKEAWAY: DevOps-enabled organizations are more likely to increase customer acquisition, market share, and profits. The net effect for these organizations is often an increase in top-line revenue growth and a decrease in bottom-line costs.

An IT organization will often acquire new tools and applications without a DevOps strategy, hoping the tool will support their DevOps efforts. Acquiring a new application or tool for the sake of the promise of efficiency in the absence of real organizational change is dangerous and carries the risk of saddling the IT organization with ever more technology debt. Just implementing the technology tools commonly used in DevOps organizations within your institution in itself will not result in desired outcomes. To achieve the benefits of DevOps, organizations must reinvent their IT organization's culture with an effective vision and strategy and then execute that strategy with excellence.

LEADERSHIP TAKEAWAY: To achieve the benefits of DevOps, organizations must reinvent their IT organization's culture with an effective vision and strategy and then execute that strategy with excellence.

In DevOps, we apply LEAN practices to the product by executing the three principles of Flow, Feedback, and Continual Learning and Experimentation as the cultural norms within the organization (see figure 1).7 In the principle of Flow, we accelerate the flow of information downstream from development to operations and customers. The inverse is true with the Feedback principle, where information flows upstream from both customers and functional areas, sometimes directly but more often through operations to development. Finally, in the case of Continuous Learning and Experimentation, we cultivate a culture of continuous learning, exploration, and experimentation while building a tolerance for failure, thus enabling internal innovation with the potential to create new value.

Figure 1. The Three DevOps Principles
image

Research in queuing dynamics demonstrates not only the undesirable effects of waste when bottlenecks and hardship form in work queues due to culture and organizational structure but also the benefits of increased efficiency and employee satisfaction when wasteful practices are removed.8 There are numerous agile methodologies for implementing Flow. The most common are Scrum, Kanban, and LEAN Development. In fact, a team might implement two or more methodologies within their organization based on the optimal fit for the product, the team's culture, and the problem being solved. Regardless of the chosen method, workflow velocity is increased by making all work visible to the team, by reducing batch sizes, and by building quality and security controls into the workflow to ensure that defects do not leak into downstream processes and into production systems. Technology tools that can facilitate efficient flow can be as simple as a spreadsheet for Scrum meetings or complex and robust tools such as Azure DevOps and GitHub Enterprise for Kanban (see figure 2).

Figure 2. Example of a Kanban Board
image

In the principle of Feedback, we institute quality assurance feedback loops at strategic points of the product workflow (see figure 3). For most organizations that are new to DevOps, implementing feedback loops constitutes significant cultural change. Most organizations begin by appointing a DevOps advocate, sometimes called a Technology Enabler, whose primary responsibility is to facilitate the free flow of feedback between development, operations, security, and customers, bearing in mind that customers constitute internal functional teams and sales teams as well as external customers.

Most organizations begin by appointing a DevOps advocate, sometimes called a Technology Enabler.

Figure 3. A Simple DevOps Feedback Loop
image

A frequently advocated DevOps culture is one of sharing ownership, sharing responsibilities, open communications, mutual trust, transparency, accountability, and mutual respect. Often these values are lacking in the organization at the onset. But as the new culture is incubated and grown, communication flows more freely into the dialogue pool,9 with de facto cultural and structural change manifesting throughout the organization. Over time, leadership executes structural change that formalizes the cultural and digital transformation that happens as the institution develops its DevOps culture.10

Feedback Loops and Quality Improvement

Feedback loops require that work be subject to quality assurance checkpoints as quickly as possible within development and deployment pipelines. The key concept is to get the feedback to the development team as quickly as possible when problems and opportunities are identified. An example of a feedback loop is adjusting the water temperature for a bath. The water is turned on and the temperature checked. If the water is too cold, an adjustment is made—to increase the flow of hot water. The temperature is checked again and further adjustments are made until the desired temperature is reached.

Completed work flows to its downstream product components, and metrics are analyzed using a combination of tools and collaborative practices by the stakeholders. Issues and improvements are added to the backlog and prioritized based on their impact to the value stream, with corrective actions applied. Then the cycle repeats.

The principle of Continual Learning and Experimentation is perhaps the most diverse and misunderstood of the three principles. DevOps by design has no designated framework or standard, with its principles and practices applied and customized for each organization.11 Perhaps the greatest impact on developing learning is the effective execution of feedback loops. Consider for example, the release of a batch of code by a development team that contains a defect, or a settings change by a system administration group. Within the DevOps-enabled organization, the team learns of the defect immediately upon discovery, perhaps by Operations or Quality Control, and hopefully prior to the code/change's final release to production. Since code/change is produced in small batches, the timeliness of a programmer/analyst/administrator learning of the defect is in itself an efficiency enabler. The code or change is still fresh in their minds since they learned about it just after pushing it into the CI/CD pipeline, the number of lines of code or setting changes is small, and a correction is conceivably produced with a very short turnaround time, perhaps in just a few hours since its discovery. This practice of "produce work, discover errors, and rapid response with an immediate fix" reinforces learning and elevates the practices of the programmer, resulting in higher quality and faster delivery times.12 Within the DevOps life cycle (see figure 4), learning arguably often follows as a consequence of the feedback that proceeds after development.

This practice of "produce work, discover errors, and rapid response with an immediate fix" reinforces learning.

Figure 4. The DevOps Development Lifecycle
image

Applying DevOps Learning to Elevating Innovation

Learning can and should be more than just learning from one's mistakes. Forward-thinking DevOps organizations like Google, Facebook, and Microsoft allocate a significant percentage of their resources in pursuit of knowledge, ideas, and innovation, in some cases as high as a 20% time allocation per employee.13 A key factor for the learning principle is for leadership to channel the pursuit of team learning for the primary purpose of adding to the value stream. Another key factor is a willingness of leadership to foster a culture that encourages failure. But the tolerance of failure must be tempered with less glamorous characteristics such as the following:

  • An intolerance for incompetence

  • Rigorous discipline

  • Brutal candor

  • High accountability

  • Strong leadership

Organizations that develop a high tolerance for failure must also have high competency standards and capable people who are constantly seeking to exceed those standards.14 

What Is ITIL?

The Information Technology Infrastructure Library (ITIL) is a service management framework based on best practices garnered from IT organizations and practicing service management professionals worldwide. The library is a collection of books and papers that describe these best practices and how to adopt and adapt them to individual organizations. The current version of ITIL, referred to as ITIL 4, reflects new approaches to service management and provides guidance on using ITIL with other methodologies such as Agile, LEAN, and DevOps.

ITIL 4 uses the Service Value System to show how the various components and activities of the IT organization work to create value (ITIL Foundation ITIL 4 Edition, 2019, TSO). The components of the Service Value System are:

  • Guiding Principles
  • Governance
  • Service Value Chain
  • Practices
  • Continual Improvement

The ITIL 4 practices provide guidance on how to achieve desired outcomes that create value for both the IT organization and its customers. The practices provide guidance on different aspects of IT such as projects, organizational change, architecture, asset management, service level management, risk and others.

KEY TAKEAWAY: The Service Value System coupled with the Four Dimensions of service management help the IT organization take a holistic view of how to co-create value through IT services and deliver the outcomes its customers want.

What Is ITIL Change Enablement?

Change Enablement is one of the practices in ITIL 4. The purpose of Change Enablement is to ensure that risks are properly assessed and that authorized changes are managed within a change schedule to maximize the successful number of service and product changes. The goal of Change Enablement is for every change to achieve its intended outcome.

KEY TAKEAWAY: The goal of Change Enablement is for every change to achieve its intended outcome.

The ITIL Change Enablement Practice defines a change as the addition, modification, or removal of anything that could have a direct or indirect effect on services.15 There is sometimes a misconception that changes only include hardware or software changes. This misconception should be avoided. Changes within the IT organization that appear to be peripheral to the product could potentially increase risk. The inverse is true for organizations that consider the peripheral as part of change.

KEY TAKEAWAY: Organizations that effectively manage documentation as part of their value stream processes have been shown to increase product reliability.

Change Enablement impacts and depends on the culture of the organization. Organizational cultures that effectively execute Change Enablement leverage a distributed decision-making structure for approving changes whereby the authority for approving change is pushed closer to those parties responsible for delivery and support. Decisions for changes are based on assessment of risk, impact, and scope of the change. These principles guide Change Enablement:

  • Change Enablement focuses on balancing effectiveness, throughput, compliance, and risk management for all changes within the defined scope of the value stream.
  • Change is planned and realized within the context of its value stream to ensure it is effective, safe, and timely to meet stakeholder expectations.
  • Change Enablement does not seek to unify all organizational changes.

Roles within Change Enablement include the following:

  • Change Authority: Entity accountable for consequences if change fails. Should be as close to the team making change as possible.
  • Change Implementer: The person making the change.
  • Change Requester: The person or group that requested the change.
  • Change Manager: Acts as a facilitator, responsible for the overall change management process.
  • Change Coordinator: The person or group responsible for coordinating the change implementation against other changes in the pipeline.
  • Service Owner: A role responsible for managing one or more services throughout their entire life cycle. Service owners are instrumental in the development of service strategy and are responsible for the content of the service portfolio.
  • Product Owner: The person who manages a specific product and seeks to maximize the value of that product for the benefit of the organization and its customers.

Misconceptions about the Relationship between DevOps and Change Enablement

Are Change Enablement in ITIL 4 and DevOps like oil and water, always close together but unable to mix? Doesn't Change Enablement just slow things down? DevOps moves too quickly—isn't that risky? Looking at these issues on the surface, it is easy to draw the wrong conclusions. Perceptions about both DevOps and the ITIL framework are often traceable to a misinterpretation about how the models are designed, how they function, and how they interact with one another. DevOps and Change Enablement are both about enabling agility. Each model manages risk, but in different ways (see figure 5).

Figure 5. DevOps, Change Enablement, and Risk Management
image

One common misconception of Change Enablement started with the earlier versions of ITIL and the process of Change Management. Many organizations perceived that all changes need to be approved through a Change Advisory Board (CAB) or a higher-level authority such as a director or an executive. Unfortunately, that perception took hold in many organizations, resulting in the belief today that "Change Management slows things down."

A common misconception about DevOps involves pushing out changes in a fast, unpredictable, and uncontrolled manner. As an example, consider a organization whose CAB members expressed frustration with several developers who were pushing out new releases using a DevOps approach to the public cloud. The business outcomes for product features and quality were significantly increased, but CAB members failed to see this and were focused on complaining about the risks posed by the developers with their changes not being presented during the CAB weekly meeting.

What Slows Down Change Execution?

For both DevOps and Change Enablement, some missteps can slow changes:

  1. Not defining a standard change—a change that is preauthorized, well understood and documented, and is low risk—and instead requiring additional approvals for each change.
  2. Running all changes through a CAB that meets on a limited and defined schedule.
  3. Implementing tools but failing to implement automation within these tools.
  4. Lack of trust for people to make changes.
  5. Lack of defined risk assessment to classify changes.
  6. Lack of quick and effective feedback loops from operations and customers to development.
  7. Lack of understanding the impact of changes.
  8. Lack of tolerance for failure.
  9. Seeking perfection over "good enough."
  10. Making changes that are too large.
  11. Misaligned communications that fail to fit organization and team needs.

Culture

The saying "Culture eats strategy for breakfast" is cliché but is very important for DevOps and Change Enablement. A receptive and supportive culture will enable DevOps and Change Enablement practices to thrive. DevOps and Change Enablement also benefit from the same culture elements, as shown in figure 6.

Figure 6. What DevOps and Change Enablement Need
A Venn diagram showing DevOps characteristics, Change Enablement characteristics, and an overlapping area of needs that are common to both approaches. The DevOps characteristics are Unexpected changes; Strong leadership; Change advocates; Small, rapid changes; and Immediate feedback. The Change Enablement characteristics are Defined, standard changes; Supporting leadership; Change champions; Scheduled changes; and Continuous improvements. The shared set of needs is Feedback loops, Trust and Accountability, Communications, Visibility and Transparency, and Understanding Risk.

If culture items are the same for DevOps and Change Enablement, the conflicts are in how changes using DevOps and Change Enablement are executed.

DevOps

  • Smaller changes
  • More rapidly executed changes
  • Immediate feedback and changes

Change Enablement

  • Defining standard changes
  • Continuous improvement
  • Coordinating changes/change calendar 

Current State Model

Anecdotally, two models are widely used to integrate Change Enablement and DevOps in higher education institutions, government, and commercial companies. The first model is one in which an organization is "doing DevOps." As described in the "What Is DevOps?" section above, this model often involves the trappings of DevOps without actually being DevOps. The same can be true for Change Enablement.

At a high level, the second model involves work performed by a DevOps team. The work is presented to a decision maker to approve the change. If approved, the change moves into production. If rejected, it is sent back to the DevOps team to address the reason it wasn't approved (see figure 7).

Figure 7. Common DevOps and Change Enablement Model Used in Higher Education
image

Several challenges are associated with the model. First, workflow begins with the DevOps team, rather than with business goals and objectives. The DevOps team can be aware of the goals and objectives, but oftentimes technical workers are driven by technical objectives. The risk of this practice is that features under development might not be mapped to the value stream.16  Ultimately, for the change to be successful, practices must keep the business goals and objectives at the forefront of design and development.

Business goals and objectives should remain at the forefront.

At the first integration point between DevOps and Change Enablement, work that flows through quality assurance peer testing is eventually deemed "Ready for Release." It is at this point that risk is assessed. If considered high risk, work is held up by an approval gate within a group such as a CAB. Otherwise, the work is submitted to a team lead or immediate supervisor for approval. The work recently completed by the team is subject to either approval or rejection. If rejected, the work returns to the beginning of the model. If approved, work continues to flow based on when the change is approved for scheduled execution by the DevOps team responsible for pushing the approved change or feature into production.

This is another process that is dependent on maturity levels and can vary greatly in how it is done. There could be another staging area where items are tested and then pushed into production via "pipelines." This could also be moving code around with file transfers or even manual edits to the code on the production server. Once the work is deployed to production, the change is typically verified to ensure it meets the initial requirements and objectives. If it does, then the workflow ends and the change is considered complete. If, on the other hand, the change fails to meet requirements and objectives, it is typically rolled back, with the work returning to the beginning of the model. If the changes don't need to be rolled back but still need further adjustments, then other priorities and workloads must be shifted to account for this. As a consequence, risk, waste, toil, and technology debt are introduced into DevOps workflows, given the complexities, short cycle times, and interdependencies of software development. DevOps depends on high frequency communications and the elimination of waste in the value stream.17 

DevOps depends on regular communications and eliminating or reducing non-value activities.

As shown, this model comes to an abrupt ending. An unsuccessful change is rolled back to a previous version and then routed back to the beginning to investigate. A successful change just ends. However, this practice often disrupts DevOps workflows and impairs both the DevOps principles—Flow, Feedback, and Continual Learning and Experimentation—and the DevOps cycle presented in the "What is DevOps?" section above, specifically the principle of Continual Learning and the portion of the cycle that moves from the Monitor phase directly back into the Plan phase. Disruptions in flow introduce inefficiencies and waste and subtract from the value stream. By design, DevOps is continuous in nature; therefore, a true DevOps model allows for the ending to become the beginning. The abrupt ending of this current model is one of the major improvements discussed in the next section.

Proposed Model: DevOps Change-Enabled Release Teams

One can hypothesize that, fundamentally, the effective implementation of DevOps depends on information sharing coupled with some form of automation.18 Our proposed model recognizes this by changing when and how change information sharing and approval decisions are orchestrated within the IT organization.

In our proposed DevOps Change-Enabled Release Team model, we form a continuous Release Team (RT). The most important distinction of this proposal is that it is a circular model that begins with a Release Cycle (RC) and is agnostic to the type of change, be it software development or otherwise. The model consists of these steps:

  1. An RC begins with a planning committee that receives new changes, features, and information regarding both successful and failed changes deployed from the most recent RC(s). The committee is responsible for either approving, deferring, removing, or recommending approval for changes in the product.
  2. This step is followed by the change being approved, either by the committee, or by other authorities with the appropriate approval authority.
  3. Approved changes are then recorded as work items. Work items are added to the team's workflow and are appended to the backlog with prioritization based on a rating set for each item as determined by the committee.
  4. Once in the workflow, work items progress through the various DevOps workflows within the team, as is common practice in most DevOps organizations.
  5. Work items pass through quality assurance and are queued in staging areas for release approval to deployment pipelines. The approver for a release could be the team manager or team lead.

The planning committee is responsible for either approving, deferring, removing, or recommending approvals for change in the product.

There is no need to circle back to the planning committee for release approvals since the work item has already received change approval. Once released, work items are deployed using a blue/green deployment model, if applicable. A blue/green deployment model gradually transfers user traffic from a previous version of an application or microservice to a nearly identical new release, with both remaining in production.19 Based on success or failure, the work items are approved to remain in production or are rejected. If rejected, the RC is marked as failed and is rolled back to its previous released work item. If successful, the RC is marked as such. Regardless of failure or success, the information from the RC is then forwarded to the planning committee, marked as closed, and the next RC begins.

For organizations with one or more complex application products, there may be multiple Release Teams supporting a product. RTs should be kept relatively small to maintain agility and speed. There may be numerous RTs that are internal and/or external to the enterprise, with each RT composed of persons with competencies that are technical, functional, and leadership that are fit-for-purpose for the portion of the product for which the RT is responsible. In this case, mechanisms should be in place that enable information orchestration between RTs that is pertinent to what each RT is working on. By information orchestration, we mean that sufficient information is shared between RTs based on Job Characteristic Theory to ensure cohesion between RTs but not too much information sharing (to avoid introducing organizational entropy into the teams).20 Job Characteristic Theory rests in part on five propositions:

  1. Individuals within teams believe—based on their own perceived competencies—that an outcome can be achieved that the team may or may not mutually value.
  2. Outcomes are valued by the individuals to the extent that they satisfy their needs.
  3. Work conditions can be arranged by working effectively toward organizational goals.
  4. Lower-level needs are served on a continuing basis in autonomy, but not for certain higher-order needs (e.g., personal growth and development, feelings of worthwhile accomplishment).
  5. Individuals receiving feedback will experience satisfaction with higher-order needs by having accomplished something as a result of their own efforts.

Release Teams should be kept relatively small to maintain agility and speed.

When sufficient information sharing is optimally practiced and coupled with automation, work becomes more efficient and team satisfaction increases.21 This information sharing could be as simple as the application product manager sitting in on all RT planning committees or could scale up to include using collaborative tools that are modeled around the RT cross-functional compositions to enable change information orchestration. Other examples include lists of change tickets, change calendars, automated detection and reporting of events that trigger changes, and more. For smaller organizations or for simple platforms with low complexity, a single RT may be considered optimal, provided that the amount of information being shared does not introduce waste within RTs.

Optimal information sharing makes work more efficient and team satisfaction increases.

Unlike the model shown in figure 7, our proposed model in figure 8 closes the feedback loop and thus increases agility. By shifting change approval left to the start of the DevOps workflow, information sharing is improved while waste and toil are reduced.

Figure 8. Proposed Change Enabled/DevOps Continuous Release Team Model
image

Benefits of the Proposed Model

The behavioral taxonomy shown in figure 9 illustrates the benefits of adopting the proposed model. As indicated at the top of the diagram, first and foremost individual and team satisfaction are increased in the proposed model. Team members ideally rotate in and out of the planning committee. Participation in planning helps with feedback and addresses individuals' higher-order needs. As such, we consider people—whether individual or part of the team—as the capstone of this taxonomy.

Figure 9. Behavioral Taxonomy
image

Second, cross-functional understanding will be broadened by the sharing of information regarding change among stakeholders represented within the planning committee as well as persons external to the committee via tools that orchestrate and automatically communicate the information about change.

Third, by virtue of increased individual satisfaction and cross-functional understanding, teams align through empathy, shared mutual purpose, and trust. By virtue of increased trust, visibility increases into change since individuals have greater understanding and alignment and are thus less likely to hoard or hide information. This has a direct impact on risk reduction since fear will be reduced among engineers to discuss new, successful, and failed changes with openness, transparency, mutual respect, and frankness. The organization realizes increased velocity and change frequency due to cultural change in the organization. By increasing change velocity, the institution's change capacity is increased and risk is reduced. Individuals experience increased productivity and decreased unproductive conflict, both within and outside the team as a direct consequence of optimal sharing of change information, from participation as active stakeholders in change, and by virtue of everyone having skin in the game.

The business outcomes and benefits that are realized with our proposed model include:

  • Increased revenue growth derived from the organization becoming more agile and innovative. Solutions are rolled out faster, quality is improved, and customer satisfaction increases.
  • Reduced operational costs by eliminating waste and inefficiencies in DevOps workflows, work sharing, and the reduction of repetitive work through improved automation processes.
  • Increased market share as the organization becomes more innovative and capable of taking market share from less agile competitors.

Recommended Future Work

There is a lack of research regarding models that are specific to the integration of DevOps and Change Enablement, despite the criticality of interfacing between these two areas. Moreover, competing frameworks attempt to resolve the clear deficiencies that arise when implementing DevOps in organizations that structure around ITIL, the most notable being the practice of Site Reliability Engineering. Also lacking from the research community are studies that explore integrating Chaos Engineering into DevOps Change-Enabled organizations and how doing so could positively or negatively impact business outcomes for government, education, and other entities that are outside of the tech sector. Although this paper attempts to address the deficiencies that commonly arise when integrating DevOps with Change Enablement, further study is needed that considers not only this work but also other approaches.

Acknowledgments

We wish to acknowledge the following, without whom this research would have been nothing more than an idea:

  • Mitchell Pautz of the University of Southern California, who served as the catalyst to bring about conversations and the idea for this work during virtual meeting of minds within the EDUCAUSE ITSM and DevOps forums.
  • Mark Smalley, author, who kept us level set and founded in correct theory.
  • Nichole Arbino and her team at EDUCAUSE, who helped bring a level of professionalism in publishing this work.
  • Erik Patterson and the team at the University of the Virgin Islands, whose input and subsequent modification of their change management process into our proposed model enabled us to "proof test" the concept.
  • The numerous peer reviewers in higher education who have helped to strengthen this paper.
  • David Kent, president of Kent Cloud Solutions, Inc., who committed to the DevOps principles and allowed a co-author of this paper to commit a 20% workload on this work in line with the principle of learning and experimentation.

Further Reading

© 2022 EDUCAUSE. The text of this work is licensed under a Creative Commons BY-NC-ND 4.0 International License.

Citation for this work
Hank Wojteczko, Lucas Friedrichsen, Christopher Todd Barber, Craig Bennion, and Nichole Arbino. Accelerating Organizational Agility and IT Velocity with DevOps and Change-Enabled Release Teams. EDUCAUSE Working Group Paper. Boulder, CO: ECAR, September 2022.
EDUCAUSE logo
EDUCAUSE is a higher education technology association and the largest community of IT leaders and professionals committed to advancing higher education. Technology, IT roles and responsibilities, and higher education are dynamically changing. Formed in 1998, EDUCAUSE supports those who lead, manage, and use information technology to anticipate and adapt to these changes, advancing strategic IT decision-making at every level within higher education. EDUCAUSE is a global nonprofit organization whose members include US and international higher education institutions, corporations, not-for-profit organizations, and K–12 institutions. With a community of more than 99,000 individuals at member organizations located around the world, EDUCAUSE encourages diversity in perspective, opinion, and representation. For more information, please visit educause.edu.

 

Notes

  1. See "A Brief History of Lean," Lean Enterprise Institute.

    ↩︎
  2. Mark Smalley, Reflections on High-velocity IT, May 2020.

    ↩︎
  3. Kate Eby, "The Way of DevOps: A Primer on DevOps Principles and Practices," November 28, 2017.

    ↩︎
  4. Aruna Ravichandran, Kieran Taylor, and Peter Waterhouse, DevOps for Digital Leaders (CA Press, 2016).

    ↩︎
  5. Ibid.

    ↩︎
  6. Floris Erich, Chintan Amrit, and Maya Daneva, "A Qualitative Study of DevOps Usage in Practice," Journal of Software: Evolution and Process 29, no. 6 (June 2017).

    ↩︎
  7. Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook (Portland, OR: IT Revolution Press, 2016); Gene Kim, Kevin Behr, and George Spafford, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Portland, OR: IT Revolution Press, 2018).

    ↩︎
  8. David L. Kaufman, Hyun-soo Ahn, and Mark E. Lewis, "On the Introduction of an Agile, Temporary Workforce into a Tandem Queueing System," Queuing Systems 51, nos. 1–2 (October 2005); Darrell Rigby, Jeff Sutherland, and Hirotaka Takeuchi, "Embracing Agile," Harvard Business Review, May 2016.

    ↩︎
  9. Joseph Grenny, Kerry Patterson, Ron McMillan, Al Switzler, and Emily Gregory, Crucial Conversations: Tools for Talking When Stakes Are High, Third Edition (New York: McGraw Hill, 2022).

    ↩︎
  10. Alok Mishra and Ziadoon Otaiwi, "DevOps and Software Quality: A Systematic Mapping," Computer Science Review 38 (November 2020).

    ↩︎
  11. Anna Wiedemann, Nicole Forsgren, Manuel Wiesche, Heiko Gewald, and Helmut Krcmar, "Research for Practice: The DevOps Phenomenon," Communications of the ACM 62, no. 8 (August 2019): 44–49.

    ↩︎
  12. Ahmad Alnafessah, Alim Ul Gias, Runan Wang, Lulai Zhu, Giuliano Casale, and Antonio Filieri, "Quality-Aware DevOps Research: Where Do We Stand?" IEEE Access 9 (March 9, 2021).

    ↩︎
  13. Bill Murphy, "Google Says It Still Uses the '20-Percent Rule,' and You Should Totally Copy It," Inc.com, November 1, 2020. 

    ↩︎
  14. Gary P. Pisano, "The Hard Truth about Innovation Cultures," Harvard Business Review, January–February 2019.

    ↩︎
  15. See ITIL Process Wiki.

    ↩︎
  16. Taiichi Ohno, Toyota Production System: Beyond Large Scale Production (New York: Productivity Press, 1988).

    ↩︎
  17. Kate Eby, "The Way of DevOps."

    ↩︎
  18. Aymeric Hemon-Hildgen, Frantz Rowe, and Laetitia Monnier-Senicourt, "Orchestrating Automation and Sharing in DevOps Teams: A Revelatory Case of Job Satisfaction Factors, Risk and Work Conditions," European Journal of Information Systems 29, no. 235 (July 2020): 1–26.

    ↩︎
  19. "What is blue green deployment?" RedHat, January 8, 2019.

    ↩︎
  20. John B. Miner, Organizational Behavior 1: Essential Theories of Motivation and Leadership (New York: Routledge, 2005).

    ↩︎
  21. Hemon-Hildgen, Rowe, and Monnier-Senicourt, "Orchestrating Automation and Sharing in DevOps Teams."

    ↩︎