- 20 February 2021
- Posted by: Erkan Sarıkaya
- Category: AGILE
This week we’re sharing one of the DevOps studies published by «Puppet» and «CircleC»:
State of DevOps Report 2020
They have been publishing a report on the state of DevOps for 9 years.
Before we get to the report:
For organizations that manage the software development life cycle, one of the most important indicators on the agile transformation journey is “DevOps maturity”
Metrics are only a small part of it; culture is everything!
By looking at the strategic management approaches and goals companies pursue in areas they consider important, such as DevOps, Security and audit-finding/compliance management, you can understand how they perform when it comes to “Change Management”.
Here are the 2 most dangerous approaches:
1. Teams being managed and controlled from the outside
When any important process area (e.g. Security, compliance, DevOps, etc.) that isn’t managed within the teams, hasn’t been internalized, and doesn’t (or can’t) involve the employees is subjected to attempts at outside control, the expected performance unfortunately weakens over the long term; after a while it grows more complex and unmanageable, and grey or even dark areas can emerge. The process becomes impossible to understand, and lead time gets longer…
2. Having many “Control/Approval mechanisms”
Let me ask you about a metric: How long does it take for a developer who has just joined your team to take a “Hello World!” piece of code all the way to deployment/production?
How many control/approval points, statuses or environments do you pass through along the way? (DoD checklist, design, dev, to-test, to-stable, uat, ready-to-deploy, ready-to-release, and every other stop you can think of)
Write down your answer to this question somewhere. That’s the starting point…
So, what would you like to do with it now? Do you feel the need to set a target for it? If it sounded silly, my apologies for wearing you out a bit. Tear up the note, throw it away, forget about it. 😉
Establishing a DevOps culture also requires change management with similar agile approaches. I won’t get into the debates about whether DevOps sits above, below or beside Agile, because the two are like yin and yang.
- A central DevOps team cannot be expected to serve the entire IT organization, audit DevOps compliance and impose standards.
- Likewise, a central Security team cannot be expected to question teams in order to address the whole company’s vulnerabilities and security findings.
- A central “Release Management” team cannot be expected to track down and fix every integration, or once again be the one “responsible” in a “controller” role.
Even if it were expected, it wouldn’t be efficient.
So, the bottom line:
Teams must be provided with a “self-managed” working environment that can offer “self-service” to teams and allow the people on those teams to meet “their own needs“.
I’m talking about “developer-friendly” “internal” platforms and tools where people can make changes at “admin“ level.
Yes, and this requires working side by side with the teams, listening to their needs and serving them. This is a very important leadership approach.
Unfortunately, culture doesn’t take root when we worry, “They’ll break it”, “Not without my approval”, “There’d be no standard”, “Everyone will do as they please”. Employees need to be involved in decision-making. When we say Agile Mindset, these are exactly the approaches we are talking about. The rest comes down to good practices and frameworks …
Anyway, let’s finally get to the report that supports these conclusions:
Around 2,400 people working in IT, development, security and similar fields took part in the survey. Look at what the results highlight — a few notes:
To access the original report, you can click here.
If you’re curious, there’s more in the report:
Erkan Sarıkaya
Enterprise Agile Coach
Related Posts
Author: Erkan Sarıkaya — Enterprise Agile Coach, founder of GONEX. He writes on enterprise agile transformation, Scrum and agile leadership coaching. You can learn more on the About Us page and read his other posts.