Kanban, Scrum & Co. – Neun Gründe, die agile Projekte scheitern lassen

Apollo 13 war kein schlauer Esel. Als er in dem Kultfilm „Der Schuh des Manitu“ Bahngleise überqueren soll, bleibt er stehen und wird von einer rasenden Dampflok – Inbegriff des technologischen Wandels im 19. Jahrhundert – überfahren. Unternehmen, die heute nicht mit den durch die Digitalisierung möglich werdenden immer kürzeren Produktlebenszyklen mithalten, geht es wie Apollo 13. Sie verschwinden vom Markt.

Neun von zehn Unternehmen entwickeln Produkte daher mit agilen Methoden wie Design Thinking, Xtreme Programming, Kanban, vor allem aber Scrum. Auf diese Arbeitsweise setzen 90 Prozent aller agil arbeitenden Unternehmen, ergab eine Umfrage des IT-Branchenverbands Bitkom.

Mit agilen Methoden erzielen sie bessere Projektergebnisse, sagen sieben von zehn Umfrageteilnehmer. Jeder zweite Befragte setzt auf Scrum & Co., weil er glaubt, Projekte so schneller abschließen zu können. Vier von zehn Umfrageteilnehmer wollen dadurch flexibler werden.

Doch Methoden des agilen Projektmanagements sind keine Wunderwaffen, die bestehende Wasserfallhierarchien effizienter und schneller machen. Sie versuchen, Rahmenbedingungen zu schaffen, unter denen Menschen ihr volles Potenzial entfalten, um flexibel auf sich wandelnde Kundenanforderungen oder Absatzmärkte reagieren zu können.

Scrum, Kanban oder Design Thinking führen deshalb nur dann schneller zu besseren Ergebnissen, wenn Führungskräfte die Mitglieder agiler Teams als Menschen ernst nehmen. „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen“, fordern die Unterzeichner des Agilen Manifests in den zwölf Prinzipien, auf denen dieses aufbaut. Wer dies nicht beherzigt, scheitert bei agilen Projekten aus folgenden neun Gründen:

Wer agile Methoden einführt, startet im Unternehmen einen Change Prozess. Dabei scheitert, wer die Ängste und Vorbehalte der Menschen nicht ernstnimmt, die die Veränderung mitmachen sollen.

Viele Kollegen sind unsicher und haben Angst, sich in Meetings lächerlich zu machen. Sie befürchten, austauschbar zu werden, wenn sie ihr Wissen mit anderen teilen.

Das verhindert, dass Kollegen wirklich miteinander kommunizieren. Selbstorganisierte, agile Teams sind jedoch nur dann erfolgreich, wenn sie sich ständig über den Fortschritt ihrer Arbeit austauschen.

Wo Fehler nicht erlaubt sind, erleben Menschen Meetings zudem oft als einen Ort, an dem sie sich rechtfertigen müssen. Das ganze Team traut sich dann zu wenig zu und setzt sich Ziele, die weit hinter seinem Potenzial zurückbleiben.

Herrscht in einem Betrieb ein Klima des Misstrauens, lassen sich solche Abwehrhaltungen kaum vermeiden. In einem agilen Unternehmen müssen Führungskräfte ihren Mitarbeitern wertschätzendes Vertrauen entgegen- und dies glaubwürdig zum Ausdruck bringen. Nur so ermutigen sie Kollegen dazu, ohne Angst vor Sanktionen Erfahrungen mit agilen Arbeitsweisen zu machen.

Sehen Mitarbeiter, dass sie mit Kanban oder Design Thinking Erfolg haben, können sie Eigeninitiative, Mut, eine offene Kommunikationskultur, die Bereitschaft, Wissen und Erfolge zu teilen und sich selbst zu reflektieren entwickeln. Dieses Mindset ist für die agile Projektarbeit unerlässlich.

Viele, vor allem mittlere, Führungskräfte lassen diesen Kulturwandel jedoch nicht zu, weil sie selbst Angst haben. Angst, Macht und Statussymbole wie ihre Assistentin oder ihr Einzelbüro zu verlieren. Sie befürchten, dass Misserfolge agiler Teams ihre Karriere stören. Deshalb sind sie nicht bereit, die Kontrolle über Projekte abzugeben.

Doch agile Teams müssen sich selbst organisieren dürfen! „Gebt euren Mitarbeitern ein Ziel und lasst sie arbeiten“, fordert Ken Schwaber, einer der Väter von Scrum.

Wenn die Geschäftsleitung Scrum und Kanban dann noch für Managementmethoden hält, die sich ohne grundlegenden Wandel der Firmenkultur umsetzen lassen, bleiben Hierarchien und Entscheidungskaskaden erhalten. Selbstbestimmt und eigenverantwortlich arbeitende Kollegen sind in solchen Betrieben im Grunde nicht gewollt.

Unternehmen verweigern Entwicklungsteams dann nicht nur, dass sie sich selbst organisieren. Bei Scrum verstehen sie auch die Rollen des Scrum Masters und Product Owners falsch.

Ohne einen starken Scrum Master steht das Team Forderungen des Kunden und der Geschäftsleitung jedoch schutzlos gegenüber. Die wichtigste Aufgabe des Scrum Masters ist es, unberechtigte Anforderungen vom Team fernzuhalten und alle Probleme aus dem Weg zu räumen, die den Fortschritt des Projekts behindern. Genießt der Scrum Master im Unternehmen nicht die nötige Rückendeckung, kann er diese Schutzfunktion nicht erfüllen.

Der Product Owner vermittelt zwischen dem Kunden und dem Entwicklungsteam. Er verantwortet das Budget und führt das Product Backlog so, dass das Team die wichtigsten Aufgaben zuerst erledigt. Außerdem sorgt er dafür, dass Sonderwünsche des Auftraggebers so an das Team herangetragen werden, dass dieses das Projektziel trotzdem ruhig und nach seinem eigenen Plan erreichen kann. Dazu muss der Product Owner auch auf die Erwartungshaltung des Kunden einwirken.

Gelingt ihm dies nicht, überfordert er das Team. Der Kunde bekommt ein Produkt, von dem er mehr erwartet, als es leisten kann. Nachbesserungen sprengen dann oft das Budget.

Um ihre Aufgaben erfüllen zu können, brauchen sowohl Scrum Master wie Product Owner außerdem ausreichend Zeit. Sie können nicht beliebig viele Teams betreuen oder ihre Rollen in Teilzeit erfüllen.

Product Owner und Führungskräfte, die Agilität mit der Erfüllung aller Kundenwünsche zu jeder Zeit gleichsetzen, schmeicheln zwar dem Auftraggeber, setzen jedoch die Motivation im Team aufs Spiel. Dieses muss darauf vertrauen können, dass es bei seiner Arbeit oder während eines Sprints an den Verpflichtungen gemessen wird, die es selbst abgegeben und im Backlog festgehalten hat.

Wird es laufend mit neuen spontanen Einfällen zugeschüttet, bricht es unter dem agilen Overkill zusammen. Teammitglieder haben nicht mehr den Eindruck, dass sie mit ihrem Engagement und ihrer Arbeit etwas erreichen. Die Folge: Frust, schlechter Code und Projekte, die nie zum Abschluss kommen.

Um dies zu vermeiden, müssen agile Teams ihre Arbeit ebenso gründlich planen, wie klassische. Der Planungsaufwand verteilt sich lediglich auf zahlreiche Meetings über die Laufzeit des gesamten Projekts hinweg. Allerdings gibt es auch Meetings, in denen es genau darum nicht geht – bei Scrum etwa das Daily. In diesem besprechen Teams ausschließlich den Fortschritt ihrer Arbeit und die Schwierigkeiten, auf die sie dabei stoßen. Wird das Treffen mit anderen Themen überlastet, lässt es sich nicht mehr in 15 oder 20 Minuten abschließen. Das hält Teammitglieder von der Arbeit am Produkt ab und nervt, wenn es jeden Tag passiert.

„Du bist vielleicht gerne den ganzen Tag in der Arbeit – ich gehe lieber surfen“, brachte Scrum-Guru Jeff Sutherland die Erwartung von Mitarbeitern daran auf den Punkt, dass Prozesse an ihrem Arbeitsplatz funktionieren und ihnen nicht unnötig Zeit stehlen.

Der Anspruch ist berechtigt. Schlecht vorbereitete und ausufernde Meetings zwingen Mitarbeiter zu unnötigen Überstunden. Das sorgt für Frust, höhere Krankenstände und führt irgendwann zu Kündigungen.

Nervige Meetings bringen irgendwann auch die produktive Kommunikation im Team zum Erliegen. Diese ist jedoch Voraussetzung regelmäßiger Feedbacks. Ohne sie funktioniert agile Entwicklung nicht. Nur wenn Teammitglieder Misserfolge und Fortschritte ständig reflektieren, lernen sie dazu. Nur dann vermeiden sie, den gleichen Fehler zweimal zu machen.

Erfolgreiche agile Teams holen sich auch Rückmeldung vom Kunden und testen ihre Entwicklung so frühzeitig, dass sie Bugs noch während der Projektlaufzeit ausbessern können. „Wenn Du einen Fehler machst, korrigiere ihn sofort“, rät Jeff Sutherland. „Lass alles andere liegen und kümmere Dich darum. Denn wenn Du es später machst, dauert es mehr als zwanzig Mal so lange.“ Eine derart produktive Feedbackkultur setzt jedoch voraus, dass Unternehmen Fehler als Chance nicht als Karrieretöter begreifen.

Zuerst gesehen bei Gulp. Verfasst von Gerd Meyring.