Das DASA DevOps-Prinzip 4: Cross-Functional Autonomous Teams
Mit DevOps wird der Wandel in der Unternehmenskultur hin zu einer höheren Kundenorientierung, besseren Produktqualität und schnelleren, innovativeren Arbeitsprozessen adressiert. Eng gekoppelt hiermit ist der Aufbau cross-funktionaler, autonomer Teams. Ein solches Team ist im Stande, gleichermaßen in der Softwareentwicklung und im IT-Betrieb möglichst interdisziplinär zu arbeiten, d. h. jedes Teammitglied unterstützt bestmöglich bei allen Problemlösungen. Die Teammitglieder besitzen weitgefächerte Kenntnisse und Fähigkeiten, um ihre Aufgaben eigenständig lösen zu können. Gleichzeitig müssen diese vertikal aufgestellten, voll verantwortlichen Teams über den kompletten Lebenszyklus mit maximaler Unabhängigkeit agieren können.
Haben Sie die Einführung in das DASA DevOps-Kompetenzmodell gelesen?
Das DASA DevOps-Prinzip 4: Cross-Functional Autonomous Teams
In product organizations with vertical, fully responsible teams, these teams need to be entirely independent throughout the whole lifecycle. That requires a balanced set of skills and also highlights the need for team members with T-shaped all-round profiles instead of old-school IT specialists who are only knowledgeable or skilled in for example testing, requirements analysis or coding. These teams become a hotbed of personal development and growth. [1]
An dieser Stelle wird schon deutlich, dass sich die gewünschten Eigenschaften des Teams – cross-funktional und autonom – im Spannungsverhältnis zwischen Mitarbeiter, Organisation und Team wiederfinden (s. Abb. 1).
Evolution statt Revolution
Agile Methoden vereinten in der IT bisher unterschiedliche Projektrollen wie Entwickler, Tester oder Qualitätsmanager, die sich auf die Erstellung von Software konzentrieren; mit DevOps beinhaltet dieser Prozess nun aber obendrein den Softwarebetrieb und das Tagesgeschäft wie etwa mit dem Operations Engineer. Und genau hierfür werden cross-funktionale Teams benötigt. Schließlich ist DevOps die konsequente Fortführung der Agilität in Unternehmen. DevOps ist also die de facto logische Weiterentwicklung agiler Prozesse im Verständnis der Definition of Done, die ja eigentlich erst erreicht sein kann, wenn Softwareänderungen ohne Fehler in Produktion übernommen wurden.
In vielen Unternehmen wird die Teamausrichtung nach DevOps-Prinzipien nun allerdings gleichbedeutend mit der Transition bestehender IT-Organisationen sein. Sowohl Rollen und Verantwortlichkeiten als auch Anforderungsprofile der Mitarbeiter ändern sich. Dies muss nicht zwangsläufig sofort mit einer Änderung der bestehenden Struktur verbunden sein. Unternehmensphilosophie, gruppendynamische Prozesse und Personalentwicklung werden sich aber evolutionär anpassen müssen. Der Fokus sollte darauf liegen, wie Teams zusammengesetzt werden und wie diese optimal zusammenarbeiten können. Hierbei gilt weiterhin: Wir brauchen keine Helden, die sich als Einzelkämpfer auszeichnen, sondern Hochleistungsteams, die in konzentrierter Zusammenarbeit erfolgreich sind.
Kulturwandel in IT-Organisationen
Umgestaltungen in klassischen IT-Organisationen sind oft schwierig und die Zielvorstellung von DevOps wird in großen, traditionell geprägten IT-Organisationen schwer zu erreichen sein. Zum Start reicht allerdings die Bereitschaft im Management, einige Ideen hinter DevOps ausprobieren zu wollen. So ist es auch nicht notwendig, vorhandene Strukturen unverzüglich für die Verbesserung abteilungsübergreifender Zusammenarbeit zu ändern. Es sollte sich ein stetiger Übergang von hierarchischem Top-Down-Management (command & control) zu autonomen Netzwerken entwickeln. Die traditionelle Hierarchie wird dabei langsam durch autonome, vernetzte Teams ersetzt, um das Unternehmen noch besser auf sich ständig ändernde äußere Einflüsse und Kundenbedürfnisse einstellen zu können.
Für den Aufbau cross-funktionaler, autonomer Teams gibt es je nach Organisationsstruktur verschiedene Optionen. Cross-funktionale Teams fügen sich am ehesten in Matrix-Organisationen mit vermehrter Projektarbeit ein. Hier kann zu Beginn versuchsweise ein kleines Team – zusammengestellt aus den vorhandenen Spezialisten der Abteilungen Entwicklung und Betrieb – die Aufgabe erhalten, ein Software-Produkt ganzheitlich zu betreuen. Die Gesamtheit eines Teams aus Mitarbeitern mit Schwerpunkten aus unterschiedlichen Fachrichtungen kann genauso sämtliche notwendige Fähigkeiten abdecken und damit ein interdisziplinär aufgestelltes Team erzeugen.
Sollte es sich um eine klassische Aufbauorganisation mit klaren Abteilungsgrenzen zwischen Entwicklung, Betrieb, Support und Wartung handeln, können in einem ersten Schritt innerhalb zu definierender Organisationsgrenzen auch Mitarbeiter ausgeliehen und versuchsweise mit neuen Projektrollen versehen werden. Hierbei gilt es, bestehende Teamdynamiken zu beachten, vor allem, wenn Teams in Teilen neu zusammengesetzt werden. Daraus folgt die Herausforderung, diese neue Teamzusammensetzung (wenn möglich mit internen Mitarbeitern) stabil zu halten und sie trotz der disziplinarischen Führungsverantwortung in der Abteilungsorganisation zu manifestieren. Eventuell kann nach erfolgreicher Pilotprojektphase, die Umorganisation entsprechender Stellen zur umfassenden Betreuung bestimmter Softwareprodukte angedacht und der Kulturwandel behutsam angegangen werden. Ein organisatorisches Thema wird dann sicherlich auch die flexible Ermöglichung interner Arbeitsplatzwechsel und die wandlungsfähige Ausgestaltung von Arbeitsverträgen.
Auf dem Weg zum Produktteam
Denn langfristig heißt es: weg von der Fokussierung auf Projekte und Spezialisten, hin zur Fokussierung auf Produkte und Fachwissen kombiniert mit Breitenwissen. Dies mag vielleicht auf den ersten Blick nicht immer am effizientesten erscheinen, jedoch werden auf der anderen Seite unnütze Abstimmungsprozesse entfernt und somit sehr wohl die Verschwendung von Arbeitszeit vermieden. Letztendlich soll es ein oder mehrere Produktteams geben, die sowohl die IT-Produktentwicklung als auch den IT-Betrieb abdecken können. Bei mehreren Produkten auf technisch einheitlicher Basis kann es zur weiteren Skalierung noch ein oder mehrere zusätzliche Infrastrukturteams geben, die flexibel und eng mit den Produktteams interagieren. Aber selbst in diesem Fall gibt es nur noch maximal eine Schnittstelle. Wartezeiten und Übergabezeiten, wie es zwischen Abteilungen üblich war, werden minimiert. Bei dieser Gelegenheit sei auch der Einsatz von leichtgewichtigen, fachlich zugeschnittenen Microservices oder Self-Contained Systems erwähnt. Deren Architekturen ähneln nämlich den Kommunikationsbeziehungen innerhalb cross-funktionaler Teams. Falls hierzu genügend technische Expertise vorhanden ist, können diese Architekturmuster ideal von Produktteams betreut werden.
Zweifellos sind aber Strategie und Unternehmensziele weiterhin vom Management vorzugeben. Die gesamte Verantwortung über den kompletten Lebenszyklus ist jedoch delegiert. Zu diesem Zweck müssen Freiräume eingeräumt, Hierarchien aufgebrochen und für Problemlösungen alle verfügbaren Informationen neben dem verfügbaren Expertenwissen innerhalb einer Organisation miteinbezogen werden. Die Zielerreichung verantwortet dann das Team, notwendige Entscheidungen werden teamintern getroffen. Und dass die richtigen Entscheidungen getroffen werden, darauf muss das Management vertrauen können und wollen. Hilfreich dabei kann der Einsatz von Visualisierungstechniken mit geeigneten Kennzahlen sein, was nicht nur für gegenseitiges Vertrauen zwischen Management und Team sorgt, sondern außerdem das Selbstmanagement im Team unterstützt. Hier sei insbesondere Kanban empfohlen, das darüber hinaus als Change-Management-Methode fungiert. Weiterhin werden vorab abgestimmte Ziele zu Terminen, Budget und Qualitätsanforderungen benötigt.
Im Hinblick darauf kann die Rolle eines Koordinators angedacht werden, der mit der Kompetenz ausgestattet ist, im Einklang zur agilen Selbstorganisation, unterstützende Aufgaben zum Abgleich mit dem Management und zur Abstimmung mit dem Kunden für das Team auszuüben. Dem Management sollte aber bewusst sein, dass es gerade bei der initialen Priorisierung oder der Portfolio-Planung zu Konflikten kommen kann, wenn Mitarbeiter in cross-funktionalen Teams arbeiten, deren Tätigkeiten immer höchste Priorität genießen. Das bedeutet nämlich, dass andere Aufgaben liegen bleiben oder nicht so effizient abgearbeitet werden.
Teamorganisation und -steuerung
Wie sieht also der typische Arbeitsalltag aus, wenn ein DevOps-Team ermächtigt wird, die Verantwortung für das Endprodukt zu übernehmen? Um dieses Unterfangen leisten zu können, verfügt das Team über sämtliche notwendigen Ressourcen und Kompetenzen. Es kennt die Bedürfnisse und Anforderungen des Kunden, stimmt diese selbständig ab und konzentriert sich vollkommen auf das Produkt. Das Team, welches bestenfalls aus einem Mix aus Generalisten und Spezialisten besteht, kann den kompletten Software-Lebenszyklus betreuen und dabei auf unvorhergesehene Ereignisse flexibel reagieren. Es trifft die Entscheidung über einzusetzende Werkzeuge und Implementationsdetails für eine höhere IT-Performance und schnellere Durchlaufzeiten. Ohne auf andere Teams warten zu müssen, ist das Team bevollmächtigt, seine Produkte zu verändern. Das ewige Hin und Her der Abstimmung mit anderen Teams oder Abteilungen entfällt endgültig. Zusammen wird definiert, welche Features benötigt werden, wie implementiert wird, wie getestet, was das Release am besten in einer Timebox enthält, wie dieses bis in die Produktion deployed und wie Support geleistet wird. Dazu gibt das Team das technische Design mittels eigens erstellten Architekturrichtlinien vor und schätzt mit eigens festgelegten Methoden Aufwand sowie Komplexität.
Steuerungsmechanismen organisationsindividuell einsetzen
Arbeitszuweisungen an jedes einzelne Teammitglied sind nicht mehr notwendig. Das Team entscheidet, wie der Arbeitsfluss effizient gestaltet wird. Wichtig ist, dass das Team auf Augenhöhe kommunizieren kann und eine kontinuierliche Abstimmung auf Basis identischer Informationsbasis und Hintergrundwissen erfolgt. Zwar herrscht das Selbstverständnis, sich bei freier Kapazität neue Aufgaben zu nehmen, allerdings geht es auch in diesen DevOps-Teams nicht vollständig ohne interne Steuerung und Kontrolle. Mit agilen oder schlanken Methoden mitsamt Vorgehensmodellen – wie z. B. Kanban und Scrum – kann die gewonnene Autonomie mit Hilfe zu definierender Rollen selbst organisiert sowie die Abläufe mit regelmäßig wiederkehrenden Terminen und Ereignissen gesteuert werden. Im Rahmen regelmäßiger Abstimmungsrunden kann sich beispielsweise durch die Anwesenheit aller Teammitglieder vor einer Planungswand (Kanban-Board) in einem Raum mühelos und ohne viel Planungsaufwand ausgetauscht werden. So wird der Prozess im Team zur schnellen und transparenten Entscheidungsfindung unterstützt und der Ideenaustausch sowie Informationsfluss verbessert. Ergebnisse sind offensichtlich und nachvollziehbar.
Die zentrale Mission jedes Einzelnen ist das Versprechen, die Kundenbedürfnisse nicht aus den Augen zu verlieren.
Auch für die teaminterne Arbeitssynchronisation gilt: Besonders der Einsatz von Visualisierungstechniken sorgt für Transparenz, unterstützt die Moderation (evtl. durch das Teammitglied mit der Rolle des Koordinators) und kann darüber hinaus den Arbeitsfortschritt zeigen. Des Weiteren können Termine verwendet werden, um den Arbeitsfluss zu analysieren und Probleme darin zu diskutieren. Agile Vorgehensweisen beruhen ja auf empirischer Prozesssteuerung, wodurch das eigene Verhalten durch Beobachtungen und Erfahrungen laufend angepasst werden soll. Feedback kann flexibel angebracht werden. Letztlich sind technische und organisatorische Optimierungen in Richtung DevOps nur möglich, wenn bevor und nachdem Maßnahmen durchgeführt wurden, entsprechend ein positiver oder aber negativer Effekt gemessen wird.
Anforderungsprofile für Mitarbeiter
Die zentrale Mission jedes Einzelnen ist das Versprechen, die Kundenbedürfnisse nicht aus den Augen zu verlieren und alles für die Zielerreichung zu tun. Jeder einzelne muss permanent dazu lernen und das eigene Können in vielleicht bisher fremden IT-Aufgabengebieten vergrößern. Denn gewissermaßen kann die Verantwortung für das Produkt erst aufgrund des gesammelten Wissens erfolgen. Infolge des Wissensaustauschs über regelmäßig einberufene Besprechungen erlangen alle früher oder später Kenntnisse über bisher fachfremde Bereiche. Dabei ergänzen sich die Mitarbeiter durch unterschiedliche Fähigkeiten und Erfahrung gegenseitig.
Bestenfalls sollen Teammitglieder als T-Shaped Professional zahlreiche Kenntnisse aus verschiedensten IT-Schwerpunkten besitzen und anwenden können. So reicht die ausschließliche Spezialisierung als z. B. Softwaretester, Entwickler oder Business-Analyst häufig nicht mehr aus. Der Aufbau von Teams mit Teammitgliedern aus ursprünglich verschieden Disziplinen bündelt zunächst organisatorische Erfahrung und sorgt für gegenseitiges Vertrauen und Respekt. Wenn dabei entsprechende übergreifende Kenntnisse im Vorfeld nicht vorhanden waren, wird ein grundlegendes Verständnis für andere Bereiche aufgebaut. Neue Erkenntnisse über das Produkt sammeln Entwickler beispielsweise, wenn diese den direkten Kundensupport übernehmen und Kundenanfragen bearbeiten. Eine Aufgabe wird also von jemand übernommen werden, der sich vielleicht nur am Rande damit auskennt. Gerade bei Engpässen können so Aufwandspitzen einzelner Mitarbeiter abgedeckt und Mitarbeiter flexibler eingesetzt werden. Zugleich ist die Zusammenarbeit von Softwareentwickler mit Mitarbeitern der Betriebsabteilungen (oder Mitarbeitern mit diesen Schwerpunkten) elementar für Aufbau und Wartung einer kontinuierlichen Lieferpipeline. Das Lernen und Experimentieren in diesem Bereich reduziert die Durchlaufzeiten weiter, sorgt für einen stabilen Prozess und kontinuierliche Lieferungen, die irgendwann sogar die iterative Entwicklung obsolet machen kann. An dieser Stelle unterstützt das DASA-Ausbildungskonzept.
Agiles Mindset
Für Neueinstellungen sind neben Fachkompetenz sowohl Kommunikations- und Teamfähigkeit, Wissen über Geschäftsprozesse und Organisationsstrukturen als auch Branchenkenntnis relevant. In cross-funktionale, autonome Teams passen vornehmlich engagierte, unternehmerisch denkende Mitarbeiter. Die Teammitglieder sollen nämlich in der Lage ist, die Gesamtheit eines Problems zu erkennen und mit unterschiedlichen Blickwinkeln innovative Lösungsansätze liefern zu können. Sofern ein Team aus langjährig erfahrenen Mitarbeitern gebildet wird und es sich dabei hauptsächlich um Spezialisten einzelner Disziplinen handelt, ist die Vielseitigkeit im Team klar zu fördern und diese Mitarbeiter in zusätzlichen Aufgabengebieten individuell zu schulen. Als bisherige Spezialisten müssen diese Mitarbeiter nun ebenso die Bereitschaft haben, ihr Expertenwissen mit den Kollegen zu teilen und gegebenenfalls Breitenwissen über andere Fachgebiete aufbauen zu wollen. Für die Förderung des Wissensaustauschs könnte z. B. für den Einsatz neuer Technologien oder während der Implementierung von Neuanforderungen Pair-Programming angewendet werden. Des Weiteren ist es zunächst einmal notwendig, die zeitgleiche Zusammenarbeit statt der bislang oftmals nicht abgestimmten, starr fortlaufenden Arbeit zu verinnerlichen. Jeder sieht direkt die Auswirkung einer getroffenen Entscheidung im Team bzw. nach Übergabe an ein Teammitglied.
Es ist keine Identifikation aufgrund von Titeln, sondern eine mit dem Team und dem Produkt gewünscht.
Generell gilt zu beachten, dass Mitarbeiter häufig kein festgelegtes Tätigkeitsprofil mehr, sondern eine oder sogar – bei zusätzlich angelerntem Fachwissen – mehrere Rollen erfüllen. Je nachdem, was gerade relevant für die tägliche Arbeit ist. Dies bedeutet auf der einen Seite mehr individuelle Freiheit für den Arbeitnehmer, kann aber auch Schwierigkeiten nach sich ziehen: wer Eigeninitiative zeigt, kann Fehlentscheidungen treffen. Eine offene Fehlerkultur im Unternehmen wird notwendig.
Die gewonnene Autonomie der Teams bedeutet ferner gehörige Verantwortung für jedes einzelne Teammitglied. Entscheidungen zu treffen und zu verantworten, kann Angst machen. Weiterhin muss das Geltungsbedürfnis des Einzelnen nach beruflichem Status zwangsläufig in den Hintergrund treten, es ist keine Identifikation aufgrund von Titeln, sondern eine mit dem Team und dem Produkt gewünscht. Gemeinhin sollten die notwendigen Rollenzuweisungen dafür im Team getroffen werden. Daneben machen unterschiedliche und möglicherweise wechselnde Rollen das Thema einer transparenten Gehaltsfindung nicht einfacher.
Sollte das Management eine Ausrichtung nach DevOps vorgeben, muss schließlich der Mitarbeiter entscheiden, ob er in einer agilen DevOps-Kultur arbeiten möchte und die Vorteile dieser modernen Arbeitswelt für ihn überwiegen oder ob er sich in dieser Organisation nicht wiederfindet.
Fazit
Cross-funktionale, autonome Teams sind in der Lage, Innovation ganzheitlich zu denken und gleichzeitig das komplette Aufgabenspektrum über den gesamten Produktlebenszyklus eigenverantwortlich und in effizienter Zusammenarbeit zu erledigen. Voraussetzungen sind sowohl der Kulturwandel in IT-Organisationen, eine schlanke Teamorganisation und -steuerung sowie das agile Mindset und die vielseitigen Fähigkeiten der Mitarbeiter. So wird das Team gemeinsam zum Unternehmenserfolg beitragen.
Publikationen
- IT-Service Management mit FitSM
- Perspektivwechsel im IT Service Management: Erfolgsgeschichten oder - Dierk Söllner, Peter Bergmann, itSMF
