Ich starre ihn entgeistert an. Was hat er da gerade gesagt?
„Aber wir haben doch bereits alles automatisiert!“ hallt es in meinen Ohren nach.
Ich denke zurück an die vielen manuellen Schritte, die mein Team mir eine Woche vorher in Form eines Runbooks präsentiert hat. Ein Entwickler muss sich mehrere Stunden neben einen Kubernetes Cluster setzen, um ihn bei der Installation zu beobachten. Zu bestimmten Zeitpunkten muss er das nächste Skript starten und schauen, dass es ordentlich durchläuft.
Sind wir damit schon am Ende der Fahnenstange angekommen? Das ist der viel beschworene Automatisierungsgrad? Das ist unser Pendant zu der Getränkefabrik, in der kein Mensch mehr arbeiten muss, weil alles vollautomatisiert läuft?
In diesem Artikel geht es nicht um die Automatisierung
Auch wenn es ein hochinteressantes Thema für Product Owner ist (oder sein sollte): In diesem Blogbeitrag möchte ich nicht über meine Erfahrung mit dem Thema Automatisierung sprechen.
In diesem Artikel gehen wir der Frage nach: Und wie bringe ich als Product Owner mein Team dazu, außerhalb ihrer Erfahrungswelt zu agieren?
Es gibt viele klassische Beispiele in der IT:
- Der Admin, der sein Leben lang manuelle Tätigkeiten ausgeführt hat und nun zum ersten Mal die Magie der vollautomatisierten Betriebsprozesse sieht.
- Der Entwickler, der sich nie mit Software Craftsmanship beschäftigt hat und staunend vor einem „Clean Code“-Code sitzt und sich fragt, wie man das wohl machen könnte?
- Der Scrum Master, der sein Leben lang als Scrum Mutti sein Team betreut und hofiert hat und dann einen HTFYDT-Scrum Master bei der Arbeit erlebt.
- Oder der Teamleader, der sein Team immer geschützt und empowert hat, um dann festzustellen, dass seinem Team die Vorstellungskraft für das fehlt, was alles möglich ist.
- Und natürlich der Product Owner, der vergeblich massenhaft Methoden zur Backlog-Strukturierung ausprobiert hat und zum ersten mal ein sauber priorisiertes Backlog vor sich hat.
Genau hier treffen wir auf das eigentliche Problem: Was tue ich, wenn die Entwicklung meines Teams an der fehlenden Erfahrung und Vorstellungskraft der Teammitglieder scheitert?
Die Krux mit der fehlenden Erfahrung
„Ein Neandertaler wünscht sich keinen Porsche.“
Auch wenn es sich in dem Moment mies anfühlte – dieser Vergleich drängte sich mir in der oben geschilderten Situation auf. Und das war nicht respektlos gemeint.
Wenn in meiner Gedankenwelt etwas nicht existiert, weil ich es nicht weiß, dann habe ich auch kein Bedürfnis danach. Wie ein Neandertaler, in dessen Erfahrungswelt es keinen Porsche gibt.
Und selbst wenn ein Porsche existieren würde: Wenn ich ihn sehe und dann denke: „Das ist ja total aufwändig, das lohnt sich nicht.“ Dann werde ich es auch nichts dafür machen.
Am Beispiel der Automatisierung ist eine differenzierte Betrachtung und Skepsis ja auch vollkommen angebracht:
- Wie könnte eine Automatisierung aussehen?
- Was brauche ich alles dafür?
- Was gibt es alles im Unternehmen, was ich bereits nutzen kann?
- Welche Qualitätskriterien muss ich erfüllen?
- Welches konkrete Zielbild habe ich vor Augen?
- Wie wird sich meine Arbeit verändern, wenn ein Computer die Standardaufgaben übernimmt?
- Habe ich dann überhaupt noch eine Arbeit?
- Woher bekommen wir die Ressourcen Know-How und Zeit, um uns intensiv damit zu beschäftigen?
- Was, wenn wir uns verkalkulieren? Automatisierung nimmt uns ja die Flexibilität und führt starre Prozesse ein. Das kann uns mächtig auf die Füße fallen.
- Haben wir überhaupt das Budget dafür?
- Ist es jetzt wirklich das wichtigste Thema?
- Welche anderen Anforderungen bleiben dafür liegen?
- Wo liegt der Break Even Point? Gibt es überhaupt einen?
Das schöne: Diese Fragen zu beantworten ist ein in der IT gelöstes Problem: Es nennt sich Anforderungsanalyse, Design und Priorisierung. Ihr Product Owner kennt das alles schon und weiß, was konkret zu tun ist.
Es ist kein Ausbildungsproblem
Die Entwickler, mit denen ich in der Regel zusammenarbeite sind hochintelligente Leute, die sich ständig mit den ihnen zur Verfügung stehenden Mitteln weiterbilden:
- Sie gehen auf die gleichen Konferenzen.
- Sie lesen die gleichen Bücher.
- Sie schauen sich die gleichen Online-Trainings und Videos an.
- Sie besuchten die gleichen Universitäten und die gleichen Seminare.
- Sie arbeiten in einem Unternehmen und unter einer Führung, die Wissensaufbau und -transfer als wichtigstes Gut in der IT betrachten.
Optimale Voraussetzungen also. Aber meine Erfahrung zeigt mir: Nicht das, was die Entwickler lernen ist entscheidend – das Wissen selbst ist zweitrangig.
Auch die Jahre, die ich ein Thema gemacht habe, sind oft keine Erfahrung. Ein Entwickler mit 5 Jahren Erfahrung in Java kann locker bessere Lösungen schneller entwickeln als jemand, der 20 Jahre Erfahrung hat – und kann dem vermeintlich erfahrenen Kollegen oft noch extrem viel beibringen.
Erst wenn die Entwickler sich
- tief in ein Thema eingraben,
- sich durch frustrierende Fehlermeldungen und „das klappt alles nicht“ hindurchkämpfen,
- Stackoverflow, ChatGPT und Google verfluchen und links liegen lassen,
- sich durch die API-Dokumentation durchwühlen,
- gute Praktiken wie Test driven Development und Continuous Delivery im Alltag leben,
- eine „Geht nicht, gibts nicht“-Haltung annehmen und
- sich dabei ständig kritisch reflektieren
dann bauen sie wertvolle Erfahrung auf. Leider gibt es für diese Entwickler, die Erfahrung aufbauen wollen, keinen Markt.
- Sie wirken vor allem am Anfang unproduktiv.
- Sie probieren viel aus und das meiste geht schief.
- Ihre Fehlerrate ist dadurch sehr hoch.
- Sie sind ständig im Gespräch mit anderen Entwicklern und halten diese mit Fragen von der Arbeit ab.
- Die Ergebnisse sind auf den ersten Blick schlechter als die Stackoverflow-Copy-Paste-Entwickler.
- Es ist unklar, ob derjenige jemals gut wird.
Von außen betrachtet sieht der zukünftige IT-Superstar genauso aus wie der letzte Low Performer – und er lernt schnell, dass Stackoverflow-Copy-Paste-Entwicklung deutlich angenehmer für ihn ist.
Erfahrene Entwickler wachsen nicht auf den Bäumen
Es gibt sie aber, die erfahrenen Entwickler, die nicht nur Zeit mit etwas verbracht haben sondern wirklich Expertenstatus erreicht haben. Aber sie sind rar gesät, weil es im Arbeitsalltag unangenehm ist und ein hohes Maß an Selbstvertrauen braucht, um richtig gut zu werden.
Es ist ja selbst in Zeiten des Fachkräftemangels nicht schwer, irgendeinen ITler zu finden – jedes Jahr spucken die Universitäten massenhaft aus, mein Postfach ist voll mit Bewerbungen.
Gute und erfahrene Leute sind aber rar. Und wenn, dann kennen sie ihren Wert und sind kaum bezahlbar – sowohl als externe, als auch als interne Mitarbeiter.
Die meisten von uns müssen sich also der Realität stellen, dass wir aus einer durchschnittlichen Gruppe das bestmögliche Team formen müssen.
Ohne Erfahrung keine Vorstellungskraft
Solange Ihre Entwickler nicht die nötige oder nur ungünstige Erfahrungen aufgebaut haben, werden sie nicht die Vorstellungskraft und den Antrieb finden, sich mit den aktuell wichtigen Themen zu beschäftigen.
Weder mit den klassischen Themen, wie
- extreme Programming, z.B. Pair Programming, Test driven Development etc.,
- arbeiten in Scrum und kontinuierliche Anpassung anhand von Daten und Kennzahlen,
- Continuous Delivery und GitOps,
- die Prinzipien hinter Clean Code und The Pragmatic Programmer oder auch
- Software Craftsmanship
noch die aktuellen, darauf aufbauenden Themen, wie
- Platform Engineering,
- Dev(Sec)Ops,
- KI-gestützte Entwicklung,
- Chaos Engineering,
- …
Wenn die Erfahrung im Team fehlt, dann fehlt auch die Vorstellungskraft des möglichen – oder der Berg an Arbeit wird als viel zu hoch eingeschätzt. Nicht der Mühe wert.
Die gängigen Mittel, um Erfahrung im Team aufzubauen
Ich habe die letzten Jahre schon diverse Möglichkeiten des Wissens- und Erfahrungsaustauschs ausprobiert:
- Pair Programming
- Slack-Time
- Dokumentation schreiben und lesen
- Vorbereitungen auf Reviews
- Tech Talks
- Test driven development
- Hackathons
- Simulationen und Szenarien
- Mob Programming
- Gemeinsames lernen
Alle funktionieren super, wenn ein wirklich erfahrener Kollege dabei ist, der voran geht und sich wirklich für den Erfahrungsaufbau des Teams interessiert – egoistische Helden sind dagegen wenig hilfreich.
Fast alle dieser Praktiken funktioniert nur mäßig, wenn das Team wenig Erfahrung mit dem Thema hat.
Was sich für mich zuletzt bewährt hat – gemeinsam ins unbekannte Land ziehen
„Wenn der Prophet nicht zum Berg kommt, muss der Berg zum Propheten kommen.“
Gemeinsames Lernen – ich habe es ausprobiert und es funktionierte großartig.
Aber Achtung: Es ist auch extrem zeitaufwendig.
Mein Vorgehen:
- Ich habe mir als Product Owner das nächste Thema auf meiner Prio-Liste angeschaut: „Nutzung von GitOps um den Betrieb des Kubernetes-Clusters deutlich zu vereinfachen.“
- Da ich wusste, dass niemand im Team echte Erfahrung mit dem Thema hatte, habe ich über mehrere Sprints hinweg auf eine Kombination aus Frontalvortrag, Workshops, Einzelarbeiten und -recherche und Reflexion gesetzt.
- Als Product Owner war es mir ein Anliegen, mein Team voll dabei zu unterstützen. Deshalb habe ich in jedem Review und am Anfang jedes Workshops jedes Mal die gleiche Präsentation gehalten:
- Wo standen wir bevor wir uns auf den Weg gemacht haben,
- was ist unser Ziel,
- welche Fortschritte haben wir gemacht? Die Präsentation unterschied sich bei jedem Vortrag, je nachdem welche Fortschritte wir bis dahin gemacht hatten.
Das hat super funktioniert. Durch den klaren Fokus und die immer wiederkehrende Geschichte, was wir schon erreicht haben und was die nächsten Schritte sind, gepaart mit den Workshops, Einzelarbeiten und der gemeinsamen Reflexion, hat das Team in kurzer Zeit massiv Erfahrung aufgebaut.
Aber funktioniert das immer?
Garantiert nicht (sonst würde es ja jeder machen).
Aber es war die richtige Methode zur richtigen Zeit.
Wollen Sie das auch?
Und genau dabei unterstützen wir Sie gerne: Wir finden mit Ihnen die richtige Methode zur richtigen Zeit, damit Sie die Zusammenarbeit in Ihrem Team stärken können, sodass Ihr Team die anfallende Arbeit schafft – ganz ohne Überstunden, Frustration und Harakiri-Heldentum.
So bereiten Sie die Basis für effizienten Erfahrungsaufbau und schaffen es, aus „durchschnittlichen“ Entwicklern ein großartiges Team zu formen, das den Mut zum Commitment aufbringt.
Ein schöner Seiteneffekt: Wenn Sie genau wissen, was ihr Team leisten kann, dann können Sie Ihren Stakeholdern und Kunden klare Vorhersagen geben, wann sie Feature X oder Y bekommen werden. Sie können sich voll darauf verlassen, dass Ihr Team in jeder Situation die richtigen Maßnahmen ergreift und Ihr Scrum Master und Product Owner das Team in die richtige Richtung steuern.