Wissen, News und Meinungen. Kurz und knapp.
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“.
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
T-shaping != Everybody is expert in everything!
A common objection against #tshaping that we commonly hear is that it is not feasible for everybody on a team to become expert in everything.
What T-shaping calls for is actually much more modest: Everybody on the team should have a shallow understanding of everything the team does.
When #teams actually start to strengthen their developers‘ T-shape, it is often surprising how quickly everybody can pick up enough working knowledge to handle common tasks that are actually not their expertise.
Just get started!
Why I consider Accelerate the number one book for IT leaders, today
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.
If you are not testing, you are not a developer!
I am always surprised when in 2023 I still encounter developers who – without blushing – say that they do not write tests. What a DevOops (sic!) moment!
Whenever that happens, I am outright awed by the inertia of attitude change. The „no test developer“ should have died out sometime around the millennium. We, as an industry, know better for more than twenty years.
💡 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗜𝗦 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗶𝗻𝗴.
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.
𝗪𝗵𝗲𝗻 𝘁𝗵𝗲 𝗲𝗰𝗼𝗻𝗼𝗺𝘆 𝗴𝗼𝗲𝘀 𝗱𝗼𝘄𝗻, 𝘆𝗼𝘂𝗿 𝘁𝗲𝗰𝗵 𝗱𝗲𝗯𝘁 𝘀𝗵𝗼𝘂𝗹𝗱, 𝘁𝗼𝗼❗
In a growing economy, some inefficiency in your software development life cycle can be temporarily tolerated. There are just too many business opportunities to chase, and time is always critical. In such times, technical debt and legacy systems pile up – but it still pays off! 💸
Unfortunately, these days are over. We are now in a downward facing economy and it’s time to get used to it.
Too many teams are drowning in technical debt and overwhelmed by a portfolio of legacy systems that, frankly, nobody knows how they are still even working.
There is no more room for such inefficiencies❗
But there is no need for pessimism! Because there has never been a better time to deal with technical debt and legacy software. With the help of AI-powered code assistants, refactoring can nowadays be done with so-far unparalleled efficiency. This is a game changer in the refactoring and code modernization business.
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?
Fragen Sie sich, ob Sie DevSecOps, FinOps, MLOps oder doch besser BizDevOps brauchen? Die Antwort lautet immer gleich: Sie brauchen DevOps.
DevOps heißt von Ende zu Ende denken und arbeiten. Ganzheitlich.
Mit dem DevOps-Mindset hält man den gesamten Wertstrom im Blick. Development, Security, Finanzen, Machine Learning, Business und Operations müssen dann ganz automatisch mitgedacht werden. Denn nur so ist es wirklich Ende-zu-Ende.
Sprechen Sie mit uns darüber, wie Sie Ihre Organisation in eine DevOps-Organisation überführen können!
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.
One of my favorite DevOops (sic!) moments. Staging is not Production. Systems running in Staging are inventory – they do not generate customer value.
Considering work „done“ after deployment to Staging is the new „It runs on my computer“.
What’s your favorite DevOops story?
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.
Lass uns starten!
Hebe deine IT aufs nächste Level - mit uns an deiner Seite. Lass uns gemeinsam loslegen. Vereinbare jetzt ein unverbindliches Gespräch mit mir.
Dr. Michael Köpf
IT-Organisationsberater und Transformationsmanager