Before we barge in by telling you what DevOps entails according to S0L1D Heroes, we take you back to the creation of DevOps and the name DevOps. Even most DevOps Engineers or DevOps coaches do not know the original story. But you will after this ;-)

There was once a Fleming who regularly got frustrated and irritated by the cooperation, read conflicts, between developers and sysadmins. This Fleming, Patrick Debois, was at a conference in Toronto in 2008 to attend a session, called “Agile Infrastructure”, initiated by Andrew Shafer. He was really surprised when he was the only person present. Apparently, nobody was interested in the subject. Even Andrew Shafer was not there at his own session. Patrick tracked down Andrew to still discuss this subject. Once he had found him and spoken with him, they decided to establish the “Agile System Administration Group”.

DevOpsDays

In 2009 Patrick was invited to attend a conference in America but unfortunately he had to cancel. The suggestion was made from America to organise a conference in Belgium himself and Patrick decided to do so. He is still struggling to come up with a name so he takes the first three letters of DEVelopers and the three letter of OPerationS and add these together and then he adds “days” to this. And there you go; the DevOpsDays conference is a fact.

After a great event, the discussion and follow-up discussions are continued on twitter. The hashtag #devopsdays is rather long so Patrick decides to shorten the name to #devops: The name DevOps is born. A few years later Patrick was asked during an interview where he got the name from. He said that this was not based on a mastermind plan. It was more an easy way of using the three letters of development and operations and adding these together. Plus, agile-system-administration-days is simply too long to use.

Mindset

Now you know where the name DevOps comes from, it is also good to know that DevOps is not a framework, or a method or a product. DevOps is a mindset, a movement, a working method. Invented and implemented by people on the shop floor. DevOps is open to innovation and improvement. A way of thinking. Cooperating and being responsible for a product or service together. It is difficult to define a standard definition for DevOps. If you ask ten different people what DevOps entails, you will get 10 different answers. And there is a big chance that all these 10 people got it right, or at least a large part of it. DevOps is thus definitely not “one size fits all”.

From cradle to the grave

But what does DevOps entail? It is sometimes said that DevOps continues where Agile stops. Agile was mainly created to add value to the customer through building and delivering iterative and incremental software to the customer. To get feedback from the customer as quickly as possible in order to test whether the team is working on the right things. However, managing software is not included in this thought. But this is the case with DevOps. A team, jointly responsible for a product or service, from start to finish. “From cradle to the grave” as we also say in DevOps country. Another nice quote for this is: “you build it, you run it” In other words: everything you build, you must also manage.

Feedback

DevOps team members are still looking for feedback, not just feedback from the customer but also feedback from the systems surrounding the product and the product itself. A DevOps team is therefore much more feedback-driven instead of value-driven which is the case with an Agile team. Because by making the feedback process as short as possible, preferably real-time, you can respond extremely quickly. And by also automating the processes, you also create a fast feedback process there.

By setting up an automated delivery pipeline with all kind of quality gates, and by setting up a good monitoring system on the health of the product and the environment on which the product runs, a DevOps team is able to spot trends and therefore prevent incidents that have not occurred yet. This way a DevOps team can provide even more value to the customer. Actually the DevOps teams are horny-for-feedback.

Now you know that DevOps is not a product, method or framework, but a way of working and thinking, you can also conclude that the certification in DevOps is complete nonsense. Obtaining a certificate in ITIL is logical because this is a framework. The same applies for a RedHat certificate because this is again a product. This does not apply for DevOps. All certificates that are offered in terms of DevOps are in my view a commercial exploitation. Catching a ride on the success of DevOps.

High Performing

However, I believe that following a DevOps awareness session or workshop does add value. Because this helps with increasing awareness (as the name indicates) but also because the team members who attend such a session or workshop, will get mutual understanding for the opinions of others. This again is useful for team building, which eventually results in a High Performing team.

But what does that mean, a High Performing Team? A High Performing team is not something different. An Agile team, a DevOps team, a service desk, these can all be High Performing teams.

The point is that teams are there for each other. Trust each other through and through, got each other’s backs, give feedback in a constructive way and can also receive feedback. These are teams that perform at a high level. As a team they are able to get the job done.

How can you create such a high performing team? I will explain this in my next blog. Because that is a totally different matter.