Innerhalb eines Entwicklerteams funktioniert die Kooperation meist sehr schnell ziemlich gut – allerdings oft nur bis zur Teamgrenze. Team- oder auch unternehmensübergreifend dagegen wird weiterhin versucht, Kooperation in Form von Hierarchien, Verträgen und Verantwortlichkeiten festzulegen. So werden zum Beispiel Wissenssilos gefördert und das wahre Potenzial der Teams kaum ausgeschöpft.
Warum ist das so? Was kann man machen, um die Zusammenarbeit über die Teamgrenze hinaus zu fördern? In meinem letzten Blogpost Mentale Modelle für eine bessere Zusammenarbeit habe ich euch erzählt, wie wir bei Mayflower die Zusammenarbeit innerhalb der Teamgrenzen stärken. In diesem Beitrag zeige ich Wege auf, wie man das teamübergreifend bewerkstelligt.
Warum wird versucht, alles in Verträgen festzulegen?
Es fühlt sich anfänglich ganz gut an, die erfolgreiche Zusammenarbeit in einem Dokument festzulegen. Verträge versuchen, Bekanntes zu regeln; also Dinge, die man sowieso schon weiß. Dadurch wägt man sich in Sicherheit, denn gibt es trotzdem einmal Unsicherheiten, kann man sich immer noch auf den Vertrag beziehen. Ebenso kann man den Vertrag nutzen, wenn die Stimmung zwischen den Parteien einmal nicht mehr so gut ist – man schätzt sich glücklich, wenn man einen Vertrag besitzt. Und natürlich wird in Verträgen versucht, schon vorab Lösungen für Probleme zu liefern. Gerade das ist jedoch reines Wunschdenken, denn in der Softwareentwicklung findet man (nach Cynefin) hauptsächlich komplexe Problemstellungen wieder.
Software-Entwicklung ist komplex
Das bedeutet: Ich habe ein Problem, für das ich die Lösung noch gar nicht kenne. Ich kann also nicht mit einem starren Vertrag auf komplexe Zusammenhänge reagieren! Deshalb steht im agilen Manifest, dass Individuen und Interaktionen wichtiger sind als Prozesse und Werkzeuge.
Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
In der Realität fehlt es uns leider oft an der Disziplin, das agile Manifest ernst zu nehmen – in einer perfekten Welt würden wir auf Basis eines gemeinsamen Verständnis zusammenarbeiten (leider steht es so nicht explizit im agilen Manifest). Oftmals stehen Probleme in der Organisation dem gemeinsamen Verständnis im Weg:
Wissenssilos / Silodenke
Wer kennt das nicht, die Zusammenarbeit zwischen einzelnen Unternehmensbereichen (z.B. Marketing, Entwicklung, Systemadministration oder Vertrieb) funktioniert nicht optimal, die Koordination untereinander ist schlecht. Jede Abteilung hat seinen eigenen Workflow bzw. Herangehensweise und optimiert für seine Zwecke. Durch diese lokale Optimierung entwickelt sich mit der Zeit eine gegensätzliche Arbeitsweise zum Rest des Unternehmens. Das nennt sich dann Silodenke – man arbeitet nebeneinander her und hat keine Berührungspunkte mehr mit den anderen Kollegen, dadurch wird die Produktivität gemindert.
Hierarchien
Hierarchische Entscheidungen verhindern das Commitment des Teams, das für die Umsetzung verantwortlich ist. Das führt zu Problemen, wenn es um die Realisierung oder die Fehlerbehebung geht, denn das Team muss mit etwas arbeiten, was es im schlimmsten Fall gar nicht will oder unterstützen kann.
Verantwortlichkeiten
Alte Strukturen verhindern das gemeinsame Verständnis. Sätze wie „das haben wir schon immer so gemacht“ bezeugen die festgefahrenen Routinen und werden oft als Argumente benutzt. Viel besser wäre es, wenn Teams gemeinsame Werte teilen und das gemeinsame Ziel, auf das man fokussiert hinarbeiten kann, kennen.
Neben den Problemen in der Organisation sollte man aufhorchen, falls man in der täglichen Arbeit folgendes Verhalten wiederfindet:
Eine User Story wird als Vertrag betrachtet
Folgt man strikt einer User Story und „führt nur aus“ was dort geschrieben steht, wird die User Story als Vertrag angesehen – letztendlich wird dadurch Verantwortung für das Resultat abgegeben und es kann zu Mehraufwand durch Änderungen kommen.
Übergaben werden als Übergaben der Verantwortung angesehen
Übergaben an andere Teams (z. B. QA) sollten nicht mit einer Übergabe der Verantwortung einhergehen, was einer Limitierung der eigenen Verantwortung gleichkommt, denn ich gebe die Verantwortung ab. Dadurch entstehen wieder viele Diskussionen und das kostet Kraft und Zeit.
Die Definition of Ready wird gegen die Kollegen genutzt
Fallen die Sätze „Damit kann man leider nicht arbeiten!“ oder „Das nehme ich so nicht an“, entsteht eine unangenehme „wir gegen die“-Situation, es machen sich also Fronten breit. Dies kann der Start einer massiven Diskussion sein, mit der Folge, dass man unnötig Zeit (die zur Klärung notwendig ist) verliert.
Was kann man machen, um die Zusammenarbeit über die Teamgrenze hinaus zu fördern?
- Eine User Story sollte als eine Promise of Conversation verstanden werden. Die Konversation von Angesicht zu Angesicht ist die effizienteste und effektivste Art der Informationsweitergabe an und in einem Entwicklungsteam (siehe agiles Manifest).
- Es sollte klar sein, wer die wichtigen Stakeholder sind und auf welchem Weg mit ihnen kommuniziert werden kann. Bei Mayflower haben wir gute Erfahrungen mit der sog. Stakeholdermap gemacht: Damit wird übersichtlich visualisiert, an wen sich gerichtet werden kann, falls Fragen aufkommen.
- In anderer Richtung sollte auch den Stakeholdern klar sein, wann sie Fragen ans Team stellen können. Das sollte idealerweise nicht zu jederzeit passieren, dafür ist das Sprint-Review-Meeting vorgesehen. In diesem Meeting ist Input von außerhalb des Teams gewünscht und man plant/geht gemeinsam die nächsten Schritte durch. Echtes Feedback zum Outcome ist sehr wichtig und hilft, ein besseres Produkt zu entwickeln.
Was macht ihr, um die Zusammenarbeit team- oder gar firmenübergreifend zu fördern? Schreibt uns eure Tricks, wir sind gespant auf eure Erzählungen.
Auch interessant:
Schreibe einen Kommentar