1. Squads sollten auf Augenhöhe mit den Tribes sein, sind es aber in der Praxis oftmals nicht.

Dass die Squads eigenständig ihre Arbeitspakete bestimmen, ist für die Verantwortlichen des Tribes mitunter ein großes Problem - kommen doch von ihnen und vom höheren Management die umzusetzenden Inhalte. Die Tribes stehen zumindest formal an der Spitze, in ehemals hierarchischen Strukturen werden sie daher oft als Chefs angesehen.

Sie geben die Richtung vor, während die Squads "nur" die ausführenden Abteilungen sind. In einem Transformationsprozess, den ich begleiten durfte, wurden ehemalige Programmverantwortliche plötzlich als Tribe-Leads eingesetzt. Sie kamen nur schwer davon los, ihre Untergebenen anzuweisen und mit Command & Control zu führen. Statt mit einer Vision die Richtung vorzugeben, bestimmten sie kleinteilig die zu liefernden Inhalte.

Meine Aufgabe bestand zu einem großen Teil darin, dafür zu sorgen, dass die Squads trotz thematischer Vorgaben ihre Eigenständigkeit bewahrten. Zudem arbeitete ich daran, hierarchisches Denken aufzulösen. Ich habe den Fall erlebt, dass mein Squad die Priorisierung der Entwicklungsaufgaben anders auslegte als vom Tribe-Lead vorgegeben; wir mussten dann gemeinsam einen für alle Seiten akzeptablen Zeitplan erstellen, so dass die Vorgaben zwar erfüllt, das Squad aber möglichst eigenständig planen konnte. Das ist häufig ein Balanceakt, der viel Fingerspitzengefühl erfordert.

2. Ziele von Großprojekten werden oft nicht ausreichend kommuniziert.

Die Fokussierung auf ein gemeinsames Ziel ist bei Agilität extrem wichtig: Was soll mit der Entwicklung schlussendlich erreicht werden? Arbeitet das Squad an diesem Ziel, sollte es weitgehend selbstbestimmt entscheiden, wie der Weg dorthin aussieht.

Dabei ist es völlig verständlich, dass ein Unternehmen einer Gruppe von 500 Personen nicht plötzlich ohne Einschränkungen oder Vorgaben erlaubt, in kleinen Teams hundertprozentig eigenverantwortlich zu arbeiten - zu viel Geld, das monatlich investiert wird, für zu wenig Kontrolle, die ausgeübt werden kann. Tatsächlich wird agile Freiheit von Mitarbeitern manchmal missverstanden, so dass Manager oft Angst haben, ihre Teams alleine arbeiten zu lassen.

Umgekehrt wissen die Teams häufig nicht, an welchen Zielen sie genau eigenständig arbeiten sollen. Wer liefert was und wann? Wie viel Investment muss ein Unternehmen tätigen, bis die geforderten Funktionen, Features, Tools, Entwicklungen fertiggestellt werden können? Und: Wer achtet darauf, dass einzelne Squads nicht in eine völlig falsche Richtung gehen? All dies sind Fragen, die gerade am Anfang einer agilen Transformation schwer zu beantworten sind. Ich rate daher dazu, die Vorgaben der großen Ziele, also was eigentlich erreicht werden soll, immer wieder in die Teams zu tragen.

"Wie oft sollen wir das denn noch sagen?"

Diese Aufforderung kann, wie in meinem Fall, dazu führen, dass das höhere Management fragt, wie oft sie ihre Ziele denn noch erklären sollten, langsam müssten es doch alle verstanden haben! Und wenn nicht, mögen sie die großen Ziele doch bitte untereinander teilen oder die angefügten Präsentationen lesen.

Ich erkläre ihnen dann, dass diese Methoden nicht funktionieren. Gerade große Teams und Gruppen brauchen immer wieder Anlässe, bei denen ihnen das große Ziel erklärt wird - ob täglich im Daily oder einmal die Woche in einem Status. Man könnte fast sagen: Je häufiger das große Ziel erklärt wird, je genauer dieses Ziel verstanden wird, desto besser und eigenständiger wird von allen Teammitgliedern genau in diese Richtung gearbeitet.

Oder um es mit einer Metapher zu sagen: Wenn ich weiß, dass ich nach Rom laufen soll, kenne ich den Weg oder die Wege dorthin vielleicht nicht genau, ich kenne aber das Ziel. An jeder Station, an jedem Bahnhof kann ich mich daher immer in Richtung Rom orientieren. Das hat weniger mit Vorgaben zu tun, sondern mit notwendiger Richtungsweisung.

Wenn die Teams die Richtung kennen, können sie schneller und eigenständiger dorthin gelangen. Es erstaunt mich immer wieder, wie eigenständig Teams arbeiten, wenn sie das große Ziel ihrer Bemühungen verstanden haben.

Ein anderes Problem in großen Unternehmen ist, dass die Umstellung auf agil oft schnell erfolgen soll. Die Wahrheit ist nach meiner Erfahrung aber: Es ist schwer, zäh und es dauert seine Zeit. Sind Unternehmen nicht bereit, dieses Investment zu tätigen, ist die Hoffnung meist schon am Anfang verloren. Eine übers Knie gebrochene Agilität hat zumindest in meinen Projekten noch nie vollends funktioniert.