Nach wie vor gibt es einen Trend „agil“ zu werden. Die Hektik der Arbeitswelt scheint in Agilität eine passende Antwort erhalten zu haben. Kein Wunder verkünden viele Führungskräfte „wir müssen agil werden“. Ich habe meine ersten agilen Projekte Ende der 90er gemacht und habe viele Fehler bei der Umsetzung von Agilität miterleben müssen.
Agile Zusammenarbeit erfordert eine andere Zusammenarbeit im Team. Ein Team benötigt eine Entwicklung um zu diese Form der Zusammenarbeit zu erreichen. Den häufigsten Fehler, den viele Führungskräfte beim Umsetzen von Agilität machen ist, dass sie nicht in die Entwicklung des Teams investieren. Es werden lediglich agilen Methoden eingeführt in der Erwartung, dass sich dann die erhoffte Flexibilität und Geschwindigkeit einstellt.
Oft passiert dann das Gegenteil: die Vorteile der agilen Methoden kommen kaum zum tragen, die Arbeit wird zäher, die Mitarbeiter sind genervt.
Agilität enthält zwei Grundprinzipien
Eigentlich ist es sehr einfach zu verstehen, was Agilität leistet. Das lässt sich in 5 min. erklären (es lohnt sich also weiter zu lesen :-).
Doch die vielen Werte, Prinzipien und Methoden sind verwirrend und legen die beiden Grundprinzipien nicht wirklich frei. Kein Wunder also, dass selbst agile Coaches und Berater die Grundprinzipien nicht auf den Punkt bringen können. Wie sollen es dann Führungskräfte und Teammitglieder verstehen und umsetzen, wenn sich der Kern der Agilität hintern einem Haufen von Werten und Prinzipien verbirgt.
Agile Berater haben oft noch ihren eigenen Hintergrund, nicht selten kommen sie aus den Geisteswissenschaften, sozialen oder pädagogischen Wissenschaften. Ihre Interpretation von Agilität ist dann aufgeladen mit ihren persönlichen Anschauungen, wie die Welt zu einem schöneren Ort werden könnte.
Also, weg mit den Nebelkerzen. Wir stoßen zum Kern der Agilität vor.
Grundprinzip 1: Embrace your customer
Um es gleich vorweg zu schicken, dieses Prinzip war für die IT-Branche ein großer Schritt für andere Branchen ist es seit jeher eine Selbstverständlichkeit. Also nicht wundern, wenn es für dich ein alter Hut ist.
Bauen nach Spezifikation
In der Informatik war es lange üblich, dass man die Anforderungen an ein neues IT-System in einer Spezifikation aufgeschrieben hat. Dann hat sich das Entwicklungsteam daran gemacht, ein IT-System zu entwickeln, das diesen Anforderungen genügt. Dabei sind oft viele Monate (oft über ein Jahr) vergangen. Anschließend war vorgesehen, dass das neue IT-System anhand der Anforderungen in der Spezifikation abgenommen wurde.
Das klingt vollkommen logisch, funktionierte aber in der Realität nicht. Weil
- sich die Anforderungen im Laufe der langen Entwicklungsdauer massiv geändert haben. Bevor ein System fertig war, kamen z.B. neue gesetzliche Vorgaben oder eine geänderte Unternehmensstrategie heraus, die das System auch abbilden musste.
- sich die Anwender die abstrakten Beschreibungen der Spezifikation nicht vorstellen konnten. Erst als das Ergebnis sichtbar wurde, konnten Anwender genauer benennen was ihnen daran gefällt, mißfällt oder fehlt.
Im Ergebnis sind weiter über 50% aller IT-Projekte nicht zum gewünschten Ziel in der geplanten Zeit gekommen oder wurden bereits vorzeitig gestoppt.
Beim Frisör wäre das absurd
Man kann sich das so vorstellen: Eine Kundin geht zum Frisör und wird von einem Berater empfangen. Dieser beschreibt die Frisur, die diese Kunden gerne hätte in einer Spezifikation. Alles wirklich präzise: Haarlängen, Übergänge, Farben, Textur, etc.
Dann setzt sich die Kundin auf den Stuhl in einem spiegellosen Raum. Die Spezifikation bekommt die Frisörin und soll die Frisur genau nach diesem Dokument erstellen. Gespräche zwischen Kundin und Frisörin sind unüblich, schließlich müssen diese im Anhang der Spezifikation protokolliert werden. Ausserdem zahlt dann die Kundin für jeden Eintrag im Anhang einen kräftigen Aufpreis.
Ja, so war die IT-Welt noch in den 90ern. Du kannst dir selbst gut vorstellen, dass das nicht richtig funktioniert hat.
Kleine Fortschritte mit Kunden abstimmen
Das erste Grundprinzip der Agilität bedeutet, dass man kleine Fortschritte erzielt und diese den Anwendern zugänglich macht („inspect“). Die Rückmeldung sorgt dafür, dass man gleich reagiert („adapt“) und nicht noch lange den falschen Lösungen anhängt. Der Anwender ist also die lebende Spezifikation, die entscheidet, ob die fertigen Funktionen dem Bedarf entsprechen und welche Funktion als nächstes wichtig sind.
Grundprinzip 1 läßt sich als „inspect & adapt“ zusammenfassen.
Nur wenige Architekten, Handwerker, Künstler oder Verkäufer arbeiten mit einer abstrakten Beschreibung des Resultats und überraschen dann die Anwender irgendwann mit dem fertigen Resultat.
Was in der IT also wirklich ein großer Fortschritt war, ist für viele Branchen schon längst der Standard.
Beispielsweise fertigt ein Architekt ein Modell des Gebäudes an – inzwischen ein virtuelles Modell im Computer. Bauherren können sich dieses Modell ansehen und bekommen dann eine Vorstellung von dem Gebäude. Oft sind dann mehrere Schleifen nötig, bis das Modell dem Wunsch entspricht. Und auf der Baustelle ist es auch oft so, dass der Kunde einen Bauabschnitt begutachtet, bevor es weiter geht. So können Wünsche und Missverständnisse ausgeräumt werden, bevor sie sprichwörtlich festzementiert sind.
Also, gleich weiter zum Grundprinzip zwei.
Grundprinzip 2: Elevate your team
Dieses Grundprinzip taucht im agilen Manifest etwas versteckt auf. Das vorletzte der 12 Prinzipien lautet dort: „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.“ (Quelle: Prinzipien hinter dem Agilen Manifest)
Agilität erreicht man durch Selbstorganisation.
Unterschiede der Selbstorganisation
Wollwissend dass klassische Führung und Selbstorganisation auch in Mischformen existieren, möchte ich die beiden Organisationsformen in ihrer Reinkultur mal gegenüberstellen. Hier einige ausgewählte Punkte:
| klassische Organisation | Selbstorganisation |
|---|---|
| Mitarbeiter sind für ihre Aufgaben verantwortlich, Führungskraft für das Gesamtresultat der Gruppe | Das Team ist gemeinsam für das Gesamtresultat verantwortlich |
| Erfüllung eigener Aufgaben steht im Vordergrund | Ein optimales Gesamtergebnis steht im Vordergrund |
| Abgrenzung und Spezialisierung der einzelnen Mitarbeiter („nicht meine Aufgabe“) | Zusammenarbeit und kollektive Verantwortung |
| Probleme bei der Koordination und Integration der Teilergebnisse Einzelner. | Fortlaufende Koordination und Integration von Teilergebnissen durch das Team. |
| Kritisiere andere Mitarbeiter nicht und möchte keine Einmischung derer bei mir. | Jeder kann Missstände ansprechen, es gibt keine dunklen Ecken. |
| Aufgabengebiete werden mit Führungskraft geklärt. | Team klärt Aufgabenverteilung regelmäßig untereinander. |
| Blick auf das Ganze nicht nötig. | Jedes Teammitglied muss die Gesamtlösung verstehen. |
| Wichtige Entscheidungen trifft die Führungskraft. | Team trifft und trägt gemeinsam wichtige Entscheidungen. |
| Jeder schaut auf seine Vorteile, Konflikte werden von der Führungskraft geschlichtet. | Mitarbeiter blicken auf Teamvorteile, das Team entwickelt eine produktive Art der Auseinandersetzung. |
Die Abstimmung in der klassische Organisation kann man sich wie einen Stern vorstellen: die Führungskraft steht in der Mitte, die Abstimmung (z.B. Wer tut was? Wie lösen wir ein gemeinsames Problem? Was hat Priorität?) geht großteils über die Führungskraft.
Gerade wenn die Führungskraft nicht jederzeit dem Team zur Verfügung steht, und Abstimmung auf die Führungskraft warten müssen, dann kostet dies wertvolle Zeit.
Ein selbst organisiertes Team kann die Teaminternen Themen selbst klären, die Führungskraft setzt dem Team nur den Rahmen.
Preis der Selbstorganisation
Das klingt doch alles wunderbar, warum scheitern dann viele Führungskraft, die sich mehr Agilität und Selbstorganisation wünschen?
Kurz: Selbstorganisation entsteht eben nicht durch Verzicht auf Führung. Ich behaupt sogar das Gegenteil:
Es braucht eine gute Führung, damit ein Team sich auf eine gute Art selbst organisiert.
Wenn sich eine Führungskraft einfach nur zurücknimmt und das Team gewähren lässt sind zwei Szenarien typisch:
- ein Mitarbeiter ergreift die Chance und füllt das Machvakuum. Nicht selten herrschen diese dann recht Autorität im Team, was sie aber nach aussen gut zu verbergen wissen.
- keiner übernimmt eine Führungsrolle und es entsteht eine Hobby-Organisation. Die Verbindlichkeit nimmt ab, keiner fühlt sich mehr so richtig verantwortlich. Das Team verstrickt sich in längliche Diskussionen über unwichtige Themen.
Beide Szenarien sind kein Fortschritt, die bringen nicht die erwünschten Vorteile der Agilität: im ersten Szenario hat man die klassische Führung nicht verlassen, im zweiten Szenario entsteht eine gegenseitige Blockade.
Es braucht also eine gezielte Entwicklung des Team, so dass Selbstorganisation in einem guten Sinne gelebt wird.
Leider lernen wir in unserer Gesellschaft nicht wirklich die Zusammenarbeit in einer Selbstorganisation auf Augenhöhe. In der Schule, Berufsschule und Hochschule werden alle Lernenden einzeln betrachtet. Hausaufgaben sind von allen individuell zu machen, Test schreibt jeder für sich und erhält eine eigene Benotung.
Dennoch glauben die meisten Menschen, dass man mit den Worten „so, organisiert euch selbst“ bereits alles getan hat um ein starkes selbstorganisiertes Team zu erholen.
Die neue Rolle der Führungskraft
Führung auf die neue Art bedeute genau zu wissen, ob man eine Gruppe oder ein core-Team vor sich hat und wie man dieses führt.
core-Team = collective responsible Team
Während man bei einer Gruppe stärker nach den klassischen Prinzipien führt, ändert sich die Rolle der Führungskraft bei einem core Team massiv: Die Führungskraft…
- hält sich mit Fachexpertise zurück
- verweigert Entscheidungen, die das Team treffen kann.
- sorgt für gute Team-Prozesse (z.B. zur Entscheidungsfindung im Team)
- achtet darauf, dass sich alle Teammitglieder als Mensch willkommen fühlen
- bringt dem Team bei, inhaltliche Auseinandersetzungen in einem harten und produktiven Disput zu klären
- erzieht die Teammitglieder dazu, gegenseitig Verantwortung einzufordern
- usw.
Die Führungskraft ist also bei einem core Team nicht mehr vorrangig für die inhaltlichen Ergebnisse und deren Entstehung zuständig, sondern für das gute Miteinander des Teams.
Wenige Führungskräfte haben diese Rolle erkannt und beherrschen diese bereits. Die große Mehrheit glaubt immer noch, dass man mit ein paar agilen Methoden – wie Daily Meetings, Kanban-Board, Sprints, Retros, etc. – zum Ergebnis kommen kann.
Dafür habe ich noch nicht ein Beispiel erlebt!
Fazit: Willst du Agilität, dann erlerne die neue Rolle der Führungskraft!
Wenn du praktische Werkzeuge als Führungskraft brauchst, dann schau mal in den Kursbereich auf diese Web-Site oder schreibe mir eine Nachricht.