Suche
Die Vorteile Crossfunktionale Teams

Agiles Projektmanagement: Mehr Agilität durch Agilität

Prof. Dr. Tobias Brückmann

©Shutterstock / Panchenko Vladimir

Das Zeitalter der Digitalisierung schafft für alle Unternehmen neue Möglichkeiten, aber bringt auch Notwendigkeiten mit sich. Zwei dieser Notwendigkeiten sind die schnelle Handlungsfähigkeit und die stetige Innovationsfähigkeit. Insbesondere IT-Unternehmen und Abteilungen müssen sich diesen Herausforderungen stellen. Als Schlüssel zum Erfolg kann die Agilität genannt werden. Im Zuge der Umstrukturierung klassischer Arbeitsweisen haben sich daher agile Techniken und Methoden etabliert. Die Bildung von crossfunktionalen Teams ist eine dieser Methoden.

Bei crossfunktionalen Teams werden die Teammitglieder so gewählt, dass das Team als Ganzes alle nötigen Kompetenzen besitzt, um ein Projekt vom ersten Konzept bis zum letztendlichen Deployment zu realisieren. Die Vorteile solcher Teams liegen auf der Hand: Alle benötigten Feedbacks und Zuarbeiten lassen sich auf möglichst kurzen Wegen einholen und umsetzen. Es ist keine Koordinierung mit anderen Teams nötig. Das führt zu deutlich kürzeren Produktionszyklen. Ebenso können entstehende Probleme viel früher erkannt und viel schneller gelöst werden. Doch es ist Vorsicht geboten: Durch die Bildung eines crossfunktionalen Teams, das aus Mitgliedern verschiedener Disziplinen besteht, wird nicht automatisch Agilität erreicht. Um durch crossfunktionale Teams echte Agilität zu erreichen, müssen die Teammitglieder einerseits bereits agile Techniken beherrschen, andererseits muss die Unternehmenskultur so beschaffen sein – oder dahingehend angepasst werden –, dass sie agilitätsfreundlich ist. Somit schaffen derartige Teams keine Agilität aus dem Nichts, sondern multiplizieren bereits bestehende Agilität.

Ein crossfunktionales Team ist ein selbstorganisiertes Team, das die Verantwortung für Produktinkremente von der Idee bis zum Deployment hat. Mit anderen Worten: Es sind möglichst alle Rollen für die erfolgreiche Projektrealisierung vorhanden. Das bedeutet, dass jedes Teammitglied eine eigene Spezialisierung mitbringt und entsprechend individualspezifisches Fachwissen besitzt. Jeder ist Experte in der eigenen Rolle. Und alle Rollen stehen in enger und direkter Kommunikation miteinander. Gerade in der agilen Softwareentwicklung ist diese Vorgehensweise zunächst nichts Neues. Die Rollenverteilung und die Einbindung möglichst vieler Rollen in ein agiles Team sind essenziell für kurze Entwicklungszyklen von Produkten. Wenn beispielsweise Architekt, Entwickler, Tester, Dokumentationsexperte und Datenbankexperte im selben Team sind, können Produktinkremente schnellstmöglich geliefert werden.

W-JAX 2018 Java-Dossier für Software-Architekten

Kostenlos: 40+ Seiten Java-Wissen von Experten

Sie finden Artikel zu Enterprise Java, Software-Architektur, Agilität, Java 11, Deep Learning und Docker von Experten wie Kai Tödter (Siemens), Arne Limburg (Open Knowledge), Manfred Steyer (SOFTWAREarchitekt.at) und vielen weiteren.

Die Vorteile crossfunktionaler Teams

Crossfunktionale Teams sind selbstgesteuert. Durch ihren weitestgehend autonom gestalteten Handlungsrahmen müssen sie sich nicht mit anderen Teams abstimmen und sind nicht auf Zulieferungen durch andere Teams angewiesen. Im Hinblick auf Prozessfortschritt ist das eine große Stärke, denn dadurch wird der Lieferungszyklus von Produktinkrementen signifikant verkürzt. Außerdem arbeiten alle Teammitglieder auf ein gemeinsames Ziel hin, nämlich die Lieferung des nächsten Produktinkrements in der Pipeline. Das bedeutet also, dass die Teammitglieder ihre Zuständigkeit nicht ausschließlich durch ihre Rolle definieren. Die Wahrscheinlichkeit, dass bei Problemen solche Gedanken aufkommen wie „Ich bin nur für die Architektur zuständig, sollen die Entwickler doch ihre Codes sauber schreiben“ bleibt eher gering. Denn alle Beteiligten ziehen sprichwörtlich an einem Strang. Das wiederum erhöht die Effizienz des Teams und somit die Erfolgsquote des Projekts deutlich.

Lesen Sie auch: Wenn agile Gehversuche scheitern

Durch regelmäßige Meetings sowie transparent gehaltenen Prozessfortschritt sind alle in den Produktionszyklus involvierten Personen stets über den Gesamtstand des Projekts informiert und haben dadurch immer das Gesamtbild vor Augen. Dadurch wird einerseits verhindert, dass bestimmte Phasen unverhältnismäßig viel Zeit in Anspruch nehmen, weil die Gefahr rechtzeitig von den restlichen Teammitgliedern erkannt wird. Andererseits können die einzelnen Teammitglieder gemäß aktuellen Gegebenheiten und Bedarfen entsprechend flexibel priorisieren, sodass der Gesamtfortschritt erst gar nicht ins Stocken gerät.

Auch die Problemlösung läuft in crossfunktionalen Teams effizient ab. Dadurch, dass die Teammitglieder in enger Kommunikation stehen und sich unmittelbar abstimmen, können Widerstände und entstehende Probleme sowohl viel schneller erkannt als auch viel schneller behoben werden.

Erfolgsfaktoren für crossfunktionale Teams

Ein crossfunktionales Team sollte so zusammengestellt werden, dass alle benötigten Kompetenzen vorhanden sind, um ein Projekt erfolgreich zu realisieren – vom ersten bis zum letzten Schritt. Dabei sollte jedoch nicht ausschließlich darauf geachtet werden, dass alle benötigten Rollen vorhanden sind. Auch die Kompetenzbreite der einzelnen Teammitglieder sollte im Idealfall berücksichtigt werden. Je mehr Aufgaben die Teammitglieder übernehmen können – unabhängig von ihrer eigenen Rolle –, desto agiler können sie arbeiten. Ein hilfreiches Analyseverfahren hierfür kann die Team-Skill-Matrix sein. Eigentlich kommt diese innerhalb eines bestehenden Teams zum Einsatz und kategorisiert die individuellen Fähigkeiten jedes einzelnen Teammitglieds nach dem Iststand. Doch wenn die Matrix in Bezug auf potenzielle Teammitglieder bereits im Vorfeld zum Einsatz kommt, lässt sich ein kompetenztechnisch harmonischeres Team zusammenstellen. Die Team-Skill-Matrix funktioniert im Kern folgendermaßen. Die für das Projekt relevanten Kompetenzen der potenziellen Teammitglieder werden in Bezug auf die zu erwartenden Aufgabenbereiche entsprechend des vorliegenden Reifegrads kategorisiert.

Die Kategorien können sein: „keine Kenntnisse“, „Grundkenntnisse vorhanden“, „kann einfache Aufgaben selbstständig bewältigen“, „kann alle Aufgaben selbstständig bewältigen“, „kann andere unterrichten“. Bei der Zusammenstellung des Teams wäre nun darauf zu achten, dass möglichst in jedem Aufgabenbereich mindestens eine Person den höchsten Reifegrad vorweisen kann und somit den anderen Teammitglieder in genau diesem Bereich weiterhelfen könnte. Ebenso wäre darauf zu achten, dass so viele Teammitglieder wie möglich in so vielen Aufgabenbereichen wie möglich zumindest den Reifegrad „kann einfache Aufgaben selbstständig bewältigen“ vorweisen können.

Mehr zum Thema: Die sieben Prinzipien einer Community of Practice: Wie organisiert man selbstorganisierte Teams?

Ein crossfunktionales Team soll in der Lage sein, Produktinkremente schnellstmöglich liefern zu können. Das Stichwort lautet also Effizienz. Was aber, wenn z. B. krankheitsbedingt ein Teammitglied kurzfristig und kurzzeitig ausfällt und das restliche Team nicht weiterkommt, weil die entsprechende Zulieferung fehlt? Dann wäre die Grundidee eines agilen, crossfunktionales Teams – überspitzt formuliert – ad absurdum geführt. Um echte Effizienz zu gewährleisten, sollten die Teammitglieder neben ihrem individualspezifischen Fachwissen idealerweise ein breites Kompetenzspektrum in Bezug auf die anderen Rollen aufbauen. Gemeint ist die T-förmige Kompetenzausprägung, auch T-shaped Skills genannt. Die vertikale Linie des Buchstaben steht für das individualspezifische Fachwissen, die horizontale Linie für das breite Kompetenzspektrum. Auf diese Weise lassen sich kurzzeitige Ausfälle problemlos ausgleichen. Der Aufbau eines breiten Kompetenzspektrums wiederum kann gefördert werden, wenn innerhalb des Teams die notwendige Lernkultur vorherrscht. Das geht natürlich nicht innerhalb weniger Tage, sondern ist vielmehr ein Langzeitprozess, der sogar über Projekte und Teams hinweg laufen muss. Zwar lernen die Teammitglieder während eines Projekts unweigerlich die Arbeit der anderen Mitglieder kennen und erhalten beispielsweise im Rahmen von Daily-Stand-up-Meetings Einblicke in deren Arbeitsweise. Doch der Wissenstransfer über Rollengrenzen hinweg muss aktiv stattfinden, damit die Teammitglieder ein breites Kompetenzspektrum entwickeln können. Auch hier kann die Team-Skill-Matrix zum Einsatz kommen, um sowohl den expliziten Weiterbildungsbedarf der einzelnen Teammitglieder als auch die entsprechenden Lehrer zu identifizieren. Diese gegenseitige Weiterbildung muss aktiv und systematisch durchgeführt werden. Der Gedanke, dass dieser Prozess eine gewisse Zeit in Anspruch nimmt, die an anderer Stelle wieder fehlt, darf nicht abschrecken. Denn diese Zeit ist gewiss mittel- bis langfristig eine mehr als gut investierte Ressource.

DevOps: die nächste Evolutionsstufe der agilen Softwareentwicklung

Auf Effizienz getrimmte, agile Softwareentwicklung nutzt wenig, wenn die in kurzen Zyklen entwickelten und gelieferten Inkremente spätestens beim Einsatz Probleme verursachen. Die enge Zusammenarbeit zwischen Entwicklung und IT-Betrieb ist somit ein logischer Schluss, wenn man das volle Potenzial der Agilität ausschöpfen möchte: DevOps also. Dabei ergeben sich Vorteile auf gleich mehreren Ebenen.

Die erste Ebene ist die Effizienzebene. Eine ausgeprägte Kommunikation zwischen den Teammitgliedern ist ein entscheidendes Effizienzmerkmal. Denn die am Softwareprozess beteiligten Rollen werden näher aneinandergerückt und können zudem weitgehend untereinander abgestimmt und selbstorganisiert arbeiten. Auch Probleme lassen sich schneller und direkter und somit besser lösen. Außerdem wird mehr Effizienz bei der Softwareentwicklung, beim Testen und beim Deployment ermöglicht. Die Automatisierung von Prozessen, insbesondere von Tests, mithilfe entsprechender Tools, die manuell durchgeführt werden müssten, ermöglicht eine Continuous Delivery.

Auf wirtschaftlicher Ebene bedeutet der verkürzte Entwicklungszyklus, dass Unternehmen in die Lage versetzt werden, langfristig konkurrenzfähig zu bleiben. Im Rahmen des Continuous Delivery ständig neue Funktionalitäten und zuverlässige Produkte in effizienten Entwicklungsprozessen gewährleisten zu können, kann der Unterschied zwischen langfristigem Erfolg und endgültigem Ausscheiden sein. Denn Innovationsfähigkeit und schnelle Handlungsfähigkeit sind unumgängliche und zugleich notwendige Eigenschaften in einer digitalisierten Welt.

Auf kultureller Ebene bietet DevOps die Chance auf produktivere und engagiertere Mitarbeiter. Und wenn etwas nicht klappt, schieben sich Entwickler und Operations nicht gegenseitig die Schuld in die Schuhe. Denn immerhin ziehen sie in enger Zusammenarbeit am selben Strang und verfolgen gemeinsame Ziele. Zudem gibt es bessere Möglichkeiten zur persönlichen Weiterentwicklung durch den Erwerb eines breiten Kompetenzspektrums mithilfe der gegenseitigen Weiterbildung.

DevOps ist mehr als eine Methode

Organisationen – insbesondere traditionelle Unternehmen – müssen zunächst erfolgreich einen Wandel auf kultureller und personaler Ebene durchlaufen, wenn sie DevOps einführen möchten. Es reicht nicht aus, lediglich ein Team aus Entwicklern, Testern und Operations zusammenzustellen. Durch die Einführung von DevOps wird erheblich in das bestehende Gleichgewicht von Organisationsstruktur, Prozessabläufen und Personal eingegriffen.

DevOps darf nicht lediglich als Methode gesehen werden. Gegebenenfalls muss ein Unternehmen bereit dazu sein, sein klassisches Selbstverständnis hinsichtlich der Unternehmenskultur zu verändern. Gefragt sind Freiräume für Experimente sowie der Mut für neue Vorgehensweisen, die sich von etablierten Denk- und Handlungsmustern unterschieden. Das birgt natürlich auch Risiken und genau da ist das Unternehmen als Ganzes gefragt. Scheitern darf in der Organisationskultur nicht als Stigma verstanden werden, sondern als Chance für ein Dazulernen. Führungskräfte, aber auch die Mitarbeiter, dürfen keine Angst vor neuen Wegen haben, nur weil diese nicht in der Dauerschleife erprobt worden sind. Denn genau dann wäre unter dem Deckmantel der Risikovermeidung in Wahrheit ein Innovationsstillstand erreicht.

DevOps zielt auf Continuous Delivery ab, das durch eine Automatisierung der Entwicklungsprozesse etabliert werden kann. Diese Automatisierung setzt eine hohe Prozessqualität voraus, die wiederum ein hohes fachliches Niveau der Teammitglieder und entsprechend ausgereifte Tools erfordert. Das ist nicht zu verwechseln mit dem Anspruch auf Perfektion. Denn Unternehmen müssen sich mit dem Gedanken anfreunden, dass sie in der Regel auf ein Minimum Viable Product abzielen, anstatt auf jahrelang im Stillen entwickelte Spitzensoftware. Kleine Fehler im Produktbetrieb dürfen nicht als qualitative Makel verstanden werden. Nachträgliche Softwareupdates zur Fehlerbehebung müssen als dazugehöriger Prozess des Continuous Delivery begriffen werden und nicht als Inkompetenz des DevOps-Teams, ebensowenig als Qualitätseinbuße, die durch die Umstellung auf DevOps verursacht wurde.

Lesen Sie auch: Aufwandsschätzung für Entwickler: Warum und wie schätzen sinnvoll ist

Durch DevOps wird ein Handlungsrahmen geschaffen, in dem die Softwareentwicklung von weitestgehend autonomen Teams übernommen wird. Das bedeutet für das vorhandene Führungspersonal, dass Hierarchiegebilde stark abgeflacht oder zumindest merklich verändert werden – und zwar subjektiv zu seinem Nachteil. Das ist zunächst nicht mit einem Zuständigkeitsverlust gleichzusetzen, erfordert jedoch einen gänzlich anderen Führungsstil. Denn immerhin laufen Einzelprozesse und Entscheidungen nicht mehr im Top-Down-Stil, sondern orientieren sich an der Dynamik des Teams oder am Ziel.

Die Mitarbeiter müssen sich von dem Gedanken verabschieden, dass sie Experten in genau einem einzigen Gebiet sind. Mit DevOps soll Effizienz sowohl in der Entwicklung und beim Testen als auch beim Deployment von Software erreicht werden. Das bedeutet, dass die einzelnen Teammitglieder als Team, als Gesamtorganismus, funktionieren müssen. Dazu gehört insbesondere die Fähigkeit, aber auch die Bereitschaft, verschiedene Aufgaben im Entwicklungs- und Deployment-Prozess zu übernehmen, die zunächst außerhalb ihrer Rolle oder Expertise liegen.

MEHR ZUM THEMA:

Die Scrum-Revolution

Geschrieben von
Prof. Dr. Tobias Brückmann
Prof. Dr. Tobias Brückmann
Prof. Dr. Tobias Brückmann ist Gründer und Geschäftsführer der CampusLab GmbH. Als Hochschullehrer und Gründer arbeitet er kontinuierlich an der Professionalisierung und Optimierung von industriellen Softwareprozessen. Zum einen als Trainer und Consultant bei CampusLab, zum anderen als Professor für das Fachgebiet Software Engineering in der Wirtschaftsinformatik an der Internationalen Hochschule Bad Honnef (IUBH).
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: