Abschied von Scrum „Der Prozess wurde unglaublich träge“
  • INSIDER
Bringt uns das agile Arbeiten mit Scrum wirklich schneller ans Ziel  - oder lähmen uns die starren Prozesse?

Bringt uns das agile Arbeiten mit Scrum wirklich schneller ans Ziel - oder lähmen uns die starren Prozesse?© Marie Maerz / photocase.de

Viele Unternehmen wollen agiler werden - und setzen dafür auf Scrum. Das Unternehmen von Björn Waide hat sich gerade bewusst von dieser Projektmanagement-Methode verabschiedet. Und alle fühlen sich befreit.

Während die meisten Unternehmen noch davon reden, sich durch Scrum agiler und schlanker aufzustellen, haben wir die Methode bei smartsteuer vor wenigen Wochen abgeschafft. Unser Fazit nach fünf Jahren: Das Projektmanagement nach der Scrum-Methode ist zu starr und spiegelt die unternehmenseigenen Anforderungen nicht (mehr) wider.

Scrum eignet sich wunderbar, um die Entwicklung von Produkten durch striktes Management in geregelte Bahnen zu leiten. Die Methode hilft dabei, wesentliche von unwesentlichen Features zu trennen, die Aufgaben entsprechend in sogenannten Backlogs zu priorisieren und so dafür zu sorgen, dass Ressourcen effektiv und effizient eingesetzt werden. Soweit die Theorie. Auch bei smartsteuer sollte Scrum genau dafür sorgen: die Planung und Entwicklung von Software-Features besser zu gestalten.

Anzeige

Wir hatten keine Lust mehr auf Verrenkungen

In der Praxis aber hat sich in den Jahren seit der Einführung von Scrum immer öfter das Gefühl im smartsteuer-Team breitgemacht, dass die Methode zu starr ist. Am besten lässt sich das wohl vergleichen mit Stützrädern, die helfen sollen, Fahrradfahren zu lernen: Am Anfang sind sie unabdingbar, um Sicherheit auf dem Sattel zu gewinnen und nicht gleich tausendmal zu stürzen; aber irgendwann stören sie dabei, das Gelernte auszureizen, scharfe Kurven zu fahren oder zu beschleunigen.

Oft war es so, dass die Kolleg*innen sich fachlich verrenken mussten, um die für die einzelnen Entwicklungszyklen gesteckten Ziele einzuhalten. Sie haben die Aufgaben dann nicht immer nach dem Prinzip “Wer kann was am besten” erledigt, sondern nach dem Prinzip “Wer kann das irgendwie umsetzen”. Dadurch hat das Team Projekte zwar qualitativ nicht schlechter umgesetzt; der Prozess wurde aber unglaublich träge.

So hat sich immer öfter der Gedanke eingeschlichen, dass das System nur noch um seiner selbst willen existiert. Im Zuge einer Re-Organisation unseres Unternehmens, bei der Hierarchien abgebaut und althergebrachte Jobprofile ganz bewusst aufgebrochen wurden, hat sich unser Entwickler*innenteam dazu entschieden, fortan nicht mehr mit Scrum zu arbeiten.

Unser neues Modell muss sich noch beweisen

Und nicht nur das: Auch das “Entwickler*innenteam” gibt es in dem Sinne nicht mehr. Unser neues Modell, das sich selbst noch als “work in progress” beweisen muss, sieht vor, dass wir je nach Anforderung an eine Aufgabe ein Team zusammensetzen aus unterschiedlichsten Mitarbeitern, die verschiedene Fähigkeiten mitbringen. Das haben wir schon eine Weile lang immer wieder so getestet und mit der Re-Organisation endlich zum Standard erklärt.

Wenn heute also ein Produktfeature gebraucht wird, arbeiten nicht nur Entwickler*innen daran, sondern auch Marketing- oder Steuer-Expert*innen. Die Teams, die sich immer wieder neu zusammenfinden und crossfunktional arbeiten, haben ohne Scrum mehr Freiraum, weil etwa die täglichen Status-Meetings entfallen.

Die Entscheidungsfreiheit ist für manche herausfordernd

Was für viele ungewohnt ist: Jeder einzelne muss seine Aufgaben jetzt selbst priorisieren. Wo früher Direktiven von Vorgesetzten und dann das demokratische Voting in Scrum für Orientierung gesorgt haben, muss jeder nun für sich entscheiden, welche Tasks wann zu erledigen sind, um ein Projekt zum Erfolg zu führen.

Tatsächlich ist das Trainieren des Entscheidungsmuskels ein wesentlicher Aspekt unserer Re-Organisation und des neuen Unternehmensmodells. Da “ohne Hierarchie” aber nicht “ohne Hilfe” oder gar “ohne Plan” bedeutet, fangen die Kolleg*innen einander bei Bedarf auf, zudem stimmen wir uns mindestens monatlich im gesamten (!) Team ab.

Einmal im Monat kommen alle zum Thesenbasar

Dieses Meeting, bei dem wirklich alle dabei sind, nennen wir bei smartsteuer “Thesenbasar”. Dort kann jede*r Mitarbeiter*in ein Thema vorschlagen, an dem er oder sie gern arbeiten möchte. Die einzige Bedingung dabei ist, dass das Thema auf unsere Vision einzahlen beziehungsweise uns helfen soll, unsere strategischen Ziele zu erreichen.

Wird eine Idee in den Raum gestellt, gibt es zwei Feedback-Runden: In der ersten Runde sagt reihum jede*r im Team, warum diese Idee nicht funktionieren kann, welche Risiken sie birgt und was gegen die Umsetzung spricht. In der zweiten Runde sagt reihum jede*r, wie aus dieser Idee eine noch viel, viel bessere Idee werden kann. Der/die Ideengeber*in nimmt das kritische wie bestärkende Feedback mit, überarbeitet ihren oder seinen Vorschlag und stellt ihn – in angepasster, weiterentwickelter Form – beim nächsten Thesenbasar wieder vor.

Jeder bekommt die Chance, gute Ideen in die Tat umzusetzen

Nun wird mit den Füßen statt mit Post-Its abgestimmt: Wer das Thema in den kommenden Wochen und Monaten bearbeiten will, stellt sich auf die Seite des/der Ideengebers*in. Kommen genügend Leute zusammen, kann das Projekt in Angriff genommen werden. Bewusst lassen wir hier nicht – wie etwa bei Scrum-basiertem Projektmanagement – demokratisch über jede Idee abstimmen. Warum? Weil die besten Ideen oft nicht die sind, die spontan und initial die meisten Stimmen bekommen.

Gute Ideen hinterfragen Bewährtes und bringen Lösungsansätze mit, die noch nicht erprobt sind. Das löst oft Zurückhaltung aus oder gar Ablehnung (“Das kann nicht funktionieren!”). Demokratische Verfahren führen daher oft zu “Durchschnittslösungen”, nicht zu echter Innovation. Bei manchen Unternehmen werden solche guten, aber gewagten Ideen einfach von oben durchgesetzt. Das widerstrebt unserer Philosophie, weswegen jede*r die Chance bekommt, gute Ideen in die Tat umzusetzen. Beweisen müssen sie sich am dann Markt.

Der Thesenbasar ist für uns bei smartsteuer ein wesentliches Instrument geworden, das das starre Gerüst von Scrum überflüssig macht. Wir wissen: Dies muss noch nicht der Weisheit letzter Schluss sein – und bleiben offen für neue Methoden und Impulse.

Wie gehen Sie in Ihrem Unternehmen mit agilen Methoden wie Scrum um? Welche Limits spüren Sie?

Besser führen. Ziele erreichen. Mehr verkaufen

An der impulse-Akademie arbeiten wir mit Ihnen an der Zukunft Ihres Unternehmens und Ihrer persönlichen Weiterentwicklung. Für alle Seminartermine 2020 gibt es aktuell 20 Prozent Rabatt. Jetzt Seminar buchen!
39 Kommentare
  • Anonymous 29. Dezember 2019 10:15

    Das nächste Mal bitte auf Strelecky und sein Buch BIG FIVE FOR LIFE verweisen und nicht seine Ideen als Ihre eigenen wiedergeben…

  • Philipp 20. Dezember 2019 08:36

    Ich habe das Gefühl, dass Scrum hier nicht als Toolbox oder Framework verstanden wird, sondern als Methode oder Prozess. Scrum will nicht Allheilmittel sein. Aber eins irritiert mich:

    Ein Scrumteam soll immer alle Fähigkeiten und Kenntnisse vereinen, die für die Entwicklung (und hier ist in einem typischen unternehmerischen Umfeld nicht nur von Softwareentwicklung sondern auch von der Entwicklung fachlicher Themen auszugehen) notwendig sind. Dementsprechend wurde bei der Reorganisation ein großer Missstand behoben, der aber nicht durch das Framework Scrum bedingt war. Scrum ist eigentlich nicht dazu gedacht, dass man von oben besser „leiten“ kann, sondern um selbstbestimmte Teams zu schaffen. Teams die über ihre Bereiche Autonomie haben. Klar, scaled Scrum ist eine riesige Herausforderung, aber es klingt für mich so, als hätte hier bei der Einführung von Scrum nicht etwas Sorgfalt und Erfahrung mit Scrum gefehlt. Trotzdem ist der Artikel ein interessanter Einblick, diese „Scrum ist tot“ – Betitelung des Artikels finde ich aber viel zu reißerisch, ich hätte mir da doch mehr kritische Auseinandersetzung und Argumentation gewünscht.

  • Anonymous 17. Dezember 2019 12:14

    Scrum ist kein Allheilmittel. Es kommt immer darauf an, in welchem Umfeld und mit welchem Ziel es implementiert wird. Einige hier heben es in den „heiligen“ Status, was defacto falsch ist. Wenn sich ein Unternehmen aktiv davon verabschiedet, sollte auch dies genauso akzeptiert werden, wie einige andere erfolgreiche Implementierungen.
    Aus eigener Erfahrung kenne ich ebenfalls das mögliche Scheitern von Scrum.

  • A.M. 16. Dezember 2019 09:59

    hier scheitert nicht Scrum an sich, sondern seine Umsetzung in einem bestimmten unternehmerischen Kontext. Wir wissen nichts über die gelebte Kultur, über die Motive für die Scrum-Einführung sowie über ihre Qualität. Wir kennen auch die „unternehmenseigenen Anforderungen“ nicht. Wir wissen nur, dass es viele Unternehmen gibt, die durch Scrum wieder erfolgreich wurden und vielleicht noch mehr, die es nie werden. Woran kann das nur liegen?

  • Thomas Manthey 16. Dezember 2019 08:01

    Ich möchte Ihnen dazu gratulieren, dass Sie es trotz des schwachen Verständnisses von Scrum in Ihrer Organisation mit dieser Re-Organisation augenscheinlich schaffen, einer korrekten Implementierung ein Stück näher zu kommen! Weiter so, noch ein paar Iterationen mit guten abschließenden Retrospektiven und sie könnten es schaffen.

  • Frank 15. Dezember 2019 07:38

    Das beste an dem Artikel sind die vielen Kommentare. Die zeigen, dass Agiles Arbeiten ein relevanter Faktor geworden ist und die Entwicklung weitergeht. Die waren Verlierer sind diejenigen, die sich nicht mit dem Thema auseinandersetzen, um dann anschließend den eigenen Weg (im eigenen Kontext) zu gehen.

  • Ste 13. Dezember 2019 15:52

    Die Eltern, die ihren Kindern das Fahrradfahren in der heutigen Zeit noch mittels Stützrädern beibringen, sind wahrscheinlich dann auch solche, die Scrum nicht richtig verstehen ;)

  • Praeceptor 13. Dezember 2019 09:42

    Prima, dass Scrum dabei geholfen hat, Crossfunktionale Teams zur Selbstorganisation zu führen. Schade dass dies durch Missverständnisse im Umgang mit Scrum enstanden ist.
    Wenn sich smartsteuer jetzt am Agilen Manifest orientiert und seine eigenen auf sich passenden Methoden entwickelt ist das super.

    Wichtig ist am Ende nicht ob Methode XYZ „richtig“ umgesetzt wurde, wichtig ist das auch smartsteuer etwas gefunden hat was ihnen weiterhilft.

    Unschön ist, dass jetzt falsche Aussagen zu Scrum gemacht werden wie „Das tägliche Statusmeeting“, etc. denn Teil bitte weg lassen. Danke.

  • Savigue 13. Dezember 2019 09:04

    Scrum ist kein Allheilmittel, und wie vielfach schon erwähnt wurde, sollte es zu keinem Dogma werden. Idealerweise ist es gut Scrum mit anderen Ansätzen zu verbinden wie z.B. Domain Driven Development oder DDD, um sich klar zu machen, dass Entwickeln von Software nicht nur eine Technik ist, sondern von Bedürfnissen aller Stakeholder gesteuert wird, aber vor allem zum Ziel hat eine bestimmte fachliche Anforderung nach allen Regeln der Zunft umzusetzen.

    Oder anders gesagt, alle die mit der Entwicklung einer Software in Berührung kommen, sollen ein tiefes Verständnis dafür entwickeln, was sie da tun und nicht einfach nur einen Punkt im Backlog abhaken. Ich denke dann bekommt man auch eine Software, mit der man arbeiten kann.

  • Gerald Fiesser 13. Dezember 2019 06:14

    Der Artikel gehört unter die Rubrik „Satire“.

  • Danke 12. Dezember 2019 20:03

    Dafür ist Dein Beitrag sehr wertvoll.

  • Danke 12. Dezember 2019 20:01

    Danke für den respektvollen Beitrag

  • Peter Schönweitz 12. Dezember 2019 19:20

    Danke, Thomas!

  • Scrummer 12. Dezember 2019 12:06

    Danke für den Artikel/Praxisbericht – wie man an den Kommentaren sieht ist Theorie (Kommentare) und Praxis nicht immer gleich…

  • Scrum Master 12. Dezember 2019 09:57

    Hier wurde Scrum eindeutig über viele Jahre nicht verstanden und auch nicht angewendet. Da hätte ich von jemandem der das „agile Arbeiten“ als Thema hat und prägt deutlich mehr erwartet. Scrum ist sicher kein Allheilmittel aber über etwas zu urteilen was Sie so eindeutig falsch verstanden und umgesetzt haben ist schon irgendwie starker Tobak.
    Und das sage ich als Team Leader, Software Entwickler und Scrum Master.

    Hier nur Einige Beispiele:

    [„striktes Management „]
    Nein Scrum ist ganz und gar kein striktes Management.

    [„Oft war es so, dass die Kolleg*innen sich fachlich verrenken mussten, um die für die einzelnen Entwicklungszyklen gesteckten Ziele einzuhalten“]
    Das Entwicklungsteam committed sich nicht zur vollständigen Erreichung aller Items im Sprint Backlog. Zudem ist das Sprint Backlog kein Vertrag, sondern eine Abschätzung was das Entwicklungsteam im nächsten Sprint für realistisch möglich hält. Es sollen auf keinen Fall Verrenkungen (ich denke mal im Sinne technischer Schulden) gemacht werden um das Sprint Backlog vollständig abzuarbeiten. Hier ist es Aufgabe des Managements zu verstehen, dass besonders in komplexen Umgebungen wie der Softwareentwicklung eine genaue vorgängige Zeitabschätzung meistens überhaupt nicht möglich ist. Wenn Sie nun von Ihren Mitarbeitern erwarten, dass diese alle Items auf dem Sprint Backlog zum „Zieltermin“ umsetzen, sprich sie für ihre Zeitabschätzung voll umfänglich haftbar machen, haben Sie Scrum und Softwareentwicklung nicht verstanden.

    [„Unser neues Modell, ….. ein Team zusammensetzen aus unterschiedlichsten Mitarbeitern, die verschiedene Fähigkeiten mitbringen. „]
    [„Wenn heute also ein Produktfeature gebraucht wird, arbeiten nicht nur Entwickler*innen daran, sondern auch Marketing- oder Steuer-Expert*innen. „]
    Schade dass sie das nicht von Anfang an gemacht haben. Ein Entwicklungsteam im Scrum ist per Definition crossfunctional. Also genau das was sie scheinbar neuerdings machen aber als sie noch „Scrum“ machten eben nicht.

    [„Die Teams, die sich immer wieder neu zusammenfinden und crossfunktional arbeiten, haben ohne Scrum mehr Freiraum, weil etwa die täglichen Status-Meetings entfallen.“]
    Es gibt im Scrum kein tägliches Status-Meeting. Es gibt nur den Daily Scrum und der ist vieles aber auf keinen Fall ein Status-Rapport. Es geht vielmehr darum zu schauen ob man sich gegenseitig helfen kann, das nichts vergessen geht usw. Kollaboration ist das Stichwort. Davon abgesehen sind es 15 min am Tag. Wenn ihre Entwickler wegen diesen 15 min nun mehr Freiraum haben, haben sie ein anderes Problem.

    [„dann das demokratische Voting in Scrum“ ]
    [„Bewusst lassen wir hier nicht – wie etwa bei Scrum-basiertem Projektmanagement – demokratisch über jede Idee abstimmen.“]
    Es gibt kein demokratisches Voting im Scrum. Einzig der Product Owner bestimmt was gemacht werden soll. Natürlich in Abstimmung mit Kunden, Stakeholdern und auch dem Entwicklerteam. Aber die Entscheidungshoheit liegt schlussendlich beim PO. Das Entwicklerteam kann in der Sprintplanung einzig zusammen abschätzen wie viele Product Backlog Items die ganz oben im Backlog stehen denn im nächsten Sprint umgesetzt werden können. Das ist eine reine Abschätzung und hier geht es darum dass zusammen im Team zu machen, damit alle wissen worum es eigentlich geht.

    [„Scrum-basiertem Projektmanagement „]
    Scrum managet keine Projekte. Es dreht sich vielmehr im Produkte!

    Freundliche Grüsse,
    Thomas Kuschel

  • Björn Waide 12. Dezember 2019 09:39

    Vielen Dank für die zahlreichen Kommentare und die rege Diskussion. Gerne gehe ich auf einige Anmerkungen ein, die ich in folgende etwas spitz formulierte Kategorien fasse:

    – Scrum wurde nicht verstanden, deswegen konnte es ja nicht funktionieren.
    – Scrum ist Agile, Agile ist Scrum.

    Interessanterweise wird der erste Kritikpunkt oft mit Verweis auf vom „Scrum Guide“ abweichende Sprache oder dort nicht erwähnte Methoden und Konzepte gebracht, während gleichzeitig vehement darauf gepocht wird, dass Scrum ja gar kein festgeschriebener Prozess sondern nur ein Framework sei.
    Ich habe in 10 Jahren Beschäftigung mit Scrum und der Einführung in 3 Unternehmen die Erfahrung gemacht:
    Wer Scrum nicht „by the book“ einführt, wird sehr wahrscheinlich aus Unzufriedenheit scheitern. Wer Scrum nach 2 Jahren aber immer noch „by the book“ lebt ebenfalls.

    Den zweiten Kritikpunkt spricht niemand offen aus, scheint mir aber vielfach implizit gemeint zu sein. Wenn man sich ansieht, wie die großen erfolgreichen Internet-Konzerne Facebook, Apple, Google, Amazon damit umgehen, wird überrascht feststellen, dass in keinem Scrum als alleinige Methode vorgegeben ist. Tatsächlich suchen sich die Teams in der Regel selbst aus, was zu ihnen und der konkreten Aufgabenstellung passend scheint.
    Von einem Entwickler bei Facebook und Uber:
    „We meet when we need to meet and track what we need to track. Doing „official“ scrum is more about checking off boxes than actually getting work done better and faster.“

    Ganz sicher sind all diese Unternehmen aber agil bis tief in ihre DNA.

    Was sagt uns das jetzt: für die Transition von klassisch zu agil ist Scrum ein kaum zu überschätzendes Tool. Wenn die agilen Werte aber einmal verinnerlicht sind und auch technisch ein Unternehmen so weit ist, dann ist Scrum ein Werkzeug von vielen und man muss sich vor der Anwendung überlegen, ob man wirklich einen Nagel oder doch eine Schraube in der Hand hält.

    Wir bei smartsteuer hatten die letzten 5 Jahre eine Menge Nägel in die Wand zu hauen und waren da auch dank Scrum sehr erfolgreich. Die Herausforderungen, die vor uns liegen, sind aber anderer Natur (Schrauben), daher passen wir unsere Werkzeuge an.

  • Alex 12. Dezember 2019 09:12

    Hört sich für mich so an, als würde man jetzt anfangen Scrum zu machen? ;-) Die Frage ist, was hat man versucht die vielen Jahre davor zu machen? Scheinbar kein Scrum – schön aber, dass Ihr jetzt die Agilität für Euch entdeckt zu haben scheint :-)

  • Herbert 12. Dezember 2019 08:31

    Der ganze Artikel ist Müll. Ich weiß gar nicht, wo ich anfangen sollte… allein die pseudoneutrale Genderscheisse nervt mich dermaßen an, dass ich das Lesen abbrechen musste… pfui deifel!!

  • Lukas Häfele 12. Dezember 2019 08:05

    Ja dieser Antwort kann ich zu 100% zustimmen.

  • Kleinkarriert... 12. Dezember 2019 01:46

    Wie kleinkarriert muss man sein, um nicht auf bessere Ideen zu kommen… :-) …

  • Markus 11. Dezember 2019 22:41

    Schade, ich dachte, dass ich impulse finde, warum Scrum scheitern könnte, damit man diese Fehler vermeiden kann. Leider zeigt der Artikel nur, dass Scrum schlicht nicht verstanden und gelebt wurde. Gescheitert sind hier das Coaching und der Wille sich zu ändern. Besonders traurig ist, dass dieser Artikel scheinbar direkt vom Geschäftsführer kommt. Anhand der Kritikpunkte mutmaße ich, dass wohl vor allem das Management selbst mit Scrum nicht zurecht kam und sich daran gestört hat, dass Management im agilen Umfeld eher ein Hindernis als eine Hilfe ist, wenn es permanent versucht zu steuern und die Priorisierung des Backlogs beeinflusst, ohne dabei die Value sinnvoll im Blick zu haben.

    Sehr enttäuschend, wirklich.

  • Klaus 11. Dezember 2019 22:21

    Danke für die Klarstellung. Ich hatte es damals bei Ken Schwaber kennengelernt.

  • Anonymous 11. Dezember 2019 19:44

    Ich habe das Gefühl, der Auto hat Scrum nicht ganz verstanden.
    Ich finde den Artikel generell ganz gut, aber da stehen auch ein paar Sachen drin, die nicht viel mit Scrum zu tun haben.

    Was für ein Modell ihr Unternehmen bisher genutzt hat (vielleicht eine an Scrum angelehnte Vorgehensweise), viel Glück mit dem neuen Vorgehen.

  • Anonymous 11. Dezember 2019 18:44

    Ich verstehe den Vorwurf, der Autor habe Scrum nicht verstanden, nicht. Oder ist es eine Meinung, weil das so geliebte Scrum nicht immer als Allheilmittel akzeptiert wird?

    Eine solche vorschnelle Wertung finde ich persönlich unangemessen zumal ich mich vielen Punkten wiederfinden konnte.

    Ich erlebe Scrum leider auch als teilweise starres System bzw. wird so von Menschen gelebt. Als Besteller habe ich stets eine gewisse Unsicherheit.

    Ich mag viele Scrum Aspekte, glaube aber dass es keine Blaupause geben kann, die immer passt. Es darf sich kritisch betrachtet werden. Ein bisschen weniger nahezu religiöse Verhaltensmuster und mehr Gelassenheit der Scrum Jünger ist sicher angebracht.

  • Esoterik 11. Dezember 2019 18:40

    Immer wieder scheitert Scrum, weil es „nicht richtig verstanden wird“
    Warum wirds nicht richtig verstanden?
    Weils nur leeres Gefasel ist!

    Da werden Rollen geschaffen, die keiner braucht(Scrum Master) ohne Mehrwert oder Output. Aber die können eben behaupten, man hätte es nicht verstanden.

    Schreibts mal den Scrum Guide so, dass er nicht missverstanden werden kann bzw. machts was Sinnvolles

  • Valuemanager Ninaus 11. Dezember 2019 18:15

    Habe ich auch festgestellt in meinem beruflichen Umfeld.
    Mit Value Engineering sind wesentlich besser erprobte Arbeitsabläufe realisierbar.

  • Herrman 11. Dezember 2019 17:13

    Ohje, was sehen meine entzündeten Augen hier nur. Ich möchte wirklich niemanden auf die Füße treten, aber es sind einfach fundamentale Fehler drin. Einige Beispiele:
    „Scrum eignet sich wunderbar, um die Entwicklung von Produkten durch striktes Management in geregelte Bahnen zu leiten.“
    Die Worte strikt und Management zu nutzen um Scrum zu beschreiben grenzt an Blasphemie. Scrum lehrt INSPECT und ADAPT, also analysieren und sich entsprechent anpassen, von „strikt“ kann hier nicht die Rede sein. Und Scrum selbst ist so leichtgewichtiges Framework, welches Selbstorganisation des einzelnen fordert. Management? Wohl kaum.

    „[…] dass die Methode zu starr ist“
    Das mag für das Unternehmen zutreffen. Und es ist meiner Meinung nach gut, wenn sie eine für sie bessere Methodik gefunden haben, aber inwieweit ist denn Scrum mit 3(+1) Meetings (pro 2-4 Wochen) und 3 Artefakten zu starr? Vor allem wenn 2 Meetings darauf ausgerichtet sein sollten sowohl das Produkt als auch die Arbeitsweise anzupassen? Das starre in dem Unternehmen kommt nicht durch Scrum und wird durch ein anderes Framework nicht gelöst.

    „[…] sondern nach dem Prinzip “Wer kann das irgendwie umsetzen”“
    Hier wird eindeutig nicht weit genug gedacht. Wenn Hierarchien abgebaut werden, jeder allerdings weiterhin Spezialist in seiner Domäne bleibt, wie werden dann Karrieremöglichkeiten geschaffen? Das wird sicherlich nur so weit gut gehen bis den Mitarbeitern auffällt, dass sie keinerlei Aufstiegsmöglichkeiten mehr haben und dann in ein anderes Unternehmen wechseln.

    „[…] dass wir je nach Anforderung an eine Aufgabe ein Team zusammensetzen aus unterschiedlichsten Mitarbeitern […]“
    Ok gutes Konzept, benötigt allerdings ein starkes Management, um jeden Mitarbeiter entsprechend auslasten zu können. Auch hier sehe ich langfristig enorm viel Frustpotential.

    „[…] haben ohne Scrum mehr Freiraum, weil etwa die täglichen Status-Meetings entfallen.“
    Das hört sich sehr nach einem 1-stündigen Daily an. Das Daily sollte auf 15 Minuten getimeboxed werden. Wenn es länger dauert ist das ein Anzeigen dafür, dass Unnötiges besprochen wird oder es zu einem Statusreport an den PO ausartet. Beides muss vermieden werden.

    „[…] Wo früher Direktiven von Vorgesetzten und dann das demokratische Voting in Scrum für Orientierung gesorgt haben […]“
    Demokratisches Voting in Scrum? Die Hauptaufgabe des PO ist ROI. Demnach sollte er wohl das Backlog nach den Kundenwünschen Priorisieren. Natürlich können die Entwickler Vorschläge einbringen, sollte es technisch gesehen Sinn machen, die Prio zu ändern. Ein demokratisches Voting sollte das aber wirklich nicht sein, sondern ein Team (PO + Devs), dass sowohl Benutzerbedürfnisse und die hinterliegende Technik verstehen um somit die besten Entscheidungen treffen kann.

    „[…] Kommen genügend Leute zusammen, kann das Projekt in Angriff genommen werden. Bewusst lassen wir hier nicht – wie etwa bei Scrum-basiertem Projektmanagement – demokratisch über jede Idee abstimmen. Warum? Weil die besten Ideen oft nicht die sind, die spontan und initial die meisten Stimmen bekommen.“
    1. Bei Scrum wird nicht demokratisch abgestimmt, OB ein Projekt gestartet wird.
    2. Zitat Steve Jobs:
    „It doesn’t make sense to hire smart people and tell them what to do. We hire smart people, so they can tell us what to do.“

    Dieser Artikel ist leider ein gutes Beispiel für „Scrum smells“. Letztenendes ist es hier meiner Meinung nach nicht das Framework, sondern die Implementierung in das Unternehmen, welches nicht passt. Hier nun einen Artikel zu veröffentlichen, der ganz offensichtlich eine schlechte Adaption beschreibt und versucht das mit falschen Informationen über Scrum zu verargumentieren ist .. naja.
    Ein letzter Satz noch: Scrum hat nichts mit Projektmanagement zu tun! Wer das meint darf gerne mal ein Scrum Training besuchen (besser noch ein LeSS Training, dort wird das alles ausführlicher Erklärt).

  • Pete 11. Dezember 2019 16:59

    Klingt für mich eher so, als hätte man nie richtig verstanden und auch nicht richtig umgesetzt.

  • Markus 11. Dezember 2019 16:41

    Scrum hat mit Demokratie nichts zu tun. Entscheidungen müssen bei Scrum getroffen, wie überall sonst auch. Vielleicht schneller und zielgerichteter. Das dies demokratisch passieren muss ist wohl falsch verstanden – steht auch nirgends im SCRUM Guide.

  • AL 11. Dezember 2019 15:50

    Ich denke SCRUM ist nicht das was hier scheitert, sondern eher die Kultur.
    Agiles Arbeiten und der Wille zur Innovation sollte etwas sein, das kulturell verankert ist. D.h. Neues sollte immer gedacht und ausprobiert werden dürfen, wie es sich dann in einer Produktion durchsetzt oder möglicherweise auch nicht, ist nicht durch SCRUM festgelegt.
    Wir nutzen Teile aus SCRUM, um unsere Arbeit zu organisieren, aber zu jedem Zeitpunkt im Prozess kann auch dir Entscheidung stehen Dinge nicht zu tun, weil sich bspw. der gewünschte Effekt nicht einstellt oder sich bessere Ansätze ausprägen.
    Wenn die richtige Stimmung im Team herrscht, die Fehlerkultur stimmt und die Sprints nicht zu 100% für die definitiv kommenden Features verwendet wird, steht SCRUM der Innovation nicht im Wege. Starr sollte SCRUM deshalb sich niemals anfühlen. Innovation und hinterfragen von bestehendem muss im Prozess eingebettet sein.

  • Juergen H. 11. Dezember 2019 15:23

    Ich stimme dem SCRUMMASTER voll und ganz zu:
    es ist kein Process,keine Technik,oder definitive Methode,sowas wie Scrum hat es vorher
    schon gegeben,und es ist eine Tatsache ,das jedes Meeting Zeit raubt,
    Dazu kommt folgendes:
    Wenn in der Gruppe ueber ein Projekt abgestimmt wird,traut sich der einzelne Mitarbeiter,der eine bessere Idee hat,nicht dagegen zu stimmen,weil er eine negative Reaktion befuerchtet
    Bei Auftragseingang sollte einmal diskutiert werden wie man den Auftrag am schnellsten,und effektivsten erledigen kann,und was die spezifischen Besonderheiten darran sind ,und wie gross das Zeitfenster ist
    so weit,so gut
    Juergen H

  • Ein Mann 11. Dezember 2019 15:15

    Wie kleingeistig man sein muss, um sich hier ob der Gendersternchen aufzuregen…

  • Anonymous 11. Dezember 2019 14:58

    Interessanter Erfahrungsbericht, danke dafür. Auch Schreibstil und Stilmittel sind in Ordnung, lassen sie sich nicht von ewiggestrigen Nörglern irritieren.

  • Beat Spielmann 11. Dezember 2019 14:34

    „The work comes to the people (or better is pulled by the people) versa people come to the work“.
    Scrum alleine ist nur Teil der Lösung, es braucht die „Continues Delivery Pipeline“ (CI, CD und Release in Demand) um das wirkliche Potential zu entfalten (weg vom Projekt Gedanken) …

  • Anonymous 11. Dezember 2019 12:44

    Scrum ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Dafür ist es gut geeignet. Die Ausgestaltung bleibt jedem Unternehmen selbst überlassen. Starr ist nicht die Methode sondern der Mensch. So wie der Autor mit Gewalt diese seltsame m/w/d- Sprache verwendet, vielleicht auch um es alles Recht zu machen.

  • Thomas Kuschel 11. Dezember 2019 11:37

    Genau das habe ich auch gedacht.
    Scrum nicht verstanden und sicher nicht gelebt.

  • Torsten Zimmermann 11. Dezember 2019 10:31

    vielen Dank für Ihren interessanten Beitrag. In der Tat ist die demokratische Entscheidungsfindung bei Scrum ein echtes Problem, weil eine fachliche Expertise eher in den Hintergrund rückt und statt dessen Entscheidungen auf der Basis von Mehrheiten getroffen werden. Aber Mehrheiten haben eben nicht immer Recht. (Im Extremfall geht es dann nach dem Wohlbefinden der Kollegen.) So richtig haben wir den Konflikt bis heute nicht aufgelöst, allerdings mit einem offenen, fehlertoleranten Klima doch eine gewisse Sensibilisierung für die Problematik erreicht. Hilfreich war außerdem, immer die wichtigste Frage überhaupt in den Mittelpunkt zu stellen, wie hilft uns diese oder jene Entscheidung dabei, die Zufriedenheit unserer Kunden (und von uns selbst) langfristig zu erhöhen (im Gegensatz zu kurzfristigen bzw. kurzandauernden Verbesserungen in diesem oder jenem Bereich). Wenn man dann eine mögliche Richtung kritisch und wohlwollend durchleuchtet, kann man in der Tat zu einem demokratieähnlichen Findungsprozess kommen.

  • ScrumMaster 11. Dezember 2019 10:30

    Allein, dass hier von einer Projektmanagementmethode bzw. Scrum-Methode geschrieben wird zeigt, dass der Autor Scrum nie verstanden hat und/oder sich nie damit ernsthaft auseinandersetzt hat.
    Schon auf Seite 3 des Scrum-Guide steht „Scrum is not a process, technique, or definitive method.“

  • Bitte schreiben Sie, wie Sie reden 11. Dezember 2019 09:43

    Intressanter Artikel, Allerdings beim lesen wich mein Fokus, vom Verstehen des Artikels zunehmend, auf die „Verrenkungen“ hin um genderneutral zu schreiben.

Hinterlassen Sie einen Kommentar

(Die Redaktion schaltet Kommentare montags bis freitags von 10 bis 18 Uhr frei. Die Angabe von Name und E-Mail-Adresse ist freiwillig. IP-Adressen werden nicht gespeichert. Mit der Abgabe eines Kommentars stimmen Sie unseren Datenschutzbestimmungen zu.)