Agile Teams II: Zusammenstellung agiler Teams
Der vorige Teil dieser Artikelserie zu agilen Teams erwähnte an mehreren Stellen, dass in einem Team sämtliche Fähigkeiten vorhanden sein müssen, um die Anforderungen des Kunden erfüllen zu können. Dieser Artikel möchte Möglichkeiten zur Umsetzung dieser Forderung beschreiben.
Funktionsübergreifende Teams
Formal ist ein Team eine Gruppe von Menschen, die versucht, gemeinsam eine Aufgabe zu erledigen oder ein Ziel zu erreichen. Klassischerweise werden Teams in Unternehmen daher nach den Aufgaben gebildet. Ein naheliegender Gedanke ist dabei, die Aufgaben in Funktionen oder Phasen zu untergliedern, zum Beispiel Entwicklung, Produktion, Marketing, Logistik, Kundenservice und so weiter. Die so entstehenden Expertenteams haben den Vorteil, dass die Teammitglieder sich über „ihre“ Themen austauschen können, von den Erfahrungen profitieren können und im Falle eines Ausfalles schnell die Ressourcen ersetzen können. Das erfahrenste Mitglied kann zum Teamleiter befördert werden und so die Qualität der Arbeit und der Mitarbeiter sicherstellen.
Ein großer Nachteil dieser Expertenteams ist, dass sie monofunktional sind. Sobald eine Aufgabe mehr als eine Funktion benötigt, existieren Abhängigkeiten zwischen den Teams. Die so entstandene Komplexität ist schwer zu beherrschen. Dies führt zu Wartezeiten auf Antworten, vielen Meetings, und sinkender Qualität, da das Expertenwissen häufig in den Teamsilos gefangen ist. Manchmal wird jemand verantwortlich gemacht, diese Komplexität zu managen, aber meistens ist die Komplexität zu schwer zu überblicken.
Wird allerdings nicht nach Phasen oder Funktionen, sondern nach Produkten gegliedert, entsteht ein radikal anderer Blickwinkel. Nun werden für die Weiterentwicklung eines Produktes Experten aus verschiedenen Funktionen benötigt. Idealerweise wird die gesamte Wertschöpfungskette eines Produktes durch ein Team abgedeckt. So werden die Schnittstellen zu anderen Teams minimiert, was zu einer massiven Beschleunigung der Projekte führt.
Natürlich ist dieser Gedanke nicht neu, Projektteams sind normalerweise genau nach diesem Prinzip aufgebaut. Diese werden dann häufig als crossfunktional oder interdisziplinär bezeichnet, in der agilen Welt werden sie sie normalerweise funktionsübergreifend genannt.
Teamzusammensetzung
Für die Teamzusammensetzung ist die entscheidende Frage, ob das Team auf das Produkt oder auf den Kunden fokussiert sein soll. Dies klingt nach einem vernachlässigbaren Unterschied, ist aber essenziell für die Unternehmensstrategie.
Ein Team, das auf ein Produkt fokussiert ist, versucht das Produkt weiterzuentwickeln. Es schafft somit einen Mehrwert für das Produkt, und somit indirekt einen Mehrwert für den Kunden. Das Team erhält normalerweise eine Liste an Anforderungen, die es dann vollständig umsetzen muss. Dies ist meist schon schwierig genug, denn dies erfordert nicht nur, dass die Teammitglieder aus den dafür nötigen Experten rekrutiert werden, sondern auch, dass das Team alle das Produkt betreffenden Entscheidungen treffen darf.
Ein Team, das auf den Kunden fokussiert ist, versucht Probleme des Kunden zu lösen. Es schafft somit direkt einen Mehrwert für den Kunden. Dementsprechend benötigt ein kundenwertoptimierendes Team weitere Fähigkeiten zur Identifizierung der Kundenprobleme. Die einfachste Möglichkeit, diese Fähigkeit im Team zu installieren besteht daraus, Personen mit entsprechenden Rollen (z.B. Business Analysten) in das Team zu integrieren.
Andere Möglichkeiten basieren auf Weiterbildungsmaßnahmen der Teammitglieder, sodass diese in die Lage versetzt werden, Kundenprobleme zu identifizieren und in Lösungen zu übersetzen. Schulungen, Mentoring, Coaching, Pairing mit Business Analysten sind effektive Varianten, außerdem wäre denkbar, dass Business Analysten für einen begrenzten Zeitraum im Team mitarbeiten, bis das Team die entsprechenden Fähigkeiten gelernt hat.
Natürlich sollte bei der Teamzusammenstellung auch bedacht werden, dass die Persönlichkeiten der Teammitglieder zueinander passen. Nur weil die einzelnen Teammitglieder jeweils die beste Person für eine Teilaufgabe sind, heißt dies noch lange nicht, dass sie in Summe ein gutes Team bilden. In den meisten Fällen stellt die Teamzusammensetzung aber kein großes Problem dar, da heutzutage so gut wie jeder die Teamarbeit gewohnt ist und entsprechend teamfähig und kooperativ ist.
Teambegleitung
Je nach Autonomiegrad des Teams (siehe Teil I) und je nachdem, wie lange ein Team bereits zusammenarbeitet, benötigt ein Team Unterstützung, um gut zu arbeiten. Dies hängt sowohl mit den zu übernehmenden Aufgaben als auch mit den verschiedenen Phasen der Teamentwicklung zusammen. Daher werden im Scrum-Framework zwei Rollen zu Teambegleitung geschaffen: Der Product Owner und der Scrum-Master.
Die zentrale Aufgabe des Product Owners ist das Produkt. Er muss dafür sorgen, dass geleistete Arbeit des Teams auch einen Mehrwert für das Produkt liefert. Wird der Product Owner von außen bestimmt, bedeutet dies normalerweise, dass er Aufgaben (User Stories) definiert und priorisiert. Im Falle kundenwertoptimierender Teams führt dies zu einem Widerspruch. Das Team möchte Kundenprobleme lösen, der Product Owner möchte aber Mehrwert für das Produkt schaffen. Daher ist es bei kundenwertoptimierenden Teams üblich, dass die Teams selbst die Aufgaben definieren, der Product Owner dagegen lediglich die Priorisierung übernimmt.
Der Scrum-Master soll dafür sorgen, dass das Team die verschiedenen Phasen der Teamentwicklung erfolgreich durchläuft. Gleichzeitig muss er darauf achten, dass das Team im Sinne von Inspect & Adapt stets besser wird. Diese Aufgaben erfüllen die meisten Scrum-Master dann besonders gut, wenn sie keine Entwicklungsaufgaben im Team haben und nicht mehr als zwei Teams betreuen.
Zusammenfassung
Wenn ein Team ein Produkt auf Basis der Kundenwünsche entwickeln soll, so werden hierfür gewisse Fähigkeiten im Team benötigt. Dazu müssen die nötigen Fähigkeiten und Entscheidungskompetenzen im Team gebündelt oder aufgebaut werden. Gleichzeitig sollten ein Team, besonders am Anfang, begleitet werden.