Geschätzte Lesezeit: 10 Minuten.

Die meisten Projekte sind zu groß und zu komplex, um von einer Person alleine vollständig erledigt zu werden. Daher bilden sich schon seit vielen Jahren regelmäßig Teams, die gemeinsam Aufgaben erfüllen sollen. Abgesehen von vielen Witzen über Teams (Toll, ein anderer macht’s) sind Teams auch im agilen Kontext unverzichtbar.

Laut Hackman¹J. R. Hackman, Leading Teams: Setting the Stage for Great Performances, 1. Aufl., Harvard Business Review Press, Brighton, 2002. gibt es vier Punkte, die beachtet werden sollen, wenn ein Team gebildet werden soll:

1. Definition des Teamzwecks
2. Zusammenstellung des Teams und Einbettung des Teams in die Organisation
3. Organisation der Arbeit des Teams
4. Erledigung der Arbeit

Anhand der Frage, welche dieser Aufgaben vom Team (bzw. vom Management) übernommen werden, kann der Autonomiegrad eines Teams klassifiziert werden. Diese verschiedenen Autonomiegrade werden in diesem Artikel diskutiert. Dazu sollte angemerkt werden, dass ein Großteil dieses Artikels auf einem hervorragendem Buch von Hoffmann und Roock²J. Hoffmann, S. Roock, Agile Unternehmen: Veränderungsprozesse gestalten, agile Prinzipien verankern, Selbstorganisation und neue Führungsstile etablieren, 1. Aufl., dpunkt.verlag GmbH, Heidelberg, 2018. basiert.

Managergeführtes Team

Ist das Team einzig und allein mit der Erledigung der eigentlichen Arbeit (Punkt 4) betraut, muss der Manager die restlichen Punkte 1-3 übernehmen. Diese Rollenverteilung wird häufig negativ mit dem Ausdruck Taylorismus³Seite „Taylorismus“. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 25. Juni 2018, 17:17 UTC. URL: https://de.wikipedia.org/w/index.php?title=Taylorismus&oldid=178627131 (Abgerufen: 2. August 2018, 14:24 UTC). beschrieben. Typisch für solche managergeführten Teams sind die folgenden Ausprägungen:

• Detaillierte Vorgabe der Arbeitsmethode durch den Manager
• Festlegung des Leistungsortes und des Leistungszeitpunktes durch den Manager
• Durch den Manager extrem detaillierte und zerlegte Arbeitsaufgaben
• Einwegkommunikation vom Manager zu den Teammitgliedern, mit festgelegten und engen Inhalten
• Detaillierte Zielvorgaben durch den Manager bei für einzelne Teammitglieder nicht immer erkennbarem Zusammenhang zum Unternehmungsziel
• Externe (Qualitäts-)Kontrolle

Natürlich gibt es Fälle, in denen eine solche Trennung der ausführenden und planenden Arbeit sinnvoll ist. Im Falle repetitiver, nicht komplexer Aufgaben (zum Beispiel in der Serienfertigung) ist diese Methode seit vielen Jahren etabliert und liefert zuverlässige und verlässliche Ergebnisse. Für solche Aufgaben ist agiles Projektmanagement nicht geeignet. Gleichzeitig kann ein managergeführtes Team auch nicht als agiles Team betrachtet werden, da das Team nicht anpassungsfähig ist. Sämtliche Anpassungen an veränderte Bedingungen müssen stattdessen durch das Management vorgenommen werden.

Selbstorganisierendes Team

Ein selbstorganisierendes Team übernimmt zusätzlich zur Erledigung der Arbeit (Punkt 1) ebenfalls die Organisation derselben (Punkt 2). Dies ist die Mindestvoraussetzung für ein agiles Team, somit kann ab hier von agilen Teams gesprochen werden.

Diese Organisation der Arbeit umfasst drei Teilbereiche. Erstens soll das Team selbst entscheiden, wer wann welche Aufgabe übernimmt. Dazu gehört auch die Überlegung, wie Aufgaben unterteilt werden sollen. Im Scrum-Framework wird hierzu das Sprint Planning genutzt. Zweitens soll das Team den Arbeitsfortschritt selbst überwachen, im Scrum-Framework passiert dies in den Dailies. Drittens ist es Aufgabe des Teams, die eigene Teamorganisation selbst zu verbessern. Das Scrum-Framework nutzt hierzu die Retrospektive.

Es gibt einige Voraussetzungen an ein Team, damit es selbstorganisierend sein kann. Das Team muss zu Beginn meist lernen, die eigene Arbeit zu planen, und für diese Planung die Verantwortung zu übernehmen. Eine besondere Herausforderung ist die Kommunikation durch den Manager. Bei managergeführten Teams wird einfach nur die Arbeitsplanung kommuniziert, aber genau diese Arbeitsplanung soll ja vom Team vorgenommen werden. Stattdessen muss also die Kommunikation auf einer höheren Ebene stattfinden, das heißt, es muss der Teamzweck und der Organisationskontext kommuniziert werden. Dies führt zu einer Transparenz in der Kommunikation, und erfordert ein erhebliches Umdenken. Mögliche Modelle, wie solche Teamzwecke kommuniziert werden können, sind z.B. Visionen im Scrum-Framework, das Management-by-Objectives-Modell, oder das Nordstern-Konzept. Zu all diesen Punkten werde ich separate Artikel verfassen, und dann hier verlinken.

Bisher sprach ich von gestellten Aufgaben. Im agilen Umfeld ist dies eher unüblich, stattdessen werden normalerweise Kundenanforderungen formuliert, zum Beispiel durch User Stories. Diese Orientierung an Kundenbedürfnissen ist fundamental wichtig, wenn ein Team kundenwertoptimierend arbeiten soll. Damit gehört zur Arbeitsplanung, die Bedürfnisse des Kunden in entsprechende Aufgaben zu übertragen, und ist somit ebenfalls Aufgabe des Teams. Eine für den Manager (oder ein Product Owner) sinnvolle Aufgabe ist üblicherweise die Priorisierung der Anforderungen.

Weiterhin muss ein Team in der Lage sein, die Anforderungen vollständig zu erfüllen. Dazu muss ein Team alle relevanten Bereiche abdecken können. Hier eignen sich besonders cross-funktionale Teams. Gleichzeitig weiß das Team häufig selbst am besten, welche Fähigkeiten dem Team noch fehlt. Leider können selbstorganisierende Teams nichts unternehmen, um fehlende Fähigkeiten aufzubauen; der Übergang zum selbstgestaltenden Team ist fließend.

Selbstgestaltendes Team

Selbstgestaltende Teams übernehmen ebenfalls die Aufgabe der Teamzusammensetzung und der Einbettung des Teams in die Organisation.

Zur Teamzusammensetzung gehört die Frage, welche Rollen im Team benötigt werden, welche Personen Teammitglieder sind, und ob Fähigkeiten durch Weiterbildung einzelner Teammitglieder aufgebaut werden müssen. Natürlich erfordert dies auch Kommunikation mit anderen Teilen der Organisation, insbesondere, falls manche Personen von mehreren Teams benötigt werden. Die Organisation von Schnittstellen und der Zusammenarbeit mehrerer Teams fällt nun ebenfalls in den Aufgabenbereich des Teams.

Erneut gibt es einige Voraussetzungen, damit ein Team selbstgestaltend sein kann. Auch hier muss ein Team bereit sein, diese zusätzlichen Verantwortungen anzunehmen, und gecoacht werden, diese Verantwortungen auch bewusst einzusetzen. Außerdem kann es sinnvoll sein, gemeinsam mit dem Team über Budgets zu diskutieren, falls dieses weitere Teammitglieder einstellen möchte.

Je nach verwendetem Framework kann es ebenfalls nötig sein, dass das Team sämtliche Anforderungen eines Kunden auch komplett bearbeiten und erfüllen kann. Dies ist insbesondere bei Scrum der Fall. Wird das Kanban-Framework genutzt, ist diese Vorgabe nicht zwingend, da hier auch Expertenteams erlaubt sind. In diesem Falle muss das Team deutlich mehr Aufwand in die Interaktion mit anderen Expertenteams des Unternehmens investieren. Da hier die Gefahr lokaler Optimierungen besteht, während gleichzeitig das Kundenbedürfnis aus dem Fokus rutscht, ist das Kanban-Framework nur für erfahrene Teams empfehlenswert.

Selbstverwaltendes Team

Selbstverwaltende Teams besitzen die höchste Verantwortung und die höchste Autonomie. Zusätzlich zu den bisher genannten Aufgaben übernehmen selbstverwaltende Teams auch die Definition und Anpassung des Teamzwecks. Dies bedeutet, dass die Teams selbst entscheiden, ob sie existieren, wer ihre Kunden sind, und welche Produktvision sie für diese Kunden erfüllen möchten. Gleichzeitig dürfen selbstverwaltende Teams diese Aspekte jederzeit anpassen, und im Zweifel auch beenden und das Team auflösen.

Auf der einen Seite klingt dies nach Chaos, auf der anderen Seite führt dies zu maximaler Flexibilität der Teams, falls sich Anforderungen schnell ändern sollten. In der Praxis ändern sich Anforderungen meist nicht so schnell, sodass häufig selbstgestaltende Teams ausreichen. Es gibt allerdings zwei Szenarien, in denen selbstverwaltende Teams sinnvoll sein können, und beide beruhen auf zu Beginn nicht genau bekannten Anforderungen.

Das erste Szenario ist das Startup. Hier wird davon ausgegangen, dass zu Beginn eines Startups nicht klar ist, welche Kunden mit welchen Anforderungen bedient werden sollen. Stattdessen soll hier durch direkte und dauerhafte Interaktion mit dem Markt herausgearbeitet werden, welche Kundengruppen überhaupt existieren, welche Anforderungen diese besitzen, und wie diese durch eine Produktvision erfüllt werden sollen.

Das zweite Szenario ist die Horizont-3-Entwicklung. Eigentlich ist dieses Szenario nicht wirklich unterschiedlich vom Startup, da Startups im dritten Horizont beginnen (sollten). Dieses Szenario wird trotzdem getrennt aufgeführt, da auch in klassischen Unternehmen Innovationsprozesse über die drei Horizonte stattfinden. Das Konzept ist daher das gleiche wie im ersten Szenario: Zu Beginn eines Innovationsprozesses müssen zuerst die Kundengruppen und Kundenbedürfnisse herausgearbeitet werden, damit für diese ein Produkt entwickelt werden kann.

Auch hier gibt es Herausforderungen. Sollen Teams so flexibel sein, dass sie sich verändernden Anforderungen anpassen können, so müssen diese Anforderungen regelmäßig überprüft werden. Dies erfordert einen iterativen Prozess mit einer kontinuierlichen Zusammenarbeit mit den Kunden. Außerdem erfordert dies, dass Teams sich an den Anforderungen orientieren, und nicht einfach spannende Technologietrends umsetzen.

Zusammenfassung

Wenn ein Team ein Produkt auf Basis der Kundenwünsche entwickeln soll, so wird hierfür eine gewisse Flexibilität benötigt. Dies erfordert die Übertragung klassischer Managementaufgaben in die Hände des Teams, damit nicht immer auf Übersetzungen und Entscheidungen des Managements gewartet werden muss. Damit dieses System nicht in Chaos abkippt, muss ein klarer Rahmen definiert werden. Außerdem muss das Team in den Fähigkeiten geschult werden, die es benötigt, um diesen Rahmen effektiv auszufüllen.

Meine persönliche Erfahrung ist, dass selbstorganisierende Teams in einem unterstützendem Framework wie Scrum in vielen Umgebungen Wert schaffen können. Das Konzept funktioniert in Großkonzernen, Familienunternehmen und Startups genauso wie in nationalen oder internationalen Organisationen. Häufig erlebe ich, dass selbstorganisierende Teams schnell lernen, und sich zu selbstgestaltenden Teams entwickeln wollen. Diese Entwicklung ist zu begrüßen, und führt dazu, dass Teams noch besser Wert für den Kunden (und damit auch für das Unternehmen) schaffen können. Leider ist an dieser Stelle die Organisationsstruktur ein häufiges Hindernis, da ein hierarchisches Verständnis mit Organigrammen nicht so einfach zu autonomen Teams und deren Zusammensetzung passt. Ist die Organisation aber bereit, agiler zu arbeiten, können autonome Teams große Vorteile mit sich bringen.

Series Navigation

Agile Teams II: Zusammenstellung agiler Teams >>