When an organization finally figures out how to get DevOps to work properly, it’s unquestionably a beautiful thing. A team working together at full speed, delivering value to their organizations, while laughing in the face of roadblocks that threaten to impede their progress.
Getting to this point wasn’t easy. We had to learn numerous lessons, many from Agile and Lean and other practices, each of which offered part of the answer. And then the technology itself had to reach a level of maturity, both among the tools themselves as well as the infrastructure. Clearly, DevOps owes much to open source. Not to mention APIs. Cloud computing and virtualization. And software-defined, well, everything.
Even taking into consideration those few but remarkable DevOps success stories – stories that are more frequent every day – the work of DevOps is far from complete.
As enterprises today undergo digital transformation, they become software-driven organizations. But software-driven is somewhat of a misnomer, because software alone is only an enabler – just as software-based tools are not the core of DevOps, but merely DevOps enablers.
In reality, to become software-driven, companies must transform organizationally – and the key to such transformation is self-organization.
What we’re missing, however, is a self-organization playbook. That’s where DevOps can help. Getting DevOps to work means getting self-organization to work. The challenge then becomes spreading the approach beyond the software organization.
For this reason I called for the spread of the DevOps ‘virus’ in my last Cortex newsletter.
We’re not simply taking a page out of the DevOps playbook and applying it to ‘non-software’ teams – assuming it even makes sense to talk about such teams in today’s software-driven world.
The goal, in fact, is more subtle: to leverage DevOps principles as a fundamental mechanism to achieve the organizational change necessary for digital transformation success.
Beyond Two Pizzas
At the heart of the DevOps culture, of course, is self-organization. Self-organizing teams, after all, are an Agile principle that serves us well today, as is the Lean principle (also familiar from Extreme Programming) that everybody on the team is responsible for everything the team produces.
Put these two basic organizational principles together, and you have the basis for cooperation, empathy, and responsibility. People working together to achieve a common goal is the essence of cooperation. Self-organization and joint responsibility facilitate empathy, since you can’t dump problems on someone else.
Nothing particularly insightful or new so far. The challenge, however, comes when we want to expand all this organizational goodness beyond teams of about eight to ten people – the perennial two-pizza challenge. In other words, how do we scale DevOps culture?
The two-pizza challenge, of course, refers to the adage that you can feed an ideally sized team with two pizzas. Clearly, if a team grows much beyond that point, then the ‘everyone is responsible for everything’ principle breaks down quickly.
How, then, can we spread self-organization more broadly? The key is to understand the primary factor limiting our success with self-organization up to this point: we’ve been assembling self-organizing teams all along.
As long as someone (a manager, say) assigns people to a team, the team’s ability to self-organize has just taken a big hit. Sure, team members can decide how to divide up tasks, who sits with whom, and so on. But there’s only so much self-organizing a team can do when someone has put together the team and given them an assignment.
The first key to spreading the DevOps virus beyond the two-pizza level, therefore, is to allow people to choose their own teams, and to allow teams to choose their own goals.
Cross-Pollination among Self-Organizing Teams
For an organization to be comfortable with such self-organization, people must have an understanding of various needs across the organization so they can best decide which teams they should help with.
There also must be adequate communication and collaboration among people outside of existing teams, so that there can be an interplay between the people on teams looking for additional help and the people who have the time, inclination, and ability to provide that help. I like to call this interplay cross-pollination.
Cross-pollination consists of the following general principles:
- Anyone can identify a business goal they wish to pursue and seek to assemble a team to achieve that goal. That person, however, must be on the team – it’s strictly against the rules for someone to organize a team they don’t belong to. (Stay tuned for part two of this Cortex for more advice to management.)
- Some people may participate in more than one team at the same time, since each team doesn’t need all of their time. Everybody on a team won’t be a partial contributor as a rule, but chances are some people on each team will qualify.
- Some people serve a role on a team for only part of the lifetime of the team. They may find themselves moving from one team to another as those teams need them.
- Nobody is ‘off limits’ when a team needs help from someone outside the team. Even customers are fair game. If a team thinks they need the help of someone else, they can ask anybody they think might help, or might know someone who can help.
Clearly, suitable social networking tools are essential for empowering cross-pollination. It’s no wonder, therefore, that collaboration and communication tools and techniques are such an important part of digital initiatives today (stay tuned for more insight into this topic in a future Cortex – don’t forget to subscribe!)
Decision Making on Self-Organizing Teams
The basic principle of decision making is for teams to do it for themselves, rather than some manager or other external party doing it for them. Here are the basics:
- It’s up to the team to decide how they make decisions. Vote of the majority? Possibly. Unanimous consensus? Might be worth a try. Let a leader decide? Perhaps – but note that the team also decides whether they need a leader and if so, who it is. Nobody has a pre-defined leadership position; instead, leaders naturally arise as a part of self-organization.
- Teams must be willing and able to resolve personal conflicts internally. Any team has the ability to kick someone out – but such an occurrence should be treated as a positive cross-pollination opportunity because it frees someone up to help elsewhere, thus turning a potentially morale-killing event into a positive result.
- All teams have natural lifetimes. When a team coalesces, they should generally give themselves an expiration date (or tie their dissolution to a particular milestone or other event). They can always decide to change this date if necessary, but the default is for teams to expect to disband, thus freeing members to join other teams.
- All teams should mind the cadence. In some cases the duration and completion times of various teams’ efforts are independent of each other, but it’s also common for teams to need to coordinate release cycles. Does this recommendation mean that there’s a need for a ‘scrum of scrums’ type coordinating team? Perhaps, perhaps not, as such a team should also self-organize.
The Intellyx Take: Where’s the Automation?
For an article that purports to describe a DevOps virus, there was scant mention of the technology enablers of DevOps. DevOps wouldn’t be DevOps without automation-driven continuous integration and continuous delivery (CI/CD), after all, right?
In fact, without CI/CD, DevOps would never have gotten off the ground, because ops folks would still have their hands full with manual tasks. The reason people could break down the dev/QA/ops silos in the first place is because the tooling freed up everybody to drive QA and ops more as extensions of development than as separate silos.
In other words, technology played an essential role in the evolution of self-organizational principles, helping move them from theory to production-tested reality.
Now it’s time to take the next step. To achieve the full vision of digitally transformed organizations, the maturation of technology and organizational principles must proceed apace. Each one needs the other.
That’s why I call this trend the DevOps virus. This virus is contagious. And we need it to infect the entire organization.
Click here for part two: Spread the DevOps Virus in Your Organization: Guidelines for Management.
Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: jeffreyw.
Comments