Should “DevOps” be a job title? Are DevOps teams an anti-pattern? Can you do DevOps within a single team? Were the moon landings staged in the Arizona desert? These are the sort of questions you’re never more than 5 feet away from at any DevOps conference or meetup. The answers, of course, are:
- Yes and no
- Don’t be silly
Everyone seems to have an opinion on the whole “DevOps Team/Job Title” question, and I’m no different, except my opinion is this:
I passionately don’t care
Let me explain:
If you have a devops team, and their job is to encourage and develop a devops culture within the organisation, then that’s perfectly fine, surely? If that team is successful and a devops culture blossoms, then you’re definitely winning. Maybe that team could subsequently change its name, but that just seems a bit pointless and overly hung-up on semantics. In this case, I don’t care what the team is called, because it doesn’t matter.
If you have a devops team, and they don’t encourage or foster a devops culture within the organisation, then you’re doing devops wrong, as simple as that. If you’re doing devops wrong then it doesn’t matter what you call a team, you’re still doing it wrong. In this case, I don’t care what the team is called, because it doesn’t matter.
I do understand the opinions of the anti-pattern crowd. Setting up a separate silo responsible for “doing devops” is completely wrong. It discourages other teams and individuals from adopting a devops attitude, as they’ll see it as someone else’s responsibility. But the problem isn’t with the existence of the team, the problem is the purpose of the team and the fact that whoever decided the team should “do DevOps” clearly doesn’t understand what DevOps is.
At the very core of the issue is an understanding of what DevOps actually is. If your CTO, (or Head of Technology or whoever calls the shots within the technology division) thinks that DevOps just means automating builds and deployments, treating Infrastructure as Code, or adopting Continuous Delivery, etc then you’ve already got a problem. DevOps is about these things (and more), sure, but it’s about everyone understanding the importance of them, and absorbing them into their culture.
I’ve previously posted about the dangers of having an obsession with Ownership and Responsibility and I think these factors can also contribute to a failed adoption of devops. Drawing up clear lines of ownership and responsibility is risky – if you get it wrong, you’re going to struggle. For instance, if you draw a clear line of ownership around “devops” and place it firmly in the domain of the devops team, then you’re not going to do devops. A single team cannot own and be responsible for a culture, it just doesn’t work like that. The lines of ownership need to be blurred or wiped out entirely. Nobody and everybody should be “responsible for” and “own” the devops culture.
Conclusions On The DevOps Team
Anyone who thinks that you can get something ingrained into an organisation’s culture by setting up an isolated group of people who are solely responsible for doing those things, is flying in the face of conventional wisdom. Even my experience suggests that this doesn’t work (and I always fly in the face of conventional wisdom, coz I’m stooopid). By all means create a DevOps Team, but don’t make them responsible for “doing devops”, that’s just wrong. Instead, give them the challenge of spreading the DevOps gospel, evangelising DevOps within the organisation and training everyone on the benefits of devops, as well as some of the tricks of the trade.
On The DevOps Job Title
Everyone’s a devops engineer these days. I’m a devops engineer, my wife’s a devops engineer, even my dog’s a devops engineer. It’s a booming industry and everyone wants a piece of it. I’m afraid we don’t have any control over this anymore, we’ve created a beast and it’s consuming everything!! Luckily it’s not the end of the world. Sure, sysadmins the world over are now rebranding themselves as devops engineers, but does it make any difference at the end of the day? If you’re hiring, you don’t just hire someone on the strength of their previous job title do you? No, you actually read their CV and interview the candidate. Good candidates will always shine through. Working out if someone’s a sysadmin or a build engineer is just a bit more hassle for recruitment agents, that’s all!
In a way I’m thankful for the devops job title. I honestly think it has helped to make the whole devops thing more popular and opened it up to a wider audience.
Should there really be such a thing as a “DevOps Engineer”? Probably not, but we’re far too late to stop it, and trying to stop it seems a bit of a waste of energy to me. Eventually “DevOps Engineer” will come to mean something more specific, but for now we’re just going to have to read a few more lines on CVs.
A couple of weeks ago I was at an Experience Devops event in London and I was talking about how software delivery, which is quite often compared to a manufacturing process, is actually more comparable to a professional sports team. I didn’t really get time to expand on this topic, so I thought I’d write something up about it here. It all started when I ran a cheap-and-nasty version of Deming’s Red Bead Experiment, using some coloured balls and an improvised scoop…
The Red Bead Experiment
I was first introduced to Deming’s Red Bead Experiment by a guy called Ben Mitchell (you can find his blog here). It’s good fun and helps to highlight how workers are basically constrained by the systems the work in. I’ll try to explain how the experiment works:
- You have a box full of coloured beads
- Some of the beads are red
- You have a paddle with special indentations, which the beads collect in (or you could just use a scoop, like I did).
- You devise a system whereby your “players” must try to collect exactly, let’s say, 10 red beads in each scoop.
- You record the results
Now, given the number of red beads available, it’s unlikely the players will be able to collect exactly 10 beads in each scoop. In my especially tailored system I told the players to keep their eyes closed while they scooped up the balls. I also had about half as many red beads as any other colour (I was actually using balls rather than beads but that doesn’t matter!). The results from the first round showed that the players were unable to hit their targets. So here’s what I did:
- Explain the rules again, very clearly. Write them down if necessary. Being as patronising as possible at this point!
- Encourage the players individually
- Encourage them as a team
- Offer incentives if they can get the right number of red beads (free lunch, etc)
- Record the results
Again, the results will be pretty much the same. So…
- Threaten the individuals with sanctions if they perform badly
- Pick out the “weakest performing” individual
- Ask them to leave the game
- Tell the others that the same will happen to them if they don’t start hitting the numbers.
In the end, we’ll hopefully realise that incentivising and threatening the players has absolutely zero impact on the results, and that the numbers we’re getting are entirely a result of the flawed system I had devised. Quite often, it’s the relationship between workers and management that gets the attention in this experiment (the encouragement, the threats, the singling out of individuals), but I prefer to focus on the effect of the constraining system. Basically, how the results are all down to the system, not the individual.
I think one of the reasons why the software industry is quite obsessed with traditional manufacturing systems is because of the Toyota effect. I’m a huge fan of the Toyota Production System (TPS), Just-in-time production (JIT) Lean manufacturing and Kanban – they’re all great ideas and their success in the manufacturing world is well documented. Another thing they all have in common is that various versions of these principles have been adopted into the software development world. I also happen to think that their application in the software development world has been a really good thing. However, the side-effect of all this cross-over has been that people have subconsciously started to equate software delivery processes with manufacturing processes. Just look at some of the terminology we use everyday:
- Software engineering
- Software factories
- Quality Control (a term taken directly from assembly lines)
It’s easy to see how, with all these manufacturing terms around us, the lines can become blurred in people’s minds. Now, the problem I have with this is that software delivery is NOT the same as manufacturing, and applying a manufacturing mindset can be counter-productive when it comes to the ideal culture for software development. The crucial difference is the people and their skillsets. Professionals involved in software delivery are what’s termed as “knowledge workers”. This means that their knowledge is their key resource, it’s what sets them apart from the rest. You could say it’s their key skill. Manufacturing processes are designed around people with a very different skillset, often ones that involve doing largely repetitive tasks, or following a particular routine. These systems tend not to encourage innovation or “thinking outside of the box” – this sort of thing is usually assigned to management, or other people who tend not to be on the production line itself. Software delivery professionals, whether it be a UX person, a developer, QA, infrastructure engineer or whatever, are all directly involved in the so-called “production line”, but crucially, they are also expected to think outside of the box and innovate as part of their jobs. This is where the disconnect lies, in my opinion. The manufacturing/production line model does NOT work for people who are employed to think differently and to innovate.
If Not Manufacturing Then…
Ok, so if software delivery isn’t like manufacturing, then what is it like? There must be some analogous model we can endlessly compare against and draw parallels with, right? Well, maybe…
I’m from a very rural area of west Wales and when anyone local asks me what I do, I can’t start diving into the complexities of Agile or devops, because frankly it’s so very foreign to your average dairy farmer in Ceredigion. Instead, I try to compare it with something I know they’ll be familiar with, and if there’s one thing that all people in west Wales are familiar with, it’s sheep rugby.
It’s not as daft as it sounds, and I’ve started to believe there’s actually a very strong connection between professional team sports and Agile software development. Here’s why:
Software delivery is a team effort but also contains subject matter experts who need to be given the freedom to put their skills and knowledge to good use – they need to be able to improvise and innovate. Exactly the same can be said of a professional rugby or soccer (yes, I’m going to call it soccer) teams. Rugby and soccer are both team sports but both contain very specific roles within that team, and for the teams to be successful, they need to give their players the freedom and space to use their skills (or “showing off” as some people like to call it).
Now, within a rugby team you might have some exceptionally talented players – perhaps a winger like former World player of the year Shane Williams. But if you operate a system which restricts the amount of involvement he gets in a game, he’ll be rendered useless, and the team may very well fail. Even with my dislike of soccer, I still think I know enough about how restrictive formations and systems can be. The long ball game, for instance, might not benefit a Lionel Messi style player who thrives on a possession & passing game.
The same can be said of software delivery. If we try to impose a system that restricts our individual’s creativity and innovation, then we’re really not going to get the best out of those individuals or the team.
So Where Does Agile Fit Into All of This?
Agile is definitely the antidote to traditional software development models like Waterfall, but it’s not immune from the same side-effects as we witness when we do the red bead experiment. It seems to be that the more prescriptive a system is, the greater the risk is of that system being restrictive. Agile itself isn’t prescriptive, but Kanban, XP, Scrum etc, to varying degrees are (Scrum more prescriptive than Kanban for instance). The problem arises when teams adopt a system without understanding why the rules of that system are in place.
prescriptive = restrictive
For starters, if we don’t understand why some of the rules of Scrum (for instance) exist, then we have no business trying to impose them on the team. We must examine each rule on merit, understand why it exists, and adapt it as necessary to enable our team and individuals to thrive. This is why a top-down approach to adopting agile is quite often doomed to fail.
So What Should We Do?
My advice is to make sure everyone understands the “why” behind all of the rules that exist within your chosen system. Experiment with adapting those rules slightly, and see what impact that change has on your team and on your results. Hmmm, that sounds familiar…
Recently I’ve been butting heads with some people on the subject of Ownership, Responsibility and Accountability. There seems to be a very unhealthy obsession with these things sometimes, and I think this is indicative of a less-than-ideal culture. I don’t want to say that they’re “anti-agile” because that just sounds a bit weak, and because I also think they’re not just bad for agile, they’re bad for pretty much any system. I’m not sure how familiar most people are with the “RACI matrix” concept, but in my eyes it’s downright evil in the wrong hands, and I’ve been hearing “RACI Matrix” a lot recently (it’s now on my Bullshit Bingo card).
I’ll start off by clarifying what I mean. I’ve got nothing against people owning actions or being accountable for certain particular (usually small) things, but I do take offence when pretty much everything has to be given an owner, someone accountable and someone to “take responsibility”. It’s divisive and results in lots of finger pointing, in my experience.
I much prefer the concept of shared ownership, and collective accountability. As a software delivery team, we should all feel responsible for the quality of the product, as well as the performance and the feature richness. These things shouldn’t be assigned for ownership to individuals, as it’ll create an attitude of “well it’s not my problem” among the other team members.
Here’s an example: I’ve worked in a team where one person was made the “owner” of the build system. They busied themselves making sure all the builds passed and that the system was regularly ticking over. Of course, the builds often failed and nobody cared except this one person, who then had to try to get people to fix their broken builds. It almost seemed as if people didn’t care about the fact that their software wasn’t capable of being compiled, or that the tests were failing, and in truth they didn’t. They cared about writing code and checking it in, because they didn’t “own” the build system.
One message that I always try to drive home with software delivery teams is that our objective is to make software that works for our users, not just write code. I know how easy it is for developers to just focus on checking in code, or perhaps just make sure it passes the tests in the CI system, but beyond that, their focus drops off. I know because I was once one of those developers :-) These days I try to encourage everyone to care about things such as:
- How your code builds
- How the tests execute
- How good the tests are
- How good the code is
- How easy it is to deploy
- How easy it is to maintain
- How easy it is to monitor
Because it takes all of these things to produce good software that users can enjoy, which means we get paid.
Here’s another example of how “ownership” has hurt a product: A large system I once worked on was deployed into production using a complicated system of bash and perl scripts, which were cobbled together by a sysadmin who did the deployments. He became the de facto “owner” of the deployment system. There were untold issues with the running of the application because of permissions, paths etc and so forth. The deployment process was creaky and relatively untested. Since the “ownership” of this system was assigned to the sysadmin, rather than devolved or collectively shared throughout the delivery team, the “deployability” was seen as a second class citizen within the delivery team, because everybody felt like it was “owned” by one person who just happened to be on the periphery of the team at best.
So here’s what I think: The ability to monitor, maintain, deploy, test, build and create software should all be treated as first class citizens and should be the collective responsibility of everyone in the team. They should all own it, and they should all be accountable.
I would extend this out further, to include supporting systems such as environments, build systems, testing frameworks and so-on. Sure, each team might have an SME or two who focuses more on one of these things than any other, but that doesn’t make that one person accountable, responsible or the owner any more than any particular developer is the “owner” of any particular class, method or function. If I write some code that depends on a method that someone else has written, and that method is failing, I don’t just down tools, shrug my shoulders and say “well I’m not accountable for that”. That would be hugely unhelpful and I’d make no friends either. In the same way, we shouldn’t treat our supporting functions and systems as someone else’s responsibility. If we need it in order to make our software work for the end user, then it’s our collective responsibility, no matter what “it” is.