5. Unrealistische Erwartungen
Führungskräfte im Technologiebereich sollten sich auf ein Engagement konzentrieren, das über die bloße Einführung neuer technologischer Tools und Verfahren hinausgeht. "Sie müssen der Veränderung der Unternehmenskultur und der Denkweise der Mitarbeiter Vorrang einräumen", appelliert Tim Potter, Principal bei Deloitte Consulting, und ergänzt: "Sie müssen außerdem auch realistische Fristen setzen, damit die Transformation im Unternehmen Fuß fassen kann. Ein Unternehmen, das einfach nur mehr automatisierte Tools einsetzt und bestehende Anwendungsteams, die sich von Anfang bis Ende um Produktionsprobleme kümmern, 'DevOps-Teams' nennt - wird von den erzielten Ergebnissen sehr wahrscheinlich enttäuscht sein."
Zudem sollten sich IT- und Tech-Entscheider laut dem Deloitte-Mann darauf einstellen, dass sich die Performance nach der Umstellung auf DevOps zunächst verschlechtert, bevor sie sich verbessert: "Sie müssen darauf vorbereitet sein, ihre Anwendungsteams zu unterstützen, damit sie testen und lernen und sich mit dem neuen Modell vertraut machen können. Unangemessene Erwartungen und ein unzureichender Zeitrahmen für die Umstellung können zu Fake-DevOps-Initiativen führen."
6. Teams, die in der Vergangenheit leben
Alte Gewohnheiten lassen sich bekanntlich nur schwer ablegen. Jahrzehntelang folgte die Softwareentwicklung der traditionellen Wasserfallmethodik, einem Prozess, bei dem es darum ging, Anforderungen im Voraus zu sammeln, Funktionen zu entwickeln und die Ergebnisse schließlich zur Freigabe an die Qualitätssicherung und andere Teams zu übergeben. Das hatte Folgen, wie auch Ashish Kakran, Principal bei der IT-Risikokapitalgesellschaft Thomvest Ventures, weiß: "Früher hat es Monate gedauert, bis die Kunden neue Funktionen zu sehen bekamen."
Wenn es den Entwicklungsteams nicht gelinge, sich vollständig vom Wasserfallmodell zu lösen, könne es zu seltsamen Kombinationen von Prozessen kommen, warnt Kakran und schlägt vor, die DevOps "Epics" und "Stories" eines Teams zu analysieren, um sich ein Bild von dessen Status zu machen: "Der gesamte Kontext eines laufenden Projekts wird oft in diesen Aufgaben erfasst. Wenn bereits ein einmonatiges Projekt in Aufgaben mit wenig oder gar keinem kontinuierlichen Kunden-Feedback aufgeteilt ist, ist das ein Zeichen dafür, dass das Team sich selbst zum Scheitern verurteilt - sei es durch das versäumte Deadlines oder die Bereitstellung von User Experiences, die den Namen nicht verdienen."
7. Flexibilitätsmängel
DevOps ist keine One-Size-fits-All-Methodologie. Um maximale Effektivität zu erzielen, sollten DevOps-Workflows und -Tools auf die spezifischen Anforderungen des Unternehmens abgestimmt werden. Diese können je nach Größe, Anwendungstyp und Entwicklungskompetenz sehr unterschiedlich ausfallen.
Dabei sollte DevOps niemals statisch sein: Die Prozesse und Tools müssen angepasst werden, wenn das Unternehmen wächst und sein Streben nach kontinuierlicher Verbesserung verfolgt. Das erfordert nach Meinung von Wing To, Vice President of Engineering bei Digital.ai, flexible Tools und die Fähigkeit, KPIs zu analysieren. Er ergänzt: "IT-Führungskräfte sollten auch den Kulturwandel berücksichtigen, der erforderlich ist, um Entwicklungs- und Betriebsteams zusammenzubringen. Anstatt eine separate DevOps-Abteilung einzurichten, die ein weiteres Silo und noch mehr Prozessengpässe schafft, sollte die Methodik in jeden Geschäftsbereich integriert werden." (fm)
DevOps is trending... Let's recap what's a DevOps for the sake of it... #jk #devops meme pic.twitter.com/mSpoz3jT06
— Marko Ntech (@markontechcom) November 2, 2021
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CIO.com.