Sinnvolle Grenzen für selbstverantwortliche Teams

Für mich ist der Anspruch eines Teams, das selbstbestimmt und selbstverantwortlich arbeiten kann, ein Idealbild, das ich jeden Tag versuche zu erreichen. Obwohl wir alle wahrscheinlich ein unterschiedliches Verständnis davon haben, was ein selbstverantwortliches Team ausmacht, so ist die Vision von Teams für viele erstrebenswert, in der alles von der Anschaffung einer neuen Kaffeemaschine bis hin zu Neuanstellungen innerhalb des Teams entschieden wird. In der Praxis ist dies nicht immer leicht: vor einigen Jahren begegnete ich Kollegen, die „Das Team ist verantwortlich“ mehr als Schimpfwort, denn als Anspruch verwendeten. Sie wurden für jeden Ausfall, für alles was schieflief, verantwortlich gemacht. Auch wenn eine Ursachenanalyse aufzeigte, dass die Gründe ganz woanders zu suchen waren, wurde trotzdem auf das Team gezeigt. „Finger-Pointing“ auf ganze Teams kann sicher nicht die Konsequenz sein.

Bei aller Euphorie über Selbstverantwortung und Selbstbestimmung dürfen wir nicht vergessen, dass Teams nicht in luftleeren Räumen existieren, sondern in Management-Kontexte eingebunden sind. Und es mag trivial klingen, Teams sind Menschen. Nur weil plötzlich ein nichtsnutziger Faulpelz in ein selbstverantwortliches Team gesteckt wird, wird er nicht zum Liebling aller und übernimmt freiwillig zusätzliche Aufgaben. Ich möchte in diesem Beitrag nicht das Schneiden von Teams bezüglich unterschiedlicher Persönlichkeiten diskutieren; das ist eher die Sache von Psychologen. Aber ich kann beschreiben, was wir technisch und auch methodisch tun können, um das Leben der Teams ein wenig einfacher und damit auch ein Schritt Richtung Selbstverantwortlichkeit zu machen. Zu diesem Thema gibt es jede Menge Literatur, die ich jedem empfehle, der sich mit dem Thema näher auseinandersetzen will: Ich schätze sehr Boris Gloger und „Selbstorganisation braucht Führung“ ¹ ist ein gut geschriebenes Buch, das über die Euphorie hinausgeht und wirkliche Handlungsanleitungen und Anleitungen zum selber Denken enthält. Und natürlich den Klassiker der Selbstorganisation und Empowerment von Jurgen Appelo².

Entscheidungen von Teams

Welche Entscheidungen kann ein solches Team überhaupt treffen:

• Es sollte in der Lage sein, die Technologie zu wählen, mit der es arbeiten möchte.
• Es sollte in der Lage sein, zu jedem Zeitpunkt, den das Team unabhängig wählt, neue Software produktiv zu setzen, ohne dabei andere Teams zu stören.
• Implementierungs- und Designentscheidungen liegen in der Hand des Teams.

Stellen sie sich vor, dass wir ein System entwickeln möchten, bei dem über eine Backend-Schnittstelle Nachrichten eines ERP-Systems entgegengenommen und dann als Dokumente dem Benutzer angezeigt werden. Wir würden Teams schneiden: Backend-Schnittstelle, Dokumentenerzeugung und Benutzer-Interface. Jetzt sollen diese Teams die Technologie wählen, mit der sie das System umsetzen möchten.

• Das Backendteam wählt JEE als Technologie, weil sie das schon lange machen und kennen. Und die Nachrichten vom Kunden ohnehin als SOAP geschickt werden.
• Das Dokumenten-Team wählt eine Dokumenten-orientierte Datenbank und verlangt, dass alle Nachrichten als JSON direkt in die Datenbank geschickt werden. Diese wird aber von den Backend-Leuten abgelehnt, da sie keine Erfahrungen mit solchen Technologien haben.
• Die Benutzer-Interface-Leute wollen Angular benutzen, bekommen aber die Dokumenten-Leute nicht dazu, die notwendige Schnittstelle zur Verfügung zu stellen. Sie kreieren clickable Mockups, die sich aber so mit den verfügbaren Daten nicht umsetzen lassen.

Die Zusammenarbeit im Team ist nicht immer einfach.

Eine solche oder auch vergleichbare Situationen haben sicher viele von uns schon mal erlebt. Schnell kommt es zu „Finger-Pointing“ und Diskussionen: „Die liefern uns nicht was wir brauchen.“, „Wir können nicht weiter machen, bevor die nicht fertig sind.“, usw. Die Management-Reaktion ist auch fast klar – sie greifen tiefer in die Teams ein, legen die Schnittstellen fest und planen auf Stunden genau, wann wer was liefern muss. Ein tägliches Eskalationsmeeting verfolgt dann diese Festlegungen. Spätestens bei einem geplanten Go-Live bricht das ganze Kartenhaus zusammen. Zurück zum Beispiel. Ich habe es mit Absicht so allgemein gehalten. Werden wir konkreter sieht die Welt schon ganz anders aus:

1. Ein Backend-System nimmt Lieferscheine über eine Legacy-SOAP-Schnittstelle entgegen.
2. Aus den Lieferscheinen werden rechnungs-relevante Informationen extrahiert und anschließend über ein REST-Interface per JSON zur Verfügung gestellt.
3. Die rechnungs-relevanten Daten werden wiederum von einem Service entgegengenommen und daraus eine Rechnung als PDF erzeugt.
4. Die Rechnung wird im Browser über ein PDF-Plugin dem Benutzer angezeigt und der Benutzer kann die Rechnung signieren.
5. Nach der Signatur wird die Rechnung per E-Mail an den Empfänger verschickt.

Mit diesen Informationen sieht die Welt schon ganz anders aus. Wir können unsere Teams und unsere Services entlang des Business-Prozesses schneiden. Die Bedenkengrenzen und damit die Verantwortlichkeiten des Teams können gut und im gegenseitigen Einverständnis festgelegt werden.

Die Basis für selbstverantwortliche Teams

Man mag sich hier über die Terminologie „Bedenkengrenzen“ wundern. Gemeint sind „Border of Concerns“ aus dem Domain-Driven-Design oder kurz DDD³. Vielleicht fragt sich nun der eine oder andere Projektleiter, Scrum Master usw.: „Was soll ich mit diesen technischen Details? Die interessieren mich nicht!“ Aber wie wir sehen werden, ist eine saubere, technische Entwurfsbasis, die Basis selbstverantwortliche Teams zu schneiden. Mit dem sauberen technischen Entwurf erreichen wir, dass die Teams unabhängig voneinander deployen und unabhängig voneinander entwickeln können. Wie sehen nun unsere Domänen aus:

1. Nachrichten-Empfang
2. Extraktion der Rechnungsinformationen
3. Erzeugung der Rechnung
4. Anzeige der Rechnung und Signatur

Wir haben also nicht mehr drei, sondern vier Teams. Das mag im ersten Schritt zu viel aussehen, aber hier geht es um Verantwortlichkeiten und wie diese geschnitten werden und wir brauchen eine klare Trennung zwischen unterschiedlichen Schritten.

Das erste Team nimmt wiederum die SOAP-Nachrichten in Empfang und stellt sie zur Extraktion bereit. Die Bereitstellung erfolgt per JSON und REST, da sich beide Teams darauf einigen können. Am Anfang stellt das zweite Team seine Expertise in diesem Bereich zur Verfügung.

Das zweite Team extrahiert aus den Lieferscheinen die relevanten Rechnungsinformationen. Da das zweite Team möglichst parallel zum ersten Team entwickeln will, muss es am Anfang auf wirkliche Kundendaten verzichten, aber sie können auf Schnittstellen-Mockups des ersten Teams zurückgreifen. Diese stellt das erste Team gemeinsam mit dem zweiten Team zur Verfügung. Damit schlagen die Teams zwei Fliegen mit einer Klappe: sie können das Wissen zum ersten Team transferieren und bekommen solche „Stubs“ mit denen sie entwickeln können.

Ohnehin müssen sich beide Teams auf einen Vertrag (Contract) einigen, mit denen die notwendigen Daten zur Verfügung gestellt werden. Dieser Vertrag ist eine technische Schnittstellen-Definition – wie z.B. Swagger. Das zweite Team schreibt dann Unit-Tests gegen die Schnittstelle, um sicher zu stellen, dass die Schnittstelle auch immer so funktioniert, wie sie es erwarten (Contract Test). Das erste Team muss aber diese Tests in seinen Deployment-Prozess einbinden, so dass sie sicher sind, bei einem Deployment nicht das zweite Team negativ zu beeinflussen. Im gemeinsamen Definition of Done wird dann festgelegt, dass ein nicht erfolgreicher Test zum Abbruch des Deployments führt.

Durch das dritte Team werden die Rechnungsinformationen wiederum über eine Schnittstelle entgegengenommen und daraus eine Rechnung erzeugt. Sie sind frei in ihrer Technologiewahl, da sie „nur“ über eine Schnittstelle mit dem zweiten Team kommunizieren. Auch hier gilt wieder, dass für Deployments der Vertrag der Schnittstelle getestet werden muss.  Der Vertrag gilt dann natürlich nicht nur zum zweiten Team, sondern auch zum vierten Team, das die Rechnung anzeigen muss.

Das vierte Team wiederum zeigt die Rechnung – vollständig unabhängig von den anderen Teams – an. Sie können auch eine Signatur-Umgebung ihrer Wahl einbinden, da sie nicht auf Informationen oder Datenbankzugriffe in den anderen Teams angewiesen sind.

Datenbankzugriffe – davon war aber bis jetzt nicht die Rede?! Stimmt! Ich habe implizite Annahmen getroffen, die ich nicht erläutert habe. Ja, wir brauchen Microservices, um wirklich selbstverantwortliche Teams zu ermöglichen – und das heißt unter anderem, dass jeder Service und damit jedes Team seine eigene Datenbank oder Datenbanken verantwortet. Die Kommunikation erfolgt ausschließlich über Schnittstellen und ein fremder Service darf nicht einfach mir nichts dir nichts auf eine andere Datenbank zugreifen. Durch diese Konventionen reduzieren wir die gegenseitigen Abhängigkeiten dramatisch und ermöglichen, dass die Teams wirklich in der Lage sind, unabhängig voneinander zu arbeiten.

Gemeinsam zum Erfolg.

Anforderungen an selbstverantwortliche Teams

Schauen wir uns nochmals die eingangs gestellten Anforderungen an ein selbstverantwortliches Team an:

• Es sollte in der Lage sein, die Technologie zu wählen, mit der es arbeiten möchte.
  Die Teams können die Technologie wählen, mit der sie arbeiten möchten. Natürlich sind sie nicht völlig frei in ihrer Wahl (weil zum Beispiel der Vertrag mit einem Cloud-Anbieter schon existiert). Aber sie können freier wählen als zuvor.
• Es sollte in der Lage sein, zu jedem Zeitpunkt, den das Team unabhängig wählt, neue Software produktiv zu setzen, ohne dabei andere Teams zu stören.
  Dieser Anspruch wird durch die Contract Tests auf den Schnittstellen sichergestellt. Dazu gehört, dass in der Definition of Done hinterlegt ist, dass die Tests in die Deployment-Pipleline eingebunden sind und ein nicht-erfolgreicher Tests auch zu einem Abbruch des Deployments führt. Gerade der zweite Teil kann zu großen Diskussionen führen, insbesondere dann, wenn die Deployments wichtige neue Funktionalitäten enthalten. Daher muss die Gesamtlandschaft frühzeitige Tests der Schnittstellen ermöglichen, so dass man auf Bugs rechtzeitig reagieren kann. Dabei müssen solche Tests nicht in einer Landschaft stattfinden, in der alle Services vertreten sind (wie vielleicht ein Pre-Produktions-Staging), sondern beide Services können gegenseitig getestet werden, ohne dass andere Services durch die Tests negativ beeinflusst werden.
• Implementierungs- und Designentscheidungen liegen in der Hand des Teams.
  Wir haben gesehen, dass die Anzeige- und Signier-Funktion vollkommen unabhängig vom Extrahieren der Rechnungsdaten ist. Dies wäre uns beim ersten Entwurf nicht gelungen, da wir zu mindestens Abhängigkeiten in der Datenrepräsentation in der Datenbank hätten.

In diesem Weg können wir es Teams ermöglichen, unabhängig voneinander selbstverantwortlich zu arbeiten. Natürlich ist die Welt nicht immer schön, aber die Welt wird durch den vorgestellten Ansatz schöner. 🙂

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

[1] Gloger, B.: Selbstorganisation braucht Führung: Die einfachen Geheimnisse des agilen Managements, Carl Hanser Verlag GmbH & Co. KG, 2. Auflage, 2017, ISBN-10: 3446454357
[2] Appelo, J.: Management 3.0: Leading Agile Developers, Developing Agile Leaders, Addison-Wesley Professional, 2010, ISBN-10: 9780321712479
[3] Evans, E.: Domain-Driven Design: Tackling Complexity in the Heart of Software, Pearson Professional, 1. Auflage, 2003, ISBN-10: 0321125215

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

Dr. Annegret Junker hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.