Was heißt hier agil?

Agil ist das Gegenteil von schwerfällig, träge, unbeweglich. Was bedeutet das für die Teamarbeit?

Agile Methoden versuchen schwerfällige Planung aufzubrechen und offen zu sein für Veränderungen. Sie versuchen, leichtfüßige Abläufe einzuführen und überbordende Bürokratie auf ein sinnvolles Maß zurecht zu stutzen. Noch ist die agile Bewegung vor allem in der IT-Welt zu Hause mit Methodiken wie Scrum und Kanban. Doch zunehmend hält sie mit ihren Qualitäten auch in der Bürowelt Einzug und wird hier in nächster Zeit für nachhaltige Veränderung sorgen.

Unabhängigvon der detaillierten Ausprägung trifft man bei agiler Organisation immer wieder auf die gleichen Säulen der Zusammenarbeit.

• Statt allzu detaillierter Planung und Dokumentation nutzt man klare Ziele und Leitlinien, um in der Arbeit besser mit Veränderungen und Unerwartetem umzugehen.
• Team und Mitglieder übernehmen die Verantwortung für ihre Arbeit und entscheiden über das detaillierte Vorgehen.
• Man schafft Transparenz, in dem man die Aufgaben und die Abläufe sichtbar macht.
• Einfache klare Regeln und Werkzeuge sorgen für direkte Kommunikation und abgestimmte Vorgehensweisen.
• Rituale und Kreisläufe ermöglichen eine gemeinsame Betrachtung des eigenen Tuns und der Ergebnisse. Das liefert Ansatzpunkte für gemeinsames Lernen und laufende Verbesserungen.
• Bei aller Offenheit für Ungeplantes und Veränderungen bestehen agile Methoden in der aktuellen Arbeit auf verbindliche Vorgaben und Entscheidungen.

Gemeinhin wird das Agile Manifest von 2001 als Startschuss der agilen Bewegung angesehen. Damals trafen sich erfahrene Software-Entwickler und diskutierten gemeinsam neue Ansätze für besseres Arbeiten: Sie rieben sich an den großen Projektdampfern, die nach langer, detaillierter Vorbereitung auf den Weg gebracht, aber viel zu träge für Kursänderungen geworden waren. Aufoffensichtlich notwendige Veränderungen konnte man so nicht reagieren und erlitt deshalb regelmäßig Schiffbruch.

Auch wenn im agilen Manifest von Software-Entwicklung die Rede ist, so finden sich hier klar und verständlich die Werte, die ein agiles Arbeiten im Team ausmachen.

Aus dieser Keimzelle entwickelten sich verschiedene agile Methodiken und Rahmenwerke für die Projektarbeit und den Umgang mit Kollegen und Kunden: Scrum, Kanban, Xtreme, um nur einige zu nennen. Dazu weiter unten etwas mehr.

Die Software-Branche hat nicht alle Konzepte neu erfunden, sondern auf den Erkenntnisse der produzierenden Industrie aufgebaut und sie für die eigene Situation angepasst und angereichert. Allen voran Toyota schuf bereits in den 50er-Jahren prägende Grundlagen mit Lean Management, mit fortlaufender Verbesserung (Kaizen) und der Konzentration auf Qualität (TQM). Selbst Kanban (japanisch für Signalkarte) entsprang der Toyota-Werkstatt, ursprünglich ein Steuerungssysteme für den Materialfluss.

Kanban hat von den agilen Methoden die größte Beachtung außerhalb der IT gefunden, nicht zuletzt weil es sich anschaulich präsentiert und auf den ersten Blick einleuchtet. Die Aufgaben eines Team werden auf Karten geschrieben und in ihrem Arbeitsfluß an einer Pinwand sichtbar gemacht. Dabei optimiert Kanban den Arbeitsfluss durch WIP-Limits, durch Obergrenzen, wieviele Aufgaben pro Arbeitsphase gleichzeitig in Bearbeitung sein dürfen.

Doch Kanban ist viel mehr als nur ein Pinboard mit Karten, es ist ein Weg - so sagt Kanban-Protagonist David J. Anderson - gemeinsame Arbeit und Ergebnisse fortlaufend Schritt für Schritt zu verbessern. Kanban tritt gerade heraus aus seiner Fokussierung auf die Software-Entwicklung und begreift sich als Management-Rahmen für Wissensarbeiter.

Scrum hat sich in den vergangenen Jahren zum Standard-Verfahren für Software-Entwicklungsteams avanciert. Der Name Scrum ist keine Abkürzung oder Akronym, sondern ein aus dem Rugby entlehnter Begriff, der in den deutschen Rugby-Regeln als "Angeordnetes Gedränge" auftaucht und für die spezielle Art von Kooperation im Scrum-Team steht.

Scrum ist durch seine klaren Rollen und Regeln so populär geworden: Hier gibt es das Entwicklungsteam, das eigenverantwortlich alle technischen Fragen entscheidet. Dazu kommt der Product Owner, der alle fachlichen und inhaltlichen Fragen zum Produkt klärt und entscheidet, das gemeinsam entwickelt wird. Und schließlich gibt es im Team den Scrum-Master, der über die Einhaltung der Prozessregeln wacht und versucht, Entwicklern und Product Owner unerwartete Schwierigkeiten aus dem Weg zu räumen, die sie in ihrer Arbeit behindern.

Die Prozessregeln sind einfach. Sie unterteilen die Entwicklung eines Produkts in mehrere Teilabschnitte, von denen jeder funktionierende, fertiggestellte Features des Produkts fertigstellt. Auf diese Weise sollen greifbare Ergebnisse erzielt werden, die anschaulich und überprüfbar sind und ggf. zur Änderung der Planung führen. Die Teilabschnitte (ebenfalls sportlich "Sprints" genannt) sind geprägt von Planungritualen, die vom Ablauf und Teilnehmern genau definiert sind: der Planungssitzung, dem Ergebnisschau und der Reflektion am Ende, den täglichen Standup-Meetings, in denen sich die Teammitglieder auf den aktuellen Stand bringen (im Stehen, um Zeit zu sparen).

Gerade bei der Definition von klaren Rollen und hilfreichen Ritualen kann man von Scrum lernen, und von den vielen verblüffend neuen Wegen, die im Rahmen von Scrum entstanden sind, etwa das agile Schätzen von Risiken und Aufwänden für ein Projekt.

Die Methoden des Xtreme Programming konzentrieren sich auf den ersten Blick auf die handwerklichen Aspekte der Software-Entwicklung, da der Fokus insbesondere auf Qualität und Produktivität liegt. Bewährte Verfahren werden hier extrem angewandt, was zu auf ungewöhnliche Praktiken führt wie die Paar-Programmierung (zwei Programmierung arbeiten gemeinsam an der gleichen Aufgabe) und die Test-Zuerst-Entwicklung (bevor neue Funktionalität entsteht, wird ein Test gemacht, der sie testet). Der Qualitätsgedanke, der hier auf die Spitze getrieben wird, lässt sich dabei hilfreich auch auf Projekte außerhalb der IT übertragen, insbesondere durch die grundlegenden Werte von Xtreme: Kommunikation, Einfachheit, Rückmeldung, Mut und Respekt. Xtreme baut auf simple Strukturen, auf klare Planung und widmet sich ausschließlich bekannten Anforderungen (nicht solchen, die später noch auftauchen könnten oder auch nicht). Ein solches Vorgehen erfordert den Mut zu klaren Entscheidungen. Und es erfordert den Respekt vor sich selbst und den anderen. Denn der hält die Beteiligten davon ab, dem Team unvollständige oder gar schlechte Ergebnisse zuzumuten, und gibt ihnen zugleich das Selbstvertrauen, auch mit neuen Anforderungen und unerwarteten Veränderungen umzugehen. Wer solche Prinzipien ernsthaft in seine Teamarbeit einführt, wird nicht nur als Software-Entwickler davon profitieren.