"Scrum" als Rahmenwerk des Arbeitsalltags: Wenn Wissen durch Gewissen ersetzt wird.
Ein Gastbeitrag von Frank2000.In diesem Forum stehen Themen der Tagespolitik oft im Vordergrund. Dabei gibt es in der Wirtschaft durchaus Themen, die sowohl eines ersten als auch eines zweiten Blicks würdig sind. Ich lade Sie ein mit mir zusammen eines dieser spannenden Themen zu durchleuchten: Scrum.
Fast überall in der westlichen Arbeitswelt, die sich mit Softwareentwicklung oder digitalen Produkten beschäftigt, hat sich Scrum als Rahmenwerk durchgesetzt. Dieser Artikel beschäftigt sich vor allem mit den Grenzen von Scrum und warum Scrum in so vielen Fällen problematisch ist.
0. Scrum in vier Sätzen
Scrum ist eine Anleitung für kleine, selbststeuernde Teams. Ein solches Team soll hochgradig flexibel sein und sich durch innere Steuerungsmechanismen immer auf die jeweils wichtigsten Aufgaben konzentrieren - und dadurch auf Marktänderungen schneller und mit vergleichsweise wertvolleren Ergebnissen reagieren können. Ein solches wertvolles Ergebnis kann dabei auch sein, schneller zu erkennen, dass eine Idee oder ein Teilergebnis sinnlos ist oder nicht mehr benötigt wird. "Versuch und Irrtum" bzw eine "Kultur des sinnvollen Scheiterns" ist Bestandteil der Scrum-Idee.1. Ausgangslage: Projektmanagement
Noch vor wenigen Jahren dominierte das "Projektmanagement", was auch als "Wasserfallmodell" bezeichnet wird. In einem ersten Schritt wird ein Markt oder Produkt abgeschätzt (Umsatzchancen zu Vollkosten der Produktion). Dann werden die Anforderungen formuliert, die der Kunde an das Produkt hat. Danach wird ein Projektplan erstellt, wer wann was zu tun hat, damit am Ende genau das Produkt verfügbar ist, das der Kunde bestellt hat bzw (hoffentlich) kauft. In einem Projektplan sind typischerweise auch das Entwicklungsbudget und der Liefertermin festgelegt.Jeder, der sich ein Haus hat bauen lassen, kennt diese Vorgehensweise:
- Zuerst kommt die grobe Idee (ungefähre Größe, Ausstattung, Lage)
- Dann das grobe Budget (bis zu xxx Tausend Euro)
- Dann das konkrete Angebot (Bauplan)
- Dann der Umsetzungsplan (der zeitliche Ablauf der Gewerke)
- Dann das endgültige Budget (Annahme des Angebots vom Bauträger) einschließlich Liefertermin (geplante Schlüsselübergabe)
- Dann die Umsetzung & Kontrolle, einschließlich Sanktionierung bei Abweichungen vom Plan (Konventionalstrafen, Schadenersatz bei Baumängeln usw)
Da bei dieser Vorgehensweise die Handlung nur in eine Richtung laufen/fließen kann, kann man sich den Lauf der Dinge wie einen Fluss vorstellen. Und da "Fluss" nicht dramatisch genug klingt, hat sich der Begriff "Wasserfall" eingebürgert.
2. "Agile Vorgehensweise"
Insbesondere bei Software zeigte sich, dass die Entwicklung schnell voranschreitet und sich der Markt schneller verändert, als ein klassisches Projektmanagement abdecken kann. Zum Beispiel sind klassische Softwareprojekte selten kürzer als ein Jahr und umfassen durchaus oft Zeiträume bis zu 5 Jahren.- Die Befürchtung ist - und es gibt Beispiel dafür, dass dem in einigen Märkten auch so ist - dass am Ende niemand mehr das Produkt haben möchte, weil sich "die Welt verändert hat". - Außerdem wird bei der klassischen Projektplanung erst sehr viel Geld investiert, bevor nach vielen Jahren mit dem Verkauf und damit mit der Kostendeckung begonnen wird.Als Lösung dafür wird die Idee angeboten, die Entwicklung in sehr kleine Schritte aufzuteilen und nach jedem dieser Schritte zu prüfen, ob das Produkt vom Markt noch gewollt oder eine Vorgehensweise noch sinnvoll ist. Das nennt man "Agil" bzw. "Agile Entwicklung".
Es gibt inzwischen zwei Bereiche, in denen nur noch so gearbeitet wird und keine andere Vorgehensweise mehr überlebensfähig wäre:
- Die Entwicklung von Apps
- Die Entwicklung von Spielen
In beiden Fällen werden unvollständige, oft sogar nutzlose Zwischenprodukte ("Alpha", "Beta") dem Kunden angeboten; manchmal kostenfrei - in der Regel aber sogar kostenpflichtig. Faszinierend ist, dass es tatsächlich eine ausreichend große Anzahl von Kunden gibt, die bereit sind, solche "Alphas" oder "Betas" auszuprobieren, einzusetzen und dem Hersteller Berichte zu liefern, was man sich anders vorstellt.
Bei Apps ist es inzwischen normal geworden, dass monatlich, ja fast wöchentlich Updates auf dem Handy installiert werden. Wem fällt das überhaupt noch auf? Die Updates laufen im Hintergrund; eine besondere Dokumentation dazu gibt es in der Regel nicht. Das Thema "Dokumentation im Rahmen agiler Entwicklung" ist aber ein eigenständiges Thema und kann ich gern im kleinen Zimmer in der Diskussion ergänzen. So weit der Ausflug in die Praxis.
"Agile Entwicklung" wird oft als "innere Einstellung" beschrieben, oder "Mindset". Eine schnell lesbare Darstellung findet sich hier:
https://sternkopf-consulting.com/der-unt...d-scrum-teil-1/
Ich kenne aber keinen Fall, bei dem lediglich das "Mindset" als neuer Grundsatz in einem Unternehmen eingeführt wurde. Kleine Unternehmen brauchen das nicht - da wird über Autoselektion sichergestellt, dass alle Mitarbeiter sich mit dem Unternehmen und dem Produkt verbunden fühlen. Und bei großen Unternehmen bleibt es bei Lippenbekenntnissen, mal wolle den "Mitarbeiter zum Unternehmer machen" und bietet Gratisaktien an.
In der Regel wird das "Mindset agile Vorgehensweise" direkt mit einem Arbeitsmodell verknüpft. (Hinweis: in der Scrum Community ist das Wort "Arbeit" verpönt. Dort wird statt "Arbeitsmodell" der Begriff "Vorgehensmodell" verwendet.) Eine bekannte Form eines Arbeitsmodells für "agile Entwicklung" ist Kanban. Kanban implementiert dezentrale Steuerungselemente und betont den Produkt- und Prozessgedanken: jeder Einzelne leistet einen Beitrag zu einem Gesamtprodukt/Gesamtprozess und schlägt das Gesamtprodukt fehl, hat jeder Einzelne seinen Anteil daran. Aber Kanban kennt weiterhin externe Kontrolle, Vorgesetzte, individuelle Leistung, Leistungsbeurteilung und zentrale Produktsteuerung.
3. Scrum mit mehr als vier Sätzen
Das derzeit angesagteste Arbeitsmodell der agilen Entwicklung nennt sich Scrum. Quellen zu Scrum gebe ich jetzt keine an, da wirklich mit einfachster Suche dazu ausreichend Artikel gefunden werden können. Scrum enhält ein paar unverzichtbare Elemente, die als "Ereignisse", "Artefakte" und "Rollen" bezeichnet werden.Ereignisse:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospektive
Artefakte:
- Product Backlog
- Sprint Backlog
- Inkrement
Rollen:
- Product Owner
- Scrum Master
- Developer (diese Rolle betreut nicht nur die Softwareentwicklung, sondern auch Testen, Dokumentieren, Service usw)
Wörtlich steht im Scrum Guide - der einzig gültigen Anleitung für Scrum (aber auch das ist ein eigenes Thema...) -, dass jedes der oben genannten Elemente unverzichtbar sei. Insgesamt nennt man die oben beschriebenen Elemente das "Scrum Framework". Es sind Elemente, die geübt werden können und in sich messbar sind. In der überwältigenden Mehrzahl der Fälle wird in einem Unternehmen die Einführung von Scrum als abgeschlossen gemeldet, wenn das Scrum Framework implementiert ist. Ob ein Scrum Framework allerdings mit dem "Mindset Scrum" gleichzusetzen ist, werde ich im folgenden Artikel diskutieren.
Auch Scrum enthält - als eine Variante der "Agilen Vorgehensweise" - glaubwürdige und/oder nutzbare Elemente. Zum Beispiel ist das Ereignis "Review" derart offensichtlich sinnvoll, dass man solche Ereignisse schon abgehalten hat, als sie noch "Zwischenbericht", "Teilabnahme" oder "Statusrunde" hießen. Und selbst ein fast schon esoterisches Element wie die "Retrospektive" ist im Kern so neu nicht: eine Retrospektive ist eine Variante der Mediation und arbeitet auch mit ähnlichen Lösungsstrategien.
Komplett neu ist der Scrum Master. Etwas ähnliches hat es meines Wissens in westlichen Arbeitsmodellen noch nie gegeben - und das hat Gründe.
4. Messbare Erfolge oder Misserfolge bei Scrum
Es gibt nur wenige Untersuchungen, die sich tatsächlich mit messbaren Erfolgen beschäftigen. Und es gibt noch weniger Artikel, die sich mit problematischen oder negativen Aspekten von Scrum auseinandersetzen. Die überwältigende Mehrzahl der Artikel zu Scrum beschreibt Misserfolge oder Probleme als selbstverschuldete Konsequenzen einer mangelhaften Implementierung des Scrum Mindset. Nach dieser Sichtweise ist ein Scrum-Projekt gescheitert, weil ich es "nicht richtig gemacht habe". Kommt das bekannt vor?Eine Untersuchung sagt folgendes:
"Über 40 Prozent aller agilen Unternehmen zeichnen sich durch überdurchschnittliche Ergebnisse aus, nur 24 Prozent schneiden schlechter als der Durchschnitt ab. Eher starre Organisationen gehören zu den Schlusslichtern: Mehr als die Hälfte dieser Unternehmen entwickeln sich unterdurchschnittlich, lediglich 18 Prozent von ihnen sind wirtschaftlich erfolgreicher als die Konkurrenz."
https://www.bcg.com/de-de/d/press/20marc...ernehmen-152999
Völlig unklar ist dabei, was Ursache und was Wirkung ist - dafür sind die beobachteten Zeiträume viel zu kurz. Es könnte durchaus sein, dass sowieso erfolgreiche Unternehmen schlicht öfter Scrum einführen. Weil man "es sich leisten kann". Immerhin kann man mal festhalten, dass Scrum schon bei dieser Untersuchung keineswegs als grundsätzlich überlegene Methode ermittelt wird: es gibt eine relevante Anzahl von Unternehmen, die auch ohne Scrum ihrer Konkurrenz überlegen sind. Nun könnte jemand behaupten: tja, aber mit Scrum wären sie noch viel überlegener...
In einer anderen Studie geben immerhin 25% der Unternehmen in einer Selbsteinschätzung an, dass die eigenen Scrum-Projekte erfolgloser sind.
https://www.vgsd.de/zwei-drittel-der-auf...-erfolgreicher/
Das ist eine durchaus beachtliche Zahl wenn man berücksichtigt, dass Scrum DIE angesagte Methode dieser Zeit ist und jeder, der ein Scheitern zugibt, Gefahr läuft, selbst als Schuldiger und Versager hingestellt zu werden:
https://www.dev-insider.de/5-gruende-war...itern-a-814640/
oder auch
https://www.projektmagazin.de/artikel/ke...heitern_1105409
Bei einer großen deutschen AG zum Beispiel ist der aktuelle Zustand, dass Projektleiter extra Budget erhalten, um von klassischer Projektplanung auf Scrum umzusteigen. Würde ein Projektleiter nach einigen Jahren melden, dass die Einführung von Scrum (abgesehen von ein paar funktionierenden Formalismen) gescheitert ist, dann könnte derjenige seine Karriere abschreiben. Eine Negativmeldung nach der Umstellung auf Scrum ist aktuell absolut ausgeschlossen. Eher wird der Weg beschritten, Scrum formal weiterzubehalten und als erfolgreich zu melden, aber unter der Oberfläche wieder hierarchische Strukturen zu installieren.
Eine weitere Untersuchung berichtet:"Anwender agiler Methoden stufen ihr Unternehmen zu 64 % als erfolgreicher bzw. deutlich erfolgreicher im Vergleich zu anderen Unternehmen der Branche ein....79 %der agilen Anwender schätzen die Erfolgsquote der mit agilen Methodendurchgeführten Projekte und Entwicklungsprozesse hinsichtlich Zeit, Kosten und Qualität bei über 50 % ein. Hingegen sehen nur 64 % der klassischen Anwender und 65 % der Anwender von Lean-Methoden ihre Erfolgsquote bei über 50 %."
https://www.process-and-project.net/studie-status-quo-pep/
Gleichzeitig wird aber berichtet: "Nur 30 % der Teilnehmer geben an, regelmäßig Retrospektiven durchzuführen."Schwer zu sagen, ob in den untersuchten Firmen tatsächlich Scrum gelebt wurde, oder lediglich ein (sogar noch beschnittenes) Scrum Framework eingesetzt wird.
Und zu guter letzt:
https://www.standishgroup.com/store/serv...18-package.html
Hier kenne ich nur eine Bewertung von Dritten, da der Kaufpreis abschreckend ist. In der Bewertung wird berichtet, dass "die Erfolgsquote agil durchgeführter Projekte fast doppelt so hoch ist (44 Prozent) als bei traditionell durchgeführten Projekten."
https://proagile.de/agiles-projektmanagement-konzerne/
Zu guter Letzt darf man noch ansprechen, dass viele Untersuchungen zum Erfolg von Scrum Auftragsarbeiten sind und keine wissenschaftlich fundierten Doppelblindstudien. Deswegen ist die Neutralität der Ergebnisse nicht "per Design" sichergestellt.
5. Scrum: der Markenkern
Im weiteren möchte ich mit den problematischen Aspekten von Scrum beschäftigen: der Philosophie, dem Menschenbild... dem theoretischen Überbau sozusagen. Genau an diesem Punkt kommt der Scrum Master ins Spiel. Im Scrum Guide gibt es eine ausführliche Beschreibung, was diese Rolle beinhaltet.
5.0 Scrum Master
"Der Scrum Master ist für das Verständnis und die Durchführung von Scrum verantwortlich. Er tut dies, indem er dafür sorgt, dass das Scrum Team die Theorie, Praktiken und Regeln von Scrum einhält."Wir haben es also bei Scrum mit einem Arbeitsmodell zu tun, wo es nicht genügt, Prozessbeschreibungen oder ähnliches zur Verfügung zu stellen. Sondern Scrum enthält ausdrücklich eine Rolle, die das "richtige Denken" sicherstellen soll. Der Scrum Master ist kein disziplinarischer Vorgesetzter und auch kein technischer Experte. Er ist auch keine neutrale Kontrollinstanz wie die QS oder QA. Sondern er ist der "Hüter des Scrum" innerhalb des Teams. Zu den Aufgaben des Scrum Masters gehören Themen wie "Vermitteln des richtigen Verständnisses von Agilität", "Coachen des Entwicklungsteams hin zu Selbstorganisation und funktionsübergreifender Teamarbeit" oder "Unterstützen von Kollegen und Stakeholdern, Scrum und empirische Produktentwicklung zu verstehen und umzusetzen".
Um zu verstehen, warum ausdrücklich ein Scrum Master vorgesehen ist, muss man etwas in die Gedankenwelt von Scrum eintauchen. Um lediglich ein Scrum Framework zu implementieren (also ohne das "Mindset") würden ganz sicher nicht so viele Scrum Master benötigt; es ist leicht zu überprüfen, ob die Ereignisse stattfinden und welche Qualität ein Artefakt hat. Aber Scrum betont, dass die richtige Einstellung, dass "Mindset" von entscheidender Bedeutung ist. Es handelt sich um ein soziales Modell - im Gegensatz zu wissenschaftlichen Modellen, die auch dann funktionieren, wenn jemand nicht daran glaubt. Dabei ist der Aufwand gigantisch (dieser Punkt wird im Folgenden noch mal behandelt): bei einem Team bis zu maximal 9 Personen, typischerweise aber 7 Personen, ist einer der Scrum Master. Die Literatur schlägt vor, dass ein Scrum Master bevorzugt nur ein Team betreut; in der Praxis betreut ein Scrum Master in der Regel zwei Teams. Nach dieser Rechnung ist also 0,5 einer Planstelle in einem 7-Personen-Team nur für "Kaderschulung" zuständig. Das ist schon gewaltig.
Um diesen Personalaufwand zu verstehen, genügt es nicht, den Scrum Guide gelesen zu haben. Scrum hat (wie alle agilen Vorgehensweisen) eine ideologische Fundierung: das "Agile Manifest". Aus diesem agilen Manifest sind die "12 Prinzipien agiler Arbeitsweisen" abgeleitet, in denen unter anderem steht:
- der Fokus auf motivierte Mitarbeitende, denen man Vertrauen entgegenbringt- nachhaltiges Arbeiten in einem konstantem Tempo, welches über die Zeit gehalten werden kann (keine Überforderung)- die Betonung von sich selbst organisierenden Teams- Technische Exzellenz als Grundlage und Treiber von Agilität
https://alinbu.net/blog/die-agile-bewegung-ist-gescheitert
Dieser Auszug aus den 12 Prinzipien klingt harmlos? Keineswegs. Denn in der Praxis bedeuten diese Prinzipien in Verbindung mit dem Scrum Framework eine gewaltige Anzahl von Paradigmen: also nicht beweisbare, unausgesprochene Voraussetzungen. Lasst uns also in die Rolle eines Scrum Masters schlüpfen und die Paradigmen verinnerlichen.
5.1 Die Arbeitsaufgaben sind "komplex"
Scrum basiert grundlegend auf der Ablehnung von zentraler Steuerung mit der Begründung, eine zentrale Steuerung sei nicht in der Lage überhaupt oder ausreichend schnell die Informationsmengen zu verarbeiten und zu reagieren.Ich möchte diesen Punkt nur erwähnen, aber nicht überstrapazieren. Ist das wirklich so, dass zum Beispiel in der Softwareentwicklung, aber auch in der Entwicklung von Dienstleistungen oder Konsumprodukten komplexe Probleme bei weitem überwiegen? Wie oft schlägt "Routine und Erfahrung" zu? Anders gesagt: werden große Unternehmen zu Bürokratien, weil dämonische Außerirdische die Menschen mit Gehirnstrahlen manipulieren - oder deswegen, weil viele Mitarbeiter mit standardisierten Abläufen (= Bürokratie) schlicht und einfach die meisten der Aufgaben lösen können?
Ist wirklich jedes GUI, dass entwickelt wird, ein Kunstwerk? Jede Zeile Code, die geschrieben wird, ein Epos? Sieht man sich die Produkte an, in denen Scrum am häufigsten eingesetzt wird - die Entwicklung von Apps - dann muss man leider feststellen: das sind vergleichsweise wenig komplexe Entwicklungsziele. Bisher wurden komplexe Softwareprodukte und sonstige komplexe digitale Produkte immer noch überwiegend als "Versionen" veröffentlicht. Eine Versionsplanung ist aber nur extrem schlecht mit Scrum kompatibel. Nicht unmöglich, aber schwierig.
Sehr interessant in dem Zusammenhang ist die Umstellung von Microsoft Office auf Microsoft Office 365: dieses Cloud-basierte Produkt würde erstmals für ein wirklich komplexes Softwareprojekt eine kontinuierliche Veröffentlichung und damit auch Scrum-basierte Entwicklung erlauben. Insgesamt erstelle ich hier kein Paradigma; aber man sollte schon im Hinterkopf behalten, dass Scrum eben kein universelles Arbeitsmodell ist, sondern ausschließlich für komplexe Aufgaben gedacht ist.
5.2 Kein Nutzen für "Einzelkämpfer"
Selbst engagierte Befürworter von Scrum geben zu:"Scrum ist ausschließlich für die Team-Arbeit konzipiert. Einzelkämpfer ziehen keinen Nutzen aus der Methode."https://t3n.de/news/kanban-scrum-unterschiede-834533/
Obwohl das nur ein einziger Aspekt ist und noch nicht mal der wichtigste, können wir uns schon mal damit beschäftigen. In der heutigen westlichen Welt gibt es eine deutliche Bewegung hin zum Sozialismus. Das Konzept "Individuum" wird verteufelt, ja als "überholt" abgelehnt. Aber ist das auch die Realität? Und ist das überhaupt erstrebenswert?
Warum sollte man "Einzelkämpfer" eigentlich per se nicht wollen? Die Behauptung ist, dass die heutigen Probleme so komplex seien, dass sie nur noch durch Teams lösbar seien. Einzelkämpfer hätten keine Chance mehr. (Zur Unterscheidung zwischen "Kompliziert" und "Komplex" siehe Dr. Google.)
Da stimmen gleich zwei Dinge nicht:- Die Existenz von Einzelkämpfern verhindert nicht die parallele Existenz von Teams; nicht mal innerhalb einer Abteilung. Früher galt es als edelste Aufgabe des Vorgesetzten, Einzelämpfer und Teamspieler in einer Abteilung auszugleichen, damit alle ihr bestes geben.- Es gibt weiterhin genügend Beispiele, in denen außergewöhnliche Einzelkämpfer bei weitem mehr zu einer Lösung beigetragen haben, als Heerscharen an "Teams".
Paradigma 1: Teams sind bei komplexen Themen den Einzelkämpfern grundsätzlich überlegen
5.3 Kein Nutzen für Spezialisten
Der Gedanke von "Nur das Team zählt!" in Scrum wirkt sich zum Beispiel dadurch aus, dass es keine spezialisierten Rollen gibt: alle sind "Developer". Es gibt keine dezidierten Tester oder Redakteure, keine UI-Designer oder Architekten. Jedes Teammitglied soll sich anstrengen, bei jedem Aspekt der Entwicklung mitreden zu können. Es mag sein, dass manche etwas mehr Erfahrung haben als andere - aber im Grundsatz soll jeder auch testen können, Doku schreiben können und so weiter. Man bezeichnet das in Dummdeutsch als "T-shaped Entwickler". Der obere Querstrich steht dafür, in jedem Bereich mitreden zu können. Der nach unten zeigende Strich symbolisiert, dass man in manchen Aspekten vertiefte Kentnisse hat.Sollte dieses Konzept Realität sein, dann gäbe es folgende Konsequenz: niemand wäre mehr unersetzbar. Kein Personalausfall wäre mehr eine Katastrophe - bestenfalls erhöht sich die Lieferzeit. Bei der Abschätzung der Lieferzeit spielt es keine Rolle mehr, wer in Urlaub oder krank ist: es wird ein Team-Durchschnittswert genutzt, fertig.
Auch hier stellt sich die Frage, ob das überhaupt gewünscht ist und wer davon profitiert.
"Programming, Motherfucker" schreien ein paar genervte Entwickler:
We are a community of motherfucking programmers who have been humiliated by software development methodologies for years.We are tired of XP, Scrum, Kanban, Waterfall, Software Craftsmanship (aka XP-Lite) and anything else getting in the way of...Programming, Motherfucker.
(http://programming-motherfucker.com/ ).
Tatsächlich ist die überwiegende Mehrzahl der Entwickler einverstanden, wenn Scrum FORMAL eingeführt wird - zu den Gründen komme ich noch. Abgelehnt wird dagegen die Idee des "T-shaped Entwicklers". So gut wie kein Entwickler hat daran Interesse, langweilige Integrationstests durchzuführen. Noch weniger haben Lust, Kunden-Dokumentation zu schreiben. Und so ziemlich jeder Entwickler hat irgendeinen Aspekt der Softwareentwicklung, den er ablehnt - und sei es, dass er nie mehr in VB programmieren möchte. Je älter Entwickler werden, desto mehr schätzt man seine Komfortzone. Und zu guter Letzt gibt es in jedem Unternehmen auch schwache Mitarbeiter, die schlicht nicht in der Lage sind, neue oder vielfältige Themen zu übernehmen.
Solche Widerstände kann man möglicherweise brechen. Ob die Pflicht zum Generalistentum aber effizienter und effektiver ist als die Existenz von Spezialisten - das kann jeder auch für sich selbst mal durchdenken.
Paradigma 2: Generalisten sind Spezialisten bei komplexen Themen grundsätzlich überlegen
5.3b Kein Nutzen für Leistungsträger
Eine Firma, die sich auf die Einführung von Scrum spezialisiert hat und damit per Auftrag zu den Befürwortern von Scrum zählt, hat sich folgende Anekdote ausgedacht:"Die Stimmung war nicht immer positiv und es kam zu Aussagen wie: „Xy leistet nicht genug“ oder „Es sind doch immer die selben, die sich richtig in´s Zeug legen – der Rest macht sich ´nen Lenz“. Wenn derlei Stimmungen in einem Wandel aufkommen, dann ist es sehr wichtig diesen Aufmerksamkeit zu schenken! Hier braucht es einen sehr gut geschulten Scrum Master, der in der Lage ist die Menschen im Team zu unterstützen, so dass Wohlwollen aufkommt. Letztlich sollte davon ausgegangen werden, dass alle im Team auch etwas leisten wollen."Und später:"Jedoch existiert der Weg nach oben bei Scrum oder auch anderen Selbstorganisationsformen nicht – alle sind auf der gleichen Stufe und rocken die Aufgabe gemeinsam. Dies ist eine völlig andere Unternehmenskultur."
https://www.berlinerteam.de/magazin/scrum-in-der-praxis/
Ein Befürworter, der zum Kritiker wurde, beschreibt das so:
" If you look at Scrum, it’s designed to disentitle the senior, most capable engineers who have to adhere to processes (work only on backlog items, spend 5-10 hours per week in status meetings) designed for people who just started writing code last month. Like a failed communist state that equalizes by spreading poverty, Scrum in its purest form puts all of engineering at the same low level..."Und später: "By age 30, you’re expected to be able to show that you can work at the whole-project level, and that you’re at least ready to go beyond such a level into infrastructure, architecture, research, or leadership.In an emergency, whether it’s a consultancy striving to appease an important client or a corporate “war room”, career coherency can wait. ...When there’s no emergency, however, programmers expect their career growth to be taken seriously and will leave if it’s not. Saying, “I was on a Scrum team” says, “Kick me”. "
https://michaelochurch.wordpress.com/201...m-are-terrible/
Scrum kennt keine Mechanismen, mit der sich Individuen hervortun könnten. Es gibt keine individuellen Ergebnisse, keine individuellen Bewertungen, keine individuellen Rangfolgen. Im Review gibt es keine Einzelleistungen. Das ganze erinnert an die "Gruppenarbeit" in der Grundschule, wo zwei Kids die gesammte Arbeit gemacht haben, während die anderen in der Zeit auf dem Gameboy gedaddelt haben - und dann alle die gleiche Note bekommen. Und das ganze wird verkauft als "die Kinder lernen soziales Verhalten" und "Rücksichtnahme auf die Schwächsten".
Ich sollte hier wohl nicht die komplette Diskussion wiederholen, ob es angeborene Intelligenz gibt oder angeborene Motivation&Leistungsbereitschaft. Fakt ist aber, dass es Unterschiede gibt. Fakt ist auch, dass selbst mit größter Mühe die Unterschiede bei Intelligenz und Leistungsbereitschaft nicht komplett nivelliert werden können. Scrum ist für die Leistungsträger - woher auch immer das Mehr an Intelligenz und Leistungsbereitschaft kommt - völlig unattraktiv. Um so mehr, weil nicht nur die UNFÄHIGKEIT, eine Aufgabe zu lösen, in Scrum versteckt wird. Auch die UNWILLIGKEIT, eine Aufgabe zu lösen, wird in Scrum versteckt. (Diesen Punkt greife ich im Folgenden noch mal bei der Retro&Transparenz heraus.) Innerhalb einer großen deutschen AG wird sogar über Bewertungs- und Entgeltsysteme nachgedacht, bei denen in der Jahresbeurteilung nur noch die Gruppenarbeit bewertet wird und es gar keine individuelle Leistungsbeurteilung mehr gibt.
Im Scrum Mindset wird dieser Konflikt gelöst, in dem der "reife Mensch" eingeführt wird. Jeder arbeitet so gut und so viel, wie er kann und nimmt nur so viel Ressourcen in Anspruch, wie er braucht. Die Aufgabe des Scrum Masters ist, alle Developer zu einer "reifen Persönlichkeit" zu führen, bei der man individuelle Ziele aufgibt und durch Teamziele ersetzt. Die theoretische Fundierung für diese Vorgehensweise ist die "Ich-Entwicklung" von Loevinger:
https://de.wikipedia.org/wiki/Ich-Entwicklung
In der Scrum Community ist weitgehend der Gedanke verankert, dass ein reifes Scrum-Team die Stufe 8, die "Systemische Stufe" erreicht haben sollte:"Voll ausgebildete Multiperspektivität, gleichzeitige Prozess- und Zielorientierung, systemisches Erfassen von Beziehungen (Zirkularität). Fähigkeit, sich widersprechende Aspekte und Meinungen zu integrieren. Hohe Motivation, sich selbst weiterzuentwickeln.Offene, kreative Auseinandersetzung mit Konflikten, hohe Toleranz für Mehrdeutigkeit. Hoher Respekt vor Autonomie anderer Personen und Aussöhnung mit eigenen als negativ erlebten Anteilen. "
Paradigma 3: Individuelle Belohnungs- und Anreizsysteme sind ungerecht und ineffizient, da sie "Leistungsträger" unverdient bevorzugen. Auch der kleinste Beitrag zu einer Aufgabe hat den gleichen Wert wie der größte Beitrag. Tatsächlich sind bereits die Kategorien "Kleiner Beitrag" und "Großer Beitrag" sinnlos, da es in einem Scrum-Team keine Möglichkeit gibt, die Bedeutung eines individuellen Beitrags zu messen. Jedes Teammitglied hat die Chance, die "Systemische Stufe" zu erreichen und so die Chance, auf inidividuelle Ziele oder Belohnungen zu verzichten.
5.4 Abschaffung von Vorgesetzten, Hierarchien & Abteilungen: Umfassende Verantwortung
Scrum kennt keine disziplinarischen Vorgesetzten: die erlaubten Rollen in Scrum sind oben abschließend aufgezählt. Die Befugnisse der einzelnen Rollen sind im Scrum Guide abschließend festgelegt. Abweichende Ansprüche sind - so fern nicht Kunden-zentriert - "Impediments" und müssen vom Scrum Master begrenzt oder abgestellt werden.Diese Tatsache ist der Grund, warum so viele Entwickler zunächst einverstanden sind, wenn Scrum FORMAL eingeführt wird: die individuelle Leistungskontrolle wird deutlich geringer. Die Anzahl der direkten Interaktion mit dem disziplinarischen Vorgesetzten wird geringer. Grundsätzlich wird überhaupt die Messbarkeit individueller Misserfolge geringer. In Scrum gibt es keine Vorgesetzten mehr, die Arbeitsaufträge erteilen und nach einer festgelegten Zeit individuelle Ergebnisse erwarten.
Statt dessen übernimmt das Team nur so viel Arbeit, wie es möchte. Das Team schätzt selber, wie komplex eine Aufgabe ist und wieviel Zeit man für die Lösung veranschlagt. Das Team entscheidet selbst, wer was macht. Ja, sogar die endgültigen Arbeitsergebnisse legt das Team selber fest: von Außen sollen nur Anforderungen kommen, die konkrete Umsetzung entscheidet das Team selbst.
Scheinbar das Paradies: ich entscheide selbst (zusammen mit meinen Kollegen), was ich mache und bis wann? Aber in Scrum hat das einen Preis: das Team ist schlicht für alles verantwortlich. Jedes Hindernis soll vom Team selbst gelöst werden. Das Team ist dafür zuständig, fehlenden Infos einzufordern, die Implementierung festzulegen, benötigte Gesprächspartner zu ermitteln und einzubinden, bei technischen Abhängigkeiten Absprache mit anderen Teams zu treffen und die Testbarkeit sicherzustellen. Das Team ist zuständig für das Aufteilen komplexer Probleme, die Dokumentation und welche Werkzeuge benötigt werden. Das Team kann zwar mehr Zeit für die Umsetzung einer Aufgabe veranschlagen; aber das Scrum-Team kann NICHT sagen: das war nicht unser Problem, das hat jemand anders zu entscheiden/zu beurteilen/zu lösen...
Wenn ein Einflussfaktor vergessen wurde, wer wird dafür verantwortlich gemacht? Das Team. Wenn das Produkt im Review nicht läuft, wer wird dafür verantwortlich gemacht? Das Team. Wenn zwei Teams gegeneinander gearbeitet haben, wer wird dafür verantwortlich gemacht? Das Team.
Paradigma 4: In einem reifen Scrum-Team entsteht niemals ein Gefühl der Verantwortungsüberlastung: jedes Teammitglied und das Team als ganzes wollen Verantwortung übernehmen. Es gibt keine Kompetenzgerangel, keine Kakaphonie, keine unterschwellige Konkurrenz; aber es drückt sich auch niemand. Die nötigen Entscheidungen werden gemeinsam, effizient und sinnvoll getroffen. Zudem ist die gemeinsame Verantwortung der individuellen Verantwortung grundsätzlich überlegen: eine einzelne Person kann etwas übersehen oder vergessen, kann krank werden. Aber eine kollektive Verantwortung ist immer... perfekt.
5.5 Transparenz und soziale Kontrolle auf kleinstem gemeinsamen Nenner
Bis jetzt wurden 4 Paradigmen ermittelt, die Scrum zugrunde liegen. Die Autoren der Scrum-Idee waren aber nun nicht völlig abgedreht. Den Autoren war bewusst, dass einige oder alle dieser Paradigmen nicht von Anfang an funktionieren. (Die GRUNDSÄTZLICHE Funktionsfähigkeit der Paradigmen wird aber nie in Frage gestellt).Um Abweichungen von den Paradigmen zu erkennen, wird in Scrum ein sozialer Kontrollmechanismen vorgeschlagen: Die Retrospektive dient dazu, Abweichungen bzw. Reifungspotentiale in der Gruppe zu erkennen (Unstimmigkeiten, Unwissenheit, falsche Einstellungen). Es gibt eine große Bandbreite an Methoden, die das bewirken sollen - da aber in Scrum gern die Selbsterkenntnis beschworen wird, werden oft "Erkenntnisspiele" eingesetzt. Kartenspiele, Lego oder Fischertechnik, verschiedene Mal- und Kreativbaukästen, Aktivitätsspiele und vieles mehr. Einfach mal bei google "Spiele für Retrospektive" oder "Spaß in der Retrospektive" eingeben und auf die Bildersuche klicken. Oder hier rumstöbern: https://retromat.org/de/?id=59-133-9-99-14
Eine kurzer Schlenker in die Praxis: als Scrum Master wurde ich von Entwicklern schon mal angesprochen mit dem Satz "Ich mache alles mit, so lange ich nicht spielen muss". Die Alternative zu diesen Spielen ist sehr oft die ritualisierte Variante: Karten schreiben zu positiven und negativen Wahrnehmungen, Karten an die Tafel heften, clustern & Maßnahmen definieren.
Die Retrospektive hat aber verschiedene Haken:
1. Es gibt weder eine Belohnung für noch Zwang zur Kooperation oder Offenlegung
2. Es gibt keinerlei Sanktionsmechanismen - weder individuell noch kollektiv
Fangen wir mit dem allerletzten Punkt zuerst an: Wozu sollte ein Team sich dem Stress aussetzen, tatsächlich ritualisiert Konflikte auszutragen? Was passiert denn, wenn ein Scrum-Team in der Komfortzone bleibt, wenn ein Team wenig Ergebnisse liefert? Im Regelfall: nichts. Das deutsche Arbeitsrecht sieht keine kollektiven Bestrafungen vor, die Tarifverträge eben so wenig. Niemand wird entlassen, nur weil ein Scrum-Team zu wenig Ergebnisse liefert. Niemand bekommt deswegen weniger Geld.
Und noch weniger Anreiz hat ein Individuum, sich diesem Stress auszusetzen. Wir haben es sogar mit einem Gefangenendilemma zu tun: wenn alle anderen Gruppenmitglieder sich in der Retrospektive der Kritrik aussetzen und im Ergebnis bessere Leistung zeigen würden, wäre es individuell immer noch besser, selbst nicht mehr Anstrengung zu leisten. Wieviele Kollegen oder Kolleginnen kennt ihr, die sich WIRKLICH sagen lassen möchten, dass sie in den letzten zwei Wochen überwiegend nur gesurft oder Löcher in die Luft gestarrt haben - und dann auch noch ihr Verhalten ändern würden? Wieviele Kollegen oder Kollegen kennt ihr, die das anderen ins Gesicht sagen möchten?
Der absolute Standardfall ist doch, dass
a) in einem leistungsstarken Team das leistungsschwache Teammitglied mitgeschleppt wird... und keineswegs von diesem leistungsschwachen Teammitglied gefordert wird, sich zu verbessern oder weiterzuentwickeln
b) in einem durchschnittlich starken Team bei kollektiver Beurteilung alle ihre Leistung absenken werden, bis man sich auf dem kleinsten gemeinsamen Nenner geeinigt hat
Die Retrospektive setzt voraus, dass Menschen im Berufsumfeld tatsächlich bereit sind ehrlich zu sein, Kritik anzunehmen, sich selbst zu hinterfragen und respektvoll (freundschaftlich) andere zu kritisieren. Mit anderen Worten: in Scrum-Teams wird vorausgesetzt, dass sich die Kollegen und Kollegen so sehr mögen und respektieren, dass wie in einer Familie sogar schmerzhafte Themen angesprochen werden, weil der Gewinn einer Konfliktlösung den Schmerz des Konfliktes überwiegt. Aber das ist doch eine völlig absurde Vorstellung. Selbst mit befreundeten Kollegen würde ein durchschnittlicher Mann so etwas nicht tun (für Frauen will ich jetzt nicht so absolutistisch urteilen) - man müsste ja schon LIEBE unterstellen, damit ein solcher Konfliktmechanismus tatsächlich selbstgesteuert funktioniert.
Zumal in typischen Arbeitssituationen die Individuen keine Belohnung für die erfolgreiche Retrospektiven erhalten und keine Sanktionierung bei erfolglosen oder unterlassenen Retrospektiven. Die Retrospektive ist damit das mit Abstand am meisten unterlassene Scrum-Element - und wenn es durchgeführt wird, dann nur nach einem Ritual, das schnellst möglich hinter sich gebracht wird. Was passiert denn, wenn zum Beispiel der Product owner in der Retrospektive den Punkt anschneidet "Zu wenig Feature fertiggestellt"? Wird das Team in einer schonungslosen Selbstkritik erkennen, dass die eine Hälfte keinen Bock hatte und gechattet hat, die andere Hälfte fachlich unffähig war, die mangelnde Motivation der Kollegen aufzufangen und im übrigen jeder einzelne nur im Büro ist, weil es sonst keine Kohle gibt? Wer glaubt, dass die Retrospektive dieses Ergebnis liefert? Mal aufzeigen bitte? Niemand?
Statt dessen werden Ausreden geliefert: es ging nicht schneller, unerwartete Probleme, Blokaden von außerhalb des Teams, böse Umwelt, schlechte Zuarbeit vom PO.... die Liste ist endlos.
Aber die Retrospektive ist die einzige Chance, Abweichungen von den oben erkannten Paradigmen zu erkennen und abzustellen! Wir erkennen also: Der zentrale Regelmechanismus bei Scrum ist SELBST EIN PARADIGMA:
Paradigma 5a: In reifen Scrum-Teams ist jedes Teammitglied bereit und fähig zur Kritik und Selbstkritik. Es gibt weder "blinde Flecken" noch Komfortzonen. Nötigenfalls führt der Scrum Master die Teams in den Retrospektiven zur Selbsterkenntnis bezüglich blinden Flecken und Komfortzonen.
Paradigma 5b: Die definierten Maßnahmen werden auch tatsächlich durchgeführt und sind wirksam (= führen zu Änderungen im Verhalten und Mindset)
Paradigma 5c: Es gibt keine unlösbaren Konflikte
5.6 Geänderte Interaktion und der resultierende Aufwand des Scrum Frameworks
"Agile is a cancer that we have to eliminate from the industry...we talk too much about code, we don’t write enough code"https://vimeo.com/110554082
In einem pro-Scrum-Artikel wird folgende Rechnung aufgemacht:
"- Sprint Planning Meeting 2 x 4 Stunden Time-Box
- Daily Scrum 15 min Time-Box
- Sprint Review Meeting 4 Stunden Time-Box
- Sprint Retrospective Meeting 3 Stunden Time-Box
- Backlog Refinement/ Grooming 10% des Sprints
Diese Meetings bzw. Events nehmen ca. 25 % der Entwicklungszeit ein."
Und dann wird der Aufwand wie folgt klassifiziert:
- Requirements Engineering: ca. 20 % - Das beinhaltet Anforderungserhebung, Anforderungsanalyse, Design und Abnahme
- Projektmanagement und Prozessverbesserung: ca. 5%"
http://blog.hood-group.com/blog/2012/05/...administration/
Zunächst mal fehlt in dieser Rechnung sowohl die Arbeitszeit des Scrum Masters als auch die Arbeitszeit des Product Owner. Beide Rollen gehören laut Scrum zum Scrum-Team (in der Praxis mit jeweils etwa 0,5 Headcount). Und dann ist das ja keineswegs der gesammte Overhead des Unternehmens: es gibt weiterhin ein Marketing, Vertrieb, Geschäftsführung... und in der Regel auch Abteilungsleiter, Personalabteilung, Systemtest usw.
Aber lassen wir den sonstigen Overhead weg und konzentrieren uns auf das Scrum-Team: In Summe werden für das Arbeitsmodell Scrum unfassbare 30% der ENTWICKLUNGSZEIT verbrannt. Also die Zeit, die auf "Softwareentwicklung" budgetiert wird. Wenn im klassischen Projektmanagement ein Drittel des R&D-Budgets für Besprechungen draufgegangen wären, da hätte es aber gerappelt... noch mal zum mitdenken:
Ohne Frage benötigt man eine Anforderungsanalyse. Und eine Abnahme. Und so weiter. Die Frage ist doch: genügt es, wenn EINER die Anforderungsanalyse macht oder müssen das ALLE machen (einschließlich denen, die absolut keine Ausbildung und keinen Bock dafür haben)? Ist das Ergebnis so viel besser, wenn ALLE Entwickler bei der Abnahme dabei sind, oder genügt einer? Müssen ALLE Entwickler beim Zerlegen einer Aufgabe in Teilaufgaben mitarbeiten, oder genügt eine Subgruppe?
In Scrum gibt es die Forderung, dass möglichst das ganze Team an diesen Ereignissen und Interaktionen teilnimmt. Nur so kann man dem agilen Manifest gerecht werden (und Scrum ist die radikale Variante von agiler Entwicklung, wie wir uns erinnern):
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge
- Funktionierende Software mehr als umfassende Dokumentation
Auch das Scrum Framework fordert ausdrücklich, dass das Team möglichst geschlossen an diesen Ereignissen und Interaktionen teilnimmt (bei einigen Ereignissen darf der PO oder Scrum Master fehlen). In der Praxis bedeutet das zum Beispiel, dass schriftliche Übergaben stark abnehmen. Ich will aus Platzgründen dieses Thema nicht zu sehr ausführen; aber als weiteren Merkposten sollte man das im Hinterkopf haben: Scrum setzt auf die direkte Interaktion (mindestens zeitlich, aber bestenfalls auch örtlich). Versetzte Interaktion (dass also die ÜberGABE und die ÜberNAHME zu verschiedenen Zeitpunkten geschieht) ist in Scrum eigentlich nicht vorgesehen.
Das Scrum Framework ist aber in dieser Form als direkte Anwtort auf eine Kritik am Wasserfallmodell entstanden... wobei die Kritik in dieser Form gar nicht glaubwürdig ist! Völlig zu Recht schreibt ein Autor:
"Kritik am Wasserfallmodell — aus der heraus die Agile Bewegung ja entstanden war — ist nur dann berechtigt, wenn man darauf besteht, dieses Modell — wie bis hin zur Jahrtausendwende tatsächlich oft geschehen — in jedem Entwicklungsprojekt nur ein einziges Mal zu durchlaufen (statt den schon durchlaufenen Teil spiralförmig so oft wie notwendig neu zu beginnen).Schon ab etwa 1990 aber haben kompetente, flexibel agierende Teams das anders gehalten: Sie begannen einzusehen, dass es keinen Sinn macht, an einer durch den Kunden zwar abgenommenen, inzwischen aber als teilweise ungeeignet erkannten Systemspezifikation festzuhalten. Ihr Ausweg: systematisches Change Management und nun mehrfach wiederholte, spiralförmige Anwendung des erprobten Wasserfallmodells noch vor dem Ende des Entwicklungsprojekts."
http://greiterweb.de/spw/Agile.htm
Paradigma 6a: Der Verwaltungsaufwand (Ereignisse, Artefakte, Rollen) von Scrum ist gerechtfertigt, weil Scrum bessere Ergebnisse liefert.
Paradigma 6b: Die (im Vergleich zum Projektmanagement) geänderte Interaktion hat keine relevanten Kollateralschäden
6. Warum bei Scrum diese Probleme auftreten und wie man die Probleme lösen kann
So ziemlich alle oben beschriebenen Phänomene können darauf zurückgeführt werden, dass Scrum ein bestimmtes Menschenbild voraussetzt bzw genauer gesagt: einen bestimmten Typus Mensch voraussetzt: den "Y-Typ".Die Theorie X nimmt an, dass der Mensch von Natur aus faul ist und versucht, der Arbeit so gut es geht aus dem Weg zu gehen. Prinzipiell ist er von außen motiviert; das heißt durch extrinsisch ausgerichtete Maßnahmen zu belohnen beziehungsweise zu sanktionieren. Im Gegensatz dazu geht die Theorie Y davon aus, dass der Mensch durchaus ehrgeizig ist und sich zur Erreichung sinnvoller Zielsetzungen bereitwillig strenge Selbstdisziplin und Selbstkontrolle auferlegt. Er sieht Arbeit als Quelle der Zufriedenheit und hat Freude an seiner Leistung. Auch Verantwortungsbewusstsein und Kreativität prägen dieses Menschenbild.
https://de.wikipedia.org/wiki/X-Y-Theorie
Wer mehr Zeit zum Lesen hat, kann sich diese pdf vornehmen:"Theorien und Konzepte zu Agilität in Organisationen"
https://nbn-resolving.org/urn:nbn:de:bsz:14-qucosa-129603
In diesem Bericht wird die zugrunde liegende Persönlichkeitstheorie als "Human-Ressourcen-Ansatz" bezeichnet:
"Der Human-Ressourcen-Ansatz geht davon aus, dass die traditionellen Modelle der Organisationsgestaltung mit dem Prinzip des Regelgehorsams den Menschen darin behindern, Eigeninitia-tive und Verantwortungsbewusstsein zu entfalten. Die herkömmlichen Strukturen bedeuten nach der Human-Ressourcen-Theorie eine Verschwendung von Humanressourcen und damit Effizienzverluste. Es wird die Notwendigkeit gesehen, neue Organisationsformen zu entwi-ckeln, die den menschlichen Bedürfnissen angepasst sind. Das zugrunde liegende Weltbild ent-hält die Idee des personalen Wachstums, des nach persönlicher Reife strebenden Menschen"
Der Text wird vollmundig als "Forschungsbericht" gelistet, ist aber inhaltlich eine Metastudie, also eine Übersicht. Die etwa 34 DIN A4-Seiten bieten immerhin einen guten Überblick und einige Literaturhinweise.
Scrum geht davon aus, dass so ziemlich jeder geistig gesunde Mensch intrinsisch motiviert werden kann, seine Arbeit zu verrichten. Aber nicht nur das; in Scrum wird sozusagen eine "Yplus-Theorie" verwendet: nicht nur, dass ein Mensch aus sich selbst heraus Verantwortungsbewusst, Kreativ und Leistungsbereit ist. Darüber hinaus ist jeder Mensch bereit, seine individuellen Ziele und Wünsche aufzugeben, um statt dessen Befriedigung aus der Erfüllung eines Gruppenziels zu ziehen. Dazu muss den Mitarbeitern blos erklärt werden, wie toll Scrum ist und welches Glücksgefühl entsteht, wenn man sich Scrum unterwirft. Diese Aufgabe hat der Scrum Master: er soll Menschen dazu führen, durch "eigene Erkenntnisprozesse" zu erkennen, dass Scrum auch für einen selbst die sinnvollste Vorgehensweise ist.
Damit erklärt sich der Subtitel dieses Artikels: "Wenn Wissen durch Gewissen ersetzt wird". Bei Scrum werden hierarchische Steuerungsmechanismen abgeschafft. Individuelle Arbeitsaufträge, Leistungskontrolle&Sanktionen, bzw. individuelle Entlohnung oder Ehrung. Diese hierarchischen Steuerungsmechanismen hatten ja einen Zweck: sie sollten Wissen schaffen, das dem Unternehmen als Basis für Handlungen dient. Zum Beispiel dient eine Leistungskontrolle als Basis der individuellen Entlohung.
In Scrum wird aus Sicht des Unternehmens dieses Wissen über individuelle Leistung, Fehler und Verhalten abgeschafft und ersetzt durch die intrinsische Motivation: die Mitarbeiter geben FREIWILLIG ihr Bestes. Jeder tut so viel, wie er kann und nimmt nur so viel, wie er braucht. Und das machen die Menschen, um ein reines Gewissen zu haben; weil sie sich dann (so die These) besser fühlen.
Die Lösung zum erfolgreichen Einsatz von Scrum ist also einfach: Autoselektion. Das Scrum-Team nur auf Menschen beschränken, deren Persönlichkeit bereits zu Scrum passt: eigenverantwortlich, leistungsbereit, hochgradig kommunikativ, kritikfähig und flexibel; ohne individuelle Ziele oder Wertgerüste. Ohne Konkurrenzorientierung. Mit solchen Menschen funktioniert sogar Scrum. Ich bin allerdings nicht der erste, der auf diese Idee gekommen ist:"I do think AGILE and SCRUM has its place. It is just that I believe this place is running projects under 5 people and delivery durations of less than 6 months. At that level, employing the right people with the right skills and motivation frequently guarantees that MAGIC will occur."
http://www.claretyconsulting.com/it/comm...ogy/2006-08-17/
Dieser kritische Artikel ist überhaupt sehr empfehlenswert!
7. Fazit
Wenn man sich allein auf das Scrum Framework konzentriert, dann hat man es lediglich mit einer modernen Version des Bullshit-Bingos zu tun: mit einer diffusen Umschreibung bereits bekannter Elemente mit einer maßlosen Glorifizierung. Inzwischen hat einer der Gründerväter von Scrum in seinem Zorn über diese Glorifizierung sogar das "Anti-Agile-Manifest" geschrieben (leider nur noch archiviert verfügbar):http://archive.is/4J1lP
In der Praxis wird in der überwältigenden Mehrzahl der Fälle (wenn man den Berichten im Internet und der eigenen Praxis trauen kann) "Scrum" bzw die agile Arbeitsweise mit der Realität existierender Unternehmen (ich würde sogar sagen: der Realität existierender MENSCHEN) gemischt. Heraus kommt das "einarmige Agil-Prinzip": http://www.halfarsedagilemanifesto.org/
Bitte beachten: "...and there’s no way ..." Scrum funktioniert nur in der Theorie, so dieser Kritiker (und ich stimme zu). Nicht mit real existierenden Unternehmen oder real existierenden Menschen. Die Befürworter des Scrum reagieren auf diese Kritik wie Eingangs erläutert: Scrum scheitere, weil man eben nur das Scrum Framework implementiere, aber das MINDSET vernachlässige. Wenn man aber den Menschen nur genügend Zeit lassen würde, dann, ja dann wird Scrum das Ende der Geschichte sein!
"...bis zur Perfektion agiler Methoden können mithin sogar Jahre vergehen."
https://entwickler.de/online/agile/agile...nde-248021.html
Die Befürworter des Scrum bestreiten also nicht das Scheitern von Scrum in der Praxis:
"Der Konflikt ist vorprogrammiert. Gehen sie auf Scrumtische, agile Meetups und andere Events der agilen Community. Die Zahl der Sessions zu Problemen an dieser Front ist nahezu endlos. Der Konflikt ist so groß, dass der Anteil der gescheiterten agilen Transformationen enorm ist. Je nach Quelle spricht man davon, dass 70-85% der Versuche agiles Projektmanagement einzuführen scheitern. Die restlichen 15-30% dümpeln vor sich hin und reiben sich an diesem Konflikt auf, statt ihr mögliches Potential auszuschöpfen."
https://alinbu.net/blog/die-agile-bewegung-ist-gescheitert
Die Befürworter behaupten, dass "unreife Menschen" schuld sind, mithin lediglich der Reife Mensch (c) erschaffen werden müsse, dann funktioniere auch Scrum. Einige Befürworter gehen sogar so weit zu behaupten, dass Scrum selbst den Reifen Menschen (c) erschaffe:
"Wir haben für unsere Studie einen kleinen Ausschnitt statistisch untersucht, das so genannte "Teamklima für Innovation". ... Zu vermuten ist, dass es daran liegt, dass die im agilen Arbeiten verankerten strukturellen Elemente Interaktion, Wissensaustausch und Verantwortung fördern, sowie dem Wir-Gedanken zuspielen und damit Gegenspieler der Ego-Statusorientierung sind. Naheliegend wäre weiterhin, dass die in den agilen Konzepten integrierte häufige Reflexion und intensive Kommunikation die persönliche Entwicklung und Reife der Einzelpersonen fördert. "
https://www.informatik-aktuell.de/manage...-zu-lassen.html
Ich überlasse es dem Leser, dazu ein eigenes Urteil zu finden.
PS.Amüsant finde ich Artikel, in denen inzwischen Scrum abgesprochen wird, das Aushängeschild der agilen Idee zu sein. Scrum sei inzwischen so "außer Kontrolle geraten", dass sogar die Idee der agilen Entwicklung drohe mit in den Abgrund gerissen zu werden:"Honestly, it’s probably too late to redeem Scrum. Things like SAFe demonstrate that the situation is already out of control. "
https://techbeacon.com/app-dev-testing/why-scrum-sucks
Frank2000
© Frank2000. Für Kommentare bitte hier klicken.
