Calling DevOps teams an anti-pattern IS an anti-pattern because needing no DevOps a team is the destination but not necessarily the journey.
In Star Wars terms, achieving the Continuous Delivery Capability without a supporting DevOps team is Jedi. Making tangible improvements with the support of a dedicated team could be the rebel alliance, but is definitely not the dark side!
Enterprises should feel an urgency to try the Continuous Delivery practice and must feel empowered to experiment on how to best to adopt it in their own organisation. All organisations whilst united by the need to adopt the Continuous Delivery practice, have a variety of different cultures, skills, history, priorities, accountability, politics etc. Therefore it is logical to expect a variety of approaches to be effective towards achieving Continuous Delivery.
I don’t disagree with the some of the arguments against teams, but I just feel that DevOps teams should be understood as having traps to avoid, rather than being a trap to avoid. In the wrong hands anything powerful usually has the ability to do at least as much bad as good. Heed the cautions and make sure your’s aren’t the wrong hands!
What DevOps strives to achieve
To summarise, DevOps aspires to achieve highly responsive and reliable IT functions that are globally optimised to support and deliver the Business objectives. In other words: “Deliver what IT is needed, when it’s needed and consistently until the need disappears or changes.” In more other words: “Restore faith in IT by going the difficult last mile beyond agile development to achieving agile releasing of software.”
What DevOps typically entails in practice
The prominent pattern for doing DevOps is to adopt the Continuous Delivery practice. DevOps and Continuous Delivery are heavily underpinned by effective solutions for the following core processes:
- Version Control
- Configuration and Release Management
- Environment Management (development, test, and production)
- Automation and orchestration throughout the software delivery life cycle of at least:
- code release
- quality assurance
Take all of the cross-team collaboration / peace and love you like, if the above let you down, you’ll not achieve continuous delivery and worse you’ll have problems.
What traditional Development teams typically achieve
We’ve all heard the statement: “Developers want Change and operators want Stability.” Surely based on this, at least the developers are ready to embrace the changes required to implement Continuous Delivery?
Unfortunately it’s not this type of change! It is very common for developers to feel pressured to focus almost exclusively on delivering functionality, even at the expense of neglecting all non-functional “ilities” . I’ve seen agile actually exacerbate this. When Product Owners (usually aka functionality champions) are permanently based in the development team, the focus on working features, features, features can go too far.
Unfortunately regular demos, valuable as they are, can sometimes also negatively reinforce this functionality addiction. Watching Chef re-build an environment from version control appeals to a fairly select group of people (of which I am included). But we are significantly outnumbered by people who prefer to watch the shadows move on fancy new sliders in a UI (or other functional things -not my bag). The typical demo audience can put development teams off tasks which don’t demo well, for example automating server creation.
I’m not criticising agile or arguing that the above problems aren’t solvable. These are just example causes of functionality changes dominating at the expense of developing the requisites for Continuous Delivery. In fact tasks related to Continuous Delivery are often left on the backlog directly below a block of non-functional requirements (if anyone even took the time to determine the relative priorities that far down the list).
What traditional Operations teams typically achieve
A common occurrence is that Operations teams dislike change. It is absolutely standard for Operations to feel accountable for maximising two things:
Stability is threatened by all change. Not just changes to the code and configuration of supported systems (as requested by Development), changes to people, processes and tools.
One compounding unpleasant phenomena I’ve seen once or twice is a tendency to scape-goat old bad processes that were invented by much blamed predecessors in favour of taking risks on improving, thus avoiding ownership and accountability. This may lead to prevailing problems like heavily manual deployment processes or worse processes being badged unfit-for-purpose and completely ignored (as we saw with the Change Process in the Phoenix project novel!).
Efficiency is often achieved by cutting back on anything outside core areas of accountability. Continuous Delivery is becoming easier to justify, but making the strategic benefits of automated deployments sound more appealing that the tactical benefits of saving money by hiring fewer people will never get easy.
Efficiency-over-emphasis for Operations parallels the functionality-over-emphasis for Development and the result is to grease the tarmac on which Continuous Delivery needs traction.
Why would you want a DevOps team?
The examples above highlight why neither Development or Operations are never going to have an easy ride implementing Continuous Delivery. We can also understand from these why both Development and Operations teams so often get to consider themselves locally successful without feeling the need to address the end-to-end cross-team effectiveness and the promise of DevOps.
A major contributing factor for a general lack of progress towards Continuous Delivery is the lack of clarity over ownership. The core concerns listed above don’t usually fit naturally into either team and as a result get left festering (and failing) in the gap between. I’ve read enough about DevOps to know that to be taken seriously, you generally need a Deming quote. I found this appropriate:
“Hold everybody accountable? Ridiculous!”, W. Edwards Deming
Finding a person accountable for each of the awkward core processes is necessary. Assuming that this person needs dedicated (or shared) resources to succeed, you may have just got yourself a team which could be called DevOps.
What would a DevOps team do?
If we’re ready to make someone accountable for addressing the problems, the two main things that their team could do are:
- Provide an appropriate set of services to Development and Operations (on-going). See here for a full discussion.
- Run a change programme to expedite adoption of Continuous Delivery (temporary). See here for a full discussion.
A quick critique of “how to do DevOps without a team” advice that I’ve read
Give developers more visibility of production.
Great idea, but this isn’t going to build an automated tool chain.
Encourage developers and operations staff to have lunch together
Not bad, will probably locally improve the productivity of the developers who now know buddies in Operations ready to cut them special treatment. This type of thing is going to take a long time to make a difference in a big enterprise.
Standardise the metrics that influence performance based-pay across development and Operations.
Like this one. But extremely difficult in a major organisation and certainly not without adverse risks of unexpected side-affects.
More than happy to discuss all other ideas anyone cares to suggest!
If you accept that the above activities are not an anti-pattern, perhaps the only remaining argument is what to call the responsible team. If you don’t accept them, as one last go, please drill down to the detailed discussions on service and programme teams.
Personally I think that so long as the people involved understand what DevOps actually is, the name DevOps gives them a daily reminder not to lose sight of their real objective. Being in a release management team that slows down delivery may carry no stigma. There is nothing more embarrassing that being in a DevOps team gets associated with impeding DevOps!