How to make Goodhart’s Law („When a measure becomes a target, it ceases to be a good measure“) actionabel?

By thinking of it as Goodhart’s Challenge!

As has been worked out by Cedric Chin in a recent excellent blog post, „Goodhart’s law is not as useful as you might think“.

Yes, it’s true that whenever #itmanagement uses #metrics, people basically do one or more of the following three things:

1) They work to improve the system
2) They distort the system
3) They distort the data

But this is by no means an excuse to just not measure at all. Instead, it implies the challenge to work hard to do another three things:

1) Give people the slack necessary to improve the system
2) Make it difficult to distort the system.
3) Make it difficult to distort the data

#challenge accepted!

Why I consider Accelerate the number one book for IT leaders, today

More than six years since its publication, the book „Accelerate – Building and Scaling High Performing IT Organizations“ by Nicole Forsgren, Jez Humble and Gene Kim remains without equal.

Over all the years that I am propagating #DevOps, I had countless arguments about the value it brings – and, being myself a natural-born skeptic, often doubted my own work. But in the very end, there is always this one book that cannot just be argued away with anecdotes and gut feelings: Accelerate is the red line that cannot be crossed, the rock-solid core of all things DevOps. It is hard evidence.

Based on years of research involving thousands of organizations, the book not only clarifies that quality and delivery speed actually amplify each other – rather than being antagonists. No, it moreover is the prime example of how we should look at methods and ways of working, in general: fact-based not anecdotal. 

Rather than starting with theory and later conducting studies to validate it, the authors took a different path. They simply looked at what people in the industry were actually doing. Then they looked at who was successful. And then they took both together to reveal the practices of successful teams. 

There is so much anecdotal management lore out there when it comes to working efficiently as an IT team. Accelerate and all the related work by DevOps Research and Assessment (DORA) are exceptionally well-researched. I do not know of any other study of IT methods that even comes close in scale.

In particular, the four key metrics, Deployment Frequency, Lead Time, Mean-time-to-restore and Change Failure Rate, are standing on rock-solid foundation. Sure, you might feel that another metric somehow better describes your software delivery and operations performance – but unless you have a 10,000 participants strong survey to back it up, it’s probably hear-say.

Although Accelerate remains unique until today, I sincerely hope its approach will eventually become the standard of how new #ITMethodologies are investigated, confirmed or rejected.

#softwareengineering #DataDrivenDecisionMaking #consilica

Want your organization ready for the AI-driven future? Implement DevOps!

If you have anything to do with software, this is a must-watch! Mik Kersten, author of „Project to Product“ gives you a preview of the next industrial revolution – and how it will change the very nature of software development (20 minutes; the quote is at 4:30): https://videos.itrevolution.com/watch/827648936/

Mik chimes in with Henrik Kniberg who, earlier this year, wrote about generative AI’s impact on software development in his insightful blog article „Are Developers Needed in the Age of AI?„.

However, Mik stresses the point that in order to thrive in the new era (which is no more than 5-10 years ahead), your organization has be ready – and that means, first and foremost, that you have to have your DevOps processes properly in place! Otherwise, friction in your bottlenecks will turn the 100x productivity increase by AI into heat – with nothing but vapor to show for it.

In my view, it will be every software-developing organization’s primary challenge.

#artificialintelligence #softwareengineering #devops

Relabeling the Ops team is not DevOps! 

Another one of my favorite DevOops (sic!) moments. Merely changing the Ops team’s label to „DevOps team“ is the exact opposite of what DevOps is about.

Developers handing over their work to somebody else to handle operations violates the very foundation of DevOps: You build it, you run it!

Relabelled Ops teams are in fact DevOops teams.

What’s your favorite DevOops story?

#devops #devopsculture #devoops

Ohne End-to-end-Verantwortung staut sich der Wertstrom an Abteilungsgrenzen. Machen Sie den Weg frei und lassen Sie den Wert sprudeln.

Von außen betrachtet gibt es keine Trennung zwischen Ihrer IT-Abteilung und den Geschäftsfunktionen, dem Business. Abteilungsgrenzen sind eine Fiktion. Für Ihre Kunden schaffen sie keinen Mehrwert. Im schlimmsten Fall wird aus der Fiktion eine Friktion: Verläuft der Wertstrom durch mehrere Abteilungen, wird an den Grenzen Verantwortung abgeladen und nur teilweise wieder aufgenommen. Es fehlt die End-to-end-Verantwortung.

In sich schon eine Form von Waste, verschlimmert dieses Setup auch eines der größten IT-Probleme unserer Zeit: Die technische Schuldenkrise.   

DevOps ist die adäquate Antwort auf diese Situation. Lesen Sie mehr dazu in meinem neuen Blog-Post zu den 4 Stufen des Umgangs mit technischen Schulden.
 
#devops #bizdevops #technicaldebt

Forget the 4-day work week! With AI, you achieve a week’s worth of development in a day – if you’re ready for it.

In his excellent recent blog article „Are Developers Needed in the Age of AI?„, Henrik Kniberg takes on the question of how AI will impact software development.

The article includes a wonderful visualisation of how AI will practically eliminate the time teams spend on actual coding. As a result, one week of work collapses into a single day!

I fully agree with this argument – in theory! AI certainly can have this effect. But only if your team’s has a healthy and mature software development process in place, to begin with: They are communicating effectively and efficiently and are able to work – uninterrupted – for long periods of flow time on the right things.

The problem is: In practice, most teams are not there, yet! Their week is way more fragmented, interruptions and sudden priority changes require constant communication and re-alignment. Consequently, the impact of AI on such a process is much less impressive.

The reasons why teams work like this are complex and manifold, but they can be summed up in a single sentence: The teams have not fully adopted DevOps and the corresponding mindset. 

Start with DevOps if you want to unlock AI’s full potential for your software development teams. Let’s start today.

#devops #ai #artificialintelligence