Teamarbeit in einer agilen Transformation

In einem zunehmend dynamischen und komplexen Umfeld setzen Unternehmen gerne auf „agile“ Arbeitsmethoden. Sie reorganisieren ganze Unternehmensbereiche in „agile Teams“. Die Verteilung von Arbeit erfolgt aber oftmals weiterhin durch Zuweisen von Aufgaben an Einzelpersonen. Das bringt nicht den erhofften Effekt. Im Gegenteil, es verschlechtert die Leistungs- und Lieferfähigkeit.

Der “VUCA-Reflex”: Reorganisation in “agile” Teams

Unternehmen kommen heute zunehmend in Bedrängnis, weil die traditionelle, phasenbasierte Umsetzung von Projektvorhaben (“Wasserfall”) in einem zunehmend dynamischen, komplexen und volatilen Umfeld an seine Grenzen stößt.

Sie reagieren darauf mittlerweile nahezu reflexartig mit der Reorganisation ganzer Unternehmensbereiche in „agile Teams“. Durch den Einsatz agiler Arbeitsmethoden soll sich die Leistungs- und Lieferfähigkeit deutlich verbessern.

Team-Rhetorik – aber Management von Einzelpersonen?

Nach der Reorganisation in Teams behält das (Projekt-) Management oftmals die bewährte  Arbeitsweise bei, den einzelnen Teammitgliedern individuell Aufgaben zuzuweisen und sie regelmäßig über deren Erledigung berichten zu lassen.

Warum bleibt das wirkungslos?

Richard Hackman erklärt in seinem Buch „Leading Teams“ sehr anschaulich, warum diese Form der Reorganisation nicht den erhofften Effekt hat:

 

A great deal of organizational work is performed these days by sets of people who are called “teams” but who really are co-acting groups. Managers in organizations where this is done may harbour the hope that they can harvest the widely touted benefits of teamwork while continuing to directly manage the behaviour of individual team members. That hope is misplaced: If you want the benefits of teamwork, you have to give the team the work.

So there is a choice here: Either design the work for a team, or design it for individuals. If done well, either strategy can yield fine results. What is not fine is to send mixed signals: to use the rhetoric of teams when the work really is performed by individuals, or to directly supervise individual members when the work really is a team’s responsibility”

 

Entweder Teamarbeit oder Einzelarbeit

Das Management muss Arbeit also entweder für Einzelpersonen organisieren oder für Teams. Niemals aber darf die Führung kommunizieren, dass die Arbeit ab sofort in Teams erfolgt und gleichzeitig immer noch Aufgaben an Einzelpersonen zuweisen. Das führt zu Verwirrung in der Organisation und verschlechtert die Liefer- und Leistungsfähigkeit.

Was gute Teamarbeit ausmacht, hat beispielsweise auch Google seit 2012 in einer Studie zur Effektivität von Teams sehr eindrucksvoll erarbeitet.

Scrum setzt auf Teamarbeit

Agile Frameworks wie Scrum (Unser Trainingsangebot) setzen klar auf die Organisation von Arbeit für Teams und nicht für Einzelpersonen. Agile Frameworks wie Scrum setzen klar auf die Organisation von Arbeit für Teams und nicht für Einzelpersonen. Scrum ist ein leichtgewichtiges Rahmenwerk, das Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.

Das Team ist umsetzungs- und ergebnisverantwortlich

Das Team zieht sich Arbeits- oder Lieferpakete (Work Items, User Stories) aus einem priorisierten Backlog. Es ist dafür gemeinsam umsetzungs- und ergebnisverantwortlich. Das Team ist daher auch befähigt und berechtigt, sich die Arbeit für die Umsetzung und Lieferung selbst zu organisieren.

Steve Denning schreibt in diesem Zusammenhang auch vom “Law of the Small Team” als einem zentralen Element von Agilität.

Das Team organisiert sich die Arbeit im Sprint selbst

Das Team plant die Umsetzung der ausgewählten Arbeits- und Lieferpakete durch Zerlegung in kleinere Arbeitseinheiten von einem Tag oder weniger (Tasks, Aufgaben).  Wie dies geschieht, liegt im alleinigen Ermessen des Teams. Niemand sagt dem Team von außen, wie es seine Arbeit organisieren soll.

Das Team verwendet dafür zumeist ein Team-Board bzw. Task-Board, als visuelles Echtzeitbild der Arbeit, die das Team während des Sprints ausführt (Information Radiator). Das Board zeigt das Sprint-Ziel (warum ist der Sprint für das Team wichtig), die ausgewählten Arbeits- und Lieferpakete (was wird das Team liefern) sowie die Arbeitsschritte für die Umsetzung (wie organisieren wir die Arbeit im Team, um zu liefern).

Teamarbeit bedeutet Selbstbestimmung

Wenn das (Projekt-) Management die Liefer- und Leistungsfähigkeit über Teamarbeit steigern will, dann MUSS es den Teams zugestehen, sich die Arbeit selbst zu organisieren. Teams zu organisieren und trotzdem weiterhin Micromanagement zu betreiben durch Zuweisen von Aufgaben an Einzelpersonen, führt nicht zu mehr Leistungsmotivation, sondern im Gegenteil zu mehr Frustration und Verwirrung.

Konzernanwendungen als Hürde

Nach der Reorganisation finden sich „agile“ Teams in Unternehmen oftmals eingebettet in bestehende Konzern-Projektportfolios und die dafür definierten Konzernprozesse. Diese Abläufe sind gehärtet, sorgen für Stabilität und lassen sich nicht ohne erheblichen Aufwand anpassen.

Konzernanwendungen wie beispielsweise Atlassian Jira® unterstützen diese Prozessabläufe. Praktischerweise sowohl in der phasenbasierten Projektabwicklung als auch beim Umstieg auf „agile“ Teams.

Dies fördert jedoch die Verschränkung von traditionellen Projektmanagement-Praktiken mit „agilen“ Arbeitsweisen und die daraus entstehende Verwirrung. Beispielsweise führt das Projektmanagement oft klassische Aufgabenlisten (Jira® Tasks) nach der Reorganisation weiter als „Product Backlogs“. Beim Sprint Planning weist es weiterhin den einzelnen Teammitgliedern Aufgaben zu. Diese buchen dann über Jira® Tempo wie bisher die aufgewendete Arbeitszeit auf ihre Aufgaben für das Projekt Controlling.

Was wäre ein erster sinnvoller Schritt im Unternehmen?

In einem ersten Schritt sollte das Unternehmen ein kleines, überschaubares Pilotvorhaben nominieren, in dem die Arbeit tatsächlich einem Team übertragen wird und nicht einzelnen Personen.

• Der Product Owner des Teams erarbeitet für das Pilotvorhaben ein priorisiertes Backlog, als Liste von priorisierten, kleinteiligen Arbeits- und Lieferpaketen (Work Items, User Stories).
• Das Backlog enthält keine Aufgaben und Tasks für Einzelpersonen. Es legt nicht fest, wer was in einem Sprint erledigen muss!
• Im Sprint Planning zieht sich das Team in Abstimmung mit dem Product Owner Arbeits- und Lieferpakete aus dem priorisierten Backlog. Es organisiert sich danach die Arbeit selbst, also wer was im Team tun muss, damit das Team liefert (Aufgaben, Tasks).
• Am Sprintende zählt nur, ob es dem Team gemeinsam gelungen ist, die vereinbarten Arbeits- und Lieferpakete umzusetzen – wie immer es sich dafür die Arbeit auch organisiert hat.

Fazit und Take-Away

Die Führung muss agilen Teams zugestehen, sich die Arbeit selbst organisieren dürfen. Nur dann entsteht echte Teamarbeit. Und im Team wächst damit die Zuversicht, mehr Verantwortung zu übernehmen und eigenständig großartige Ergebnisse zu schaffen.