Suche
Jetzt ziehen wir an einem Strang

DevOps Stories: Warum cross-funktionale Teams funktionale schlagen

Konstantin Diener

Agilität, Management 3.0, New Work oder DevOps – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen möchten wir gerne in dieser Kolumne berichten.

In der ersten Folge der Kolumne hatten Lukas und sein Team Probleme bei der Auslieferung einer Musikplattform für einen ihrer Kunden. Mit viel Einsatz haben sie es geschafft, die Lösung rechtzeitig für den Messeauftritt zur Verfügung zu stellen. Der Kunde hat auf der Messe sehr gutes Feedback bekommen und möchte zusätzlich zur bereits existierenden Webversion Apps für iOS und Android entwickeln lassen. Lukas und sein Kollege Christian sind für die Umsetzung des Backends zuständig, Julia kümmert sich mit ihren Kollegen um die Webanwendung und Jörg und Adrian bauen die mobilen Apps. Es gibt erste Anzeichen, dass sich die Auslieferung verzögern wird. Deshalb hat Erik, der Produktmanager, ein gemeinsames Meeting einberufen.

Erik (Produktmanager): „Lukas, Christian, ich habe diesen Termin einberufen, weil Jörg und Adrian mir sagten, dass sich die Bereitstellung der Service-Endpoints verzögert und der Releasetermin damit gefährdet ist.“

Christian (Backend): „Was? Sorry, Jungs, das meint ihr aber jetzt nicht ernst, oder? Ihr habt wochenlang gebraucht, um uns zu sagen, welche Daten ihr braucht. Jetzt bekommen wir nach acht Wochen das erste Mal Feedback und euch fällt nichts Besseres ein, als gleich in der Woche danach bei Erik auf der Matte zu stehen? Erik, natürlich gibt es Verzögerungen. Aber das Problem liegt sicher nicht bei uns!“

Jörg (Mobile-App): „Christian, darf ich dich daran erinnern, dass wir direkt zu Beginn eine Schnittstellenbeschreibung bei euch angefragt haben? Die haben wir nie bekommen und mussten uns selbst etwas aus den Fingern saugen!“

Julia (Web-Frontend): „Wir haben auch das Gefühl, dass Serviceimplementierungen immer unglaublich lange brauchen und dann die Services nicht passen. So wie die Services Daten liefern, können wir sie im Frontend nicht sinnvoll anzeigen und müssen sie konvertieren.“

Christian: „Da wir nicht wissen, wie ihr die Services im Web-Layer und in den Apps einsetzt, müssen wir immer eine ganze Reihe von Annahmen treffen und bekommen immer erst nach zwei Wochen Feedback.“

Erik: „Wie bekommen wir die Kuh denn nun vom Eis? Was können wir als Nächstes tun?“

Lukas: „Ich würde mich gerne mal mit Christian, Julia, Jörg und Adrian vor einen Rechner setzen und die Probleme richtig verstehen. Ohne dass wir uns gegenseitig die Schuld in die Schuhe schieben …“

Abb. 1: Die Entwickler aus den verschiedenen Teams schieben sich gegenseitig die Schuld in die Schuhe – das sollte nicht so sein

Die Kommunikationsbeziehungen beachten

Für Erik ist es schwer nachzuvollziehen, warum sein Produkt in der Entwicklung nicht vorankommt. Er hat die maßgeblichen Personen aus allen Entwicklerteams zusammengerufen und es stellt sich heraus, dass die Software zwischen den einzelnen Teams Ping-Pong spielt. Zudem scheint sich keines der Teams für den Produkterfolg verantwortlich zu fühlen, sondern sieht nur die jeweiligen technischen Komponenten, die es zu implementieren hat. Damit Erik seinem Kunden ein funktionsfähiges Produkt liefern kann, ist er aber auf alle drei Entwicklerteams angewiesen. Keines der Teams kann für sich alleine eine Produktversion bauen – das aus Scrum bekannte Potentially Shippable Product Increment. Wenn in Lukas’ und Christians Team ein Service eine gewisse Reife erreicht hat, geben sie ihn für das Frontend- und das App-Team frei. Die beiden Teams versuchen in einer zweiwöchigen Iteration, den Service zu integrieren und geben danach die gewonnenen Erkenntnisse an Lukas und Christian zurück.

Die beobachteten Probleme und die schwierige Kommunikation haben also vermutlich irgendwie mit den Übergaben zwischen den einzelnen Teams zu tun. Aber warum hat man überhaupt Teams eingeführt und arbeitet nicht in einer großen Gruppe zusammen?

DevOps Docker Camp

Teilnehmer lernen die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Schritt für Schritt bauen sie eine eigene Infrastruktur für und mit Docker auf.

Alle Termine des DevOps Docker Camps 2018 in der Übersicht

München: 19. – 21. Februar 2018
Berlin: 14. – 16. März 2018

Wenn Organisationen eine gewisse Größe erreichen, fängt man an, sie in kleinere Einheiten zu zerlegen. Mit jedem weiteren Mitglied der Organisation würden sonst die Kommunikationsbeziehungen rapide zunehmen. Die Zerlegung erfolgt mit dem Ziel, die Kommunikationsbeziehungen sinnvoll zu reduzieren. Das hat im beschriebenen Beispiel offensichtlich nicht funktioniert. Die Kommunikation ist sogar schwieriger geworden.

Jurgen Appelo schlägt in „Management 3.0“ [1] vor, dass man sich bei der Strukturierung von Organisationen von den Kommunikationsbeziehungen leiten lassen soll. Auch das agile Manifest räumt den Individuen und ihren Interaktionen einen hohen Stellenwert ein: „Individuals and interactions over processes and tools.“ Appelo schreibt weiter, dass sich aus einer sinnvollen Struktur eine bessere Kommunikation ergibt. Die Mitarbeiter mit den häufigsten Kommunikationsbeziehungen bilden zusammen ein Team. Dabei sind zwei Ausprägungen möglich: fuktionale und cross-funktionale Teams. Bei funktionalen Teams haben alle Mitglieder dieselben oder ähnliche Aufgaben. Bei cross-funktionalen arbeiten alle Mitglieder am selben Geschäftsziel oder Produkt.

Cross-funktionale Teams schlagen funktionale

Die Teams, mit denen Erik es zu tun hat, wurden als funktionale Teams strukturiert. Das hat offensichtlich nicht zur Entwicklung seines Produkts gepasst. Ein cross-funktionales Team wäre hier besser geeignet. Appelo vergleicht cross-funktionale Teams mit Musikbands: Eine Band hat alle Spezialisierungen an Bord, um ein Konzert zu spielen. Umgekehrt würde niemand auf die Idee kommen, jeweils eine Band aus Sängern, eine aus Gitarristen und eine aus Schlagzeugern zu bilden.

Durch die vielen Übergaben und langwierigen Feedbackschleifen hat sich in Eriks Fall die Produktentwicklung bereits so verzögert, dass der mit dem Kunden abgestimmte Releasetermin in Gefahr ist. In einem cross-funktionalen Team entfallen all diese Übergaben [2]. Im Buch „The Phoenix Project“ [3] wird dieses Problem eindrucksvoll dargestellt: Durch die sich aufsummierenden Wartezeiten dauert eine Tätigkeit, die eine Bearbeitungszeit von wenigen Minuten hat, insgesamt mehr als 63 Stunden.

Die erste Folge der DevOps Stories beschrieb den Zusammenhang zwischen Informationen und guten Entscheidungen. Die beiden Backend-Entwickler haben nicht die passenden Informationen, um ihre Services sinnvoll implementieren zu können. Bleibt es bei den funktionalen Teams, müssen die Web- und die App-Entwickler ihnen immer alle Informationen für eine sinnvolle Entscheidung bereitstellen. Das ist sehr aufwendig, weil Julia und Jörg gar nicht wissen, welche Informationen Lukas und Christian brauchen. In einem cross-funktionalen Team können sich die einzelnen Spezialisierungen in sehr kleinen Häppchen zielgerichtet abstimmen.

Lesen Sie auch: DevOps mal ganz praktisch: Der Vorteil autonom arbeitender Teams liegt darin, dass…

Durch die Trennung in funktionale Teams haben die einzelnen Entwickler nur wenig Einblick, welchen Einfluss ihr Handeln auf die Arbeit der anderen hat. In der Diskussion kommen gerade die schmerzhaftesten Punkte zur Sprache. Außerdem ist es den einzelnen Personen nahezu unmöglich, etwas außerhalb ihrer Spezialisierung zu lernen. In cross-funktionalen Teams sehen die Mitglieder relativ direkt die Auswirkung ihres Handelns und sind ständig mit der Arbeit der anderen Teammitglieder konfrontiert, was automatisch dazu führt, dass z. B. ein Backend-Entwickler ein grundlegendes Verständnis für App-Development entwickelt. Außerdem hat außer Erik niemand den Kunden der Musikplattform im Fokus, sondern nur seine eigenen Implementierungs-Tasks. Aber um einen aktuellen Stand zu bekommen, muss Erik drei Entwicklungsteams einladen, die zum Teil widersprüchliche Aussagen machen. Mit einem cross-funktional Produktteam hätte Erik eine zentrale Anlaufstelle.

Lukas und seine Kollegen haben durch die gemeinsame Analyse ähnliche Erkenntnisse gewonnen. Sie haben dem Management vorgeschlagen, alle relevanten Disziplinen in einem cross-funktionalen Produktteam zusammenzufassen und durften diesen Vorschlag auch umsetzen. Natürlich bietet ein solches Team auch neue Herausforderungen. Darüber berichten wir in einer zukünftigen Folge der DevOps Stories.

DevOps Stories

„Agilität“, „Management 3.0“, „New Work“ oder „DevOps“ – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Und wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen berichtet Konstantin Diener (CTO von cosee) in dieser Kolumne. Doch wie lassen sich Erfahrungen zu Veränderungen der Unternehmenskultur transportieren? Er ist der Meinung, so wie die Menschheit seit Jahrtausenden Erfahrungen transportiert: durch Geschichten, den DevOps Stories.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.