Regelmäßig bringt die Standish Group ihren CHAOS Report heraus und zeigt in eben jener Regelmäßigkeit auf: durchschnittlich 62% aller IT-Projekte scheitern. (Chaos-Report von 2015)
Die Gründe für das Scheitern von Softwareentwicklungsprojekten sind vielfältig und zum Großteil nicht technischer, sondern organisatorischer Art: Zu hohe Komplexität, unklare Anforderungen, nicht-funktionale Teams, Fokus auf den falschen Dingen oder überhandnehmende Konzernpolitik.
Bereits zum Projektstart können Maßnahmen getroffen werden, um einige dieser Risiken einzudämmen und die Aussicht auf einen Projekterfolg zu erhöhen.
Dieser Artikel wird den Fokus auf ein funktionierendes, erfolgreiches Entwicklungsteam legen und erörtern, welche Stellschrauben Sie drehen können – und von welchen Sie lieber die Finger lassen sollten.
Was macht ein erfolgreiches Team aus?
Software wird selten von Einzelpersonen entwickelt. Im Normalfall sind ein oder mehrere Teams für ein Produkt verantwortlich. Dementsprechend unerlässlich für den Projekterfolg ist es, dass diese Teams als solche funktionieren. In diesem Artikel konzentrieren wir uns auf den Aufbau und die Zusammenarbeit innerhalb eines einzelnen Teams – der ebenso wichtigen Kommunikation zwischen mehreren Teams gebührt ein eigener Artikel.
Soziales Gefüge
Enge Zusammenarbeit, die wiederum auf einem gesunden Arbeitsklima und einem sozialen Miteinander fußt, ist die Grundessenz eines erfolgreichen Teams. Ein solches soziales Miteinander entwickelt sich durch ein gemeinsames menschliches Verständnis aller Teammitglieder füreinander: Wie kommunizieren wir am effektivsten? Wie lösen wir Konflikte konstruktiv? Wie reagieren wir auf unerwartete Herausforderungen? Wie sind Kompetenzen verteilt und wie können wir voneinander lernen?
Ein funktionierendes Team sollte diese Fragen beantworten können. Entsteht dieses soziale Miteinander nicht, können die Konsequenzen Machtkämpfe und wertlose, weil nicht zielgerichtete Diskussionen sein. Es ist kein “Safe Space” und keine gesunde Fehlerkultur vorhanden. Anstatt eines Teams entwickelt sich eine Ansammlung von Einzelkämpfer:innen. Eine solche Entwicklung führt dazu, dass Menschen aneinander vorbei oder sogar gegeneinander arbeiten. Missverständnisse und eine große Heterogenität im Code entstehen und es wird ein immenser Wartungsaufwand erzeugt, der darauf fußt, dass Architekturentscheidungen im Alleingang getroffen und nicht dokumentiert werden, einzelne Entwickler:innen sich nicht mehr im Code zurechtfinden und somit eine sogenannte “Spaghetti-Architektur” entsteht. Starke Verzögerungen im Projektverlauf sind im wahrsten Sinne des Wortes vorprogrammiert.
Gemeinsames Verständnis des fachlichen Kontextes
Software soll uns die alltägliche Arbeit erleichtern. Um dieses Ziel bestmöglich zu erreichen, müssen die Menschen, die diese Funktionalitäten umsetzen, die zu lösenden Probleme bestmöglich verstehen, denn:
”It is not the domain experts knowledge that goes into production, it is the assumption of the developers that goes into production“
– Alberto Brandolini, Inventor of Event Storming
Ein fehlendes Verständnis für die Fachlichkeit sorgt dafür, dass das Team nicht in der Lage ist, wichtige Fragen zu stellen, deren Antworten Grundlage essentieller Architekturentscheidungen sind. Hierbei geht es vor allem um die sogenannten unbekannten Unbekannten, sprich: Das Team weiß nicht, was es nicht weiß und kann dieses Wissen daher weder in der Entwicklung nutzen, noch ist es in der Lage, wichtige Stakeholder, die über dieses Wissen verfügen, zum richtigen Zeitpunkt einzubeziehen.
Es ist demnach unerlässlich, das Team mindestens auf einen fachlichen Wissensstand zu bringen, bei dem viele dieser unbekannten Unbekannten zu bekannten Unbekannten werden. Passiert dies nicht, so fallen aus technischer Sicht kritische Anforderungen erst spät im Projektverlauf auf und sorgen für starke Verzögerungen.
Technisch / Methodisch heterogene Expertise
Oft werden Softwareentwicklungsprojekte genutzt, um nebenbei neue Methoden (beispielsweise agile Arbeitsweisen) oder Technologien in der Organisation einzuführen. Doch auch wenn dies kein explizites Projektziel ist, sollte der Lösungshorizont des Teams möglichst breit sein. Während der Quellcode möglichst homogen sein sollte, hilft Heterogenität in der technischen und methodischen Expertise der Teammitglieder dabei, auf der Suche nach Lösungen und beim Erforschen von Methoden bestmögliche Resultate zu erzielen und möglichst unabhängig von anderen Teilen der Organisation arbeiten zu können.
Sollen neue Methoden oder Technologien eingeführt werden und das Team kennt nur die eine Arbeitsweise und die eine Technologie, kann das zu halbgaren Lösungen führen, die sich letztlich in Form geringer Produktstabilität und Teamproduktivität äußern werden.
Durch eine Erweiterung des Lösungshorizonts und - besonders wichtig - die Befähigung, die richtigen Entscheidungen zu treffen, wird es dem Team erleichtert, die gesteckten Ziele zu erreichen. Es ergibt beispielsweise wenig Sinn, für eine simple Formularanwendung mit wenig Fachlogik auf eine hexagonale Architektur und möglichst viele Patterns aus dem taktischen Domain Driven Design zu setzen - auch, wenn die Entwickler:innen gerade aus einer Schulung kommen und darauf brennen, ihre neu gewonnenen Fähigkeiten in der Praxis auszuprobieren.
Wie stelle ich ein Team zusammen?
Um ein Team für Ihr Entwicklungsprojekt zusammenzustellen, untersuchen Sie Ihre Projektumstände:
- Wie komplex ist Ihre Fachdomäne?
- Wie wichtig ist das Projekt für Ihre Organisation?
- Sollen neue Technologien (z.B. wegen Modernisierung) oder ein neues Zusammenarbeitsmodell (z.B. Agile Softwareentwicklung) etabliert werden?
- Ist externe Expertise gefragt?
Beantworten Sie diese Fragen und stellen Sie Ihr Team auf Basis der im Folgenden beschriebenen drei grundlegenden Stereotypen (Abbildung 1) zusammen.
Das bestehende Produktteam
Bei einem bestehenden Produktteam, das bereits längere Zeit in der Fachdomäne zusammenarbeitet, ist es wahrscheinlich, dass bereits ein gemeinsames Verständnis für- und miteinander existiert. Außerdem kennt sich das Team bereits mit den Organisationsstrukturen aus, in denen es arbeitet. Im besten Fall kennt man hier sogar den fachlichen Kontext, um den es im Projekt geht.
Allerdings steht einem solchen Team oft ein eingeschränkter Lösungshorizont zur Verfügung, der den Blick über den Tellerrand erschwert. Dies ist oft eintönigen, wenig innovativen Entwicklungsumgebungen geschuldet und vor allem in Modernisierungsprojekten ein Problem, das allerdings durch Ergänzung oder Enabling des Teams durch interne oder externe Expert:innen gelöst werden kann.
Die internen oder externen Expert:innen arbeiten mit dem Team zusammen und erfüllen sowohl einen Entwicklungs-, als auch einen Coaching- und Beratungsauftrag. Soll ein ein bestehendes System beispielsweise in die Cloud überführt werden, steht das Entwicklungsteam ohne Erfahrungen in der Entwicklung von verteilten Systemen und Cloudfähigen Anwendungen nicht alleine da, sondern wird durch Entwickler:innen ergänzt, die bereits viel Erfahrung in diesen Themen gesammelt haben.
Das interne Projektteam
Oft ist es der Fall, dass “Projektteams” für ein bestimmtes Produkt und einen bestimmten Zeitraum aus verschiedenen Abteilungen heraus gebildet werden. Ein solches Team kennt sich ebenfalls bereits mit den Organisationsstrukturen aus, in denen es arbeitet, hat allerdings den Nachteil, dass die jeweiligen Teammitglieder sich möglicherweise nur teilweise kennen, durch Verpflichtungen gegenüber ihren Abteilungen kein 100%-Commitment für das Projekt geben können und zuvor kaum miteinander gearbeitet haben. Auch ist der fachliche Kontext für das neue Projekt oft nur teilweise bekannt.
Der Lösungshorizont eines solchen Teams ist oft weiter als der einer bereits seit Jahren am selben Produkt arbeitenden Gruppe, allerdings - vor allem in großen, hierarchisch strukturierten Organisationen - im Rahmen genau dieser Organisation eingeschränkt. Dazu kommt, dass das Team im Normalfall nach Projektende durch ein Wartungsteam ersetzt wird, das weder den fachlichen Kontext, noch die Software an sich kennt.
Das externe Team
Ein externes Team ist oftmals schnell verfügbar und hat aufgrund von Projektarbeit schon einiges mehr von der Welt der Softwareentwicklung gesehen als ein bestehendes Projektteam. Es bringt also einen breiteren Lösungshorizont mit - dies ist vor allem für Modernisierungsprojekte ein Vorteil.
Die Probleme liegen hier im Zwischenmenschlichen: Externe Teammitglieder kennen meistens weder die Organisationsstrukturen, noch den fachlichen Kontext, in dem das Entwicklungsprojekt stattfinden soll.
Nach Projektende ist es zudem üblich, das externe Team schnellstmöglich durch ein internes Wartungsteam zu ersetzen, um Kosten zu sparen und die Expertise im Unternehmen zu halten. Eine vernünftige Übergabe ist hier durch den Zeitdruck oft nicht möglich und der Schnitt hart, da das Entwicklungsteam das Unternehmen verlässt. In dem Fall wird auch das Ziel, Expertise im Unternehmen zu halten, nicht erreicht.
Investieren Sie in das Team
In den meisten Fällen entscheiden sich Projektverantwortliche für eine Mischung dieser Stereotypen, zum Beispiel weil sie aus organisatorischen Gründen dazu gezwungen sind. Ein bestehendes Produktteam dürfte externe Expertise benötigen, um über den berühmten Tellerrand hinweg Modernisierungsansprüchen gerecht werden zu können. Ein Team, bestehend aus externen Mitarbeiter:innen, benötigt Fachwissen von innerhalb der Organisation. Ein internes Projektteam benötigt von beidem etwas. In jeder Konstellation werden Sie in Maßnahmen investieren müssen, die Sie vor allem eines kosten: Zeit. (Abbildung 2)
Sozialisierung
Sorgen Sie dafür, dass das Team sich persönlich kennenlernen und zusammenarbeiten kann. Legen Sie den Fokus in dieser Kennenlernphase nicht auf sichtbare Ergebnisse in Form eines Produktinkrements. Es geht darum, sich als Menschen kennenzulernen, einen gemeinsamen (vorläufigen) Arbeitsmodus zu finden und soziale wie technische Grundlagen zu schaffen. Geben Sie dem Team ausreichend Zeit und Gelegenheit, sich zu formen - beispielsweise durch Workshops, in denen Erwartungen, Ziele, Prozesse und Kommunikationsformen gemeinsam erarbeitet werden.
Persönliche Treffen des gesamten Teams sorgen für die Stärkung der zwischenmenschlichen Beziehungen. Teammitglieder müssen keinesfalls auch im privaten Bereich beste Freund:innen werden, allerdings trägt eine gute Arbeitsatmosphäre nicht unerheblich zu einer erfolgreichen Zusammenarbeit bei.
Um ein gemeinsames Verständnis der Zusammenarbeit und auch der gemeinsamen technischen Basis zu schaffen, bieten sich Konzepte wie Pair- und Mob-Programming an. Neben dem gemeinsamen Verständnis der Codebasis werden hier auch Mikroarchitekturentscheidungen auf dem kurzen Weg getroffen und Probleme gemeinsam erkannt. Es ist keine aufwändige Transferleistung mehr nötig, wenn in einem separaten Treffen zur Lösung eines Problems zuerst das Problem erläutert werden muss. Zudem lernen alle Teammitglieder voneinander und gewöhnen sich an einen gemeinsamen Code-Stil, die Codebasis wird homogener und zahlt somit auf die Wartbarkeit des Systems ein.
Fachverständnis
Ermöglichen Sie den Dialog zwischen den Menschen. Ein gemeinsames Verständnis der zugrunde liegenden Fachthemen zwischen allen Projektbeteiligten kann nur entstehen, wenn diese Personen zusammenkommen und miteinander kommunizieren. Bringen Sie das Entwicklungsteam und den Fachbereich so nah wie möglich zueinander. Führen Sie eine gründliche Stakeholder-Analyse durch und ermöglichen Sie auch diesen Personen, ihre Perspektiven einzubringen.
Wenn Entwickler:innen im Projektverlauf selbst zu Fachexperte:innen werden, ist die Chance auf einen erfolgreichen Projektverlauf sehr hoch. Im besten Fall sollte dem Team also die Gelegenheit zu einem Shadowing des Fachbereichs geboten werden. Da dies aus verschiedenen Gründen - zum Beispiel aufgrund zeitlicher Einschränkungen - oftmals nicht durchführbar ist, können verschiedene, wiederkehrende Workshop-Formate, wie beispielsweise ein Event Storming oder Domain Storytelling, mit dem Entwicklungsteam und anderen Stakeholdern durchgeführt werden.
Diese Formate dienen dazu, eine solide Grundlage für das Entwicklungsteam zu schaffen, um im Verlauf des Projekts die richtigen Fragen stellen zu können. Verlassen Sie sich bei der Vermittlung der Fachlichkeit nicht auf die Fähigkeit der fachlichen Ansprechpartner:innen, sich in den Informationsbedarf der Techniker:innen hineinversetzen zu können. Für die Bewertung der Priorität fachlicher Hintergründe im Hinblick auf Architekturentscheidungen ist ein technischer Blickwinkel und somit unbedingt ein interaktives Lernen gemeinsam mit Entwickler:innen und Architekt:innen gefordert.
Technische / Methodische Expertise
Es gibt verschiedene Möglichkeiten, ein Team in technischen und methodischen Themen zu stärken. Am offensichtlichsten dürfte hier der Zugang zu Schulungen und Fachlektüre sein. Der Besuch einer Schulung oder das Lesen eines Buches helfen aber nicht sofort. Im Worst Case führen diese Dinge aufgrund von fehlender Erfahrung in den gelernten Bereichen dazu, dass die erlernten Lösungsmöglichkeiten an den falschen Problemen angesetzt werden.
Um die Erfahrung und das Verständnis, wann welcher Lösungsansatz zu wählen ist, im Team zu etablieren, sollten Sie Erfahrung für einen längeren Zeitraum und mit ausreichendem Commitment in das Team bringen. Das kann durch Zuwachs aus einem anderen Team, beispielsweise einem Enabling Team passieren oder durch ein Engagement externer Expert:innen. Auch hier ist es ratsam, vor allem zu Projektbeginn und zur Einarbeitung neuer Mitarbeiter:innen auf Pair- und Mob-Programming zu setzen, um Erfahrung und Expertise möglichst effizient ins Team zu tragen.
Fazit
Ein erfolgreiches Team zeichnet sich durch ein intaktes soziales Gefüge, ein gemeinsames Verständnis der zugrunde liegenden Fachthemen sowie das technische und methodische Know-how aus, um die Anforderungen für die Softwareentwicklung umzusetzen.
Idealerweise arbeiten Sie mit einem bereits etablierten Produktteam zusammen, das nicht nur eingespielt ist, sondern auch ein umfassendes und einheitliches Verständnis der Fachthemen besitzt. Investieren Sie in die kontinuierliche Schulung des Teams in technischen und methodischen Themen und ergänzen es zusätzlich um externe Expertise und Erfahrung.
Arbeiten Sie mit einem internen Projektteam zusammen, sorgen Sie möglichst dafür, dass diese ausgewählten Menschen bereits länger miteinander arbeiten. Investieren Sie in die weitere interne Sozialisierung des Teams, in Fachverständnis und in die kontinuierliche Schulung des Teams in technischen und methodischen Themen. Ergänzen Sie es bei Bedarf zusätzlich um externe (technische / methodische) und interne (fachliche) Expertise und Erfahrung.
Arbeiten Sie mit einem externen Projektteam zusammen, haben Sie im Normalfall keinen Einfluss auf die weitere Sozialisierung des Teams, denn diese liegt in der Verantwortung der jeweiligen Arbeitgeberin. Investieren Sie in jedem Fall in Fachverständnis, zum Beispiel durch die Durchführung wiederkehrender Workshops und um die Ergänzung des Teams durch eben jene interne Mitarbeiter:innen. In diesem Fall haben Sie wiederum Einfluss auf das soziale Gefüge des Teams. Investieren Sie auch hier.
Wenn Sie ein bestehendes Team durch neue Menschen ergänzen, müssen die Neuzugänge sich im sozialen Gefüge des Teams einfinden, die Fachlichkeit und bestehende Technik kennenlernen – Fluktuation in einem bestehenden Team erfordert stets eine zeitliche Investition. Dabei gilt die Faustregel: Je stärker das Team verändert wird, desto größer ist der erforderliche zeitliche Invest.
Vielen Dank an meine Kolleg:innen Christiane Mezger, Anja Kammer, Hermann Schmidt, Joachim Praetorius und Tina Schönborn für das Feedback zu einer früheren Version des Artikels.