In nearly any enterprise, a small, determined team can adopt new ways of working that can dramatically impact their ability to deliver value through software. We saw this in the early days of agile and scrum, where agile adoption was typically a grassroots effort.
I experienced this myself when I worked at Macromedia and then, through acquisition, Adobe in the 2000's. There was no top-down decision made one day that all teams would no longer follow a waterfall methodology. Rather, one team here and another there would experiment with the new approach. It was through hallway conversations or over lunch at the café at Townsend St. that peers would share their experiences with the newer methodology. The ideas would slowly spread as teams were eager to experience the promised benefits for themselves.
Fast forward a decade or more and a similar scene is playing out at many enterprises with DevOps. But DevOps
isn't something that can be adopted by a single Dev team in the way that scrum was. DevOps is a cross-discipline transformation that needs to grow and spread differently. While a small determined team can leverage DevOps to bring about great changes in how they deliver value through software, what happens next? After those initial, often isolated successes, how do you spread DevOps through an entire organization to achieve a total DevOps transformation?
These questions and more were explored in a recent XebiaLabs webinar
featuring DevOps thought-leader Gene Kim
, and Jeff Gallimore
, Partner & Co-Founder of Excella Consulting. Spreading DevOps in an organization is also the topic of a document, "Expanding Pockets of Greatness: Spreading DevOps Horizontally in Your Organization
," that was produced at the DevOps Enterprise Forum event in Portland, Oregon earlier this year.
In the same way that agile and scrum were never mandated from above at Adobe, the strategies and tactics Gene and Jeff describe in the webinar rely on influence rather than control. They favor “opt in” participation over mandated adoption, using a “pull” approach to change rather than a “push.”
The strategies and tactics suggested to spread DevOps through the enterprise fall into four categories: Share, Communicate, Standardize, and Empower.
Back at Adobe, individual development teams made the success of agile visible through reduced defects (see Peter Green's article "Early Agile Scaling at Adobe
"). Making DevOps success visible is important too. It allows early adopters to share their knowledge, and it allows potential allies to find you. It also allows the discussion about DevOps to center around practical, real-world results instead of just opinion. Don't say, "here's why we should do DevOps!" Instead say, "here's what DevOps did for us - and here's how you can experience the same benefit for yourself." Jeff and Gene pointed out how Ross Clanton and Heather Mickman at Target started hosting internal DevOps Days, recreating the popular community events as an internal tech conference. This helped build community and drive learning.
With Gene Kim and Jeff GallimoreA small determined team can leverage DevOps to bring about great changes in how they deliver value through software. But how do you spread DevOps through an entire organization? Watch this webinar to learn how to build and promote DevOps efforts within your organization based on proven strategies and tactics.
After sharing, you need to keep the conversation going. Help your colleagues who are just starting out find information they need to imitate your successes and avoid your pitfalls. And facilitate ongoing discussion among the steadily growing group of participants. One favorite technique of mine is using chat rooms like Slack
. Not only are these great places for ad-hoc discussion, Q&A, and general encouragement and support, they can also eventually integrate with the actual tools you may use to support your DevOps efforts. Our XebiaLabs products (XL Deploy
and XL Release
) can integrate directly with these chat tools, allowing users to query and execute commands to fully integrate workflow into team communication (see XebiaLabs Launches ChatOps For Software Community
for an overview)
A certain degree of standardization can increase the efficiency of scaling DevOps in your enterprise
. I know we just said that a top-down, mandated approach is undesirable, but there are ways to apply some standardization while still respecting individual flexibility when required. When teams adopt different sets of approaches, it's rarely malicious: they simply try to find the easiest way to accomplish their goal. If you can make it easy for everyone to adopt common services (e.g., CI/CD, analytics, self-service portal[s], code repository) you should encounter much less pushback to adopting those standardized tools and processes.
New leaders tend to rise during transformations. In agile, many early grassroots supporters went on to become evangelists or coaches (like Peter Green at Adobe, whose article I mentioned earlier). If you can recruit, identify, and support these leaders early, you can amplify their impact on the entire transformation. In fact, I think that DevOps gives a great opportunity for a new generation of leaders to make a mark on their organizations, much in the same way as agile did. If you're an individual contributor looking for ways to impact beyond your immediate role, leadership in the DevOps transformation
is perfect for you.
One word of caution; don't expect that every attempt at transformation will work out perfectly. Failures don't mean that you have the wrong leader - in fact, your leaders will grow much stronger if you treat failure as a learning opportunity and make it clear it’s okay to fail and move on. Not everything worked out well in the early days of adopting agile, but constant self-improvement drove progress. The same will be true in your DevOps transformation.
I hope you can check out the recording
and the paper
. Most importantly, I hope this helps you find more success in expanding the DevOps greatness throughout your organization.