TopMenue

Was ist Scrum?

Was ist Scrum eigentlich? Ist es ein Rahmen oder Rahmenwerk? Eine Methode? Ein Prozess? ein Modell? 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 Softwareentwicklungs…dings. 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
  • Reflexion/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, Selbstreflexion 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 eine 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 das Produktionsklima 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.

Scrum ist kein Werkzeugkasten!  ^

Die Definition von Scrum läuft darauf hinaus, dass Scrum eine konzeptuelle Maschine ist, die aus einem System kollaborierender Komponenten besteht. Der Wirkungsgrad der Maschine wird durch die Wirkungsgrade ihrer Komponenten und deren Kollaboration bestimmt. Sind — und das ist das Ziel — die Wirkungsgrade der einzelnen Komponenten hoch, ist auch der Wirkungsgrad der Maschine hoch; ist der Wirkungsgrad einzelner Komponenten jedoch klein oder gar 0, sinkt damit auch der Wirkungsgrad des Gesamtsystems!

Aus dieser Sicht heraus soll hier aus der Praxiserfahrung mit der Implementation und dem „Betrieb“ von Scrum heraus ein auf dem Scrum-Rahmenwerk basierender, interaktiver und nachhaltiger, „best practice„-Prozess beschrieben werden, der diese Maschine implementiert. Der Begriff und Name „Scrumcess“ grenzt den Prozess gegenüber dem Rahmenwerk ab, stellt aber auch Quelle und Basis klar heraus.

Scrum ist der Rahmen, Scrumcess der Prozess

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1503130747DE