Grundlagen und Philosophie von «Scrum»

Scrum Grundlagen

Scrum Definition (Scrum Guide, 2017):
Scrum (n): Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern.

Scrum ist:

• leichtgewichtig
• einfach zu verstehen
• schwierig zu meistern

Scrum wird seit den frühen 1990er Jahren als Prozessrahmenwerk zum Management der Arbeit an komplexen Produkten verwendet. Scrum ist weder ein Prozess, noch eine Technik oder vollständige Methode. Vielmehr ist es ein Rahmenwerk, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können. Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Ihrer Arbeitstechniken sichtbar, damit Sie fortlaufend das Produkt, das Team und die Arbeitsumgebung verbessern können. Das Scrum-Rahmenwerk besteht aus Scrum-Teams und den zu ihnen gehörenden Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente innerhalb des Rahmenwerks dient einem bestimmten Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg.

Scrum wurde von Beginn an nicht als Methode oder Technik konzipiert. Der Anspruch von Scrum ist es nicht, eine Antwort auf alle Fragen im Bereich der Software-Entwicklung zu liefern. Es schreibt keine Entwicklungsmethoden vor, beschreibt nicht, wie Releaseplanung oder Projekt-Budget-Planung zu machen ist. Nicht, weil dies nicht wichtig wäre, sondern einfach, weil Scrum hier die Meinung vertritt, dass es viele mögliche Ansätze gibt, welche je nach Art des Entwicklungsprojektes mehr oder weniger gut passen. Dazu wurde Scrum von Anfang an als Framework (ein Rahmenwerk) konzipiert, das offen für Ergänzungen und Erweiterungen ist.

Der Fokus von Scrum ergibt sich aus dem Anliegen, in Entwicklungsprojekten optimalen Kundennutzen zu erzielen. Dabei geht es nicht darum, innerhalb kurzer Zeit möglichst viel Software umzusetzen. Vielmehr ist es das Ziel, durch klare Priorisierung und Fokussierung mit möglichst wenig Software einen möglichst großen Kundennutzen zu erzielen und dabei alles, was keinen Kundennutzen bringt, so weit wie möglich wegzulassen.

Wer heute Stellenanzeigen, Kursausschreibungen oder Fachartikel liest, kommt leicht zum Schluss, dass agile Herangehensweisen und insbesondere Scrum quasi eine Wundermethode sei, welche für jedes denkbare Projekt und jede denkbare Fragestellung innerhalb der IT herangezogen werden könne. Dies ist natürlich falsch! Scrum ist dann erfolgreich und nutzbringend, wenn drei Grundvoraussetzungen gegeben sind:

• Ein Team, das bereit ist, sich auf Scrum als Framework einzulassen, und laufend daran arbeitet, seine Ergebnisse zu optimieren.
• Eine Organisation und Management, welches bereit ist, die Philosophie, Vorgehensweisen und Regeln von Scrum zu unterstützen.
• Ein Kunde, der bereit ist, sich auf eine Scrum-Vorgehensweise einzulassen. Dazu gehört genauso die Bereitschaft zur laufenden Mitarbeit in der Definition und Ausgestaltung von Anforderungen wie auch die Bereitschaft, geeignete Mitarbeiter mit dem notwendigen Fach-Know-how für Feedbacks abzustellen. Genauso gehört dazu die Bereitschaft, sich auf ein Projekt einzulassen, dessen genauer Funktionsumfang sich erst im Laufe des Projektes definiert, und dies auch durch den Abschluss dazu passender Verträge mitzutragen.

In vielen Fällen sind diese drei Punkte nur zu einem geringen Teil gegeben. Die Erfahrung zeigt, dass Kunden immer häufiger agile Vorgehensweisen und Scrum als Voraussetzung für Projekte definieren, dabei aber nach wie vor Lastenhefte mit 95% Muss-Kriterien als Grundlage setzen. Diese Rahmenbedingungen widersprechen agilem Vorgehen. Dies heißt aber nicht, dass Scrum oder andere agile Vorgehensweisen deshalb fallen gelassen werden sollten. Vielmehr muss uns bewusst sein, dass die Einführung von Scrum selbst ebenfalls als Projekt zu sehen ist, in welchem sowohl der Kunde wie auch die eigene Organisation lernen und sich weiterentwickeln. So ist es nicht überraschend, wenn manche Fachleute vorschlagen, die Einführung von Scrum selbst auch als agiles Projekt zu sehen, bei dem das Verständnis und der Einsatz von Scrum als agilem Framework mit jeder Iteration weiter manifestiert wird.

Anwendungsbereiche von Scrum

Der Scrum-Guide schreibt, dass es bei Scrum darum gehe, «produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern». Scrum fokussiert entsprechend zentral auf die Entwicklung von Produkten, nicht auf deren Unterhalt. Dabei erweisen sich virtuelle Produkte wie Software, Marketing-Produkte oder konzeptionelle Arbeit als tendenziell geeigneter als beispielsweise die Entwicklung grösserer Hardware-Einheiten, Gebäude oder größere Maschinen. Es existieren aber sehr wohl Ansätze zum Einsatz von Scrum in ganz anderen Bereichen oder auch als Gesamtkonzept für Unternehmen mit Einsatz von Geschäftsleitung über Vertrieb, Marketing, Kundendienst etc. bis hin zur Produktentwicklung. Dabei ist es notwendig, sich auf die Philosophie von Scrum zu fokussieren und gewisse Regeln womöglich in deren Licht an Fragestellungen anzupassen.

Die Säulen von Scrum

Scrum basiert auf drei Säulen. Neben den Werten von Scrum stellen sie die weltanschauliche und methodische Basis des Frameworks dar. Sie heissen Transparenz (Transparency), Überprüfung (Inspection) und Anpassung (Adaption).

Transparenz
Fortschritte und Hindernisse werden offen festgehalten und kommuniziert (auch dem Kunden gegenüber). Sie bilden die Grundlage für eine vertrauensvolle und zielführende Zusammenarbeit zwischen Auftragnehmer (Scrum-Team) und Auftraggebern (Stakeholdern / Kunden).

Überprüfung
Zwischenprodukte (Inkremente) werden regelmässig geliefert und beurteilt. Das dabei zustande gekommene Feedback bildet die Basis für ein gemeinsames Lernen, wo der grösste Kundennutzen liegt, und die Möglichkeit, das entstehende Produkt darauf auszurichten.

Anpassung
Ein Scrum-Entwicklungsprojekt wird von den beteiligten Personen und Organisationen als gemeinsames Lernen verstanden. Dies ermöglicht es dem Scrum-Team, seinem Kunden maximale Wertschöpfung und ein optimales Kosten/Nutzen-Verhältnis zu bieten. Gerade bei Software-Projekten kann der Kunde oft bei Projektbeginn gar nicht alle Anforderungen bis ins Detail einschätzen und viele dieser Anforderungen nehmen im Laufe der Entwicklungszeit an Bedeutung zu oder ab. So kann es sein, dass neue Rahmenbedingungen wie Gesetzgebung, Kunden oder strategische Ausrichtung dazu führen, dass Aspekte eines Projektes, welche bei Entwicklungsbeginn wichtig waren, an Bedeutung verlieren (oder umgekehrt). Prozesse beim Kunden können sich verändern oder die beteiligten Personen auf Kundenseite erkennen im Verlauf eines Projektes, dass bisher unterschätzte Aspekte eine größere Bedeutung und Wertschöpfung haben. Andere verlieren womöglich an Bedeutung oder werden vollständig überflüssig. In anderen Fällen verstehen Kunde und Entwickler Anforderungen unterschiedlich. Durch das regelmässige Feedback des Kunden besteht die Möglichkeit, die Richtung der Entwicklung laufend zu verbessern und somit eine höhere Wertschöpfung zu erzielen. Dabei müssen alle Beteiligten verstehen, dass das gesamte Projekt nur dann erfolgreich sein kann, wenn alle Beteiligten daraus Profit und Wertschöpfung erzielen. Anpassungen von Anforderungen dürfen entsprechend nicht einseitig zulasten einer der beteiligten Parteien gehen.

Die Werte von Scrum

Der Erfolg von Scrum hängt zu einem großen Teil von der Einstellung des Teams und den damit zusammenarbeitenden Personen ab. Diese basiert auf den fünf Werten von Scrum. Natürlich ist es möglich, die Rituale, Rollen und Artefakte von Scrum auch inhaltsleer nachzuahmen, ohne die Werte zu teilen. Dabei geht aber ein großer Teil des Nutzens und der Kraft von Scrum verloren. Nur wer die Werte von Scrum verinnerlicht hat und als Grundlage für seine Tätigkeit umsetzt, wird sich den Herausforderungen des Alltags stellen können und dabei im Sinne von Scrum handeln und den entsprechenden Erfolg erleben. Ansonsten bleibt der Erfolg auf das Abarbeiten eigentümlicher, für den Handelnden sinnloser Abläufe beschränkt.

Fokus
Mit dem Ziel, die größtmögliche Wertschöpfung für den Kunden zu erzielen, ist eine klare Fokussierung auf das jeweilige Sprintziel ausschlaggebend. Jede Ablenkung vom Sprintziel muss vermieden werden. Entsprechend wichtig ist es auch, dass das Entwicklungsteam seine Aufmerksamkeit nicht zwischen verschiedenen Entwicklungsprojekten oder Aufgabenstellungen aufteilen muss.

Offenheit
Agile Vorgehensweise bedingt Offenheit gegenüber neuen Anforderungen und sich verändernden Rahmenbedingungen. Dabei meint Offenheit zum einen die Bereitschaft, sich auf agile Vorgehensweisen einzulassen und die damit verbundenen Änderungen umzusetzen, und andererseits die Art, mit Informationen umzugehen. Unabhängig davon, ob es sich um Anforderungen, Hindernisse, den Projektfortschritt oder die Zusammenarbeit im Team handelt. Kontinuierliche Verbesserung setzt Offenheit und Transparenz voraus.

Mut
Offenheit braucht Mut. Es braucht ebenso Mut, sich neuen Herausforderungen und Risiken zu stellen, wie sie eine neue Herangehensweise wie «Agile» und «Scrum» fordert.
Scrum fordert ein hohes Maß an Selbstverantwortung des Teams. Dies bedeutet auch, Entscheidungen zu treffen und deren Konsequenzen zu tragen, auch wenn oft nicht alle Fakten bekannt sind.

Respekt
Scrum ist Teamarbeit in einem Team gleichrangiger Personen. Es gibt keinen Teamleader oder Scrum-Leiter, der Entscheidungen treffen würde. Um gemeinsam die besten Entscheidungen zu treffen und eine optimale Zusammenarbeit zu ermöglichen, ist es notwendig, die Verschiedenheit der Teammitglieder und ihre unterschiedlichen Erfahrungen und Kenntnisse zu schätzen und zu nutzen. Nur wenn die Zusammenarbeit von gegenseitigem Respekt getragen wird, sind alle Beteiligten in der Lage, ihren optimalen Beitrag zum Erreichen des gemeinsamen Ziels einzubringen.

Committment
Das Team verpflichtet sich während des Sprints, ein selbst bestimmtes Ergebnis zu erzielen. Diese Selbstverpflichtung erhöht die Wahrscheinlichkeit, dass die vereinbarte Funktionalität auch in geeigneter Qualität umgesetzt wird. Sie setzt voraus, dass dem Team Aufgaben nicht zugewiesen werden, sondern es diese basierend auf seinen Fähigkeiten und seiner Kapazität übernimmt.