The continuous innovation journey to DevOps is just that—continuous—meaning it's unlikely you'll ever reach the destination.
As depicted in the graphic below, the journey's steps are: assess and compare the organization with the rest of the industry, ensure that the people buy into the transformation, introduce an engineering process and products that enable teams to delight their stakeholders, continuously deliver value, and scale solutions from hundreds to millions of users. Conceptually, the transformation should be the same for any organization.
The DevOps transformation journey
However, a DevOps transformation in a company with a handful of engineers is quite different from one with hundreds or thousands of engineers.
Instinctively, the DevOps journey should be easiest with small organizations, as they are typically abundant with passion and an appetite for change. However, small organizations tend to be more constrained on resources, infrastructure, and budget, while larger organizations tend to have more policies, governance, and politics that affect the transformation.
So, how does size matter? Here's what members of the community said in a poll about how size affects the ease of transforming.
Ability to embrace DevOps based on organization size
Small and emerging organizations
In small organizations, management and engineering lines of responsibility tend to blur, which naturally creates a lean environment. Similarly, because resources are scarce, engineering typically wears multiple technical and operational hats, which organically creates cross-functional teams that are accountable for their solutions. Also, there is usually an abundance of passion and appetite for new products and processes in small and emerging organizations, which makes then ideal candidates for a transformation to a DevOps mindset. In addition, the DevOps transformation is becoming a necessity to compete with larger competitors.
As management and engineering in small organizations are lean, it is important to ensure there is a clear vision, engineering is empowered and accountable, the line of autonomy is respected, and the feedback and fail-fast processes are active. There also needs to be a clear "2 AM call" process for when a live site incident impacts the user experience—in many cases, even the CEO of a small organization must be on the standby roster. Engineers who are unwilling to fulfill a cross-functional role are a risk for these organizations. Engineers must have the right attitude, and some may need to find another home (within the organization or without). For more on DevOps teams, see "Blueprint for a team with a DevOps mindset."
DevOps patterns in organizations by size
Consider the DevOps-as-a-Service and Fully Embedded models Matthew Skelton discusses in "What Team Structure is Right for DevOps to Flourish?" The former model is ideal for small organization and the latter is feasible, as Microsoft's part-time ALM | DevOps Ranger community demonstrates.
Midsize organizations
Midsize organizations' rising resources and budget often create an environment where politics, policies, and technical governance raise their ugly heads. You are likely to find a focused IT operations team, one or a few engineering teams, and the dreaded divide between development and operations. These are siloed environments where development builds the solutions and IT ops supports the infrastructure and solutions.
Midsize organizations must focus on breaking down the silos, creating a common language, and establishing technical governance that will unite the business, development, and operations leadership and engineering. Talking about manifestos (instead of governance) will reduce the angst and resistance from engineering.
DevOps anti-patterns in organizations by size
Consider the Temporary DevOps Team Skelton describes in the "team structure" article linked above. It is a good, albeit temporary strategy to bring dev and ops closer together.
Large and established organizations
Few of us have the luxurious resources and budgets of large organizations such as Amazon, Facebook, Google, or Microsoft. Large organizations have the diversity, experience, and ability to divide their operations and development teams into many small, focused teams. For example, Microsoft has several product-focused units, such as Windows, Office, and Azure DevOps, each broken down into many small teams using a common engineering system. The teams naturally embrace agile and DevOps practices, supported by a unified enterprise-level vision and transformation strategy.
Consider establishing a community of excellence or center of excellence to create special interest groups. Tapping thought leadership by skilled knowledge workers in this way can enable and provide the organization with best practices. These groups also support the concept of a DevOps-as-a-Service pattern to help move the organization to the next level of awareness and maturity, share knowledge, cut waste, and innovate. Ensure you have representation from business, development, and operations! While all types of organizations would benefit from DevOps-as-a-Service, resource requirements—budget and people—make it viable for medium and large organizations only.
Some large organizations feel like midsized organizations, with siloed leadership, business, operations, and development teams, just bigger and more segregated. Their challenges include encouraging the entire organization to consider and embrace DevOps practices, translating organizational business-speak into a common language, and introducing unfamiliar concepts such as scrums, kanban, sprint cadence, short delivery cycles, quick and lightweight feedback loops, and continuous experimentation in production. While many organizations see the value of bringing development and operations closer together, you will experience resistance from waterfall teams that are used to stringent sequences, detailed and predictable scope, and milestone-focused projects. You may also experience leadership unintentionally interfering with engineering teams, blurring the line of autonomy that separates the WHAT and WHY (owned by leadership) from the HOW and WHEN (owned by engineering).
The Fully Embedded or Smooth Collaboration models Skelton discusses in his blog have proven successful with large organizations that naturally embrace DevOps. For others, the DevOps-as-a-Service and Temporary DevOps Team models are ideal to bring dissimilar teams closer together.
The right strategy
DNA: Culture, leadership, process, and team
Every organization is different, and assessing the right strategy is a combination of multiple characteristics, irrespective of size.
People, process, products challenges in DevOps
It is important to perform an assessment of the organization's people, process, and products to reveal its culture, leadership, teams, and appetite for change. More importantly, the assessment will highlight the areas that will transform naturally and the areas you need to nurture thoughtfully.
At the core, it is people and their culture, not an organization's size, that molds and differentiates organizations from one other.
For more insight, explore Microsoft Azure's DevOps Resource Center for a collection of videos and articles on transforming and adopting DevOps, including lessons learned.
2 Comments