How to build self-organizing DevOps teams

Source:- techbeacon.com

The idea of a self-organizing DevOps team is enticing: Promote business growth by combining automation at all levels with the innovation that’s enabled when individuals with a sense of ownership focus on progressive transformation in an environment that encourages continuous improvement. Parties in self-organizing teams should have a keen understanding of their business goals and the ability to make decisions about how to achieve them on their own.

In the context of swiftly and consistently changing market dynamics, in fact, there seems no other way to effectively operate, says Jason Bloomberg, president of Intellyx, an industry analysis advisory firm focused on agile digital transformation.

“Self-organization is nature’s way of building adaptable systems. The more dynamic and disruptive the business environment, the more important business agility becomes at an enterprise level.”
—Jason Bloomberg, Intellyx

Self-organization at team levels helps a large organization achieve this business agility, Bloomberg believes. Given how DevOps continues to be an evolving concept in many organizations, though, it should come as no surprise that practical advice on how to create self-organizing teams has been in somewhat short supply. Part of the problem, too, is that there’s a “Zen” factor when it comes to self-organization that resists the imposition of a specific order for managing workloads and budgets, determining toolsets, conducting reviews, and so on, says Bloomberg.

Here are the key considerations when building a self-organizing DevOps team.

Take a cue from agile

There are opportunities to foster a smart, self-organizing DevOps culture. One of them is to learn some lessons from agile principles that are specific to self-organizing teams as outlined in the Agile Manifesto, recommends Tan Moorthy, head of global services for application development and management at technology services and consulting firm Infosys Ltd.

“DevOps is a natural progression from agile,” he says. Like self-organizing agile teams, self-organizing DevOps teams should be built around motivated individuals who will work toward achieving shared goals and incorporate practices such as automation, as well as in-built quality and traceability to provide the required environment and support to get jobs done.

In the context of continuous improvement scenarios, it only makes sense that each team member, indeed, must be proactive about seeking better ways to do things, says Nick Meshes, director of analytics and optimization at strategic marketing, interactive web, and usability firm Sandstorm Design.

That includes creating proofs of concept individually or with others, integrating to improve processes, and incorporating automated testing and scripted build and deployment processes. Tools and platforms should be agreed upon by the team and tailored to the needs of the project, Meshes says. Where there are mistakes, process issues, or human factors negatively affecting the DevOps process, “the team would work together for resolution, likely incorporating improvements to the defined process and automated procedures.”

It’s useful for teams to get experience and training in how they can align to properly organize themselves, notes Bloomberg, since self-organization should not equate to chaotic, uninformed organizations. With that footing in place, they ideally can then conform to a governance structure that Moorthy says should focus on providing a unified view of appropriate processes and metrics at the system level across the value stream; incorporating effective communications, early feedback mechanisms, and dashboards to foster a culture of continual experimentation, learning, and improvement; and setting up the automation blueprint.

When it comes to defining and redefining roles, Moorthy encourages businesses to think of self-organizing DevOps teams as working exactly like Scrum teams. “IT and business teams collaborate and prioritize requirements to build a minimum viable product that can reap early and incremental benefit within the given budget,” he says. “In DevOps parlance, the development, test, and operations teams work under one umbrella in a prime-and-backup model to promote team development and handle cross-functional activities.”

The value of each team member having a responsibility for collaboration, for working together to define roles and responsibilities that best fit their skills and knowledge, and for adjusting for workload is significant, adds Meshes, as is “cross-training to ensure that team structure changes and scheduling do not disrupt DevOps processes.”

What success can companies realize from embracing these self-organization concepts? As an example, Moorthy points to the work Infosys did for a US-based media company that leveraged agile methodology and a self-organized DevOps team, tools, infrastructure, and automation to transform one of its portfolio companies to cutting-edge open-source architecture. “The client reduced release cycle time by 50 percent, thereby improving time-to-market and expanding their customer base,” he says.

Learn from the business

It’s equally useful for self-organizing DevOps teams to benefit from business knowledge that has accumulated over the years. “One thing that often happens, particularly in technology organizations, is that we reinvent a lot of the things that have worked well in business units for decades,” says Donnie Berkholz, research director for development, DevOps, and IT Ops at 451 Research.

“We act like it’s a brand-new idea to do something like set up a collaborative culture” to help people organize, even across functional separations, he says. It’s not. Therefore, it’s possible “to learn from the great business literature that’s out there in terms of case studies and books and apply that to technology organizations.”

Take, for example, the idea of self-organizing DevOps teams pulling in their own membership as necessary to achieve a business goal. In a completely flat technical organization, which Berkholz notes represents a newer iteration of defining self-organizing teams, there are many difficulties inherent to the idea of “teams just coming together to congeal around a problem to be solved.”

But it is possible to take well-known statistics-based business approaches, like inventory management methods used to ensure that the right items are always available on retail shelves, to make certain that individuals with the right DevOps expertise are available on demand to take on necessary project roles, especially across different functions.

“It takes a lot of process overhead to put into place the things that can make self-organizing teams work well. [But] if you can make it work, there is the tremendous benefit of being able to have the right expertise to attack any problem at any time.”
—Donnie Berholz, 451 Research

Similarly, self-organizing DevOps teams will be better poised for progress if individuals are hired for adaptability, given the speed at which technology changes and the need to be able to change with it, he says. It’s also critical to get incentives right to ensure that DevOps pros understand the efforts for which they’ll be rewarded, such as encouraging production engineers to better liaison with developers during the design process. “Again, this is a generic business problem of how to do business right,” he says, now applied to the self-organizing DevOps practice.

Plan for challenges

DevOps teams may confront interference to their inherent self-organization from external forces such as management, according to Bloomberg. Keeping their own team running smoothly, then, may be “less about incorporating self-organization than resisting externally imposed organization,” he says.

When management does work against DevOps’ own self-organization efforts, the results could be bad. Jeanne Morain, a digital/cloud strategist and author at iSpeakCloud, recounts the story of one DevOps director who self-organized efforts outside of executive leadership as a demonstration of why the model would benefit the business.

He wound up demoted to an analyst role because leadership felt that his efforts distracted others on the DevOps teams from their primary roles—and also because leaders believed it was their domain to define new roles and responsibilities. “He is very good at what he does, so they kept him,” she says. “His approach was just not appreciated.”

When executive leadership trouble strikes, Bloomberg recommends that DevOps teams engage in an open discussion of how best to meet business goals with executives.

“The challenge is to raise the awareness of the goals from specific, tactical deliverables to the more strategic goals,” he says. In the case of DevOps, Bloomberg says, that means continually circling back to the main issue: Realizing business velocity in the face of dynamic business requirements.