Gut funktionierende Teams mit Vision

Was brauchen Sie für ein agiles Projekt, dessen Aufgabe es ist, ein neues System oder Produkt zu erstellen? Klar: ein Team. Außerdem eine passende Infrastruktur für die Zusammenarbeit im Team und mit den Stakeholdern. Das allein reicht aber noch nicht. Sie brauchen außerdem eine Vision von der neuen Lösung, die von allen Beteiligten geteilt wird. Doch wie stellen Sie Ihr Team zusammen und wie entwickeln Sie mit diesem Team eine gemeinsame Vision?

Teams zusammenstellen

Wenn Sie vor einer umfangreichen Projektaufgabe stehen, für deren Lösung Sie mehr Personalkapazität benötigen, als ein agiles Team von idealer Weise 3 bis 9 Personen bietet, dann ist es sinnvoll, mit mehreren kleinen Teams zu arbeiten. Schätzmeetings, Planungsmeetings, Daily Stand-up Meetings, Retrospektiven mit Teams von sagen wir 20, 35 oder mehr Mitarbeitern durchzuführen, ist wenig effizient. Außerdem ist die Selbstorganisation von so großen Teams schwierig. Wichtig ist, dass Sie die Teams nicht so definieren, dass jedes Team das Know-how für jeweils eine Architekturschicht oder Komponente Ihres Systems mitbringt. Bilden Sie also keine Komponententeams, d.h. kein Datenbankteam, Team von Usability Experten, Geschäftslogik-Team, etc. Jedes Team soll ja am Ende eines Sprints ein potenziell einsetzbares Produktinkrement – also ein “Miniprodukt” – liefern. Kein Team sollte einem anderen Ergebnisse zuliefern, sodass zeitliche oder inhaltliche Abhängigkeiten zwischen den Teams sowie zusätzlicher Koordinations- und Integrationsaufwand entstehen. Bilden Sie anstelle von Komponententeams besser Features-Teams.

Feature-Teams sind interdisziplinär besetzt, sodass Know-how über alle Komponenten der Architektur im Team vorhanden ist. Es ist ein weitverbreitetes Missverständnis, dass Mitglieder agiler Teams Generalisten sein müssen. Das stimmt so nicht: Einzelne Mitglieder können und sollten die notwendigen Spezialkenntnisse mitbringen, sodass das Feature-Team als Ganzes in der Lage ist, ein von einem Stakeholder gefordertes Feature vollständig zu realisieren.¹

Der Teambildungsprozess

Durch das Benennen der beteiligten Personen bilden Sie eine Gruppe. Eine Gruppe ist aber noch lange kein Team. Wenn sich Ihre Organisation an Scrum orientiert und die Rolle des Scrum Masters eingeführt hat, dann schlägt jetzt seine Stunde. Er führt das Team durch den Teambildungsprozess, der mit dem Kick-off Meeting zum Projektstart beginnt und sich über die gesamte Dauer der Zusammenarbeit erstreckt. Dieser Teambildungsprozess läuft häufig in Phasen² ab:

Forming – Einstiegs- und Orientierungsphase

In dieser Phase geht es um das gegenseitige Kennenlernen, das Festlegen der Regeln für die Zusammenarbeit und die Klärung von Erwartungen.

Storming – Konfliktphase

Früher oder später kommt es in jedem Team zu Auseinandersetzungen. Hier sind Fähigkeiten in Hinsicht auf Moderations- und Konfliktlösungstechniken gefragt. Dabei ist es besonders wichtig zu erkennen, wann die Konfliktparteien die Sach­ebene (gesagt: „Deine Lösung ist zu eng konzipiert.“) benutzen, um Bot­schaften auf der Beziehungsebene zu übermitteln (gemeint: „Du blickst nicht richtig durch. Du bist nun mal nicht besonders helle.“).

Norming – Regelungs- und Stabilisierungsphase

Sind die Konflikte überwunden und die Rollen im Team gefunden, dann können Regeln für die Zusammenarbeit entwickelt und optimiert, sowie Best Practices herausgearbeitet und angewendet werden. Die Rollen werden flexibler gesehen, persönliche Beziehungen entstehen, das Miteinander wird harmonischer.

Performing – Arbeits- und (Hoch-)Leistungsphase

Sind die Mitglieder aufeinander eingespielt, erreicht das Team die Phase konstant hoher Leistung. Es treten Synergieeffekte bei der Zusammenarbeit ein. Das Team verhält sich flexibel. Rollen wechseln zwischen den Teammitgliedern nach Bedarf.

Reforming/Adjourning – Neuorientierung/Auflösung

Das Hochleistungsniveau lässt sich nicht dauerhaft halten. Veränderungen im Team durch ausscheidende oder neu hinzukommende Mitglieder erfordern eine Neu­orientierung. Die beschriebenen Phasen werden also immer wieder durch­laufen, solange bis das Team nach Abschluss des Projekts aufgelöst wird. Auch die Auf­lösungsphase sollte inhaltlich gestaltet werden, indem das Team zum Beispiel die „Lessons Learned“ des Projekts zusammenträgt als Anregung und Hilfestellung für nachfolgende Projekte. Dabei können die Erkenntnisse vorange­gangener Retro­s­pektiven einfließen.

Der Teambildungsprozess mit Phasen

Die Zusammenarbeit vorbereiten

Auch das allerbeste Team wird nur schwer in die Performing-Phase kommen, wenn eine unzureichende Infrastruktur die Zusammenarbeit behindert. Zweck dieses Schrittes ist es deshalb, die räumlichen und technischen Voraussetzungen für die Zusammenarbeit in den Teams und mit den Stakeholdern zu schaffen. Ideal dafür sind – je nach Anzahl der Teams – ein oder mehrere Teamräume, die ausreichend Möglichkeiten zum Visualisieren bieten. Was Sie brauchen, ist das genaue Gegenteil eines Besprechungsraums mit Tischen, die sich nur schwer oder gar nicht verrücken lassen, und einem einsamen Flip Chart Ständer mit einem einzigen, fast ausgetrockneten schwarzen Filzstift. Aber setzen Sie nicht nur auf Whiteboard, Pappwände und buntes Moderations­material. Nutzen Sie auch Technik, wenn sie hilfreich ist. Zum Beispiel kann es sehr effizient sein, wenn Sie in den Meetings mit den Stakeholdern direkt auf die bereits mit einem Tool festgehaltenen Ergebnisse zugreifen können, um Änderungen sofort vorzunehmen. Welche Tools Sie im Laufe einer Zusammenarbeit verwenden, hängt von Ihren Szenarien ab. Es macht einen Unterschied, ob Sie mit internen oder externen Stakeholdern kommunizieren und auch das Arbeiten mit einem lokalen Team, mit verteilten Teams oder mit verteilten Mitarbeitern eines Teams hat Einfluss auf die verwendete Technik.

Wenn Sie das Projekt soweit eingerichtet haben, dann müssen alle Projekt­beteilig­ten über die technische Infrastruktur, die Organisation der Zusammen­arbeit und die Arbeit mit dem Tool informiert werden. Dem Team vermitteln Sie diese Informa­tionen am besten im Rahmen eines Kick-off Meetings zu Beginn der Projektarbeit. Wenn die Stakeholder direkten Zugang zu den Ergeb­nissen des Requirements Engineering bekommen sollen, dann müssen Sie sie in die Bedienung des Tools, die Art der Artefakte und die Ablagestruktur einführen. Die beste Form dafür ist ein Workshop.

Eine gemeinsame Vision entwickeln

Formal haben Sie jetzt alles beisammen, um durchstarten zu können. Fragt sich nur: Durchstarten – in welche Richtung? Als Grundlage für die inhaltliche Projekt­planung benötigen Sie eine klare Vorstellung von den Zielen der Stakeholder, die Sie mit dem Projekt erfüllen sollen. Es ist Aufgabe des Requirements Engineering, die Ziele zu ermitteln und zu analysieren, um daraus konkrete Anforderungen abzuleiten. Aber schon bevor das im Detail geschieht, brauchen Sie als Projektmanager oder Product Owner und braucht das gesamte Team eine Vision davon, was am Ende des Projekts erreicht sein soll.

Als Projektmanager sind Sie dafür verantwortlich, dass die Teammitglieder nicht mit unterschiedlichen Annahmen und Vermutungen ins Projekt startet. Wenn es Ihnen nicht gelingt, eine einheitliche Vision in den Köpfen aller Beteiligten zu erzeugen, was dann? Jeder Einzelne wird im Projektverlauf eine individuelle Vorstellung davon entwickeln, was gebaut und was damit erreicht werden soll. Das Ergebnis: Die Kommunikation wird für die Stakeholder verwirrend, Entscheidungsprozesse dauern länger, Missverständnisse häufen sich und die Motivation im Team sinkt. Teams mit einem einheitlichen Verständnis darüber, was mit dem Projekt erreicht werden soll, arbeiten erfahrungs­gemäß deutlich produktiver als solche, denen eine gemeinsame Vision fehlt. Die gemeinsame Vision bietet selbstorganisierten Teams Orientierung, ohne sie in ihrer Kreativität einzuschränken.

Der Vision-Workshop

Eine gemeinsame Vision entwickelt man am besten im Rahmen eines Workshops. Hier ein paar Tipps zum Vorgehen:

• Laden Sie die Requirements Engineers und das Entwicklungsteam zu einem Workshop ein und nennen Sie bereits in der Einladung das Ziel des Workshops und den zeitlichen Rahmen. Sollten Stakeholder dabei sein? Wenn Sie viele Stakeholder haben, wird das schon organisatorisch schwierig, so dass sie evtl. durch die Requirements Engineers mit ihrem Wissen über die Stakeholder-Ziele vertreten werden. Wenn Sie ein neues Produkt für den Markt entwickeln, kann die Runde auch schon mal größer werden. Dann kann es sinnvoll sein, Produktmanager, UX-Experten und Marketing-Leute dabei zu haben. In diesem Fall haben Sie in der Regel auch keine Stakeholder dabei, die die zukünftigen Anwender repräsentieren. Hier könnten Sie Personas im Vorfeld definieren, also fiktive Benutzer des zu entwickelnden Systems.
• Legen Sie im Workshop – ausgehend von den zentralen Zielen der Stakeholder und der Abgrenzung des Systems – die wesentlichen Features der neuen Lösung fest. Möglicherweise haben die Requirements Engineers mit den Stakeholdern bereits aus den Zielen Anforderungen auf hohem fachlichen Niveau – also Features – abgeleitet. Arbeiten Sie die Features heraus, die einen hohen Wert für die Stakeholder schaffen. Im Falle der Produkt­entwicklung für den Markt treten an die Stelle der wertschaffenden Features die Alleinstellungsmerkmale, die das Produkt verglichen mit Wett­bewerbs- oder Vorgängerprodukten auszeichnen. Und bedenken Sie, dass bei der Entwicklung von Software und softwareintensiven Systemen auch eine grund­sätzliche Vorstellung von der Systemarchitektur zu der gemeinsamen Vision gehört.
• Dokumentieren Sie die Vision: Wenn Sie das Ergebnis des Vision-Work­shops etwas ausführlicher festhalten wollen, erstellen Sie Vision-Dokument. Ein einheitliches Verständnis schaffen Sie nicht durch ein 80-Seiten Papier. Deshalb ist es übrigens auch nicht sinnvoll, statt eine Vision zu entwickeln, den Beteiligten einfach den Business Case zuzusenden, mit dem freund­lichen Wunsch, das Dokument doch bitte zu lesen. Versuchen Sie vielmehr, ein kurzes und prägnantes Vision-Statement zu finden. Eine anschauliche Faustregel: Das Vision-Statement sollte so kurz sein, dass es den Fahrstuhl-Test besteht. Das heißt, das Statement sollte so formuliert sein, dass Sie damit jemandem in einer Minute – sagen wir auf der Fahrt mit dem Fahrstuhl vom Erdgeschoss in den fünften Stock – das Projekt erklären können. Schwierig? Helfen kann nachfolgende Schablone:

Schablone für Vision-Statement

Wie Sie die Schablone verwenden, zeigt das nachfolgende Beispiel:

Fazit

Ein gut funktionierendes Team, idealerweise als interdisziplinäres Feature-Team organisiert und mit speziellen Kenntnissen einzelner Mitarbeiter ausgestattet, ist ein wichtiger Faktor für die erfolgreiche Entwicklung von Produkten. Im Rahmen der Zusammenarbeit durchläuft jedes Team Phasen, von der Orientierungsphase, über die Konfliktphase, die Regelierungs- und Stabilisierungsphase, hin zur Performingphase bis zur Auflösung. Hilfreich für die Zusammenarbeit ist eine gemeinsame Vision. Am besten verwenden Sie zur Erstellung einer Vision eine Schablone, so dass Sie bei der Beschreibung der Vision nicht aus Versehen die Umsetzung der Lösung einschränken. Formulieren Sie die Vision am besten so einfach und leicht verständlich, dass alle Beteiligten wirklich eine gemeinsame Vorstellung von den Zielen des Projekts haben.

Da sich im Projektverlauf die Ziele und Anforderungen der Stakeholder sowie die Rahmenbedingungen des Projekts (z.B. durch Eintreten einer neuen Marktsituation) ändern können, kann sich auch die Vision verändern. Die Vision, die Sie am Anfang des Projekts entwickelt haben, ist dann möglicherweise nicht mehr passend. Überprüfen Sie die Vision daher regelmäßig und überarbeiten Sie sie gegebenen­falls. Das eigentliche Vision-Dokument sollten Sie idealerweise versionieren. Und wenn Ihr Team definiert ist und die Vision feststeht, dann geht es darum, den Weg festzulegen, auf dem die Vision erreicht und dabei die Ziele der Stakeholder in konkreten Nutzen umgesetzt werden sollen. Wie Sie eine solche Strategie definieren, ist aber Thema für einen zukünftigen Blogbeitrag.

Wie sind denn Ihre Erfahrungen beim Prozess der Teambildung und bei der Nutzung von Vision-Statements?

Hinweise:

Zur Vertiefung dieses Themas siehe Roock, A., & Roock, S. (August 2013). Wie cross-funktional soll mein Team sein?
https://stefanroock.files.wordpress.com/2013/08/crossfunktionaleteams_roocks.pdf
Tuckman, B. (1965). Developmental Sequence in Small Groups. Psychological Bulletin 63, S. 384-399, sowie Tuckman, B., & Jensen, M. A. (1977). Stages of Small-Group Development revisited. Group Org. Studies 2, S. 419-427.