TopMenue

3×10 gute Gründe für Scrum

Es gibt sehr viele gute Gründe, Scrum einzusetzen

Im Folgenden werde ich Ihnen die aus meiner Sicht 10 wichtigsten Gründe jeweils für

  1. die beauftragenden Kunden
  2. die ausführenden Unternehmen
  3. die beteiligten Mitarbeiter

nennen und erläutern.

Im weiteren Text werde ich den Begriff „Stakeholder“ als Sammelbegriff für die Rollen Stakeholder selbst, aber auch für die Kunden, bzw. die Auftraggeber verwenden.


1. Für die Stakeholder

1.1. Hohe Produktqualität  ^

Qualität ist eines der höchsten Güter in Scrum und daher nicht verhandelbar.

Konzentration auf das Wesentliche  ^

Die Entwickler konzentrieren sich in einem Sprint lediglich auf ein überschaubares Set an Anforderungen, das sie gemeinsam mit dem Product-Owner aus der Menge der höchstpriorisierten Anforderungen heraus für die Realisation im Sprint ausgewählt haben. Durch Praktiken wie Pair-Programming und gegenseitigen Code-Reviews haben immer mehrere Entwickler-Augen den Code im Blick und sichern dadurch einen hohen Qualitätsstandard.

Frühzeitige und regelmäßige Auslieferung funktionierender Software  ^

Anders als in den klassischen Softwareentwicklungsprozessen erhalten die Stakeholder nicht erst am Ende des Projektes ein funktionierendes Produkt, sondern sie erhalten jeweils am Ende jedes Sprints einen getesteten, lauffähigen, gegenüber der jeweiligen Vorversion um die wichtigsten und damit für die Stakeholder wertvollsten Anforderungen erweitertes Produktinkrement, in dem nur vollständig implementierte, einsetzbare Anforderungen enthalten sind. Die Aufgabe der Stakeholder ist dann, das ihnen übergebene Produktinkrement noch einmal einer fachlichen Prüfung und manuellen Tests zu unterziehen, um Erfahrungen mit dem Projektstand zu machen und wertvolles Feedback in das Projekt zurückfließen lassen zu können.

Hohe Produktqualität  ^

Fehler oder Unzulänglichkeiten, die bei der Abnahme im Sprint-Backlog oder danach bei den Tests der Stakeholder auffallen, werden ja nach Schwere umgehend in einem der als nächstes folgenden Sprints korrigiert. Damit wird erreicht, dass auch bereits die jeweils frühzeitig ausgelieferten Produktinkremente über eine hohe fachliche und technische Qualität verfügen.

Akzeptanzkriterien  ^

Jede Anforderung, die vom Product-Owner in das Product-Backlog als User-Story aufgenommen wurde, hat er mit Akzeptanzkriterien versehen, um eine technisch und fachlich einwandfreie Implementationen nachvollziehbar sicherzustellen. Die Akzeptanzkriterien definieren ein klares Ziel und werden durch fachliche Tests abgesichert, die automatisch und / oder manuell durchgeführt werden können. Darüber hinaus wird von den Entwicklern jede einzelne Funktionalität separat für sich mit Unit-, Modul und Integrationstests abgesichert.

„Test first“ und „clean Code“- Ansatz  ^

Der Einsatz von „Testdriven Development“, z.B. gemeinsam mit einem gut eingeführten „Clean Code“-Ansatz, schafft eine hohe Quellcode-Transparenz und -Sicherheit, die eine nachhaltige Grundlage für einen hohe Qualitätsstandard des Quellcodes und des Projektergebnisses ist. Permanente Quellcodebereinigung und Qualitätsverbesserung des Quellcodes durch zeitnahes Refactoring und das Vermeiden technischer Schuld ergänzen den nachhaltigen Ansatz zur Erreichung einer hohen Produktqualität.

Definition of Done  ^

In Scrum-Projekten wird eine lebendige, d.h. vom Scrum-Team immer an die neuesten Erkenntnisse angepasste „Definition of Done“ erstellt, gepflegt und im Projekt eingesetzt. In der DoD sind Kriterien festgelegt, die als Rahmenbedingungen dafür anzusehen sind, wann ein Modul als „fertig“ bezeichnet werden kann. Alle Quellcode- und Projekt-Änderungen können über ein Configuration-Management oder ALM-Tool (z.B. Microsoft Team Foundation Server) jederzeit abruf- und nachvollziehbar gemacht werden.

1.2. Intensive Projektbeteiligung  ^

Die Stakeholder sind in Scrum als für den Projekterfolg unverzichtbare Teammitglieder tief und auf Augenhöhe in das Projekt eingebunden.

Die Stakeholder sind wichtig  ^

In Scrum sind die Stakeholder nicht nur Kunden und Auftraggeber, sondern sie sind auch aktiv beteiligte Projektmitglieder. Sie geben Inhalt und Priorisierung des Product-Backlogs vor und können — unter Beachtung der sich daraus ergebenden Risiken und Konsequenzen — nahezu jederzeit beliebige Änderungen ins Projekt einfließen lassen.

Darüber hinaus erhalten die Stakeholder am Ende des Sprints ein lauffähiges Produkt zum Ausprobieren, Testen und um neue Erfahrungen als Feedback ins Projekt zurückfließen lassen zu können.

Auslieferung des Sprint-Ergebnisses  ^

Am Ende jedes Sprints erhalten sie ein neues und je nach Stand der Implementierung zumindest potenziell einsetzbares Produktinkrement, das die jeweils aktuell wichtigsten Funktionen vollständig und lauffähig implementiert enthält. Die Aufgabe der Stakeholder ist es, dieses Inkrement ausführlich zu testen und auszuprobieren, um Erfahrungen mit dem Produkt zu sammeln. Da sie diese Erfahrungen jederzeit wieder ins Projekt zurückfließen lassen können, erhalten sie am Ende des Projektes das Produkt, das sie wirklich benötigen und nicht eines, dessen Spezifikation irgendwann vor oder am Beginn des Projektes festgelegt wurde und im Laufe des Projektes mehr und mehr veraltet ist.

1.3. Frühe Marktreife des Produktes  ^

Die Stakeholder erhalten am Ende eines jeden Sprints ein lauffähiges und im bis dahin realisierten Funktionsumfang vollständig implementiertes Produkt, dass sie potentiell, d.h., sofern es das bis dahin realisierte Anforderungsset möglich macht, auch direkt in Produktion einsetzen können.

Permanente Priorisierung der Anforderungen  ^

Der Product-Owner befindet sich in permanentem Dialog mit den Stakeholdern. Die von ihm aufgenommenen Anforderungen sammelt er im Product-Backlog, priorisiert sie anhand aktueller Erkenntnisse, Erfahrungen und Wünsche der Stakeholder und sortiert das Product-Backlog nach dieser Priorität. Damit ist sichergestellt, dass die wichtigsten und damit die für die Stakeholder wertvollsten Anforderungen immer vollständig und als erstes entwickelt werden. Das führt dazu, dass das Produkt frühzeitig einsetzbar ist.

Frühzeitige Auslieferung einer lauffähigen Version am Ende jeden Sprints  ^

Anders als in den klassischen Softwareentwicklungsprozessen erhalten die Stakeholder nicht erst am Ende des Projektes einen funktionierenden Softwarestand, sondern sie erhalten jeweils nach Beendigung eines Sprints einen getesteten, lauffähigen, gegenüber der Vorversion um die wichtigsten und damit für die Stakeholder wertvollsten Anforderungen erweiterten Softwarestand, in denen die jeweils implementierten Anforderungen vollständig implementiert und damit einsetzbar sind. Zudem wird mit der Entwicklung bereits sehr früh begonnen, da nicht erst der Abschluss der Anforderungsaufnahme abgewartet werden muss, um mit der Entwicklung beginnen zu können.

Wenn das den Stakeholdern ausgelieferte Produktinkrement getestet, ausprobiert und in Hinblick auf Qualität und Funktionsumfang für in Produktion einsetzbar befunden wurde, können sie diesen Stand selbstverständlich an die Nutzer ausliefern und sofort — also frühzeitig, statt erst am Ende des Projektes — in Produktion nehmen, sofern der bis dahin realisierte Funktionsumfang dies sinnvoll erscheinen lässt.

Qualität ist nicht verhandelbar  ^

In Scrum wird sehr hoher Wert auf die Produktqualität gelegt. Fehler oder Unzulänglichkeiten, die bei der Abnahme im Sprint-Backlog oder danach bei den Tests der Stakeholder aufgefallen sind, werden ja nach Schwere umgehend in einem der als nächstes folgenden Sprints korrigiert, sodass auch bereits die zwischenzeitlichen Softwarestände über eine Qualität verfügen, die in Produktion einsetzbar ist. Die sich oft in den klassischen Softwareentwicklungsprozessen an die Auslieferung anschließende Phase der Fehlerbehebung, die, je später in einem Projekt begonnen, umso schwieriger und damit in Hinblick auf Zeit und Kosten aufwändiger wird, entfällt in Scrum-Projekten daher.

1.4. Hohe und frühe Wertschöpfung  ^

Bislang mussten die Stakeholder damit leben, dass sie auch nach erfolgreicher Beendigung des Softwareentwicklungsprojektes ein Produkt erhalten, das bereits bei der Fertigstellung — zumindest potenziell — veraltet war. Es wurde dann — wenn möglich — im Nachhinein unter hohem Zeit- und Kostenaufwand auf einen aktuellen Stand gebracht. In Scrum kann dieser Schritt daher im Allgemeinen entfallen.

Änderungen sind Teil des Erfahrungsprozesses  ^

Scrum ist ein Prozess, der Änderungen an der Spezifikation nicht nur berücksichtigt, sondern sogar erwartet. Er geht davon aus, dass sich die endgültige Spezifikation (sofern es überhaupt eine endgültige Spezifikation geben kann) erst im Laufe des Projektes herauskristallisiert. Der Grund dafür liegt in dem Erfahrungsprozess, der bei den Beteiligten im Laufe des Entstehungsprozesses des Produktes permanent stattfindet und der aus diesem Grund in der ursprünglichen Planung gar nicht berücksichtigt sein konnte.

Zeitnahe Berücksichtigung von Veränderungen der Spezifikation  ^

Was in den klassischen Softwareentwicklungsprozessen erst spät, vielleicht sogar erst nach Abschluss des Projektes berücksichtigt werden kann, kann in Scrum bereits im nächsten Sprints — und damit zeitnah — ins Projekt einfließen.

Handelt es sich jedoch um sofort zu berücksichtigende Änderungen, die nicht bis zum nächsten Sprint warten kann, hat der Product-Owner die Möglichkeit, die Änderungen nach eingehender Bewertung der Risiken und Konsequenzen für Produkt und Projekt und in Absprache mit dem Entwicklungsteam sofort im Sprint-Backlog zu berücksichtigen.

Handelt es sich bei der Änderungen um das Entfallen einer Anforderung, wird das Entwicklungsteam die Anforderung aus dem Sprint-Backlog entfernen und eine Reihe der höchstpriorisierten Anforderungen aus dem Product-Backlog schätzen und eine vom Aufwand her passende Anforderung neu in das Sprint-Backlog aufnehmen.

Handelt es sich bei der Änderungen um eine Anforderung, die — aus welchen Gründen auch immer — sofort im aktuellen Sprint umgesetzt werden muss, muss das Entwicklungsteam diese Anforderung schätzen und gemeinsam mit dem Product-Owner schauen, welche der aktuell im Sprint-Backlog enthaltenen Anforderung(en) entfernt werden können, um den zeitlichen Rahmen für die Realisierung dieser Anforderung zu schaffen.

Insbesondere im zweiten Fall bedeutet diese Maßnahme, dass der Sprint gestört und das Entwicklungsteam um Ruhe und Konzentration gebracht wird. Planung und Organisation werden zunichte gemacht, was die Produktivität sinken lässt. Es muss daher sehr genau geprüft werden, ob das Einschieben der Anforderung tatsächlich notwendig ist, oder ob es im Gesamtzusammenhang des Projektes nicht sinnvoller ist, die Änderung erst im folgenden Sprint zu berücksichtigen.

Am Ende jeden Sprints potenziell einsetzbare Software  ^

In jedem Fall erhalten die Stakeholder jeweils am Ende eines jeden Sprints einsetzbare Software, in der die jeweilig für sie wichtigsten und wertvollsten und damit mit dem höchsten Wertschöpfungspotenzial versehenen Funktionalitäten implementiert sind.

1.5. Hohe Budgetsicherheit  ^

Scrum legt großen Wert auf die Minimierung des Projektrisikos und eine frühe Marktreife des Produktes.

Frühzeitige Auslieferung funktionierender Software  ^

Anders als in den klassischen Softwareentwicklungsprozessen erhalten die Stakeholder nicht erst am Ende des Projektes einen funktionierenden Softwarestand, sondern verlässlich jeweils am Ende jedes Sprints einen getesteten, lauffähigen, gegenüber der Vorversion um die wichtigsten und damit für die Stakeholder wertvollsten, vollständig implementierten Anforderungen, erweiterten Softwarestand, der — je nach Struktur der Anforderungen – sofort in Produktion einsetzbar ist.

Continuous Delivery  ^

Scrum arbeitet nach dem Prinzip des „Continuous Delivery“, der fortwährenden Auslieferung lauffähiger Produktinkremente in kurzen Zyklen. Das eröffnet die Möglichkeit, das Projekt bereits vor dem geplanten Ende abschließen zu können, z.B., um Zeit oder Budget einzusparen. Dies kann schon frühzeitig möglich sein, da in Scrum immer die wichtigsten und damit für die Stakeholder wertvollsten Anforderungen zuerst realisiert werden und somit die Kernanforderungen im Produkt je nach Zeitpunkt mit hoher Wahrscheinlichkeit bereits vollständig realisiert wurden.

Effiziente Kommunikation  ^

Eine effiziente Kommunikation führt zu effektiven Meetings, in denen ein Maximum an Informationen übertragen und Erkenntnisse erarbeitet werden können, was zu einer hohen Produktivität führt und damit Zeit und Geld spart.

1.6. Hohe Termintreue  ^

Fast alles in Scrum ist eine Timebox und damit verlässlich und pünktlich. Die Stakeholder können sich darauf verlassen, dass sie am Ende jedes Sprints, die das gesamte Projekt hindurch die gleiche Zeitdauer in Anspruch nehmen, ein erweitertes Produktinkrement erhalten werden. Wenn sie an Meetings teilnehmen oder Kontakt zum Product-Owner aufnehmen wollen, wissen sie, wann und wo diese Meetings stattfinden werden, bzw. wie und wo sie den Product-Owner erreichen können. Scrum-Projekte sind verlässliche und pünktliche Projekte.

Timeboxen  ^

Die Vorgänge, die aufgrund des Ablaufens der Timebox beendet wurden, gelten dann nicht als fast oder teilweise fertig, sondern strikt als unfertig, unabhängig davon, ob sie kurz vor der Fertigstellung standen, „nur noch nicht getestet“ waren oder gerade erst damit begonnen wurde, sie zu entwickeln. Das hat zur Folge, dass unfertige Anforderungen z.B. im Review nicht präsentiert werden dürfen und im auszuliefernden Produktinkrement dann auch nicht enthalten sind. Damit ist sichergestellt, dass Termine eingehalten werden und keine unfertigen Features im Produktinkrement enthalten sind, womit ein weiterer Beitrag zum Verlässlichkeitsprinzip von Scrum geleistet ist.

Da in Scrum immer von der höchsten Priorität zur niedrigeren, also vom Wichtigeren zum geringer wichtigen gearbeitet wird, kann es nicht sein, dass geringer wichtige Anforderungen Eingang ins Produkt finden, Wichtigere aber nicht.

Fortwährende Auslieferungen in kurzen Zyklen  ^

Die fortwährenden Auslieferungen erfolgen im Rhythmus der Sprints, die über das gesamte Projekt verlässlich einen gleichbleibenden Zyklus im Bereich von ca. 2 – 4 Wochen haben. Diese Zeiträume sind recht gut zu überblicken und die Termine sind daher gut einzuhalten. Zudem arbeitet Scrum nach dem Timeboxing-Prinzip, was dazu führt, dass ein Vorgang auch dadurch abgeschlossen werden kann, dass sich das Zeitfenster der Timebox schließt, selbst wenn noch nicht alle Arbeiten abgeschlossen wurden.

Zeit und Budget  ^

Zeit (Termine, Termintreue) und Geld (Budget, Budgetsicherheit) sind einander sehr ähnliche Faktoren. In den klassischen Softwareentwicklungsprozessen werden beide letztendlich und wenn möglich, sollten sie zur Neige gehen, ohne dass alle wichtigen Anforderungen umgesetzt sind, verlängert.

Scrum stellt hier die Welt gewissermaßen auf den Kopf, da in Scrum die Einhaltung der Grenzen von Zeit und Geld in den Vordergrund gestellt werden und die vollständige Implementation des Anforderungssets in den Hintergrund, da fast alles in Scrum eine Timebox ist, die es einzuhalten gilt und das gilt im übertragenen Sinn insbesondere auch für das Budget.

Die jeweils wichtigsten Anforderungen werden zuerst realisiert  ^

In Scrum werden die wichtigsten und für die Stakeholder wertvollsten Anforderungen (hohe Priorität) immer so früh wie möglich und die weniger wichtigen Anforderungen (niedrigere Priorität) erst danach realisiert. Gehen zum Ende des Projektes hin Zeit und Geld zur Neige, obwohl noch nicht alle Anforderungen implementiert wurden, handelt es sich mit hoher Wahrscheinlichkeit um solche, deren Implementierung unter den gegebenen Umständen zumindest verhandelbar sein sollten.

Einer permanenten Pflege, Aktualisierung, Priorisierung und Sortierung des Product-Backlogs durch den Product-Owner kommt aus diesen Gründen eine besondere Bedeutung zu.

1.7. Hohe Anforderungsflexibilität  ^

Scrum ist ein agiler Prozess, was u. A. bedeutet, dass Scrum flexibel mit Anforderungsänderungen umgeht.

Die Stakeholder können jederzeit Änderungen einbringen  ^

Die Stakeholder können das Anforderungsset, das vom Product-Owner im Product-Backlog verwaltet wird, in Absprache mit ihm jederzeit unter Beachtung der sich aus der Änderung ergebenden Risiken und Konsequenzen (z.B. Zeit, Budget) ändern. Der Product-Owner wird die Änderungen umgehend in das Product-Backlog einpflegen und es anschließend nach der vergebenen Priorität absteigend sortieren, damit die wichtigsten Anforderungen im Product-Backlog weiterhin ganz oben auf der Liste zu finden sind.

Auf das Sprint-Backlog des aktuellen Sprints hat das zunächst keinen Einfluss.

Änderungen des Sprint-Backlogs  ^

Der Sprint wird als geschützte Zone betrachtet. Bei schwerwiegenden Änderungen, z.B., weil im aktuell laufenden Sprint Anforderungen implementiert werden, die jedoch kurzfristig überflüssig geworden sind und nicht mehr realisiert werden sollen, kann es vom Team als angemessen angesehen werden, dass Product-Owner und Entwicklungsteam gemeinsam und im Einvernehmen das Sprint-Backlog ändern.

Durch solche Änderung im Sprint-Backlog frei gewordener Platz wird durch die höchstpriorisierten Anforderungen aus dem Product-Backlog wieder aufgefüllt; sollen dagegen zusätzliche Anforderungen in das Sprint-Backlog aufgenommen werden, müssen, da die Sprintlänge begrenzt ist und der Sprint als Timebox nicht verlängert wird, dafür andere Anforderungen aus dem Sprint-Backlog entfernt werden.

Auch hier gilt, dass der Product-Owner und Stakeholder, evtl. unter Einbeziehung des Entwicklungsteams, Risiken und Konsequenzen solcher Änderungen bewerten und, je nach Bedeutung und Schwere der Änderung, diese in die weitere Planung einfließen lassen müssen.

1.8. Hohe Projekttransparenz  ^

Die Beteiligten handeln auf Augenhöhe und erhalten die gleichen Informationen.

Fortwährende Auslieferungen in kurzen Zyklen  ^

Die fortwährenden Auslieferungen erfolgen im Rhythmus der Sprints, die über das gesamte Projekt verlässlich einen gleichbleibenden Zyklus im Bereich von ca. 2 – 4 Wochen haben. Die Planung über diese Zeiträume, z.B., welche Anforderungen in einem Sprint zu realisieren sind, ist relativ leicht überschau- und nachvollziehbar und wird den Stakeholdern zugänglich, bzw. bekannt gemacht.

Sprints sind Timeboxen  ^

Die Sprints sind eingebettet in Releases und die Releases in die Dauer des Projektes. Da es sich bei allen Zeiträumen um Timeboxen handelt (alles was bis zum Ende der Timebox nicht fertig im Sinne der DoD ist, wird bei der Bewertung des Zeitraumes ignoriert). Diese Zeiträume sind recht gut zu überblicken und Termine damit gut einzuhalten, wobei Auskunft über den Stand der Dinge jeweils entsprechende Sprint-Burndown-Charts (Sprint-Burndown-Chart (Entwicklungsteam), Release-Burndown (Product-Owner) und weitere Metriken) geben.

Fast alle Meetings sind öffentlich  ^

Fast alle Besprechungen sind in Scrum öffentlich und können von Gästen besucht werden, wobei die Gäste in den meisten Besprechungen jedoch lediglich als stille Besucher anwesend sein dürfen. Nach Ende jedes Sprints erhalten die Stakeholder ein aktuelles Produktinkrement zum Begutachten und Testen, um zum einen den Entwicklern wertvolles Feedback geben zu können und zum anderen, um sich über den aktuellen Stand der Entwicklung in Kenntnis zu setzen.

1.9. Minimierung des Projektrisikos  ^

Die schwerwiegendsten Risiken in Softwareentwicklungsprojekten liegen in den Bereichen Planung, Kommunikation und Qualität. In allen diesen Bereichen minimiert Scrum die Risiken, indem die Planung auf einen überschaubaren Rahmen begrenzt, die Kommunikation zwischen allen Beteiligten systemisch gefördert und die Qualität des Produktes vom Entwicklungsteam in enger Zusammenarbeit mit den Stakeholdern stetig verbessert wird.

Frühzeitige Einsetzbarkeit des Produktes  ^

Die Stakeholder können das Produkt frühzeitig einsetzen, denn bei den im Rhythmus der Sprints ausgelieferten Produktinkrementen handelt es sich jeweils um die aktuellsten Softwareversionen, in denen die höchstpriorisierten Anforderungen jeweils vollständig implementiert wurden und die somit im Rahmen des Entwicklungsstandes des Produktes bereits vollständig einsatzfähig sind.

Hohe Projekttransparenz  ^

Da die Stakeholder an fast jeder Besprechung, sei es z.B. Daily-Scrum oder auch Sprint-Review, teilnehmen können, bietet Scrum ihnen eine hohe Projekt-Transparenz. Dank der verschiedenen Sprint-Burndown-Chart-Charts haben sie jederzeit Einblick in den Projektstand und -fortgang. Darüber hinaus haben sie mit dem Product-Owner einen einzelnen, kompetenten und nahezu jederzeit kurzfristig erreichbaren Ansprechpartner im Projekt. Darüber hinaus ist der Product-Owner die exklusive Schnittstelle und der Filter zwischen den Stakeholdern und dem Entwicklungsteam, damit es zu keinen Nebenabsprachen zwischen Stakeholdern und Entwicklungsteam kommt.

Agieren auf Augenhöhe  ^

In den Scrum-Teams gibt es zwar unterschiedliche Rollen, jedoch keine Hierarchie und so agieren alle Beteiligten auf Augenhöhe. Eine effiziente teaminterne Kommunikation hilft, Reibungsverluste zu vermeiden. Das gesamte System ist darauf ausgerichtet, sowohl Leerläufe, als auch Arbeitszeitspitzen zu vermeiden und eine konstant hohe Effektivität des Prozesses zu gewährleisten.

Hohe Produktqualität  ^

Darüber hinaus gibt es — da sich alle auf gleicher Augenhöhe bewegen — keine Hierarchie und teaminterne Konkurrenz, dafür aber eine hohe Professionalität, Kollegialität und Mitarbeiterzufriedenheit. Das wirkt sich positiv auf die Qualität des Produktes und damit auf eine Verringerung des Projektrisikos aus. Weitere Punkte, die die Qualität des Produktes verbessern, sind Faktoren wie intensives Testing durch Entwickler und Stakeholder, sowie die immer wieder zu durchlaufenen Feedback-Schleifen.

1.10. Optimales Projektergebnis  ^

Ein optimales Ergebnis für die Stakeholder ist, dass das Produkt, das sie bekommen, ihren Bedürfnissen entspricht und in Time & Budget fertiggestellt ist.

Höchstmögliche Wertschöpfung zum frühestmöglichen Zeitpunkt  ^

Die Stakeholder erhalten am Ende eines jeden Sprints ein (zumindest potenziell) einsetzbares, lauffähiges Produkt, das die für sie wichtigsten — und damit für sie wertvollsten — Anforderungen abdeckt. Die im Produkt realisierten Anforderungen sind vollständig gemäß der jeweiligen Spezifikation implementiert und getestet. Diese Vorgehensweise ermöglicht den Stakeholdern die höchstmögliche Wertschöpfung zum frühestmöglichen Zeitpunkt, was so weit gehen kann, dass ein Produkt bereits vor der eigentlichen Fertigstellung produktiv genutzt werden kann.

Die Stakeholder erhalten das Produkt, das sie wirklich benötigen  ^

Zudem erhalten die Stakeholder aufgrund der agilen Vorgehensweise ein Produkt, das realistisch ihren Anforderungen genügt, da der finale Funktionsumfang nicht bereits weit im Vorwege der Nutzung bis ins Detail hinein festgelegt werden muss, sondern die Erfahrungen, die sich die Stakeholder in der Zeit der Produktentwicklung durch das Testen der Produktinkremente erarbeiten, nahezu jederzeit ins Projekt einfließen und berücksichtigt werden könnten.


2. Für das ausführende Unternehmen

2.1. Hohe Kundenzufriedenheit  ^

Zufriedene Stakeholder und Dienstleister sind einander zuverlässige Partner. Ist man miteinander zufrieden und kann man sich aufeinander verlassen, wird man sich bei Problemen im Projekt oder in Verhandlungen, z.B. in Hinblick auf Folgeaufträge und -projekte, wohlwollend und aufgeschlossen begegnen.

Frühzeitige, verlässliche Auslieferung funktionierender Software in kurzen Zyklen  ^

Die Stakeholder werden als Partner in Augenhöhe tief in das Projekt eingebunden und erhalten am Ende eines jeden Sprints ein potentiell einsetzbares, lauffähiges Produktinkrement. Die im Produkt realisierten Anforderungen sind vollständig gemäß der jeweiligen Spezifikation implementiert und getestet und das Produkt ist damit — sofern das bis dahin realisierte Anforderungsset bereits ein ausreichend breites Anforderungsspektrum abdeckt — von den Stakeholdern direkt und sofort in Produktion einsetzbar.

Änderungswünsche werden zeitnah berücksichtigt  ^

Änderungswünsche, die sich z.B. über die im Test von den Stakeholdern gemachten Erfahrungen, ihr Feedback, etc., ergeben, können nahezu sofort im Projekt berücksichtigt werden. Auf diese Weise hat das ausführende Unternehmen die Chance, jeden einzelnen Sprintabschluss zu einem gemeinsamen Erfolg werden zu lassen, was das Vertrauensverhältnis zwischen Dienstleister und Kunde vertieft und die Kundenzufriedenheit steigen lässt.

2.2. Hohe Termintreue  ^

Das Einhalten von Terminen ist ein wesentliches Element, dass den Stakeholdern ein hohes Maß an Professionalität und Verlässlichkeit vermittelt. Dadurch, dass fast alles in Scrum eine Timebox ist, deren zeitliche Grenze auf keinen Fall überschritten wird, setzt Scrum eine wesentliche Grundlage für Verlässlichkeit, Vertrauen und Planbarkeit.

Timeboxen schaffen guten Überblick  ^

Durch gute und kleinteilige Planung über einen kurzen Zeitraum, sowie tagaktuelles Reporting (über Taskboard und Sprint-Burndown-Chart) ist ein guter Überblick über die zeitlichen Abläufe, ihre Fortschritte und Gefahren gegeben. Es ist daher gut möglich, Engpässe und Probleme frühzeitig zu erkennen und Gegenmaßnahmen zu ergreifen, bzw., die Stakeholder frühzeitig über evtl. Engpässe und Verzögerungen in Kenntnis zu setzen.

Verlässliche Sprintergebnisse  ^

Fast alles in Scrum ist eine Timebox, deren Grenzen verlässlich eingehalten werden. Gemäß dem Prinzip des Timeboxings hat jeder Sprint die gleiche Länge und wird pünktlich beendet. Nur die gemäß der DoD als vollständig fertig geltenden Anforderungen werden ausgeliefert. Da stets die für die Stakeholder wertvollsten Anforderungen (und diese zudem verlässlich immer vollständig und lauffähig in höchster Qualität) umgesetzt werden, haben die Stakeholder — je nach Struktur der Anforderungen — die Möglichkeit, das Produkt bereits vor der endgültigen Fertigstellung produktiv einsetzen zu können.

Einhalten von „Time & Budget“  ^

Scrum stellt die Einhaltung der Rahmenbedingungen von Zeit und Geld gegenüber einem vollständig implementierten Anforderungsset in den Vordergrund, indem es sicherstellt, dass diejenigen Anforderungen, die für die Stakeholder die höchsten Geschäftswerte darstellen, als erstes und vollständig implementiert werden. In einer Situation, wo Zeit oder Budget knapp werden könnten, sind demnach mit hoher Wahrscheinlichkeit nur noch Anforderungen zu implementieren, deren Bedeutung und Dringlichkeit zumindest verhandelbar ist.

2.3. Hohe Budgetsicherheit  ^

Das Unternehmen kalkuliert die Kosten für das Projekt, um dem Kunden ein Angebote machen zu können. Scrum schafft die Voraussetzungen, dass das Unternehmen das Projektbudget später in „Time & Budget“ verlässlich einhalten kann.

Die wichtigsten und wertvollsten Anforderungen werden zuerst realisiert  ^

Durch die enge Abstimmung der Anforderungen zwischen Product-Owner und Stakeholder werden immer die für die Stakeholder wertvollsten Anforderungen — vollständig und lauffähig in hoher Qualität — umgesetzt. Sie erhalten verlässlich, frühzeitig und regelmäßig in kurzen Zyklen lauffähige, funktionierende Softwarestände, die sie begutachten und testen können. Dadurch fließt frühzeitig viel Feedback in das Projekt zurück und die Stakeholder haben je nach Struktur der Anforderungen die Möglichkeit, das Produkt bereits vor der endgültigen Fertigstellung produktiv einsetzen zu können, bzw., das Projekt bereits frühzeitig ohne wesentlichen Verlust an Funktionalität zu beenden. Der Entwicklungsprozess selbst verbessert sich dank „Inspect & Adapt“ stetig.

Einhalten von „Time & Budget“  ^

Genau wie im gleichnamigen Abschnitt im Punkt 2.2. „Hohe Termintreue“ dargestellt, stellt Scrum die Einhaltung der Rahmenbedingungen von Zeit und Geld gegenüber einem vollständig implementierten Anforderungsset in den Vordergrund. Damit wird sichergestellt, dass in einer Situation, wo Zeit oder Budget knapp werden könnten, wahrscheinlich nur noch Anforderungen zu implementieren sind, deren Wegfall den produktiven Einsatz des Produktes nicht gefährden.

Minimierung des Projektrisikos  ^

Ein gut implementierter Scrum-Prozess minimiert das Projektrisikodurch seine Maßnahmen, Abläufe und Regeln und fördert eine frühe Marktreife des Produktes.

2.4. Hohe und frühe Wertschöpfung  ^

Nicht nur die Stakeholder, sondern auch das ausführende Unternehmen will eine hohe und möglichst frühe Wertschöpfung erreichen. Scrum unterstützt beide Seiten, diese Anforderung jeweils für sich zu realisieren.

Intensive Einbindung der Stakeholder in das Projekt  ^

Die intensive Einbindung der Stakeholder in das Projekt, die regelmäßige und verlässliche Auslieferung einsetzbarer und lauffähiger Software, die hohe Budgetsicherheit und Termintreue sind allesamt Faktoren, die die Zufriedenheit und das Vertrauen des Kunden in den Dienstleister stärken, was sich positiv auf Zahlungsmoral, Folgeprojekte und entsprechende Verhandlungen auswirkt.

Frühe und regelmäßige Auslieferung  ^

Die regelmäßige Auslieferung eines produktiv sehr früh einsetzbaren Produktinkrements schafft die Möglichkeit, regelmäßig und frühzeitig die erbrachten Leistungen mit den Stakeholdern abrechnen zu können.

2.5. Hohe Produktivität  ^

Eines der Kernelemente von Scrum und eine der Hauptaufgaben des Scrum-Masters ist, eine möglichst hohe Produktivität des gesamten Scrum-Teams durch Parallelisierung mit verlässlicher Synchronisierung bei gleichzeitiger Reduzierung von Reibungsverlusten zu erreichen und zu gewährleisten.

Überschaubare Planung  ^

Große Zeiträume lassen sich nur schlecht verlässlich planen, da sich jederzeit unvorhergesehene Änderungen ergeben können, die die aufgestellte Planung zunichtemachen können, daher setzt Scrum auf eine gute, kleinteilige und überschaubare Planung über einen kurzen Zeitraum. Hierzu wird gemeinschaftlich von Product-Owner und Entwicklungsteam in der ersten Phase des Sprint-Planning das im Sprint zu realisierende Anforderungsset vereinbart, im Sprint-Backlog festgehalten und später im Laufe des Sprints zu einem lauffähigen und vollständig realisierten Produktinkrement implementiert.

Jede einzelne Anforderung dieses Sets wird vom Entwicklungsteam in der zweiten Phase des Sprint-Planning weiter in einzelne Arbeitspakete zerlegt und in eine für die Abarbeitung sinnvolle Reihenfolge gebracht. Die Größe eines einzelnen Arbeitspaketes muss so beschaffen sein, dass die Realisation nicht länger als maximal einen Tag in Anspruch nimmt. Die Anforderungen und die dazu gehörigen Arbeitspakete werden vom Entwicklungsteam im Sprint in der Reihenfolge ihrer jeweiligen Sortierung abgearbeitet.

Hohe, gleichmäßige Auslastung  ^

Die Teams sind in Scrum interdisziplinär besetzt, d.h., auch wenn jeder Entwickler wahrscheinlich seinen individuellen Schwerpunkt hat, sollte er trotzdem in der Lage sein, jede anfallende Entwicklungsaufgabe im Projekt bearbeiten zu können; es gibt es keine Kopfmonopole. Somit können die Anforderungen und Arbeitspakete „von oben nach unten“ eins nach dem anderen abgearbeitet werden. Wer die Realisation eines Arbeitspaketes abgeschlossen hat, kennzeichnet es am Taskboard als „fertig“ und beginnt mit der Realisation des nächsten, noch nicht in der Realisation befindlichen Arbeitspaketes. Auf diese Weise ist stets eine hohe Auslastung ohne Leerlaufzeiten gewährleistet.

Leichtgewichtige Koordination  ^

In der Praxis hat es sich als vorteilhaft gezeigt, dass jeweils einer der Entwickler aus einer Gruppe, die an einer zu realisierenden Anforderung arbeitet, verantwortlich über die Realisation der zu implementierenden Arbeitspakete wacht. Er fühlt sich für die Realisation dieser Anforderung verantwortlich, er greift, wenn nötig, koordinierend ein und er stellt — zusätzlich zu den Unit-Tests der anderen Entwickler – mit Hilfe automatischer Akzeptanz- und Integrationstests sicher, dass die Akzeptanzkriterien eingehalten und somit die geforderten Funktionalitäten realisiert werden. Am Ende des Sprints präsentiert er die fertig realisierte Anforderung im Sprint-Backlog.

All das bedeutet nicht, dass er die Realisation der Anforderung allein durchführen sollte, sondern, dass er den Überblick über die Implementation der Anforderung hat und neben einer hohen Qualität des entwickelten Codes auch eine hohe Produktivität des an der Entwicklung der Anforderung beteiligten Teils des Entwicklungsteams sicherstellt.

Effiziente Kommunikation und hohe Problemlösungskompetenz  ^

Da die Mitglieder der Teams in Scrum idealerweise in Nähe zueinander arbeiten und auch der Product-Owner prinzipiell kurzfristig für Fragen zur Verfügung steht, werden Problemfälle zumeist sehr schnell allein oder im Team geklärt und behoben. Erfahrungsgemäß ergibt sich aus dieser Zusammenarbeit und der effizienten und permanenten Kommunikation als Synergieeffekt ein Flow, der sowohl einer hohen Produktivität, als auch der Mitarbeiterzufriedenheit zugutekommt.

2.6. Hohe Anforderungsflexibilität  ^

Hohe Anforderungsflexibilität zu ermöglichen, ist eine der Kernaussagen agiler Softwareentwicklung.

Scrum setzt diese Forderung in hohem Maße um.

Die Stakeholder können jederzeit Änderungen einbringen  ^

Die Stakeholder können das Anforderungsset, das vom Product-Owner im Product-Backlog verwaltet wird, in Absprache mit ihm jederzeit unter Beachtung der sich aus der Änderung ergebenden Risiken und Konsequenzen (z.B. Zeit, Budget) an aktuelle Erkenntnisse und Bedürfnisse anzupassen. Der Product-Owner wird die Änderungen umgehend in das Product-Backlog einpflegen und es anschließend nach der vergebenen Priorität absteigend sortieren, damit die wichtigsten Anforderungen im Product-Backlog weiterhin ganz oben zu finden sind. Auf das Sprint-Backlog hat das zunächst keinen Einfluss.

Änderungen des Sprint-Backlogs  ^

Zwar wird der Sprint als geschützte Zone betrachtet, aber bei schwerwiegenden Änderungen, z.B., weil im laufenden Sprint Anforderungen implementiert werden, die kurzfristig überflüssig geworden sind und nicht mehr realisiert werden sollen, kann es sich in solchen Ausnahmefällen durchaus als angemessen erweisen, dass der Product-Owner — gemeinsam und im Einvernehmen mit dem Entwicklungsteam — ausnahmsweise das Sprint-Backlog ändert. Durch solche Änderung im Sprint-Backlog frei gewordener Platz wird durch die nächsten höchstpriorisierten Anforderungen aus dem Product-Backlog aufgefüllt. Auch hier gilt, dass der Product-Owner gemeinsam mit den Stakeholdern – ggf. sogar unter Einbeziehung des Entwicklungsteams — die Risiken und Konsequenzen dieser Änderungen bewertet und, je nach Größe der Änderung, in die weitere Planung einfließen lässt.

2.7. Minimierung des Projektrisikos  ^

Je niedriger das Projektrisiko, desto eher sind Stakeholder und Unternehmen bereit, gemeinsam Projekte zu planen und durchzuführen.

Risikominimierung  ^

Scrum minimiert in den Bereichen Planung, Kommunikation und Qualität die Risiken, indem die Planung auf einen überschaubaren Rahmen begrenzt, die Kommunikation zwischen allen Beteiligten systemisch gefördert und die Qualität des Produktes vom Entwicklungsteam in enger Zusammenarbeit mit den Stakeholdern stetig verbessert wird. Durch die hohe Code-Qualität, die tiefe und intensive Einbindung der Stakeholder und ihrer aktiven Rolle im Projekt, sowie der von Scrum geförderten Transparenz und den kurzen Feedbackzyklen werden Probleme frühzeitig gemeinschaftlich thematisiert und einer Lösung zugeführt.

2.8. Optimales Projektergebnis  ^

Ein optimales Projektergebnis ist dann erreicht, wenn durch das Projekt eine hohe Wertschöpfung für Stakeholder und ausführendes Unternehmen bei gleichzeitigem Ausbau der Reputation erzielt werden kann. Scrum stellt für Stakeholder und Unternehmen beides in den Mittelpunkt.

Vollständige Realisierung der Anforderungen  ^

Die im Produkt zu realisierenden Anforderungen werden gemäß der jeweiligen fachlichen Spezifikation vollständig implementiert und getestet, so dass sie gemäß Styleguide und „Definition of Done“ als fertig abgeschlossen gelten. Diese Vorgehensweise ermöglicht den Stakeholdern, dass sie auch das noch nicht vollständig realisierte Produkt bereits im Vorfeld der vollständigen Fertigstellung produktiv einsetzen und dadurch eine höchstmögliche Wertschöpfung zum frühestmöglichen Zeitpunkt erreichen können.

Die Stakeholder erhalten das für sie richtige Produkt  ^

Aufgrund der agilen Vorgehensweise erhalten die Stakeholder am Ende des Projektes ein Produkt, das ihren wirklichen Anforderungen genügt. Sie konnten ihre Erkenntnisse und Erfahrungen, die sie sich im Laufe des Projektes in den Diskussionen, insbesondere gemeinsam mit dem Product-Owner im Zuge der Anforderungsaufnahme, aber auch in der Zeit der Produktentwicklung und während des Testens der Produktinkrement erarbeitet haben, direkt in das Projekt zurückfließen lassen, die dort zeitnah berücksichtigt werden konnten.

Hohe Kundenzufriedenheit  ^

Aus der Gesamtheit der genannten Punkte ergibt sich für die Stakeholder und daraus in der Folge auch für das ausführende Unternehmen und Mitarbeiter ein optimales Projektergebnis, was auf allen Seiten zu einer hohen Wertschöpfung und Zufriedenheit führt.

2.9. Hohe Mitarbeiterzufriedenheit  ^

Zufriedene Mitarbeiter sind flexibler und leistungsbereiter. Gleichzeitig setzen sie ihr Wissen schneller um und sind unternehmenstreuer.

Verbesserung der Rahmenbedingungen  ^

Im Gegensatz zu den klassischen, eher hierarchiebetonten Softwareentwicklungsprozessen öffnet Scrum für die Mitarbeiter kreative Räume, indem ihnen Verantwortung übertragen, und Gestaltungsfreiheit ermöglicht wird. Durch intensive und effiziente Kommunikation, dem Recht zur Mitbestimmung und die Freiheit sich teamintern vollständig selbst zu organisieren, werden die Mitarbeiter von Befehlsempfängern zu Partnern auf Augenhöhe, was ihre Motivation, Zufriedenheit, sowie Leistungsbereitschaft und -fähigkeit steigen lässt.

2.10. Permanente Team-Weiterentwicklung  ^

Gerade in der professionellen Softwareentwicklung ist die Bereitschaft zur permanenten Weiterbildung und zum Begehen neuer Wege essentiell und ist daher ein wesentliches Merkmal von Scrum, indem es das Prinzip des „Inspect & Adapt“, also das Prinzip der permanenten Verbesserung, als Teil des Prozesses fest im Projekt verankert.

Daily-Scrum und Sprint-Retrospektive  ^

Das Entwicklungsteam unterzieht am Ende einer jeweils abgelaufenen, festen Zeitperiode (z.B. Arbeitstag oder Sprint) einer Betrachtung und Bewertung.

Dies geschieht im Daily-Scrum für den vergangenen Arbeitstag, bzw. in der Sprint-Retrospektive am Ende des Sprints für den Zeitraum des Sprints, um diese Zeiträume unter der Moderation des Scrum-Masters zu analysieren und zu bewerten. Aus dem Ergebnis der Analyse werden konkrete Beschlüsse für die Veränderungen der Verhaltensweisen oder Abläufe getroffen, die dann zeitnah umgesetzt werden.

Der Scrum-Master überwacht die Umsetzung der Beschlüsse und berichtet darüber im jeweilig nächsten Meeting (Daily-Scrum, bzw. Sprint-Retrospektive).

Darüber hinaus führt das Prinzip, das jeder Entwickler in der Lage sein muss, nahezu jede anfallende Entwicklungsaufgabe im Projekt bearbeiten zu können, dazu, über den Rand des jeweilig eigenen Spezialgebietes des Entwicklers hinaus weitere Fertigkeiten anzueignen.


3. Für die beteiligten Mitarbeiter


3.1. Gutes Arbeitsklima in Team und Projekt  ^

Das Klima in Scrum-Projekten ist gekennzeichnet durch Vertrauen, Offenheit, Kollegialität, Hilfsbereitschaft, Team- und Verantwortungsbewusstsein, sowie einer effizienten und professionelle Zusammenarbeit aller Beteiligten.

Gestaltungsfreiheit  ^

Jedem Entwickler steht ein hohes Maß an Gestaltungsfreiheit als Raum für Kreativität und Innovation zur Verfügung, solange er sich an die durch das Projekt vorgegebenen technischen und fachlichen Rahmenbedingungen und Absprachen, die u.a. in Styleguide und DoD definiert sind, hält.

Kurze Wege  ^

Die Arbeitsplätze der Entwickler eines Teams liegen idealerweise nahe beieinander; so werden Probleme, die ein Entwickler nicht schnell allein lösen kann, kurzfristig mit den direkten Kollegen im Team besprochen und dann mit den gefundenen Lösungsideen allein oder in der Gruppe gelöst. Ist das nicht möglich, weil es sich um ein Problem handelt, dass auch von der Gruppe mit den ihr vorliegenden Informationen nicht gelöst werden kann, muss das Problem an den Product-Owner eskaliert werden, damit er entweder zusätzliche Informationen liefern kann oder eine Entscheidung zum weiteren Vorgehen trifft.

Permanenter Austausch  ^

Alle anwesenden Mitglieder des Entwicklungsteams und der Scrum-Master treffen sich an jedem Arbeitstag verlässlich zur gleichen Zeit am gleichen Ort zum Daily-Scrum. Im Daily-Scrum informiert jedes Teammitglied alle anderen Teammitglieder darüber, was es seit dem letzten Daily-Scrum erledigt hat, was es vorhat, bis zum nächsten Daily-Scrum zu erledigen und ob es etwas gab, was es in seiner Arbeit behindert hat. Zuvor oder während der Runde wird das Taskboard auf den neuesten Stand gebracht, d.h. die bearbeiteten Arbeitspakete werden in den aktuellen Zustandsbereich verschoben (todo / in progress / finished).

Darüber hinaus tauschen sich die Entwickler permanent im Laufe ihrer Arbeit fallbezogen untereinander aus.

Problembehandlung  ^

Einer der Aufgaben des Scrum-Masters ist, die Rahmenbedingungen für eine optimale Produktivität des Teams zu gewährleisten. Tritt während der Arbeit im Projekt bei einem Teammitglied ein Problem auf, dass das Teammitglied (Product-Owner eingeschlossenen) in der Ausübung seiner Tätigkeit behindert oder in seiner Produktivität einschränkt und mit eigenen Mitteln allein kurzfristig nicht zu lösen ist, hat es die Möglichkeit, sich mit dem Problem an den Scrum-Master zu wenden. Der Scrum-Master wird sich dann umgehend um eine Lösung des Problems kümmern, über die er dann im nächsten Daily-Scrum berichten wird.

Agieren als Team  ^

Das Team handelt getreu dem Leitbild „einer für alle und alle für einen“ wie ein einziger Körper, organisiert sich hierzu vollständig selbst und hat gemeinsam die Verantwortung für das Erreichen des Sprint-Zieles, was bedeutet, dass immer das gesamte Team gemeinsam erfolgreich ist — oder eben nicht — und nicht der Einzelne.

Das bedeutet jedoch auch, dass sich die einzelnen Mitglieder des Entwicklungsteams gemeinsam als handelnden Körper verstehen lernen müssen.

Selbstorganisation  ^

Die Selbstorganisation des Entwicklungsteams durch die Teammitglieder führt zu einer verbesserten Teamarbeit. Da letztlich einzig das Team entscheidet, wie viele Aufgaben in einem Sprint zu bearbeiten sind, hat es das Team selbst in der Hand, die Arbeitsbelastung auf ein gutes Maß zu regulieren und Überstunden, wie sie insbesondere in den klassischen Softwareentwicklungsprozessen zum Ende des Projektes hin fast regelmäßig auftreten, zu vermeiden.

3.2. Ruhiges, entspanntes Arbeiten  ^

Druck, Hektik und Stress sind Faktoren, die — wenn überhaupt — nur sehr kurzzeitig zu einer höheren Produktivität führen, dafür aber häufig aufgrund einer steigenden Fehlerquote zu einer Minderung der Qualität und erhöhten Werten für Erschöpfung und Verschleiß der beteiligten Personen. Daraus ergeben sich Konsequenzen, wie z.B. Minderung des vermeintlichen Zeitgewinns durch Fehlersuche und -behebung, längere Regenerationsphasen des erschöpften Teams und einen eventuellen Vertrauensverlust innerhalb und außerhalb des Projektes aufgrund der höheren Fehlerquote.

Kontinuität statt „Start-Stopp“  ^

Eine kontinuierliche und angepasste Geschwindigkeitssteigerung, die dann über einen längeren Zeitraum ebenso kontinuierlich gehalten werden kann, ist wesentlich effektiver und ressourcenschonender (Arbeits- und Produktqualität, Motivation, Kommunikation, Teamgeist, Verlässlichkeit), als vielleicht „mit Vollgas aus der nächsten Kurve zu fliegen“.

Verlässliche Rahmenbedingungen  ^

Alle am Projekt Beteiligten müssen sich auf die Rahmenbedingungen rund um den Scrum-Prozess absolut verlassen können. Dazu gehört für z.B. für das Entwicklungsteam, dass der Sprint ein besonders geschützter Raum ist, in dem nur in absoluten Ausnahmefällen Änderungen an den Rahmenbedingungen, wie geplanter Arbeitsumfang, Abzug / Austausch Mitarbeiter, Zuweisung anderer Aufgaben, zugelassen sind und dann auch nur unter Berücksichtigung der sich aus den Änderungen ergebenen Risiken und Konsequenzen.
Die regelmäßigen, fest gesetzten Termine, wie z.B. Daily-Scrum, Sprint-Planning, Sprint-Backlog und Sprint-Retrospektive, sollten darüber hinaus auf jeden Fall in Hinblick auf Zeitpunkt, Dauer, Inhalt und Ablauf verlässlich eingehalten werden.
Für die Stakeholder gilt, dass sie fest darauf vertrauen können, dass sie mit Abschluss eines jeden Sprints ein lauffähiges, um die für sie wichtigsten und wertvollsten Anforderungen erweitertes, im Rahmen des jeweiligen Implementationsstandes vollständig realisiertes und von ihnen in Produktion einsetzbares Produktinkrement in höchstmöglicher Qualität erhalten werden.

Selbstorganisation und Verantwortung im Team  ^

Das Entwicklungsteam organisiert sich selbst, es führt die Aufwandsschätzungen durch und verantworten diese auch selbst und wird während des Sprints von außen nicht gestört oder beeinflusst. Die im Sprint zu absolvierenden Aufgaben und Termine sind dem Team nach Abschluss des Sprint-Planning bekannt und werden gemäß des Verlässlichkeitsprinzips von Scrum ebenfalls nur aufgrund außergewöhnlicher Umständen und dann auch nur in direkter Absprache zwischen den Beteiligten geändert.

3.3. Abbau von Druck und Stress  ^

Durch die intensive, kleinteilige aber trotzdem flach gehaltene Vorplanung, der verlässliche Schutz des Sprints, die überschaubare, bekannte und realistische — da vom Entwicklungsteam selbst bestimmte — Arbeitsmenge, der permanente Austausch zwischen den Mitgliedern des Scrum-Teams (Entwicklungsteam, Scrum-Master, Product-Owner) sowie die klare und verlässliche Terminlage reduziert sich der Druck auf die Teammitglieder und die Mitarbeiter und damit auch der Stress; in der Folge arbeiten alle Beteiligten und damit auch die Mitarbeiter wesentlich motivierter, engagierter und leistungsbereiter auf das Projektziel hin.

3.4. Effiziente Kommunikation  ^

Schlechte oder ineffiziente Kommunikation führt zu Reibungsverlusten und Frustration im Projekt und bei den Beteiligten, kostet Zeit und andere Ressourcen. Eine optimierte Kommunikationskultur nimmt in Scrum einen sehr hohen Stellenwert ein.

Ineffiziente Kommunikation vermeiden  ^

Ineffiziente Kommunikation ist in Projekten sehr oft ein äußerst schwieriges Problem, sei es, dass zu wenig, sei es, dass zu viel oder sei es, dass auf die falsche Art kommuniziert wird; i. A. handelt es sich um eine Mischung aus allen Varianten. Scrum macht hier eine ganze Reihe konstruktiver Vorgaben, wie eine effiziente Kommunikationskultur gestaltet sein sollte.

In kurzer Zeit ausschließlich das Wesentliche austauschen  ^

Im Daily-Scrum berichten die Team-Mitglieder einander über ihre Arbeit, indem jeder die 3 imaginär gestellten Fragen („Was habe ich seit dem letzten Daily-Scrum gemacht“, „was werde ich bis zum nächsten Daily-Scrum machen“, „hat mich etwas / was hat mich in meiner Arbeit aufgehalten“).

Die Vorgabe ist, dass genau DAS gemacht wird; nacheinander berichtet jeder, die anderen hören zu.

Kurze Fragen für das Verständnis dazu: JA. Diskussionen oder Berichte, wie einem selbst genau das auch — oder etwas ganz ähnliches — oder etwas gar viel Schlimmeres — passiert ist: NEIN. Gibt es Diskussionsbedarf, kann dieser kurz adressiert und NACH dem Daily-Scrum in passender Runde — oft sind nicht alle betroffen und/oder interessiert — befriedigt werden.

Die Struktur einhalten  ^

In der ersten Phase des Sprint-Planning stellt der Product-Owner die Anforderungen, die er für die Realisation im Sprint vorgesehen hat, vor.

Kurze Fragen für das grundsätzliche Verständnis einer Anforderung: JA.
Diskussionen über die Anforderung: NEIN.

Die Vorstellung der Anforderungen dient dem Überblick, ist sozusagen die Agenda der folgenden detaillierten Besprechungsrunde, stellt einen Zusammenhang her. Die Beschäftigung mit den Details erfolgt danach, im zweiten Teil der ersten Phase.

Sich nicht in Details verlieren  ^

Beschäftigt man sich mit den Details einer Anforderung, geht es um das Verständnis der zu implementierenden Anforderung im Kontext des aktuellen Modules und im Kontext der anderen zu implementierenden Anforderungen. Es geht darum, eine Idee der Implementierung und eine Vorstellung des zu erwartenden Aufwandes zu erhalten.

Es geht in diesem Moment noch nicht um die Implementation selbst und das Für und Wider verschiedener konkreter Ansätze. Solche Diskussionen gewinnen rasch an Tiefe und verlieren ebenso schnell an Wert, da sie an (zu dieser Zeit noch gar nicht relevanten) Details hängen bleiben. Die Zeit für diese Diskussionen kommt erst später in einem wahrscheinlich kleineren Kreis von Interessierten, zumal nicht immer alles mit allen besprochen werden muss; für unterschiedliche Themen sollten sich unterschiedliche Gruppen zusammenfinden, die dann parallel arbeiten können und nach Abschluss einander ihre Ergebnisse berichten.

Zielgerichtetes Vorgehen  ^

Gleiches gilt für die zweite Phase des Sprint-Planning, der Zerlegung der Anforderungen in Arbeitspakete. Hier sich nicht gleich in die Tiefe begeben um sich dabei fast zwangsläufig in Details verlieren, vielleicht sogar schon damit beginnen, produktiven Code zu schreiben. In dieser Phase sollte man sich besser darauf beschränken, erst einmal Abläufe und Strukturen skizzieren, Schnittstellen definieren; noch weiß niemand, welcher der Kollegen das Paket bearbeiten wird und wie derjenige sich die Realisation vorstellt.

Timeboxen im Auge behalten  ^

Eine Timebox ist ein zeitlich scharf begrenzter Vorgang, dessen Zeitrahmen auf keinen Fall überschritten wird und fast alles ist in Scrum eine Timebox. Die erste Phase des Sprint-Planning, Sprint-Backlog und auch Sprint-Retrospektive sollen nicht länger als 4 Stunden dauern, das Daily-Scrum nicht länger als 15 Minuten, usw., usf.; i.a. verlassen sich die Beteiligten darauf, dass so ein Meeting nicht länger als die vorgesehene Zeit dauert.

Eine kleine Ausnahme gibt es davon dann doch, das ist die zweite Phase des Sprint-Planning; die Zerlegung der Anforderungen in Arbeitspakete. Zwar sollte auch dieses Meeting nicht länger als 4 Stunden dauern (irgendwann kann man auch nicht mehr), da dort aber wichtige Planungs-Vorarbeit geleistet wird, deren Aufwand nur schwer abzugrenzen ist, gilt hier, dass man sich spätestens nach 4 Stunden vertagt und sich am nächsten Tag oder einem anderen Zeitpunkt, ggf. in reduzierter Runde, erneut trifft, um die Planung weiterzuführen.

Ein guter Ansprechpartner und Moderator ist der Scrum-Master, der die Meetings ohnehin immer begleiten sollte und der auch an dieser Stelle die Koordination übernehmen kann.

Frühe Informationen im Estimation-Meeting  ^

Das Estimation-Meeting ist ein öffentliches Meeting und der ersten Phase des Sprint-Planning sehr ähnlich; es sollte im letzten Drittel des Sprints stattfinden. Es handelt sich um ein vom Product-Owner organisiertes und moderiertes Meeting, das der Vorbereitung des folgenden Sprints dient. Der Product-Owner stellt dem Entwicklungsteam die für den nächsten Sprint vorgesehenen Anforderungen vor. die vom Entwicklungsteam dann ohne tiefgehende Diskussion jeweils grob geschätzt werden. Dieses Meeting ist sowohl für das Entwicklungsteam, als auch für den Product-Owner von hohem Wert; das Entwicklungsteam bekommt frühzeitig einen Ausblick auf die als nächstes zu implementierenden Aufgaben und der Product-Owner die Möglichkeit, seine Planung anhand der Schätzungen zu validieren und zu verfeinern.

3.5. Gleichwertigkeit im Projekt  ^

Teams und Projekte in Scrum zeichnen sich dadurch aus, dass sie flach und nicht hierarchisch organisiert sind. Der Ansatz, mehr zu fördern als zu fordern, schafft eine natürliche Basis für ein hohes Maß an Verantwortungs- und Leistungsbereitschaft, sowie Vertrauen in sich und sein Team.

Auf Augenhöhe kommunizieren und agieren  ^

Alle Beteiligten kommunizieren und agieren auf Augenhöhe miteinander. Keine Rolle in Scrum ist einer anderen Rolle überstellt, übergeordnet oder weisungsbefugt.

Gleichwertigkeit aller Beteiligter  ^

Scrum bricht ausdrücklich mit den Prinzipien von „Command & Control“ und des Taylorismus und den damit einhergehenden hierarchischen Strukturen und festen Vorgaben. Scrum setzt stattdessen auf die Gleichwertigkeit aller Beteiligten im Projekt, auf ihre Kompetenz, ihre Bereitschaft, Leistung zu erbringen und eigene Verantwortung zu übernehmen und um Raum für kreative Lösungen zu ermöglichen, deren Umsetzung nicht an Entscheidungsgrenzen zur nächsten Hierarchieebene verzögert oder vielleicht sogar vereitelt wird.

Gemeinsame Verantwortung  ^

Das bedeutet allerdings auch, dass man sich — gemäß dem Motto „einer für alle und alle für einen“ — nicht nur auf der einen Seite gemeinsam im Erfolg sonnen darf, sondern auf der anderen Seite auch einen eventuellen Misserfolg gemeinsam zu vertreten und zu schultern hat.

3.6. Hohes Maß an Selbst- und Mitbestimmung  ^

Motivierte und leistungsbereite Mitarbeiter sind der Motor eines Projektes. Ein hohes Maß an Selbst- und Mitbestimmung schafft Raum und Möglichkeiten für hohe Produktivität, Kreativität und Leistungsbereitschaft.

Mitbestimmung  ^

Der Product-Owner präsentiert in der ersten Phase des Sprint-Planning diejenigen Anforderungen aus dem Product-Backlog, die er für die Realisation im Sprint vorgesehen hat. Dann obliegt es ausschließlich dem Entwicklungsteam, anhand der geschätzten Aufwände festzulegen, wie viele der vorgeschlagenen Anforderungen in das Sprint-Backlog übernommen und damit im Sprint realisiert werden.

Flexibilität  ^

Sollen nach Beginn des Sprints Änderungen an den Inhalten des Sprint-Backlog durchgeführt werden, weil z.B. Anforderungen verändert, ausgetauscht, entfernt oder hinzugefügt müssen, tauschen sich Product-Owner und Entwicklungsteam vor der Änderung des Sprint-Backlogs aus. Sie erörtern die vorzunehmenden Veränderungen, betrachten die Risiken und die sich ergebenden Konsequenzen, und treffen die notwendigen Entscheidungen gemeinsam und einvernehmlich.

Selbstorganisation  ^

Über die Art und Weise der Realisation der Anforderungen hat das Entwicklungsteam weitestgehend frei Hand und organisiert den Ablauf und die Durchführung der Entwicklungsphase vollständig selbst, was zu einer intensiven und effektiven Kommunikation und Zusammenarbeit innerhalb des Teams führt.

Verantwortung  ^

Die Selbstorganisation führt allerdings auch dazu, dass das Entwicklungsteam nicht nur das Anforderungsset, das im Sprint realisiert wird, festlegt und im Sprint realisiert, sondern, dass es auch für Organisation und Durchführung des Sprint-Reviews, incl. der Präsentationen der im Sprint vollständig realisierten Anforderungen verantwortlich ist.

3.7. Großer Gestaltungsraum für kreative Lösungen  ^

Das Entwicklungsteam definiert in Scrum nicht nur den Realisationsumfang des Sprints, sondern auch das Softwaredesign des Produktes. Scrum schafft einen großen Freiraum als Grundlage für die Gestaltung kreativer Lösungen für ein Team, das bereit und in der Lage ist, sich auch komplexester Herausforderungen zu stellen.

Design & Architektur  ^

Das Entwicklungsteam spricht während der Zerlegung der Anforderungen in Arbeitspakete und in der Absprache und Planung untereinander Die Architektur und das Design der Lösung ab. Wichtig dabei ist, dass wirklich jeder Entwickler Architektur und Design versteht und annehmen kann.

Berücksichtigung der Vorgaben  ^

Hier müssen selbstverständlich bereits eventuell vorhandene technische und fachliche Vorgaben berücksichtigt werden, so dass ggf. Unterstützung des Product-Owners und/oder der Stakeholder einzuholen ist. Ist der Product-Owner technisch entsprechend fachkundig, kann er selbstverständlich eigene Vorschläge für die Umsetzung einbringen, die als gleichberechtigte Beiträge für die Umsetzung diskutiert werden sollten.

Nutzen von Spielräumen  ^

In der Art und Weise der Realisation der Arbeitspakete sind die Entwickler ebenfalls frei; es muss jedoch in die zuvor vom Entwicklungsteam erarbeitete Architektur und das Lösungsdesign passen. Jedem Entwickler steht ein hohes Maß an Gestaltungsfreiheit und kreativer Raum zur Verfügung, solange er eine Lösung entwickelt, die das gestellte Problem löst, zu keiner technischen Schuld führt und er sich an die vorgegebenen technischen und fachlichen Rahmenbedingungen und Absprachen, die u.a. in Styleguide und DoD definiert sind, hält.

3.8. Wohlfühlen in einem guten Team  ^

Eines der wesentlichen Ziele von Scrum ist, dem Team eine Atmosphäre zu ermöglichen, die nicht nur eine hohe Leistungsbereitschaft und Produktivität ermöglicht, sondern, in der sich darüber hinaus die Teammitglieder auch wirklich wohlführen können.

Hohe Produktivität  ^

Scrum ist darauf ausgerichtet, insbesondere dem Entwicklungsteam als Motor des Projektes, neben den oben besprochenen Punkten, ein Umfeld entspannter Atmosphäre zu schaffen, das von Professionalität, Verlässlichkeit, Solidarität, Team-, aber auch von dem Willen geprägt ist, die Aufgabe erfolgreich zu bewältigen, um ein Höchstmaß an Motivation und Engagement als Vorrausetzungen für effizientes Arbeiten zu erzielen und eine höchstmögliche Produktivität des Teams zu erreichen.

Teamfindung  ^

Aus einer Anzahl (für das Entwicklungsteam also ca. 5 – 9), einzelner, potentiell einander zuvor nicht bekannter Mitarbeiter muss ein homogenes, gut funktionierendes Team werden. Dies kann — völlig unabhängig vom Scrum — insbesondere neuen Teams recht schwer fallen, zumal oft gerade in den ersten gemeinsamen Sprints von ihnen bereits eine repräsentative Leistung erwartet wird. Ähnliches gilt für das Entwicklungsteam in Zusammenarbeit mit dem Product-Owner, bzw. Product-Owner und Stakeholder.

Unterstützung vom Scrum-Master  ^

Es gehört von Beginn an zu den Aufgaben des Scrum-Masters, das Team in seinem Formungsprozess zu leiten und zu unterstützen und dafür zu sorgen, dass das gesamte Scrum-Team — und hier insbesondere das Entwicklungsteam als Motor des Projektes -– eine Umgebung hat, in der es eine verlässlich stabil hohe Produktivität erreichen kann.

3.9. Transparente Anforderungen  ^

Sicherheit, Klarheit, Verständlichkeit und Vollständigkeit in den Definitionen der zu bewältigenden Aufgaben ist eine wesentliche Grundlage für effizientes Arbeiten mit hohen Werten für Produktivität und Output.

Öffentliches einsehbares Product-Backlog  ^

Das Product-Backlog ist eine Liste aller Anforderungen des Projektes, die stets nach der Priorität der Anforderungen sortiert ist. Die Anforderungen werden i.A. in Form von User-Stories in normalsprachlicher Form formuliert. Das Product-Backlog ist ein öffentlich zugängliches Dokument, auf das alle Interessierte lesend zugreifen können; die Verwaltung obliegt jedoch ausschließlich dem Product-Owner.

Mitarbeit am Product-Backlog  ^

Die Mitglieder des Entwicklungsteams sollten als aktive, an vorderster Front stehende Projektbeteiligte die Möglichkeit nutzen, sich frühzeitig im Product-Backlog über die zukünftig zu realisierenden Anforderungen informieren zu können, um einen über die nächsten Sprints hinausgehenden Horizont zu gewinnen. Dazu sollten sie sich selbst und ihre Ideen mit einbringen, indem sie das Product-Backlog bei Bedarf um zusätzliche User-Stories erweitern, die dann vom Product-Owner begutachtet, bewertet, ggf. bearbeitet und entweder von ihm im Product-Backlog belassen und priorisiert, oder entfernt.

Tiefes Verständnis der Anforderungen  ^

In der ersten Phase des Sprint-Planning stellt der Product-Owner die von ihm für den Sprint vorgesehenen User-Stories zunächst einmal in einem Vortrag vor, um den Anwesenden (Entwicklungsteam, Scrum-Master, evtl. stille Gäste) einen Überblick zu verschaffen. Im Anschluss daran werden die Kandidaten noch einmal und — vor allem — tiefgehender durchgegangen, um im Detail gemeinsam durchgesprochen, diskutiert und vom Entwicklungsteam in ihrem Aufwand geschätzt zu werden. Die User-Stories werden so lange diskutiert, bis alle Beteiligten ein ausreichend gutes Verständnis von der Aufgabe, die eine User-Story im Kontext der Anforderungen, erfüllen soll und von dem Aufwand, den die Realisation der User-Story mit sich bringt, haben. Am Ende dieser Phase gibt es dann ein vom Entwicklungsteam zur vollständigen Realisation zugesagtes Sprint-Backlog, das alle im Sprint zu realisierenden Anforderungen enthält.

Top-Down-Ansatz  ^

Im Anschluss tritt das Entwicklungsteam, unterstützt vom Scrum-Master, in die zweite Phase des Sprint-Planning ein, um die Anforderungen zu verfeinern und in Arbeitspakete herunterzubrechen. Der Product-Owner muss an diesem Teil des Sprint-Plannings nicht direkt anwesend sein, sollte sich aber in der Nähe befinden, um für Rückfragen kurzfristig zur Verfügung zu stehen. Auch hier steht im Vordergrund, dass alle Beteiligten ein gutes und tiefgehendes Verständnis der Aufgabe erhalten, um eine möglichst optimal Lösung finden zu können.

Die Arbeitspakete und ihr jeweiliger Status sind später im Sprint am Taskboard öffentlich einsehbar.

3.10. Stetige Weiterentwicklung  ^

Ein wichtiges Prinzip in Scrum ist das permanente Lernen und das zeitnahe Anwenden des Gelernten. Permanente Weiterentwicklung schafft Zukunftssicherheit und verdrängt Ängste, vielleicht morgen noch Wettbewerbsfähig zu sein

Stetige Reflexion  ^

Das Entwicklungsteam führt verlässlich an jedem Arbeitstag zur gleichen Zeit am gleichen Ort das max. 15 minütige Daily-Scrum durch, an dem — ebenso verlässlich — zumindest alle anwesenden Entwickler und der Scrum-Master teilnehmen. Das Daily-Scrum ist ein öffentliches Meeting; Product-Owner, Stakeholder und weitere Gäste dürfen an dem Termin als stille Zuschauer teilnehmen. Die Entwickler und der Scrum-Master berichten nacheinander reihum einander über ihre Arbeit und über evtl. aufgetretene Probleme. Im Daily-Scrum selbst werden keine Diskussionen begonnen oder geduldet, da diese häufig ausufern. Besteht zu einem Thema Diskussionsbedarf, kann dieser an Ort und Stelle adressiert und im Anschluss an das Meeting oder zu einem anderen Zeitpunkt mit den benötigten / interessierten Personen durchgeführt werden.

Verteilen von Informationen, Erfahrungen und Wissen  ^

Auf diese Weise werden zumindest einmal am Tag verlässlich und so kompakt wie möglich viele wichtige Informationen übertragen. Dieses gezielte und effiziente Austauschen, ggf. im erweiterten Kreis mit eventuellen Gästen, die ggf. im Anschluss an das Daily-Scrum Informationen, Anregungen und — vor allem — Feedback, z.T. aus der Außensicht heraus, geben können, erweitert Horizont, Wissen und Erfahrung jedes Beteiligten.

Selbstreflexion und Konsequenz  ^

Ganz am Ende jedes Sprints wird die vom Scrum-Master organisierte und moderierte Sprint-Retrospektive des Entwicklungsteams durchgeführt, in dem sich das Prinzip des „Inspect & Adapt“ am deutlichsten gelebt wird. In diesem Meeting werden die Erfahrungen des aktuellen Sprints in offener, kollegialer Atmosphäre rekapituliert, reflektiert und diskutiert. Zeigt sich Verbesserungspotenzial — was in der Regel der Fall ist — wird dieses in konkrete Beschlüsse gefasst, die sobald als möglich, z.B. direkt im folgenden Sprint, umgesetzt werden. Aufgabe des Scrum-Masters ist nicht nur die Organisation und Moderation der Sprint-Retrospektive, sondern auch die Protokollierung der Beschlüsse, die Unterstützung in der Umsetzung der Beschlüsse, sowie, über die Umsetzung in der Retrospektive des folgenden Sprints zu berichten.

In der Sprint-Retrospektive sollten alle professionell, ruhig, pragmatisch, sachlich und fair miteinander umgehen; die Retrospektive ist ein sehr konstruktives Meeting und kein Forum für persönliche Abrechnungen, denn alle Beteiligten sind gleichwertig, handeln und kommunizieren verantwortungsvoll und auf gleicher Augenhöhe. In diesem Rahmen sollte es jedem möglich sein, alles, was notwendig und zu sagen ist, sagen zu dürfen und zu können.


[zurück zum Seitenanfang]


, , , , , ,

No comments yet.

Schreibe einen Kommentar

V1503130747DE