General information about DevOps
DevOps is not an end in itself, but it should solve a problem: Minimizing friction losses between development and operation when software releases go live. And while we’re at it, we would also like to push product increments into production in an agile way and in rapid succession – at least where it makes sense. The means of choice is automation, in addition to the general CALMS principles, which also include soft factors such as „culture“ and „sharing“.
To perform DevOps efficiently, you should get used to deploying small product increments. In the context of automated integration and deployment, these are easier to handle than giant releases.
In my book „DevOps-Strategies“ I have summarized my experience in introducing DevOps to an organization. In an upcoming edition of the book I will have to sharpen the focus and emphasize that DevOps without real agility involves a high risk of failure and is ultimately uneconomical.
One could exaggerate it in such a way that only „agile“ organizations can introduce and operate DevOps sensibly.
This starts with the fact that the construction of CD and CI pipelines should take place in parallel and iteratively to the creation of the functional software. The CALMS principles are best reconciled with the agile manifesto.
DevOps in SAFe® Context
Now, the Scaled Agile Framework (SAFe®) turns the tables: SAFe® postulates the use of DevOps already with the introduction of the lowest common denominator of SAFe® in an organization, the „Essential SAFe®“. In addition to the team level at which conventional SCRUM teams are active, this core of SAFe® comprises a superordinate program level at which the activities of several SCRUM teams are coordinated in so-called agile „Release trains. These include „Super Sprints“, which consist of several conventional agile „SCRUM Sprints“.
SAFe® now not only requires that a program increment is generated at the end of a super sprint, but that the progress of a super sprint must be permanently validated. This is to be done on the basis of automated tests and deployments. The SAFe® documents therefore also refer to DevOps. As understandable as this is, many companies will face a high hurdle in the introduction of SAFe®.
The ubiquitous claim to introduce and apply DevOps without getting involved in agile, and thus ultimately non-existent planning, is symptomatic. Agility consists of more than sprints and daily scrums.
Recently all conceivable roles have been adorned with the term dev-ops, e.g. „DevOps administrator“, „DevOps developer“. Obviously, senior management requires the introduction of DevOps to „finally“ get the problem solved with the transition into production.
Consequently, the obedient middle management sticks the label „DevOps“ on everything and everyone to document that it takes the demand for DevOps of senior management seriously – and in general – everyone wants to be a part of the solution, and that is called „DevOps“. Because otherwise you’d be part of the problem, wouldn’t you?
The result: By sticking the label DevOps with and without conviction on everything that is not out of the way in three seconds, all participants believe themselves at some point that they actually „do DevOps“, and forget about it the agile foundation and the actual claim that one should have to DevOps.
Because of this development, in the best-case DevOps is going to stand for well-groomed scripting in automation of deployment processes. In the worst case, DevOps is discredited – as an empty phrase with exaggerated expectations.
- Superior: By when will we have deployment on click up-and-running on all environments?
- Employee: Once we have introduced DevOps and completed our continuous delivery pipeline.
- Superior: But we have built DevOps (See board memo of…)
- Employee: Where?
- Superior: Well you – we hired you as a „DevOps-Engineer“ two months ago, is already being rolled out automatically?