TopMenue

Was ist Scrum?

Was ist Scrum eigentlich? Ist es ein Rahmen oder Rahmenwerk? Eine Methode? Ein Prozess? ein Model? ein Werkzeugkasten? Oder ein Sonstwas-Dings?

Die Legende sagt …  ^

… Scrum sei ursprünglich auf einer Serviette — oder war es ein Bierdeckel? — konstruiert worden. Zwar sagt ein Bild mehr als 1000 Worte, aber leider enthält zumindest ein technisches Bild immer nur das Sichtbare und gerade bei Scrum ist es weniger das Sichtbare, als vielmehr das Verborgene, das die eigentliche Bedeutung darstellt.

Aber beginnen wir noch einmal ganz von vorn.

Was für ein Dings ist Scrum?  ^

Scrum ist ein leichtgewichtiges, nachhaltiges, auf den Werten des agilen Manifests aufbauendes Softwareentwicklungsdings. Scrum setzt auf Klasse, statt auf Masse und läuft in kurzen, zeitlich eng begrenzten Zyklen (Sprints) ab. Die Sprints ihrerseits bestehen aus den Phasen

  • Planung,
  • Realisation,
  • Abnahme, sowie
  • Reflektion/Adaption

Das Ergebnis eines Sprints ist ein lauffähiges Produktinkrement, das der Auftraggeber, bzw., allgemeiner, die Stakeholder, jeweils nach Abschluss eines Sprints erhalten und dann testen und kommentieren können, um ihr Feedback zeitnah wieder in die Entwicklung einfließen zu lassen.

In Scrum werden die Stakeholder durchgehend in die Entwicklung mit einbezogen, da in der agilen Sichtweise berücksichtigt wird, dass Softwareentwicklungsprojekte zumeist zu komplex sind, um sie bereits im Vorwege vollständig durchplanen zu können, zumal die Stakeholder zumeist erst durch eine intensive Beschäftigung mit dem lauffähigen, jeweils nach Ende eines Sprints ausgelieferten Produktinkrement in die Lage versetzt werden, Entscheidungen über die wirklich und konkret benötigte Funktionalitäten treffen zu können.

Scrum ist auch ein Team- oder People…dings, in dem alle Beteiligten gemeinsam einander zuarbeiten, sich auf Augenhöhe begegnen, niemand jemand anderem gegenüber weisungsbefugt ist und die Zusammenarbeit auf Werten wie Achtung, Vertrauen, Konsensfähigkeit, Selbstbestimmung und -organisation, Konzentration auf das Wesentliche, Selbstreflektion und Adaption, sowie steter Verbesserung der projektspezifischen Prozessausprägung basiert. Dabei minimiert Scrum Organisations- und Verwaltungsaufwände und stellt die Produktqualität und — vor allem — den höchsten für die Stakeholder erreichbaren Geschäftswert in den Vordergrund.

Scrum ist simpel, polarisiert jedoch  ^

Der Ablauf von Scrum ist recht einfach erklärbar, da es – zumindest im Vergleich zu den klassischen Abläufen — nur relativ wenige Regeln, definierte Abläufe und Artefakte gibt, die aber z.T. in nicht geringem Maße von den breit ausgetretenen Wegen unserer heutigen Arbeitswelt und den in ihr vorherrschenden Abläufen abweichen, ja, sich z.T. sogar konträr zu diesen verhalten, indem es z.B. die Teams von Hierarchie und zentralistischer Fremdsteuerung befreit.

Nanu? Was soll denn so schlimm daran sein, dass eine einzelne Person alle Fäden in der Hand hält und alle wesentlichen Entscheidungen trifft? Das geht doch viel schneller, als wenn sich erst ein Gruppe oder ein Team — gleichsam einem Komitee — an einen gemeinsamen Tisch setzen muss, um sich nach endloser Diskussion halbherzig auf den kleinsten gemeinsamen Nenner zu einigen.

Oder?

Scrum ist qualitäts- und produktivitätsorientiert und demokratisch  ^

Nun, Scrum verbannt nicht jegliche Hierarchie aus dem gesamten Unternehmen, sondern lediglich aus der im Verhältnis zum Unternehmen kleinen Zelle eines einzelnen Projektteams. Selbst wenn es in einem Projekt mehrere oder gar viele Projektteams gibt, konzentriert sich Scrum zunächst hauptsächlich auf diese Teams. Scrum betrachtet diese, aus ca. 7-9 Mitgliedern bestehenden Teams, als homogene Aktionskörper, als unteilbare Einheiten, als Entitäten, in denen alle beteiligten Individuen auf gleichem Level, auf gleicher Augenhöhe gemeinsam agieren und wenn vielleicht auch mit unterschiedlichen Aufgaben, so doch mit gleichen Rechten und Pflichten versehen sind.

Während der Produktion werden sich innerhalb der Entwicklungsteams immer wieder technische/fachliche, kompetenz- und aufgabenzentrierte, sich spontan an den aktuellen Anforderungen orientierende, quasi mäandernde Hierarchien herausausbilden, in denen die beteiligten Entwickler immer mal wieder über die Zeit der Produktion beliebig geartete und kurzfristige Führungsrollen im Team übernehmen werden. Starre, fest installierte, wahrscheinlich sogar von außerhalb der Teams her Einfluss nehmende Hierarchien und Entscheidungsstrukturen werden in solch kleinen, extrem intensiv kollaborierenden Teams jedoch — das zeigt die Erfahrung — schnell zu einem die Produktivität und die Qualität begrenzenden Flaschenhals … und u.A. gerade diese Flaschenhälse sind es, die Scrum zu beseitigen sucht.

Verlassen der „comfort-zone“  ^

Die die Produktivität behindernden Hierarchien und Kommandostrukturen zu beseitigen oder zumindest einzuschränken und die Produktionssituation und die Leistungsfähigkeit der Beteiligten in allen Belangen zu optimieren, ist eines der Ziele und Erfolgsrezepte von Scrum. In vielen Organisationstrukturen werden solche Veränderungen von manchen Betroffenen jedoch mit äußerster Skepsis und — zumindest gefühlt — wie „das Böse an sich“ betrachtet, denn Scrum verlangt von seinen Nutzern, die persönliche comfort-zone, in der man es sich gut eingerichtet hat, zu verlassen. In der Praxis führt das bei manchen der Beteiligten zu starken Widerständen und Beharrungskräften, die sich nur manchmal offen, viel öfter jedoch verdeckt und subtil durch inneren Widerstand und den sich daraus ergebenden Konsequenzen zeigen.

Diese, z.T. nicht unerheblichen Widerstände richten sich dann oft gegen die Einführung von Scrum insgesamt oder gegen die Durchführung aller oder einzelner Abläufe oder Regeln, mit dem Ziel, im Wesentlichen doch lieber bei den bislang eingesetzten, „guten alten“ Praktiken bleiben zu wollen.

Da ist z.B. das Daily-Scrum, dessen Notwendigkeit generell oder Ablauf und Dauer (nicht länger als maximal 15 Minuten) in Frage gestellt wird oder das Estimation-Meeting, das immer wieder der reflexhaften Suche nach Optimierungspotenzial zum Opfer fallen soll, da werden Meetings zusammengelegt oder weggelassen oder in Ablauf oder Struktur verändert oder es werden wesentliche Werte oder Strukturen von Scrum ignoriert oder umdefiniert. Manchmal ist die „Optimierung“ auch reiner Selbstzweck, um zumindest das Gefühl zu haben, etwas „verbessert“ zu haben.

Der Scrum-Guide  ^

Offenbar gestaltet sich die Einordnung und Klassifizierung von Scrum schwierig. Manche sagen, Scrum sei ein Managementrahmen, andere sagen, Scrum sei eine Entwicklungs- oder Vorgehensmethode oder -modell oder ein Konzept für professionelle Softwareentwicklung. Im aktuell knapp 20-seitigen Scrum-Guide ist zu finden, Scrum sei „ein Rahmenwerk zur Entwicklung und Erhaltung komplexer Produkte„; schon allein aus der geringen Seitenzahl ist ersichtlich, dass es sich dort bestenfalls um die Darstellung einer durchdachten Idee vielleicht hohen Potenzials handeln kann, aber nicht um die Beschreibung eines direkt in Produktion einsetzbaren Prozesses.

Vielleicht ist jedoch gerade diese allgemein gehaltene Beschreibung im Scrum-Guide der Grund für die Unsicherheit, mit der Scrum oftmals begegnet wird; sie führt zu einem hohen Verlangen nach Konkretisierung und ist wahrscheinlich auch der Grund für die Aussage im Scrum-Guide, Scrum sei zwar „leichtgewichtig“ und „einfach zu verstehen„, aber — so offenbar die Erfahrung in der Praxis — „schwierig zu meistern„. Gerade diese beiden Voraussetzungen, die allgemein gehaltene Beschreibung im Scrum-Guide und die Aussage, Scrum sei „schwierig zu meistern„, hinterlassen in potenziellen Nutzern offenbar eine ordentliche Portion Ratlosigkeit.

Was für ein Ding ist Scrum denn nun?  ^

Der Scrum-Guide beschreibt Scrum vage als Softwareentwicklungsrahmenwerk.

Was in der täglichen Praxis jedoch benötigt wird, ist nicht ein allgemein definiertes Softwareentwicklungsrahmenwerk, sondern ein einfach zu handhabender und weitestgehend durchdefinierter Softwareentwicklungsprozess, der die an den Projekten beteiligten Individuen intensiv mit allen zur Verfügung stehenden Mitteln darin unterstützt, die Projekte zu einem im Sinne des Auftraggebers umfassend erfolgreichen Abschluss führen zu können.

Aus diesem Grund soll hier und unter scrumcess.de aus der Praxiserfahrung mit der Implementation und dem „Betrieb“ von Scrum heraus ein auf dem Scrum-Rahmenwerk basierender, interaktiver und nachhaltigerbest practiceProzess beschrieben werden. Der Begriff und Name „Scrumcess“ grenzt den Prozess gegenüber dem Rahmenwerk ab, stellt aber auch Quelle und Basis klar heraus.

Was ist Scrumcess?  ^

Was verbindet / unterscheidet Scrum und Scrumcess?

Wenn Scrum ein Rahmenwerk ist, dann ist Scrumcess eine möglichst vollständige, strikte Implementation von Scrum als Prozess. Darüber hinaus ist Scrumcess das Versprechen, dass sich diese Scrum-Implementation nicht nur in der Theorie gut anhört, sondern in der Praxis unter entsprechenden Bedingungen auch gut funktioniert und erfolgreich ist. Dieses Versprechen wird in der Zukunft im Zuge seiner weiteren Entwicklung zu einer Garantie ausgebaut werden; aktuell fehlt dazu jedoch noch der vertragliche Rahmen.

Wenn Scrum also das Rahmenwerk ist, dann ist Scrumcess der Prozess dazu. Es hat

  • einen Anfang mit Eingangsdaten (initiales Product-Backlog),
  • eine Anzahl definierter Schritte in der Mitte (Sprint-Planning, Daily-Scrum, etc.),
  • zu jeder Zeit einen Status (Burndown-Charts) und
  • am Ende definierte Ausgangsdaten (Produktinkrement) als Ergebnis.

Scrumcess ist somit ein interaktiver Prozess, der nicht nur einmal zu Anfang Eingangsdaten entgegennimmt und in der Folge dann auch nicht nur nach einmaliger Verarbeitung einmalig Ausgangsdaten zurückgibt. Scrumcess startet mit oder ohne Eingangsdaten, nimmt dann nahezu permanent zur Laufzeit Daten zur Verarbeitung entgegen (jeweils am Sprintanfang definiertes Sprint-Backlog), die dann im Zeitrahmen der Sprints mit klar definierten Abläufen verarbeitet und zeitnah als Ausgangsdaten (in diesem Falls das Produktinkrement) jeweils am Sprintende den Stakeholdern zur Verfügung gestellt werden.

Der Abschluss des Prozesses wird ebenfalls von außen (durch die Stakeholder oder den Product-Owner) initiiert.

Scrumcess ist Scrum, Scrum ist aber nicht Scrumcess. Betrachtet man Scrum als Rahmenwerk, dann ist Scrumcess die konkrete und strikte Implementation dieses Rahmenwerkes in Form eines Prozesses. Wird hier von Scrum gesprochen, ist somit auch Scrumcess gemeint. Da es sich bei Scrumcess um die konkrete, aus der Praxis entstandene Implementation von Scrum handelt, wird nicht jedes im Umfeld von Scrumcess genannte Detail in der Beschreibung von Scrum oder im Scrum-Guide wiederzufinden sein; umgekehrt sollte das allerdings schon der Fall sein.

Dann ist Scrumcess ein „scrum-but„?  ^

Nein. Scrum-but („Yes, wie do scrum, but …„) ist etwas, das Scrum nur teilweise oder von Gedanken her abweichend einsetzt. Scrumcess jedoch nimmt die Gedanken von Scrum so strikt wie möglich auf und setzt sie konkret im Prozess um. Scrumcess ist etwas, was viele an Scrum vermissen, Scrumcess eine konkrete, sich dicht an das Scrum-Rahmenwerk haltende, strikte und erweiterte „best practice“ Implementationsvorlage. Scrumcess kann auch keine Implementation von Scrum sein, sondern lediglich eine strikte Implementationsvorlage, da die Implementation vor Ort bei dem jeweiligen im Projekt erfolgt.

Strikte Umsetzung? Wieder so ein Dogma?  ^

Scrum wird auf aktuell knapp 20 Seiten im Scrum-Guide beschrieben. Darüber hinaus gibt es eine erklecklich Anzahl von Fachbüchern, Publikationen und Schulungsangeboten, die sich hauptsächlich mit der Mechanik von Scrum, also das „wer macht was, wann, warum und womit und welches Ergebnis kommt am Ende heraus?“, beschäftigen. Betrachtet man die Bestandteile von Scrum unabhängig davon einmal genauer, erkennt man, dass es implizit drei verschiedene abstrakte, übergeordnete Elemente enthält und dass die Mechanik nur einen, von insgesamt drei Teilen von Scrum darstellt. Die beiden weiteren Elemente — sie werden im nächsten Abschnitt erläutert — haben jedoch einen außerordentlich großen Einfluss auf das Verhalten und den Erfolg von Scrum und die mit Scrum durchgeführten Projekte!

Wie bereits gesagt, wird Scrum im Scrum-Guide als

  • leichtgewichtig,
  • einfach zu verstehen und
  • schwierig zu meistern.

beschrieben.

Gerade die letzte der drei Charakterisierungen ist ein starkes Indiz dafür, dass es da noch etwas weiteres, abseits der tatsächlich leichtgewichtigen und einfach zu verstehenden Mechanik von Scrum geben muss; etwas vielleicht weniger Intuitives, das der ganzen Sache jedoch eine Idee und Leben gibt, eine Seele, Energie. Diese weiteren Elemente gibt es durchaus, sie sind jedoch nicht so offensichtlich und werden in der Beschreibung von Scrum nur implizitzwischen den Zeilen“ genannt und aus diesem Grund in Scrumcess explizit definiert.

„Strikte Umsetzung“ bedeutet an dieser und an allen weiteren Stellen, dass — will man die von Scrum versprochene Leistung auch wirklich erhalten — die Qualität der Implementation von Scrum in einem direkten Zusammenhang mit der Leistung, die der konkret implementierte Scrumprozess dann auch zu erbringen im Stande ist, stehen und dass die Qualität der Implementation daher — sofern man Wert auf eine hohe Leistung des Prozesses legt — nicht verhandelbar oder gar optional ist. Einen hohen Stellenwert haben in diesem Zusammenhang insbesondere die Implementationen der Prinzipien und Werte, die in Scrum lediglich implizit, in Scrumcess jedoch explizit vorausgesetzt werden und die eine wesentliche Grundlage für den erfolgreichen Einsatz von Scrum / Scrumcess sind.

Es geht dabei nicht z.B. um die Einhaltung des Zeitpunkts oder um die Länge des Daily-Scrum oder ob das Planning-Poker mit T-Shirt-Größen oder ganzen Zahlen durchgeführt werden sollte oder so, es geht vielmehr darum, dass die Kraft von Scrum in seiner Verlässlichkeit und in den Potenzialen der Scrum einsetzenden Individuen liegt, deren Maß sich aber auch und insbesondere am Maß der Qualität des Prozesses — und damit an der Qualität der Implementation — ausrichtet. Und noch etwas: Nicht Scrum als implementierter Prozess ist erfolgreich oder versagt, es ist immer das Team, das erfolgreich ist oder scheitert. Scrum ist kein Werkzeugkasten, sondern ein Werkzeug, das vom Team damit auch insgesamt als ein Werkzeug eingesetzt werden muss.

Anhand der Prinzipien und Werte ist zu erkennen, dass Scrum aus einem Netzwerk subtiler und hoch optimierter Bestandteile besteht, die ineinander greifen und insgesamt die Leistung Scrums begründen. Beginnt man damit, in dieses Netzwerk einzugreifen und es zu verändern, ohne Kenntnisse oder Erfahrungen mit diesen Zusammenhängen zu haben, läuft man schnell Gefahr, Lücken in das Netz zu reißen und bezahlt eine vermeintliche Optimierung an der einen Stelle schnell mit einem Verlust an Produktivität oder Qualität an einer anderen Stelle.

Scrum bringt für die viele Unternehmen einige, z.T. grundsätzliche Veränderung mit sich und die verlangen nach einer gewissen Portion von Akzeptanz und Disziplin — häufig ist das der Grund, warum Scrum als „schwierig zu meistern“ gilt.

Die drei abstrakten, übergeordneten Elemente  ^

Das Konzept  ^
Das Konzept ist auf einen Satz komprimierbar:

Scrum zielt mit der Gesamtheit aller Prozessbestandteile intensiv darauf ab, dem Projektteam bei konsequenter Umsetzung des Prozesses ideale Produktionsbedingungen zur ermöglichen und alle dem Team innewohnenden Potenziale und Emergenzen zu aktivieren, sie zu vergrößern und auszuweiten und aktiv zum Vorteil des Kunden und seiner Ziele -- in kurzen Intervallen Produkte höchstmöglichen Wertschöpfungspotenzials zu erhalten -- einzusetzen

Das Konzept ist somit, das Team uneingeschränkt in die Lage zu versetzen, alles Notwendige für das erfolgreiche Erreichen des Projektzieles tun zu können. Scrumcess greift dieses Konzept auf und liefert die Implementierung.

Die Kraft  ^

Die Kraft von Scrum stellt den beteiligten Individuen Schnittstellen in Form von Prinzipien und Werten zur Verfügung, deren Implementierung sie darin unterstützt, die ihnen innewohnenden, für ihre Aufgabe essenziellen mentalen Energien zu optimieren und zu maximieren und sie dem Prozess und dem Projekt zur Verfügung stellen zu können. Diese Energien sind notwendig, um das Konzept auszufüllen und produktiv nutzen zu können und so stellt die Kraft gleichzeitig auch die Verbindung zwischen dem abstrakten Konzept und dem operativen Teil des Prozesses, der Mechanik, her.

Die Mechanik  ^

Die Mechanik ist der operative, „sichtbare“ und leicht erlernbare Teil von Scrum, das „wer macht was, wann, warum und womit und welches Ergebnis kommt am Ende heraus?“, also die Rollen, Prozeduren/Besprechungen, Regeln, Abläufe und Artefakte, usw. usf. Der Umfang dieser Mechanik ist gut überschaubar, hat einen sehr kleinen Footprint und verfügt über ein auf Effizienz optimiertes Verhalten. die Mechanik ist der Teil, der zur Routine wird, in den Hintergrund tritt und dort verlässliche seinen Teil zum Erfolg beträgt.

Worin liegt denn dann das Problem?  ^

Die Mechanik ist es nicht, die Mechanik ist das Einfache an Scrum. die Mechanik ist gut überschaubar, Thema vieler Bücher, wie auch dieser Seiten und lässt sich leicht und schnell erlernen. Das Komplexe an Scrum sind die hinter dem Konzept und der Kraft steckenden, für den Erfolg von Scrum essenziellen Ideen, Konzepte und Konstruktionen, die sich nicht ohne Weiteres als konkrete Handlungsanweisungen oder kausale Zusammenhänge („Situation A ==> Handlungsanweisung A, Situation B ==> Handlungsanweisung B, Situation C ==> Handlungsanweisung C, etc. ) verpacken lassen, denn Scrum ist, z.B. in Form von Scrumcess, ein Prozess, der den Menschen und seine Potenziale, wie z.B. seine Wünsche, Bedürfnisse und seine Motivationen, aber auch seine mentalen Energien und Fähigkeiten in das Zentrum stellt — und nicht sich selbst.

Das Verhalten von Menschen, insbesondere wenn sie als Gruppe auftreten, ist weitaus komplexer, als es Technik jemals sein kann und trotzdem — oder gerade deshalb — liegt das größte und umfangreichste Optimierungspotenzial in den am Projekt beteiligten Individuen. Die klassischen Prozesse sind darum bemüht, die dem Projektteam zur Verfügung stehenden Energien zu kontrollieren, zu reglementieren und zu kanalisieren und begrenzen diese für das Projekt essenziellen Energien auf diese Weise. Das Ziel des Prozesses mit Scrum ist jedoch das genaue Gegenteil; das Ziel ist, diese Energien für das Projekt vollumfänglich zugänglich und nutzbar zu machen, sie zu optimieren und leistungsverträglich zu maximieren, z.B. durch das Prinzip der Schaffung einer optimalen Produktionssituation für das Team und mit der Optimierung der Interaktionen zwischen den beteiligten Individuen untereinander und des Prozesses.

Drei Fragen dazu  ^

1. Manche sagen, Scrum sei eine Art Religion?  ^

… weil man nichts an Scrum ändern dürfe, sondern es nur genauso anwenden darf, wie es der „Standard“ vorsehe. Stimmt das, ist Scrum eine „Religion„? Und was ist mit Scrumcess?

Keineswegs, allerdings sollte dem gefühlten Optimierungswunsch nicht schon im Vorwege nachgegeben werden. Da dies immer wieder ein brennendes Thema ist, ist ihm eine eigene Seite gewidmet.

2. Scrum ist ein Prozess?  ^

… und keine wie-auch-immer-Methode, -Rahmen oder -Konzept?

Der Scrum-Guide bezeichnet Scrum als Rahmenwerk und nicht als Prozess. Aus diesem Grund wird Scrum hier ebenfalls als Rahmenwerk angesehen, dass in Form von Scrumcess als interaktiver Prozess implementiert wird. Scrumcess verfügt über ein Konzept, ist aber nicht das Konzept und enthält Methoden, deren Nutzung über den Rahmen innerhalb des Prozesses festgelegt wird.

3. Scrum stellt den Menschen in das Zentrum?  ^

… dann müssen doch auch die Menschen das Verhalten des Prozesses selbst bestimmen können!

Ja, natürlich. Trotz allem ist und bleiben Scrum und auch Scrumcess nur Werkzeuge. Ungefähr so, wie ein Fahrzeug ein Werkzeug zur Fortbewegung ist, in dem man sitzt und das Ziel bestimmt. Das Fahrzeug gibt die Rahmenbedingungen für die Fortbewegung vor, man kann sein Ziel frei bestimmen, muss sich aber an die technischen / rechtlichen / physikalischen Rahmenbedingungen des Fahrzeugs (z.B. die Bedienung, Betriebsstoffe, StVZo, etc.) halten. Tut man das nicht, indem man z.B. nicht tankt oder bei einem Wagen mit Schaltung grundsätzlich die Kupplung meidet (was — unter kundiger Hand — durchaus funktioniert) oder indem man die physikalischen Grenzen des Machbaren / des der Gesundheit Zuträglichen ignoriert, ist die Wahrscheinlichkeit, nicht, oder zumindest nicht vollständig oder nicht pünktlich am Ziel anzukommen, relativ groß. Ähnlich ist es mit Scrum und Scrumcess. Ignoriert man das Konzept oder die Bestandteile oder die Rahmenbedingungen des Konzeptes, bewegt man den Prozess also außerhalb der Grenzen seiner Spezifikation, dann zerreißt es einen vielleicht nicht gleich, aber vielleicht tut das der Auftraggeber, weil er sich unter „Produkte höchstmöglichen Wertschöpfungspotenzials in kurzen Intervallen“ etwas ganz anderes vorgestellt hat.

Trotzdem: ja, es stimmt, Scrum stellt den Menschen in das Zentrum und ja, die Menschen können den Prozess selbst bestimmen. Wenn man sich aber für Scrum, das bereits auf einen sehr schlanken Fuß und hohe Effizienz optimiert wurde und bei dem oft eine unreflektierte, durch Unerfahrenheit (mit Scrum!) getragene weitere Optimierung oftmals zum gegenteiligen Effekt führt, entscheidet, sollte man zunächst mit dem Prozess Freund werden, bevor man ihn verändert, ohne die Hintergründe und damit die Ergebnisse zu kennen.

Sieht man sich dazu nicht in der Lage („der Prozess ist für uns da und nicht wir für ihn„, „wir akzeptieren keine Regeln, wir definieren sie„, „wir brauchen Scrum nicht, Scrum braucht uns„, etc.), sollte man besser einen anderen Weg durch die professionelle Softwareentwicklung einschlagen, denn ein schlecht implementierter Prozess führt zu schlechten Ergebnissen und das beschädigt den Prozess.

Ist Scrum also doch unagil?  ^

Scrum ist also unflexibel und darf nicht verändert oder angepasst werden?
Ist das denn angemessen für einen agilen Prozess?

Nein, nein und nein. Selbstverständlich kann, darf und soll man Scrum im Rahmen seiner Spezifikation personalisieren können. Auch ein Fahrzeug kann und darf man tunen, allerdings darf auch das nur im Rahmen der genannten technischen / rechtlichen / physikalischen Rahmenbedingen stattfinden und sollte — und das ist der eigentliche Kern — nicht geschehen, ohne zuvor live und in Farbe, also selbst und „mit der Hand am Arm“ Erfahrungen gemacht zu haben; dies betreffend eben mit einem intakten und gut funktionierenden Scrumprozess, z.B. in Form von Scrumcess. Woher soll man denn sonst die Risiken und Effekte der Modifikation und das Delta zwischen Vorher und Nachher beurteilen können? Man muss sich vergegenwärtigen, dass eine vermeintliche Optimierung an der einen Stelle zu Insuffizienzen an einer ganz anderen Stellen führen kann, die dann nicht nur den Ertrag der Optimierung zunichtemachen können, sondern zu einer echten Verschlechterung, also zu einer Verschlimmbesserung führen können. Das ist genau wie das Überdrehen einer Schraube, ganz nach der alten Weisheit „nach fest kommt ab“, wobei bei der Schraube der Zusammenhang zwischen Ursache und Wirkung noch klar erkennbar ist; bei einem Prozess in der IT ist das zumeist nicht so.

Scrum ist der Rahmen, Scrumcess der Prozess

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1503090852DE