Abhängigkeiten in Scrum eliminieren

Wie Abhängigkeiten durch soziotechnisches Lernen effektiv eliminiert werden können

Organisationen müssen schnell handeln und fortlaufend Feedback von Kunden erhalten, um durch kontinuierliche Entdeckung und Lieferung von Mehrwert nachhaltig Innovationen voranzutreiben. Aber es gibt ein Problem: Abhängigkeiten.

Abhängigkeiten sind Wissenslücken

Michael James schreibt, Abhängigkeiten in der Wissensarbeit — wie in der Softwareentwicklung — werden durch Wissenslücken verursacht und nicht durch Gesetze der Physik.¹

Damit hat er Recht. Dass wir zuerst unsere Socken anziehen müssen, bevor wir unsere Schuhe anziehen können, trifft auf Wissensarbeit nicht zu. Wir können beim Schreiben eines Buches mit dem zweiten Kapitel beginnen, wenn wir den Inhalt des Ersten kennen. Wissensgenerierung wird allein durch die Fähigkeit, Wissen zu entdecken und zu schaffen beschränkt, und nicht durch physische Abhängigkeiten.

Wenn es Unklarheiten hinsichtlich bestimmter Anforderungen gibt und der Product Owner nicht zur Verfügung steht, wenn für die Durchführung einer Schemaänderung die Anleitung durch einen Datenbankadministrator benötigt wird, wenn die Entwicklung erst nach der Bereitstellung der Entwicklungsumgebung beginnen kann, wenn die Arbeit erst weitergeführt werden kann, nachdem die Änderung an einer API durch ein anderes Team abgeschlossen ist, wenn ein Product Backlog Eintrag nicht abgeschlossen werden kann, da auf die Genehmigung der Änderung durch das Change-Review-Board gewartet werden muss, dann sind dies keine physischen Abhängigkeiten für Teams, sondern Abhängigkeiten, welche allein auf fehlendes Wissen zurückzuführen sind.

Wodurch entstehen Wissenslücken? Sind sie von Haus aus da, oder entstehen sie erst im Laufe der Zeit in einer Organisation? Wer trägt die Verantwortung für deren Entstehung?

Das Management von Abhängigkeiten löst diese nicht auf

Fortschritt in derSoftwareentwicklung lässt sich nur durch die Auslieferung von Software greifbar machen. Stellen Teams den Nutzern nicht regelmäßig neue Versionen ihres Produkts zur Verfügung, fehlt die Basis für das Feedback durch die Nutzer. Ohne Feedback ist der Entwicklungsfortschritt für die Organisation nicht erkennbar. Diesem Kontrollverlust begegnen Manager, indem sie teilen und herrschen:

• Sind die Anforderungen unklar, wird ein Requirement Engineer beauftragt, die Anforderung des Kunden vorab zu dokumentieren, bevor sie an die Teams übergeben werden können.
• Treten vermehrt Probleme während des Tests auf, wird ein Testmanager eingestellt, der die Testaktivitäten teamübergreifend koordiniert.
• Kommt es zu Qualitätsproblemen, wird eine separate Abteilung für Qualitätskontrolle gegründet, welche die Arbeit der Teams validiert und freigibt, wenn diese mit den Anforderungen konform gehen.

Wenn Teams die Möglichkeit genommen wird, ihre Arbeit eigenständig zu erledigen, müssen diese Arbeiten an andere übergeben. Und dadurch sind sie von ihnen abhängig. Durch die Schaffung neuer Funktionen, Einheiten, Teams und Koordinierungsrollen fördern Manager die Spezialisierung und Teilung der Organisation. Mehr Teilung führt zu mehr Abhängigkeiten.

Begreifen wir hingegen Abhängigkeiten als Wissenslücken, sehen wir, dass das Management keine Verbesserung bringen kann. Wissen lässt sich nicht teilen, herumschieben und anordnen. Es lässt sich nur dort entdecken und schaffen, wo es fehlt.

Wie können Organisationen Wissenslücken aufdecken?

Mit Refinement Wissenslücken aufdecken

Scrum Teams verwenden dazu das Refinement. Dieses hilft ihnen, kontinuierlich Wissenslücken aufzudecken, indem sie regelmäßig die bevorstehende Arbeit besprechen. Sollten mehrere Scrum Teams gemeinsam an einem Produkt arbeiten, hat sich teamübergreifendes Refinement bewährt, um Wissenslücken kontinuierlich über Teamgrenzen hinweg zu identifizieren.

Nachdem die Abhängigkeiten identifiziert wurden, können wir keine Abarbeitungsreihenfolge finden, welche alle Abhängigkeiten berücksichtigt?

Bei dem Versuch, Abhängigkeit im Vorfeld detailliert zu antizipieren, um die Arbeit der Teams um sie herum zu planen, begeben sich Organisationen auf einen gefährlichen Pfad. Nick Tune beschreibt das Ende dieses Pfades als Wasserfall. Tiefgreifende Antizipation ist das Herzstück von skalierten agilen Frameworks wie SAFe. Der Wasserfall ist das extreme Ende dieser tiefen Antizipation.³ Tiefe Antizipation ist ein Wasserhahn, und je weiter wir ihn aufdrehen, desto näher sind wir dem Wasserfall, egal wie wir unseren Prozess nennen. In einem sich ständig ändernden Umfeld — in dem Produktwicklung stattfindet — nehmen sich Organisationen selbst den Wettbewerbsvorteil auf Änderungen schnell zu reagieren.

Wie lassen sich also die Wissenslücken schließen?

Kurzfristig lassen sich aufgedeckte Wissenslücken beseitigen, indem

• Teammitglieder teamübergreifend zusammenarbeiten,
• Arbeit auf andere Teams umverteilt wird,
• der Product Backlog neu angeordnet wird oder
• einzelne Teams nur mehr für bestimmte Features verantwortlich sind.

Diese kurzfristige Denkweise hat ihren Preis: Der Product Owner kann das Product Backlog nicht mehr danach ordnen, was wahrscheinlich den höchsten Mehrwert liefern wird. Dadurch wird die Organisation der opportunistischen Wertfindung beraubt, welche Agilität im Kern ausmacht.
Deshalb müssen Organisation Wissenslücken nachhaltig schließen, ohne dabei den Product Owner in dessen Handlungsspielraum einzuschränken. Welche Wege führen zu diesem Ziel?

Soziotechnisches Lernen ist die nachhaltige Beseitigung von Wissenslücken

Nur Lernen beseitigt Wissenslücken. Lernen im Organisationskontext ist eine soziotechnische Aktivität. Wir können hierbei weder über die Zusammenarbeit zwischen Menschen und Teams noch über Weiterentwicklung von Entwicklungspraktiken isoliert nachdenken. Es ist symbiotisch. Stattdessen sollten wir uns darauf konzentrieren, lernfähige Organisationen zu schaffen, indem wir ständig die technologischen und organisatorischen Barrieren zwischen Teams beseitigen, so dass sie effektiv mit teamübergreifenden Abhängigkeiten umgehen können, anstatt zuzulassen, dass sie zu weiter Teilung der Organisation führen.

Wie lässt sich soziotechnisches Lernen umsetzen? Ich beobachte, dass bei Organisationen aller Größenordnungen folgende Praktiken an Popularität gewinnen:

Inner Sourcing. Wenn Team A Änderungen am Code von Team B benötigt, Team B aber andere Prioritäten hat und deshalb Team A blockiert, kann Team A Änderungen am Code von Team B vornehmen und einen Pull Request einreichen. Open Source innerhalb einer Organisation wird als Inner Sourcing bezeichnet und ist somit ein Ansatz, der auf offener Kollaboration und selbstorganisierender Arbeit basiert. Es hilft Organisation, die Zusammenarbeit über Teamgrenzen hinweg zu ermöglichen.

Communicate in Code. Teams verwenden kontinuierliche Integration, was bedeutet, dass jeder Entwickler seinen gesamten Code in das zentrale Repository eincheckt. Jeder synchronisiert sich mehrmals am Tag mit dem Repository und ist somit über alle Änderungen informiert. Nach Aktualisierungen hat jeder Entwickler die Möglichkeit, die Änderungen der anderen durchzusehen und sieht, woran sie arbeiten. Branching hingegen verzögert die Integration und damit den zentralen Wissensaustausch und sollte deshalb vermieden werden.

Komponenten-Communitys of Practice. Wenn Team A und Team B zur gleichen Zeit an der gleichen Codekomponente arbeiten, müssen sie voneinander wissen, damit sie Fragen stellen und die Codeänderungen des anderen Teams reviewen können. Komponenten-Communitys of Practice helfen diese Kommunikation zu ermöglichen, und zwar durch Mailinglisten, Chats, gelegentliche Treffen oder andere Kanäle. Diese Communitys werden von Komponenten-Mentoren organisiert, welche Mitglieder von Teams sind und die zusätzliche Verantwortung übernehmen, anderen Teams als Mentoren zur Seite zu stehen. Dabei genehmigen sie nicht die Änderungen an der Komponente, sondern unterstützen die Entwickler mit Design Workshops, Code Reviews und als Ansprechpartner für Implementierungsfragen. Diese Patenschaften fördern die Verbreitung von Wissen innerhalb der Organisation.

Organisationsweites Pair Programming. Es gibt viele Formen von Pair Programming, die von Vorteil sein können. Wenn wir zum Beispiel eine Abhängigkeit zwischen Team A und Team B sehen, könnten Mitglieder von Team A vorübergehend eng mit Mitgliedern von Team B zusammenarbeiten, um gemeinsam das Problem zu lösen und voneinander zu lernen. Anstatt nur bei akuten Problemen zusammenzuarbeiten, ist in vielen Organisationen Pair Programming auch über Teamgrenzen hinweg zum aktuellen Entwicklungsstand geworden. Dort tragen sie die Entwickler in einem unternehmensweiten Kalender ein, um Partner für ihre Pair Programming Sessions zu finden. Dadurch wird organisationsweit ein kontinuierlicher Wissensaufbau und Austausch zwischen Entwicklern gefördert.

Team Rotation. Bei der Team Rotation wechselt in einem regelmäßigen Rhythmus ein Mitglied aus Team A zu Team B und ein Mitglied aus Team B zu Team A. Regelmäßige Rotation liefert ein größeres Bewusstsein für das große Ganze und verbessert die Fähigkeiten des Einzelnen und somit des gesamten Teams. Meiner Erfahrung nach sollte aus jedem Team mindestens eine Person alle zwei bis drei Monate in ein anderes Team rotieren. Diese deckt sich auch mit den Fallstudien, welche Heidi Helfand in Dynamic Reteaming vorstellt.⁴ Tritt nun eine teamübergreifende Abhängigkeit auf, hilft sowohl das Wissen über die Systeme der anderen Teams als auch die gestärkte persönliche Beziehung, um mögliche Wissenslücken und Reibungspunkte in der Zusammenarbeit frühzeitig zu reduzieren.

Organisationsweites Lernen eliminiert Abhängigkeiten

Leidet Ihr Team unter Abhängigkeiten und den daraus resultierenden Verzögerungen? Ist der Product Owner nicht mehr in der Lage, das Product Backlog nach dem höchsten Mehrwert zu ordnen?

Dann sollte die kontraintuitive Erkenntnis aus diesem Artikel sein, dass sich durch mehr Management die Abhängigkeiten nicht auflösen, sondern potenzieren!

Der beste Weg, noch mehr Abhängigkeiten zu erzeugen, ist es, die Organisation durch Abhängigkeitsmanagement noch weiter zu zerteilen. Deshalb ist es besser, ein Umfeld für soziotechnisches Lernen zu schaffen. Eine lernende Organisation bedeutet im Kern, dass jeder Einzelne ständig dazulernt und sein Wissen an andere weitergibt. Somit ist der Weg, um langfristig Abhängigkeiten zu eliminieren, sich auf organisationsweites Lernen zu konzentrieren.

Hinweise:

Simon Flossmann bietet Einblicke in seine Arbeit als Steward für Scaled Professional Scrum Training, sowie schreibt gelegentlich über skaliertes Scrum und agile Produktentwicklung. Wenn Sie sich dafür interessieren, dann können Sie sich hier in seinen Newsletter eintragen.

[1] Michael James: The Seattle Scrum Company
[2] Solutioneers: 17 Kanban Dependency Management Hacks To Improve Flow Efficiency, Program Dependency Board
[3] Nick Tune: Strategy, Architecture, Continuous Delivery, and DDD
[4] Heide Helfand: Dynamic Reteaming

Diesen Beitrag finden Sie auch im kostenlosen Blogpaper Scrum – Sieben Perspektiven zu Scrum.

Simon Flossmann hat zwei weitere Beiträge im t2informatik Blog veröffentlicht:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.