a Randstad company
Login
© Adobe Stock / Steve Lovegrove

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

10.09.2019
Gerd Meyring – Freiberuflicher Autor
Artikel teilen:

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. 

Der Mensch macht’s

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:

1. Frust und Angst bremsen Teammitglieder aus

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. 

2. Misstrauen fördert Abwehrhaltungen

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. 

3. Führungskräfte verhindern den agilen Wandel

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.

4. Agilität braucht eine neue Firmenkultur

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. 

5. Scrum Master genießen im Unternehmen keine Rückendeckung

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. 

6. Product Owner ohne Plan

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. 

7. Agilität ist nicht spontan

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. 

8. Meetings erfordern Disziplin und Vorbereitung

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. 

9. Keine Fehlerkultur, keine Feedbackschleifen

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. 

Lesermeinungen zum Artikel

4,9 von 5 Sternen | Insgesamt 13 Bewertungen und 10 Kommentare

  • Der überflüssige Spezialist

    SR am 16.10.2019 um 01.35 Uhr

    Als zertifizierter Scrummaster arbeite ich derzeit höchst erfolgreich in einem genialen, höchst agilen und kommunikativen Team, das seine Kraft und seinen Erfolg seit mehr als einem Jahr daraus zieht, dass wir eben gerade nicht Generalisten, sondern Spezialisten sind! Jeder im Team macht das, was er am besten kann und auch mag. Dabei verwenden wir agile Elemente wie Kanban Board, Planning, Commitment etc. Vor allem aber: wir schätzen und vertrauen uns und die Experten-Expertise des jeweils anderen ist Rückhalt und Garant für die anderen Teammitglieder. Keine endlosen Meetings und Diskussionen mehr! Einfach gemeinsamer Erfolg und damit einhergehend Vertrauen, Wertschätzung und massig Freiheit durch den Kunden. Sagte ich, dass ich Scrummaster bin? Agil und erfolgreich geht in Profi-Teams vielleicht besser ohne dogmatisches Scrum!

  • 6. Product Owner ohne Plan

    Pete McWilliams am 29.09.2019 um 21.30 Uhr

    Ich lese "Der Product Owner vermittelt zwischen dem Kunden und dem Entwicklungsteam.", also nicht zwischen Kunden und Scrum Master. War das wirklich so gemeint?

    Antwort von der GULP Redaktion

    Eigentlich tut er beides: Er arbeitet eng mit dem Scrum Master zusammen, steht aber auch für Rückfragen der einzelnen Entwickler parat.

  • Methodisch vorgehen

    Halstrick am 19.09.2019 um 20.21 Uhr

    Wer Agil unterwegs sein will, muss methodisch stark sein, denn nur so können die aufgezeigten Hindernisse überwunden oder umgangen werden.
    Agiles Engineering ist noch anspruchsvoller in der Umsetzung.

  • Richtig! - aber nicht ganz rund

    Anonymer Knowledge Base Leser am 14.09.2019 um 20.45 Uhr

    Jawohl, kurz & knapp & gut. Habe aus 49 J. IT Projekt zu ergänzen, dass die nachhaltig destruktiven Versäumnisse folgende, meist fehlende Elemente sind: Anforderungsmanagement e2e, ständige Effektivitäts-, Effizienz-, Fortschritts- & Wertschöpfungsprüfung der Teilergebnisse an den Zielen zusammen mit dem Auftraggeber, Nachhaltigkeitsabsicherung der Ergebnisse.

  • Präsentieren?

    Jelle van Wieringen am 13.09.2019 um 20.02 Uhr

    @All (Author und Leser) Wir haben eine Gruppe "Agile Crisis" (https://www.meetup.com/de-DE/Agile-Crisis/) wobei wir von Professional zu Professional über diese Themen diskutieren. Das Treffen findet immer remote statt (keine Reise nötig) und dauart meist von 18:00-19:00 an einem Wochentag (kurz). Hättet Ihr lust diesen Beitrag zu präsentieren?

    Antwort von der GULP Redaktion

    Hallo Herr Wieringen,

    es ehrt uns sehr, dass Sie uns bitten, unseren Beitrag zu präsentieren. Wir können Ihr Angebot leider nicht wahrnehmen, da wir keine Vorträge durchführen.

    Beste Grüße
    Ihre Redaktion

  • ...und deshalb...

    Dieter am 13.09.2019 um 12.59 Uhr

    funktionieren und scheitern die meisten sogenannten "agilen" Projekte auch. Mit Verlaub gesagt, im Grunde sind diese Methoden kontraproduktiv gegen den gesunden Menschenverstand. Ihre Zelebrierung hat schon esoterische Eigenarten angenommen. Wohlmeinend könnte man auch von Kokolores sprechen. Kanban ist empfehlenswert, wenn es darum geht, nur ja kein Schräubchen zu wenig zu haben. In der Fertigungsindustrie mit ihren Fabrikaktionsabläufen, von daher kommt es ja ursprünglich auch (Toyota).
    Scrum mutet eher wie eine erneut aufgeschriebene Ansammlung von Milchmädchenweisheiten an. Wohl dem, der meint damit glücklich werden zu müssen.
    Aber, viele neue unnütze Rollen (die niemand wirklich braucht) hat diese sogenannte "Agilität" geschaffen.
    Erinnert irgendwie an die Geschichte der fleißigen Ameise. Wer diese Geschichte nicht kennt, einfach "agil" googeln.
    In diesem Sinne...ich muss nun wieder in die nächste Besprechung, Meeting, Erfahrungsaustausch, Jourfix etc, Vielleicht komme auch mal wieder zum Arbeiten. Demnächst..naja.

  • Toller Artikel

    Tobias Hofer am 13.09.2019 um 10.23 Uhr

    Die Punkte sind alle nicht neu, aber es ist wichitg diese immer wieder zu erwähnen. Steter Tropfen höhlt den Stein. Danke!

  • Walter am 13.09.2019 um 10.18 Uhr

    Entweder man entwickelt Software oder man verwendet Scrum.

  • Nicht zu vergessen...

    Enrico Falk am 13.09.2019 um 06.53 Uhr

    Die meisten Unternehmen versuchen "Agile" zu machen, anstatt es zu sein / zu werden. Es ist leicht, Methoden und Prozesse einzuführen. Diese machen ein Unternehmen aber nicht agil. Sie sind lefiglich Vehikel, die helfen sollen, agile Werte, Prinzipien und das agile Mindset aufzubauen und zu verinnerlichen. Anstatt Unternehmen nun ihre Kultur an den Prozess anpassen, beginnen sie sehr früh damit, den Prozess an ihre bisherige Kultur anzupassen und merken dabei gar nicht, dass sie nun eine Abwärtsspirale anstoßen. Dies gilt für alle Ebnene eines Unternehmens. Das Ergebnis ist: "Agil passt nicht zu uns." Dabei wäre die treffendere Aussage: "Wir passen nicht zu Agil". Daher: Focus on becoming agile, instead of doing agile.

  • Gut

    A.D. am 13.09.2019 um 02.50 Uhr

    Den Artikel finde ich sehr gut.

    Aber ist das, was sowie so selbstverständlich ist, nicht genauso im Wasserfallmodell enthalten? Ich sehe da keine besondere Ausprägung von "Scrum". Project-Owner und Scrum-Master sind im Wasserfallmodell in der Rolle des Teamleiters vereint. Und regelmäßige Absprachen sowie Reviews gibt es dort auch. Ebenfalls den täglichen Austausch der Programmierer untereinander gibt es dort. ... Allerdings gibt es im Wasserfallmodell Spezialisten für Bereiche einer Software (Datenbank, Front-End, Services). Bei Scrum wird erwartet, dass jeder alle Bereiche gleich gut beherrscht, dass alle gleichgeschaltet denken und dass jeder über die Fortschritte und Konzepte des anderen - neben seiner eigenen Entwicklungstätigkeit - ständig 100 % informiert ist und bleibt. Das ist aus meiner Sicht eine utopische Illusion und nur bei kleineren Einzelprojekten überhaupt realistisch.

Weitere Kommentare anzeigen

Ihre Meinung zum Artikel

Bitte verwenden Sie keine Links in Ihrem Kommentar.

Ihr Kommentar wird zunächst geprüft. Möchten Sie informiert werden, wenn er veröffentlicht wurde?
Bitte tragen Sie dazu Ihre E-Mail-Adresse ein:
Wir konnten Ihre Bewertung leider nicht speichern. Bitte geben Sie zuerst Ihr Feedback ab.
Lieber Leser, vielen Dank für Ihr Feedback.
Ihre Bewertung für den Artikel wurde gespeichert. Wir prüfen Ihren Kommentar bezüglich Netiquette und Datenschutzrichtlinien und veröffentlichen ihn danach in Kürze. Sie werden von uns per E-Mail darüber benachrichtigt.
Ihre GULP Redaktion.

Ähnliche Artikel