Auf einem Meetup habe ich als Speaker über zwei teambezogene Themen gesprochen. Einmal geht der Blick nach innen und einmal an die Ränder des Dev-Teams.
Der Fokus der Ausführungen liegt dabei auf Softwareentwicklungsteams. (Leider ist eine interdisziplinäre Aufstellung meiner Erfahrung nach v. a. im Projektgeschäft immer noch nicht die Norm.) Die Erkenntnisse lassen sich jedoch genauso gut auf jede andere Form von Team und Organisation übertragen.
Hier die Zusammenfassung meiner beiden Impulse. Beginnen wir mit der Innensicht.
Inhaltsverzeichnis
Wie veränderbar sind Devs?
Die Teams, auf die ich mich im Folgenden beziehe, bestehen aus Wissensarbeiter:innen. Deren Aufgabe ist es, in komplexen Umfeldern Lösungen zu liefern und Wert zu schaffen. Und das in einer Welt, die gefühlt immer schneller und undurchschaubarer wird und in der wir Ansätze wie VUCA und BANI als Denkstützen brauchen.
In unserem agilen Werkzeugkoffer gibt es vielfältige Antworten, um dieser Gemengelage Herr zu werden. Wir wollen den Teams Autonomie geben und sie "empowern", sich selbst zu organisieren. Wir fördern und fordern direkten Kundenkontakt zur Klärung von Fragen und Schärfung von Anforderungen. Wir führen Refinement, Planning, Daily, Review und Retrospektiven ein. Wenn das nicht reicht, schleichen sich auch noch mehr Besprechungen, Syncs und Jour fixe ein.
Versteht mich nicht falsch, viele dieser Punkte sind gut und richtig. Der Punkt ist: aus unserer Sicht dürfen die Devs sich selbst organisieren. Sie sind auch schlau genug, um Selbstorganisation zu können - ggf. mit etwas Anschubhilfe und Begleitung durch einen Agile Coach.
Doch wollen sie das auch?
Zunächst: Ja, manche Devs lieben diese Freiheit. Sie gehen darin auf, den Freiraum zu nutzen, der ihnen gegeben wird. Doch die Erfahrung zeigt, dass eine wachsende Anzahl Entwickler:innen das Thema "Agile" mittlerweile als Belastung sehen.
Warum? Devs lieben es, Probleme zu lösen. Dafür braucht es u. a. längere Phasen konzentrierter Arbeit. Immer mehr Meetings, große Besprechungen und Abstimmungen empfinden sie als Störung und Zusatzbelastung.
Schlussendlich sollen Devs im Rahmen ihrer "regulären" Arbeit buchstäblich Lösungen entwickeln. Und sie wollen sehr gerne einfach programmieren. Sie wünschen sich einfach nur eine Spezifikation, die sie umsetzen können. Stattdessen sollen sie unter Zeitdruck auch noch Zeit in, in ihren Augen sinnlosen und ermüdenden, Besprechungen verbringen.
Zugegeben, das ist ein etwas düsteres Bild, das ich hier male. Nur leider ist es auch ein zu oft erlebtes.
Was ist hier passiert? Agile Arbeit kommt ursprünglich aus der Softwareentwicklung und nun wollen Softwareentwickler:innen nichts mehr damit zu tun haben?
Einen Teil der Antwort finden wir im Agile Manifesto. Eines der Prinzipien lautet:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Und genau da ist der Punkt: "give them [what] they need". Da steht nicht "was wir von ihnen wollen", sondern "was sie brauchen".
Meine Hypothese: Agilität im Team, im "Kleinen", hat den Dev-Fokus verloren.
Es steht natürlich außer Frage, dass sich die Devs trotzdem noch anpassen müssen und wir auf keinen Fall mehr zurück zu den "Kellerkindern" dürfen.
Doch die Kernfrage muss wieder sein: Was brauchen Devs, um das Richtige richtig zu liefern?
Also fragt in der nächsten Retrospektive oder einem passenden Alternativformat nach den Bedürfnissen der Devs und gebt dann euer bestes, ihnen das auch zu geben. Da können so vermeintlich einfache Sachen dabei sein wie eine Vision und Mission, ein Ziel und Vertrauen. Oder vielleicht auch sehr technische Punkte wie Zeit für Verbesserungen, sauberes Design und saubere Architektur. Oder die Möglichkeit, technische Schuld abzubauen. Vielleicht auch Raum für neue Technologien, Pair- und Mob-Programming, DevOps-Denken, Freiheit bei den Werkzeugen und vieles mehr.
Es dürfen auch heilige Kühe geschlachtet werden: Ziel ist nicht das perfekte Scrum oder jeder andere Prozess. Prozesse sind Mittel zum Zweck. Sie sollen unterstützen und nicht behindern. Im Mittelpunkt muss stets die Wertschöpfung stehen.
Und da Teams nicht im luftleeren Raum bestehen, lohnt sich nach der Innenperspektive auch der Blick an die Ränder und von dort tiefer in die Gesamtorganisation.
Wie veränderbar sind Organisationen?
Nehmen wir an, wir haben ein Dev-Team, das im besten Fall nicht nur agil tut, sondern auch agil ist.
Die Erwartungshaltung kann nun sein, dass der Erfolg vorprogrammiert ist. Effektive Produkte und Dienstleistungen werden effizient auf die Straße gebracht und alles wird gut.
Nur leider wird das höchstwahrscheinlich nicht passieren. Eine mögliche Erklärung hierfür kann sein, dass das Team in Isolation agiert.
Und rund um das Team existieren weitere Inseln.
Weiterhin mache ich die Annahme, dass diese Inseln in sich gut funktionieren und lokal hochoptimiert sind. Nur führt lokale Verbesserung nicht zu einer automatischen globalen Optimierung.
Eine Lösung ist es, dass sich das Dev-Team dessen bewusst wird. Man kann dies als "Blase der Agilität" bezeichnen, als Waterscrumfall oder Waterfall Agile (kurz Wagile). Innerhalb dieser Blase gibt das Team sein Bestes und muss sich gleichzeitig stets bewusst sein, dass an den Rändern eine Organisation existiert, die anders denkt und funktioniert.
Man darf damit die Frage in den Raum stellen, wozu nur Dev-Teams agil denken und handeln sollen. Warum passiert noch zu wenig im Gesamtunternehmen? Was sagt das über die Veränderbarkeit der Organisation aus?
Auch hier gibt es eine Teilantwort im agilen Manifest:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Das Stichwort hier lautet "to satisfy the customer". Denn darum muss es immer gehen. Der Zweck eines Unternehmens ist es, Geld zu verdienen. Dieses Geld kommt von Kunden, die für ein wertvolles Produkt bezahlen.
Meine Hypothese: Wir drehen uns oft um uns selbst und verlieren dabei den Kundennutzen aus den Augen.
Anstatt der lokalen Aktion, mal eben die Entwickler:innen in ein vermeintlich agiles Prozesskorsett zu zwängen, ist die Betrachtung des gesamten Wertstroms eines Unternehmens auf lange Sicht sehr viel nachhaltiger und sinnvoller. Nur so kann echte Business-Agilität erreicht werden.
Damit stellt sich die Frage: Was sind erste Schritte zur „Agilisierung“ der Gesamtorganisation? Generell mag dieses Vorhaben zunächst erschrecken. Es entsteht vielleicht das Bild, einen gordischen Knoten zerschlagen zu müssen.
Ein guter erster Schritt kann sein zu erfassen, was der aktuelle Zustand ist:
- Was ist die Strategie des Unternehmens?
- Welche Projekte und Initiativen zahlen auf die strategischen Ziele ein?
- Wie werden diese Projekte koordiniert?
Mit dieser Visualisierung und Denkhilfe fällt es leichter, über das gleiche zu sprechen und geeignete Stellen zu identifizieren, an denen als erstes gearbeitet wird. Und ein Werkzeug, das hierbei helfen kann, sind die Flight Levels.
Fazit
Der Kern von Agilität ist der Umgang mit Veränderung. Dieser Umgang wiederum erfordert selbst eine Veränderung. Damit fangen die Probleme an, ob eine betrachtete Einheit veränderbar sein kann, will und darf.
Bei der Veränderbarkeit von Devs und Teams ist es sinnvoll, sich (wieder) auf die Bedürfnisse der Wissensarbeitenden zu konzentrieren. Ohne sich zu verbissen an Prozesse zu halten oder nur auf kurzfristige Ziele zu achten.
Zur Veränderung von Organisationen ist es angebracht, mithilfe von einfachen Visualisierungen zunächst ein gemeinsames Bild der Gesamtsituation zu schaffen. Davon ausgehend werden erste Schritte zur Verbesserung identifiziert.
Die Kunst dabei ist es, stets den Status quo und die eigene Arbeit zu hinterfragen. Und den Blick für das Ganze zu öffnen, ohne die Details aus den Augen zu verlieren.
Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.
