Wie viel Agilität ist sinnvoll?

Agile Methoden haben sich durchgesetzt und werden stets weiterentwickelt. Parallel zur praktischen Anwendung und Entwicklung im Projektmanagement werden die verschiedenen Aspekte der Agilität auch medial und in der Fachwelt auf Blogs ständig neu bewertet und diskutiert. Unter den unendlichen Artikeln über agiles Management sticht ein Beitrag von Luk Van Wassenhove heraus, der auf Knowledge.insead.edu erschienen ist und sich mit der Frage befasst, was passiert, wenn agile Techniken nicht funktionieren. Luk Van Wassenhove sagt: Geben Sie nicht dem Team die Schuld – zumindest nicht sofort. Auf viele wirken der schnelle Rhythmus und die ständigen kurzlebigen Deadlines im agilen Management zu Beginn sehr hektisch. Immer ist alles dringend und das Team scheint kontinuierlich unter Druck zu stehen. Zwar sorgt dieser Druck für eine hohe Produktivität, allerdings müssen Teamleader immer den Mittelweg zwischen destruktiver Überforderung und Laissez-faire finden. Zu kurze Sprints sind nicht förderlich für die Leistungsfähigkeit des Teams. Legen Sie Ihren Fokus bei Softwareentwicklungsprojekten auf das Datensammeln, statt sich der Illusion von Kontrolle hinzugeben! Im Folgenden fassen wir die Thesen von Van Wasserhove zusammen.

Luk Van Wassenhove hat die Erfahrung gemacht, dass viele Firmen das agile Konzept auf ihre eigene Struktur anwenden bzw. „überstülpen“ und dabei zu wenig auf die Auswirkungen achten, die diese Umstellung auf die Teams haben wird. Agil ist gut, aber es gibt auch zu viel des Guten. Bestimmte Grenzen und Normen müssen eingehalten werden, sonst ziehen sich Probleme aus einem Sprint in die nächsten hinein und sammeln sich langsam an. Als Führungskraft müssen Sie unter allen Umständen diese Art von Teufelskreis zu vermeiden. Ihre Aufgabe ist es, zu erkennen, wann der Druck zu hoch wird und wann der Druck zu Fehlern und zu schlechter Qualität führt. Luk Van Wassenhove hat gemeinsam mit Kim van Oorschot von der norwegischen Business School und mit Kishore Sengupta von der Cambridge Judge Business School an Forschungsprojekten zum Thema Software-Projektmanagement gearbeitet. Die drei haben eine Arbeit veröffentlicht, die den Titel „unter Druck“ trägt. Darin zeigen sie gemeinsam auf, dass der 20-tägige agile Arbeitszyklus nicht optimal für Qualität des Ergebnisses, die Kosten und die Projektdauer ist.

Das Team um Luk Van Wassenhove hat sich Gedanken gemacht, wie agile Methoden mit technischen Aspekten der Softwareentwicklung und dem menschlichen Faktor am besten in Einklang gebracht werden können. Das Lernen, Erfahrung und Arbeitsrhythmus spielten dabei eine Rolle. Sie verwendeten für ihre Betrachtungen Daten aus dem wirklichen Arbeitsleben, nämlich ein Projekt, an dem fünf Personen 260 Tage lang gearbeitet hatten. Untersucht wurden die Effekte von längeren und kürzeren Sprints, von Sprints unter Druck, das Verhalten der Teammitglieder und die Leistungsfähigkeit. Ergebnis der Studie war, dass die Menschen am besten und effizientesten in der Softwareentwicklung tätig waren, wenn ihre Sprints zwischen 43 und 65 Tagen lang waren, also zwischen zwei und drei Monaten. Bei diesem Szenario waren auch die Kosten am besten eingesetzt.  Die Anzahl der unentdeckten Fehler lag bei dieser Geschwindigkeit fast 40 % unterhalb der Fehlerrate von schnelleren Projekten. Die Kosten konnten um über ein Viertel gesenkt werden. Die Teammitglieder leisteten bei dieser moderaten Geschwindigkeit zwar trotzdem einige Überstunden, aber nicht in dem Maße, dass es zu Erschöpfung oder dem Risiko eines Burnouts kam. Gleichzeitig führte die Reduzierung der Geschwindigkeit dazu, dass keine Abkürzungen gewählt und damit weniger Fehler gemacht wurden. Am Ende der Arbeit betonen die drei Autoren, dass die ideale Länge und Geschwindigkeit eines Projektes immer vom Projekt und seinen spezifischen Eigenheiten abhängt, nicht zuletzt auch deshalb, weil Kunden unterschiedliche Toleranzen haben, was Fehler betrifft. Selbstverständlich spielt auch die Frage eine Rolle, ob das Produkt unbedingt schnell auf dem Markt sein muss oder ob es wichtiger ist, ein fehlerfreies und optimal laufendes Produkt zu launchen. Letzteres kann zum Beispiel bei militärischen Anwendungen, bei Software für Banken oder andere Bezahlsysteme der Fall sein, oder bei Projekten, in denen Datenschutz eine wichtige Rolle spielt. Dagegen wiederum gibt es Kunden, die maximal einen Monat Zeit haben, um eine App zu veröffentlichen.

Die meisten Firmen erfassen Daten wie die Anzahl von Fehlern und die Abweichung von Kosten und Fristen. Das ist zwar prima, aber es zeigt eben nicht das ganze Bild. Irgendwie sollte es auch möglich sein, den menschlichen Faktor zu erfassen, wenn es darum geht, zu evaluieren, wie gut oder schlecht ein Projekt gelaufen ist. Zwar ist es nicht einfach, zu messen, wie viel erschöpfter die Mitarbeiter bei diesem Projekt waren im Vergleich zum letzten, weil diese Werte immer subjektiv sind. Aber es sollte die Erfahrung der Teammitglieder auch in die Bewertung eingehen. Unzufriedene und ausgebrannte Mitarbeiter sehen sich vielleicht nach einem anderen Job um und es kostet bares Geld, neue Mitarbeiter suchen und einzuarbeiten. Ganz zu schweigen von der Tatsache, dass mit guten Mitarbeitern auch viel Wissen und Erfahrung verloren gehen.

Firmen wie auch Menschen suchen meist nach dem einfachsten Weg. Diese Tatsache ist wahrscheinlich der Grund dafür, dass sich nur wenige Firmen tatsächlich lange damit aufhalten, abgeschlossene Projekte umfangreich zu evaluieren. Es steht ja immer schon das nächste Projekt vor der Tür. Die Erkenntnisse, die man durch eine Evaluierung und Nachbearbeitung gewinnt, sind allerdings essenziell für den Erfolg der kommenden Projekte. Wer aus seinen Fehlern nicht lernt, macht diese immer wieder, vor allem wenn er nicht weiß, dass es Fehler sind. Die Chance, Erfahrung direkt aus einem abgeschlossenen Projekt zu sammeln und festzuhalten, ist unschätzbar und wird oft einfach nicht genutzt. Luk Van Wassenhove plädiert daher für die Nachbetrachtung von Projekten, insbesondere was die Auslastung, Belastung und eventuelle Überlastung von Mitarbeitern betrifft. Geschwindigkeit ist nicht immer das A und O. Agil bedeutet nicht immer, dass alles viel schneller gehen muss, sondern ist im besten Fall eine neue Art zusammen zu arbeiten, eine menschliche und flexible Art, Projekte zum Erfolg zu führen und die Teams leistungsfähig zu halten.