SCRUM: Anleitung fĂŒr Einsteiger

SCRUM ist ein Megatrend. Wer Projekte managt oder sich mit dem Thema Projektmanagement beschÀftigt, kommt um das Thema AgilitÀt nicht mehr herum. Und AgilitÀt bedeutet heutzutage SCRUM. Denn in mehr als 90 Prozent aller agilen Projekte wird SCRUM angewandt. Obwohl SCRUM bereits vor mehr als 20 Jahren entwickelt wurde, erleben wir erst heute in Deutschland den wirklichen Durchbruch dieser revolutionÀren Methode im Projektmanagement. Es gibt aktuell in Deutschland einen regelrechten Boom. Wie kommt das? Nun, letztlich liegen die Grundprinzipien und AnsÀtze, die mit SCRUM vermittelt werden, absolut im Trend: das hierarchische Projektmanagement ist am Ende. Autonome, sich selbst managende Teams sind heute eine SelbstverstÀndlichkeit. Themen wie Holocracy, Design Thinking zeigen ganz deutlich: die Macht liegt heute beim Team beziehungsweise den Mitarbeitern. Und dieser Trend zeigt sich auch beim Managen von Projekten.

Einleitung

Da es das Framework schon einige Jahre gibt, haben sich in den letzten Jahren immer mehr Autoren, Berater scrum-playbookund Experten darangemacht, die Methodik weiterzuentwickeln, zu verĂ€ndern und zu ergĂ€nzen. So entstanden viele Varianten von SCRUM. Oft war der Beweggrund dahinter wirtschaftlicher Natur, um auf den bereits sehr schnell und erfolgreich fahrenden Zug aufzuspringen. Wir sehen diese Entwicklung kritisch. Denn aus unserer Sicht funktioniert es nur, wenn es in seiner einfachsten und reinsten Form angewendet wird. So wie es von den BegrĂŒndern dieser Methode auch angedacht war. Aus diesem Grunde begrĂŒĂŸen wir es auch sehr, dass die beiden VĂ€ter von SCRUM, Jeff Sutherland und Ken Schwaber, im Jahr 2010 den SCRUM-Guide herausgegeben haben. Dieser stellt auf wenigen Seiten den Kern und das Rahmenwerk von SCRUM klar dar und definiert die wichtigsten Regeln und Prinzipien.

Aus diesem Grund ist es auch das Ziel dieses Leitfadens, SCRUM nicht weiter zu verfĂ€lschen oder mit eigenen Ideen zu ergĂ€nzen. Unser Maßstab ist es, das von Jeff Sutherland und Ken Schwaber erdachte und ĂŒber die Jahre immer weiter entwickelte Rahmenwerk von SCRUM in seiner Reinheit und Klarheit, verstĂ€ndlich und in strukturierter Form darzustellen.

SCRUM: GrĂŒnde fĂŒr den Erfolg

Mehr als 90 Prozent aller Projekte, die agil gemanagt werden, nutzen SCRUM. AgilitĂ€t ist im Trend – und SCRUM ist es umso mehr. Weltweit nutzen mehr als 12 Millionen Menschen das Framework als Methode im Projektmanagement. Was fĂŒr eine beeindruckende Zahl. Man kann heute sagen: AgilitĂ€t bedeutet SCRUM. Mehr als 20 Jahre gibt es nun bereits SCRUM. Was also macht SCRUM so erfolgreich? Was ist das Geheimnis hinter dem Erfolg? Die folgenden GrĂŒnde spiegeln unsere Meinung wider:

SCRUM ist einfach …

SCRUM besteht aus nur sehr wenigen Regeln und ist somit sehr einfach. Konkret besteht es aus nur drei Rollen, fĂŒnf Events und drei Artefakten. Diese Einfachheit ist aus unserer Sicht der Hauptfaktor fĂŒr den Erfolg von SCRUM. Denn oft wird versucht, die KomplexitĂ€t unserer Zeit und unserer Umwelt durch entsprechend komplexe AnsĂ€tze und Methoden zu managen. Der von Jeff Sutherland und Ken Schwaber veröffentlichte SCRUM-Guide beschreibt das Framework auf lediglich 16 Seiten.

SCRUM ist agil 


Und agil bedeutet SCRUM. Keine andere Methodik, kein anderer Ansatz, keine andere Technik hat sich im Rahmen von Agilen Projekten so erfolgreich durchgesetzt wie SCRUM. Wie schon beschrieben, setzen 90 Prozent aller agil gemanagten Projekte SCRUM ein. Von Marktführerschaft zu sprechen wĂ€re hier schon untertrieben. Zumal man davon ausgehen kann, dass die 10 Prozent, die von sich behaupten, dass sie nicht SCRUM einsetzen, zumindest teilweise SCRUM verwenden. So hat sich beispielsweise ein Daily Stand up in so gut wie allen agilen Projekten als Standard durchgesetzt.

SCRUM ist hierarchielos …

SCRUM gibt einen großen Teil der „Macht“ zum Managen und Organisieren an das Team zurĂŒck. Einen Projektmanager im klassischen Sinne gibt es nicht mehr. Die Annahme, die hierbei zugrunde liegt, ist, dass die Teams selbst ausreichende Motivation und genug Wissen haben, um sich selbst zu organisieren, und selbst am besten wissen, wie sie ein vorgegebenes Ziel erreichen. Und das ganz ohne detaillierten Projektplan und ganz ohne jemanden, der ihnen sagt, wann sie was genau zu tun haben. Es gibt in einem SCRUM-Projektteam kein Hierarchiegefälle, sondern lediglich klar definierte Rollen. Jeder respektiert jeden als gleichwertig und kennt seine Rolle ganz genau. So funktioniert SCRUM.

SCRUM ist pragmatisch …

SCRUM kommt mit so wenig Administration wie möglich aus. Denkt man daran, wie viel Energie bei nach der klassischen Wasserfall-Methode gemanagten Projekten in Projektplanung, Budgetmanagement und Statusreports anstatt in das eigentlichen Management des Projekts geht, wird schnell klar, warum SCRUM so erfolgreich ist. All dieser Aufwand entfällt bei SCRUM nahezu gänzlich. SCRUM ist einfach pragmatischer und effizienter als andere Methoden. Kommunikation findet nicht mehr in Form von langen E-Mails, E-Mail-Ketten und Powerpoint-Präsentationen statt, sondern direkt von Angesicht zu Angesicht, ohne Medienbrüche, von Mensch zu Mensch. Probleme werden nicht über Ampeln kommuniziert, sondern direkt mit dem Betroffenen besprochen.

SCRUM funktioniert …

Oft beschreiben die Väter von SCRUM, Jeff Sutherland und Ken Schwaber, SCRUM mit sehr plakativen Aussagen wie beispielsweise „Wie Sie mit SCRUM in der Hälfte der Zeit doppelt so viel erreichen können“. Diese Aussagen sind sicherlich etwas überspitzt. Dennoch kann man neidlos eingestehen, dass die Methodik von SCRUM aufgrund der bereits oben beschriebenen Merkmale sehr effektiv und effizient ist – und deswegen einfach funktioniert. Andernfalls wäre es nicht möglich, dass SCRUM so erfolgreich ist und seit über 20 Jahren weltweit immer groÌˆĂŸere Verbreitung findet

SCRUM: Die Grundlagen

Was ist SCRUM? Eine Methode, ein Tool, eine Technik, ein Prozess? Keines von allem. Fangen wir damit an, woher der Begriff kommt …

SCRUM: Der Begriff

Der Begriff SCRUM lässt sich auf die beiden japanischen Wirtschaftswissenschaftler Nonaka und Takeuchi zurückführen. Sie schreiben in ihrem im Jahr 1986 erschienenen Artikel „The New Product Development Game” über den von ihnen so genannten “Rugby-Approach”. Dieser bedient sich einer Analogie aus dem Rugby. Sie gehen davon aus, dass einer der außergewöhnlichsten Erfolgsfaktoren von sehr erfolg- reichen Produktentwicklungsteams die räumliche Nähe des Teams während der Entwicklungsarbeit ist. So wie bei dem aus dem Rugby stammende Gedränge, welches SCRUM genannt wird und bei dem viele Spieler eng zusammenstehen. Denn auch diese Teams arbeiten als kleine und selbstorganisierte Einheiten. Sie bekommen von außen nur eine grobe Richtung vorgegeben. Es bleibt in der Umsetzung jedoch ihnen überlassen, wie sie ihr gemeinsames Ziel erreichen. Und diese Art der Zusammenarbeit soll auch Projekte erfolgreich machen.

Dieser Rugby-Approach wurde dann mehr als zehn Jahre später von den Vätern von SCRUM, Jeff Sutherland und Ken Schwaber, zu einem Framework für Softwareentwicklungsprojekte weiterentwickelt: Und dieses Framework nannten sie mit einem entsprechenden Verweis auf den Artikel von Nonaka und Takeuchi: SCRUM. Da die Anfänge von SCRUM schon mehr als 20 Jahre zurückliegen und SCRUM immer erfolgreicher geworden ist, haben sich immer mehr SCRUM-Varianten entwickelt. Dies liegt daran, dass viele Autoren, Berater und Experten von dem immer weiterwachsenden SCRUM-Kuchen ihren wirtschaftlichen Anteil abhaben wollten. So wurde der Kern dessen, was SCRUM ausmacht, immer stärker verfälscht. Dieses Problem haben auch die beiden Väter von SCRUM, Jeff Sutherland und Ken Schwaber, erkannt und aus diesem Grunde im Jahr 2010 den SCRUM-Guide veröf- fentlicht. Dieser wurde letztmalig in Jahr 2017 überarbeitet. Er fasst den Kern und das Grundverständnis von SCRUM nach Sutherland und Schwaber zusammen.

SCRUM: Empirische Prozesskontrolle

Die wissenschaftliche Basis von SCRUM ist die Theorie der empirischen „Prozesssteuerung“, kurz auch „Empirie“ bzw. im Englischen Empirical Theory genannt. Die Empirie besagt, dass Wissen auf Erfahrung basiert. Und dass Entscheidungen auf der Basis von diesem bestehenden Wissen erfolgen. SCRUM stellt durch seinen iterativen und inkrementellen Ansatz sicher, dass in regelmĂ€ĂŸigen und kurzen AbstĂ€nden die Möglichkeit zur ÜberprĂŒfung und Anpassung besteht.

So wird regelmĂ€ĂŸig Erfahrungen in Wissen transferiert. Dieses Wissen wiederum wird dann genutzt, um immer wieder Entscheidungen zu treffen. Je mehr Erfahrung, je mehr Wissen, und umso bessere Entscheidungen können getroffen werden. durch dieses Vorgehen können Risiken minimiert, frĂŒhzeitig erkannt und auch gegengesteuert werden.

SCRUM: Die 3 SĂ€ulen

Transparency Transparenz

Offene Kommunikation und das Teilen von Wissen ist die Grundlage für Transparenz. Zudem sollten das gesamte Vorgehen beziehungsweise der Prozess in einem agilen Projekt für alle Beteiligten transparent sein. Dies umfasst insbesondere auch die verwendeten Begriffe in einem Projekt. Jeder sollte unter den verwendeten Begriffen das gleiche verstehen. Als ein typisches Beispiel in einem Projekt zu nennen ist, dass es ein einheitliches Verständnis von „Done“ – also wann etwas erledigt ist – gibt. An welchen genauen Kriterien festzumachen ist, dass etwas erledigt ist.

empirische-prozesskontrolle

Inspection – Überprüfung

Inspection bedeutet, dass alle Vorgehensweisen und Arbeitsergebnisse regelmaÌˆĂŸig überprüft werden. In einem nach SCRUM gemanagten Projekt bedeutet dies, dass das Team in regelmaÌˆĂŸigen Abstän- den die Artefakte dahingehend überprüft, ob diese und ihre Ausgestaltung geeignet sind, um das jeweilige Sprint-Ziel zu erreichen. Die Überprüfung darf jedoch nicht so oft stattfinden, dass sie die eigentliche Projektarbeit behin- dert. Sie muss stets effizient bleiben. Die Überprüfungen müssen in einer Weise stattfinden, dass auch sie einen Mehrwert für die Projektarbeit darstellen.

Adaption – Anpassung

Adaption bedeutet das Anpassen an die Rahmenbedin- gungen, um schneller und besser zu werden und das Ziel effizient zu erreichen. Wenn im Rahmen einer Überprüfung festgestellt wird, dass das Vorgehen oder die Arbeitsergebnisse ein nicht akzeptables Limit überschreitet, müssen Anpassungen vorgenommen werden. Diese Anpassungen müssen möglichst kurzfris- tig, ohne unnötigen Zeitverzug entschieden werden, um unnötige weitere Ab- weichungen zu verhindern.

Die fĂŒnf Values von SCRUM

Denn die fĂŒnf Values sorgen dafĂŒr, dass die drei SĂ€ulen von SCRUM gelebt werden. Wir beschreiben diese fĂŒnf Values im Folgenden kurz – in Anlehnung an den SCRUM-Guide. Viele haben diese Values nĂ€her im Detail beschrieben und konkretisiert. Wir wollen hier jedoch nicht zu viele Vorgaben machen und es dadurch jedem SCRUM-Team selbst ĂŒberlassen, wie konkret es diese Values fĂŒr sich definiert, lebt und umsetzt. Diese Vorgehensweise folgt der grundsĂ€tzlichen Logik von SCRUM, einfach zu sein, wenige Regeln aufzustellen und die Ausgestaltung im Sinne der FlexibilitĂ€t dem Projektteam zu ĂŒberlassen. GrundsĂ€tzlich ist es auch so, dass SCRUM zwar klare Regeln aufsetzt. Im Sinne von ÜberprĂŒfung und Anpassungen können die Regeln jedoch fĂŒr jedes Projekt im Detail so konkretisiert werden, dass sie auf das jeweilige Projekt und fĂŒr das jeweilige Projektumfeld passen. Trotz sehr klarer und eindeutiger Regeln bietet SCRUM dennoch Raum zur individuellen Ausgestaltung.

Courage – Mut

Die Mitglieder des SCRUM-Teams haben den Mut, die richtigen Dinge zu tun und an den Herausforderungen und Problemen im Projekt zu arbeiten.

Focus – Fokussierungscrum-leitfaden_scrum-values

Jeder fokussiert sich auf die Arbeit des aktuellen Sprints und auf die Ziele des SCRUM-Teams.

Commitment – Selbstverpflichtung

Jeder verpflichtet sich, persönlich die Ziele des SCRUM-Teams zu unterstĂŒtzen und zu erreichen.

Respect – Respekt

Die Mitglieder des SCRUM-Teams respektieren sich und befÀhigen sich gegenseitig, kompetente und unabhÀngige Individuen zu sein.

Openness – Offenheit

Das SCRUM-Team und seine Stakeholder einigen sich darauf, bezogen auf die Arbeit und die mit dieser verbundenen Herausforderungen offen zu sein.

Wie funktioniert SCRUM?

Im Folgenden erklĂ€ren wir, wie SCRUM funktioniert, also welche Methoden und Techniken im Rahmen das SCRUM Frameworks zum Einsatz kommen. Der Kern von SCRUM ist aus unserer Sicht der SCRUM-Prozess. Dieser Begriff stammt nicht von den VĂ€tern von SCRUM, sondern wurde von uns aus didaktischen GrĂŒnden definiert. Im Rahmen des SCRUM-Prozesses wird im Wesentlichen dargestellt, welche Events und welche Artefakte wie zusammenspielen und in welchem zeitlichen Verlauf erfolgen. Letztlich zeigt der SCRUM-Prozess, wann welche Events stattfinden und welche Artefakte wann zum Einsatz kommen.

Die SCRUM Rules

Die SCRUM Rules sind im SCRUM Guide niedergeschrieben. Sie beschreiben, wie die wesentlichen Elemente von SCRUM – Roles, Events und Artefacts – zusammen­spielen. Sie liefern also beispielsweise die Antwort darauf, wann welches Event stattfindet, welche Rollen in welchem Event anwesend sind, welche Aufgaben sie hierbei haben – oder auch welche Rolle fĂŒr welches Artefact zustĂ€ndig ist. Die Details der Regeln werden im weiteren Verlauf dieses Buchs ausfĂŒhrlich erklĂ€rt.

scrum-leitfaden_scrum-rulesRoles

Rollen regeln die Aufgaben jedes einzelnen Teammitglieds, je nachdem, zu welcher Rolle es gemĂ€ĂŸ den nach SCRUM definierten Rollen gehört. Jede Rolle hat konkrete Aufgaben, Rechte und Pflichten.

Artefakte

Dies sind bestimmte Tools und Techniken, die die Anwendung von SCRUM erfolgreich machen und notwendig sind, den Projektablauf effizient zu gestalten.

Events

Sie regeln Form, Frequenz und Inhalte der Kommunikation zwischen den Rollen und den Mitgliedern im Projekt.

Rules

Regeln bestimmen das Zusammenspiel und die Wechselwirkungen der Rollen, Artefakte und Events.

Dieses SCRUM-Rahmenwerk beziehungsweise SCRUM Framework ist in dieser Form auch im von Jeff Sutherland und Ken Schwaber veröffentlichten SCRUM-Guide so beschrieben. Alle weiteren Komponenten und Elemente, die ĂŒber diese hier genannten Komponenten hinausgehen, wurden von anderen Autoren und von Praktikern im Laufe der Jahre zu SCRUM ergĂ€nzt. Es ist absolut nicht zu empfehlen, dass SCRUM durch die ErgĂ€nzung anderer Elemente verfĂ€lscht wird. Zumindest wenn man ein Projekt rein agil managen will. Elemente aus SCRUM in das klassische Projektmanagement zu ĂŒbernehmen kann aus unserer praktischen Sicht durchaus Sinn machen.

Die einzelnen Rollen gemĂ€ĂŸ SCRUM stehen wĂ€hrend des gesamten SCRUM-Pro­zesses in Interaktion. Um einen GesamtĂŒberblick von Artefakten und Events der jeweils zum jeweiligen Zeitpunkt eingebundenen Rollen zu bekommen, haben wir den SCRUM Framework-Überblick erstellt.

Der SCRUM Prozess

scrum-leitfaden_scrum-prozessDer Prozess beginnt, wenn ein oder einige Stakeholder ein Produkt benötigen. Die Anforderungen an das Produkt werden dann in einem so genannten Product Backlog gesammelt. Das Product Backlog ist also die Zusammenfassung aller Produkteigenschaften, die das finale Produkt umfassen sollte. Nachdem das Product Backlog vollstĂ€ndig ist, beginnt man mit dem Sprint Planning. Hier wird geplant, welche Produktfeatures im kommenden Sprint umgesetzt werden sollen. Diese Teilmenge der Produkteigenschaften wird dann in ein Sprint Backlog ĂŒberfĂŒhrt. Das Sprint Backlog umfasst somit alle Produkt­eigenschaften die im kommenden Sprint umgesetzt werden sollen. Diese sind sozusagen das Sprint-Ziel.

Danach beginnt der Sprint. Der Sprint ist die eigentliche Phase der Produktentwicklung. Im Rahmen der Produktentwicklung erfolgt dann ein tĂ€glicher Austausch des Teams im Rahmen des Daily. Nach Abschluss des Sprints sollten als Ergebnis neue Produkteigenschaften fĂŒr das Produktinkrement hervorgebracht werden. Ein Produktinkrement ist hierbei ein fertiger Teil des Gesamtproduktes. Nach dem Sprint besteht die Möglichkeit des ÜberprĂŒfens und Anpassens in Form eines Sprint-Reviews. Hierbei wird das Produkt, das entwickelt wird, ĂŒberprĂŒft und gegebenenfalls angepasst. So besteht einerseits die Möglichkeit fĂŒr alle, die nicht selbst am Entwicklungsprozess beteiligt waren, Informationen ĂŒber den aktuellen Entwicklungsstand zu erhalten, wie beispiels­weise die Stakeholder. Alle diejenigen, die an der Entwicklung direkt beteiligt waren, erhalten so das Feedback, inwiefern sie sich mit der Arbeit im letzten Sprint bezogen auf die Produkteigenschaften des gesamten Produkts angenĂ€hert haben.

Die SCRUM Events

Events gemĂ€ĂŸ SCRUM finden immer in persönlicher Form statt. Sie erfolgen regelmĂ€ĂŸig, um kontinuierlich ĂŒberprĂŒfen und anpassen zu können. Alle Events haben ein festes Zeitfenster. Dieses Zeitfenster wird auch Timebox genannt. Das bedeutet, dass fĂŒr jedes Event ein Zeitrahmen vorgegeben ist, der auf jeden Fall eingehalten wird. Die Einhaltung dieses Zeitfensters ist Aufgabe des SCRUM Masters. Gibt es dennoch mehr Themen als es die Zeit des Events hergibt, so werden diese Themen auf das nĂ€chste Event verschoben. Abbildung 20 gibt dir einen Überblick ĂŒber die wesentlichen Eigenschaften von Events nach SCRUM und einen Überblick darĂŒber, welche Events es gibt.

Charakteristik von Events

Events nach SCRUM haben eine ganz spezielle Charakteristik, die Events nach SCRUM „typisch“ SCRUM werden lassen. Diese lassen sich wie folgt beschreiben.

RegelmĂ€ĂŸigkeit

Um den iterativen Charakter von SCRUM sicherzustellen, finden die Events bei SCRUM regelmĂ€ĂŸig statt. Es gibt eine feste Frequenz, in denen die Events stattfinden. Diese Frequenz wird nicht verĂ€ndert oder angepasst. Sie wird wĂ€hrend des gesamten Projekts konsequent verfolgt. Auch der Ort der jeweiligen Events sollte immer der gleiche sein. Diese RegelmĂ€ĂŸigkeit und die klare Definition von Frequenz und Ort stellen den Fluss und die Effizienz des SCRUM-Prozesses sicher.

Timebox

FĂŒr jedes Event ist ein fester Zeitrahmen vorgegeben. Das bedeutet, dass fĂŒr jedes Event vorher ein Zeitfenster festgelegt wurde. Dieses wird auf jeden Fall eingehalten. Wenn das Zeitfenster abgelaufen ist, ist das Event beendet. Es gibt keine VerlĂ€ngerung des Events. Themen, die noch offen sind, werden dann im nĂ€chsten Event besprochen beziehungsweise auf das nĂ€chste Event verschoben. Zudem finden die Events gemĂ€ĂŸ SCRUM immer zum gleichen Zeitpunkt, also bezogen auf die Uhrzeit und den Wochentag, statt. Dies vermindert den koordinativen Aufwand der Event-Organisation. Eine Verschiebung von Events oder immer wieder neue Festlegung des Zeitpunkts von Events ist bewusst nicht vorgesehen.

Die fĂŒnf Events von SCRUM

Nach SCRUM gibt es genau fĂŒnf Events, die im Rahmen eines nach SCRUM gemanagten Projektes stattfinden. Weitere Events sind nicht zugelassen. Es ist jedoch wichtig zu erwĂ€hnen, dass dies nicht bedeutet, dass es keine Kommunikation außerhalb der SCRUM-Events geben darf. Nur die Art und Anzahl der Events selbst ist klar vorgeben. Dennoch haben in den letzten Jahren mehrere Autoren und Praktiker in ihren Veröffentlichungen weitere Events fĂŒr sinnvoll erkannt. Diese sind jedoch nicht Teil von SCRUM und werden aus diesem Grund nicht in diesem Buch vorgestellt. Es ist uns wichtig, zu erwĂ€hnen, dass die beiden BegrĂŒnder von SCRUM Ken Schwaber und Jeff Sutherland betonen, dass jede Abwandlung und ErgĂ€nzung des von ihnen definierten „Kerns“ von SCRUM den Erfolg und die Effizienz der Methode mindern.

Der Sprint

Das Ziel des Sprints ist es, die jeweiligen Ziele beziehungsweise das jeweilige Ziel, das sich das Development Team fĂŒr den jeweiligen Sprint vorgenommen hat, zu erreichen. Konkret sind die im Rahmen des Sprints umzusetzenden Produkteigenschaften in Sprint Backlog festgehalten. Der Sprint selbst ist kein eigenstĂ€ndiges Event, sondern die Klammer um mehrere Events, die innerhalb des Sprints stattfinden. Insofern gibt es keine konkrete Form, wie der Sprint selbst stattfindet. Die Events, die innerhalb des Sprints stattfinden, sind: Sprint Planning, Daily SCRUM, die Entwicklungsarbeit, der Sprint Review und die Retrospektive. Teilnehmer innerhalb des Sprints sind der Product Owner, der SCRUM Master, das Entwicklungsteam und die Stakeholder.

Der Sprint selbst wird nicht moderiert, da er wie schon erwĂ€hnt eine Klammer bzw. einen Container um mehrere Events darstellt. Insofern gibt es auch keine Agenda des Events selbst. WĂ€hrend des Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefĂ€hrden. Der Anspruch an die QualitĂ€t der Arbeit darf nicht geĂ€ndert werden. Der Scope des Sprints darf zwischen dem Product Owner und dem Entwicklungsteam verhandelt werden, wenn er dem Lernen dient. Die Agenda des Sprints ist quasi die Abarbeitung des Sprint Backlogs. Innerhalb des Sprints haben die beteiligten Rollen die Aufgaben, Kompetenzen und Verantwortung, die ihnen auch grundsĂ€tzlich gemĂ€ĂŸ ihrer Rollendefinition zukommen. Das Ergebnis des Sprints ist die Abarbeitung der fĂŒr den Sprint vorgesehen Produkteigenschaften gemĂ€ĂŸ dem Product Backlog.

Wie lange dauert ein Sprint?

Die Dauer des Sprints ist unterschiedlich. Ein Sprint kann wenige Tage gehen bis hin zu einem Monat. Die maximale Dauer des Sprints sind vier Wochen beziehungsweise ein Monat. Wichtig ist, dass die Sprints immer die gleiche Dauer haben. Hintergrund ist, dass es sich erwiesen hat, dass die LeistungsfÀhigkeit der Sprint-Teams am höchsten ist, wenn die Dauer jeweils gleich lange ist. GrundsÀtzlich kann man sagen, dass Sprints immer so kurz wie nur möglich sein sollten. Wenn ein Sprint zu Ende ist, beginnt schon der nÀchste Sprint. Es gibt demnach quasi keine Pause zwischen den einzelnen Sprints. Auf jeden Sprint folgt sofort der nÀchste Sprint.

Wie viele Sprints innerhalb eines SCRUM-Projektes stattfinden, ist unterschiedlich. Letztendlich finden Sprints statt, so lange das Produkt bzw. die Dienstleistung, die entwickelt wird, besteht. Die Struktur innerhalb eines Sprints ist auch immer die gleiche. Ein Sprint beginnt immer mit dem Sprint Planning als erstem Event.

Das Sprint Planning

Das Ziel des Sprint Plannings ist, den jeweils anstehenden Sprint zu planen. Der Sprint erfolgt in Form eines PrÀsenz-Events, das immer als allererstes Event eines Sprints stattfindet. Das Sprint Planning findet einmal pro Sprint statt. Jeder Sprint beginnt damit.

Am Sprint Planning nimmt das gesamte SCRUM-Team teil, also der Product Owner, der SCRUM Master und das Entwicklungsteam. Das Sprint Planning dauert bei einem Sprint von vier Wochen maximal acht Stunden. Dauert der Sprint weniger als vier Wochen, passt sich die Dauer des Sprint Plannings auch entsprechend proportional an und ist kĂŒrzer.

Der SCRUM Master ist dafĂŒr verantwortlich, dass das Sprint Planning stattfindet und dass alle Mitglieder des SCRUM-Team verstehen, was das Ziel des Events ist. Er ist zudem dafĂŒr verantwortlich, dass das Sprint Planning im vereinbarten Zeitfenster bezĂŒglich der Dauer bleibt. Das Sprint Planning ist in zwei Teile gegliedert.

Das Daily SCRUM

Nachdem das Spring Planning abgeschlossen wurde, beginnt das Entwicklungsteam seine Arbeit. Konkret bedeutet dies, dass es die Aufgaben, die im Sprint Planning definiert wurden, im Team selbstorganisiert bearbeitet. Wichtig ist hierbei, dass das Entwicklungsteam die Aufgaben nacheinander abarbeitet und im Idealfall gemeinsam und gleichzeitig am gleichen Backlog Item arbeitet. WÀhrend dieser Entwicklungsarbeit trifft sich das SCRUM-Team physisch einmal an jedem Tag, an dem gearbeitet wird, zum Daily SCRUM.

Dieses findet immer zur gleichen Zeit am gleichen Ort statt. Grund hierfĂŒr ist, dass die organisatorische Arbeit der Eventplanung und die KomplexitĂ€t reduziert werden soll. Die Dauer des Daily SCRUM ist auf maximal 15 Minuten beschrĂ€nkt. Das Ziel des Daily SCRUM ist, dass sich das Entwicklungsteam abstimmt und synchronisiert.

Wie lÀuft das Daily SCRUM ab?

Bei jedem Daily SCRUM wird die Entwicklungsarbeit fĂŒr die nĂ€chsten 24 Stunden geplant. Hierbei werden immer zuerst die Arbeit der letzten 24 Stunden transparent gemacht und ein Ausblick auf die Aufgaben der nĂ€chsten 24 Stunden gegeben. Das Entwicklungsteam verprobt hierbei den Fortschritt der letzten 24 Stunden bezĂŒglich des Sprint-Ziels. Zudem analysiert es, wie der Fortschritt bezogen auf die Backlog Items, die im Sprint Backlog sind, ist. Hauptziel des Daily SCRUM ist es, die Wahrscheinlichkeit zu maximieren, dass das Entwicklungsteam das Sprint-Ziel auch erreicht.

Die Agenda des Events wird vom Entwicklungsteam selbst festgelegt. Es gibt keine konkreten Vorgaben gemĂ€ĂŸ SCRUM, wie das Daily SCRUM strukturiert werden soll, so lange alles darauf abzielt, dass das Sprint-Ziel erreicht wird. Es gibt Entwicklungsteams, die strukturierte Fragen nutzen, wie die folgenden:

1. “Was habe ich gestern fĂŒr das Entwicklungsteamgetan, um das Sprint-Ziel zu erreichen?”

2. “Was werde ich heute fĂŒr das Entwicklungsteam tun, um das Sprint-Ziel zu erreichen?”

3. “Gibt es irgendwelche Hindernisse, die mich oder das Entwicklungsteamdar­an hindern, das Sprint-Ziel zu erreichen?”

Andere Entwicklungsteams hingegen nutzen das Daily SCRUM fĂŒr ausfĂŒhrliche Diskussionen. Die genaue Agenda des Daily SCRUM ist dem SCRUM-Team letztlich freigestellt, so lange es darum geht, das Sprint-Ziel zu erreichen und die maximale Dauer von 15 Minuten einzuhalten.

Der Sprint Review

Der Sprint Review findet immer am Ende der Entwicklungsarbeit statt. Er dient dazu, die wichtigsten Ergebnisse aus dem Sprint zu prĂ€sentieren und um zu ĂŒberprĂŒfen und gegebenenfalls anzupassen. So kann der neueste Stand des Produktinkrements transparent gemacht werden, und das Product Backlog kann entsprechend aktualisiert werden. Der Sprint Review findet in Form eines physischen Events statt. Der Product Owner lĂ€dt zu dem Event ein. Das gesamte Team ist beim Sprint Review anwesend. Zudem sind auch die Stakeholder mit eingeladen. So erhalten sie einen Überblick ĂŒber den neuesten Stand der Entwicklungsarbeit und können dem Entwicklungsteam gleichzeitig Feedback geben.

Die PrĂ€sentation der Ergebnisse des Sprints dient im Wesentlichen dazu, Feedback zu ermöglichen und die Zusammenarbeit zu fördern. Der Sprint Review dauert maximal vier Stunden bei einem Sprint, der vier Wochen dauert. Wenn die Dauer des Sprints kĂŒrzer ist, dann sollte auch der Sprint Review entsprechend angepasst werden. Der SCRUM Master ist dafĂŒr verantwortlich, dass das Event stattfindet und dass alle den Grund des Events kennen. Zudem unterstĂŒtzt der SCRUM Master dabei, dass jeder, der am Event teilnimmt, dazu beitrĂ€gt, dass das Event in dem festgelegten Zeitrahmen bleibt.

Der Sprint Review hat typischerweise die folgende Agenda:

Das Entwicklungsteamstellt die Arbeit vor, die erledigt, „Done“ ist und beantwortet Fragen ĂŒber das Produktinkrement.

Der Product OwnererlĂ€utert, welche Items des Product Backlog erledigt, also „Done“ sind und welche nicht.

Der Product Ownerdiskutiert das Product Backlog in seinem aktuellen Stand. Er gibt einen Ausblick auf kĂŒnftige Lieferdaten und Ziele basierend auf dem aktuellen Fortschritt (sofern dies notwendig ist).

Die gesamte Gruppe (SCRUM-Teamund Stakeholder) arbeitet zusammen daran, was als nĂ€chstes getan werden sollte, so dass der Sprint Review einen wertvollen Input fĂŒr das nĂ€chste Sprint Planning liefert.

ÜberprĂŒfung,wie sich der Markt oder der potenzielle Einsatzbereich des Produkts geĂ€ndert haben könnte bezogen darauf, was der beste nĂ€chste Schritt wĂ€re.

ÜberprĂŒfungdes Zeitplans, des Budgets, der potenziellen Ressourcen und des Markt fĂŒr das nĂ€chste anstehende Release bezĂŒglich der Funktionen und Capabilities des Produkts.

Das Ergebnis des Sprint Reviews ist ein ĂŒberarbeitetes Product Backlog. Das Product Backlog kann auch grundlegend angepasst werden, wenn sich neue Möglichkeiten ergeben.

Die Sprint-Retrospektive

Das Ziel der Sprint-Retrospektive ist, Feedback einzuholen, um den Entwicklungsprozess organisatorisch und strukturell zu verbessern. Es geht also nicht um Feedback bezogen auf die erzielte Arbeit wie beim Sprint Review, sondern um die Arbeitsweise, wie sie war und was verbessert werden kann. Im Kern geht es darum, dass Verbesserungspotenzial bezogen auf Menschen, Interaktionen, Prozess und Werkzeuge identifiziert wird.

Das Event findet immer nach dem Sprint Review und vor den kommenden Sprint Planning statt. Das Event erfolgt in Form eines PrĂ€senz-Events. An dem Event nehmen das gesamte Team, nicht jedoch die Stakeholder teil. Dies liegt daran, dass die Sprint Retrospektive sich auf eine Verbesserung der Entwicklungsarbeit bezieht, also die Art und Weise, wie das Entwicklungsteam inklusive dem Rest des Teams zusammengearbeitet hat. Der Fokus der Stakeholder liegt jedoch auf dem Ergebnis dieses Prozesses, also dem Produkt. Die Dauer des Events ist auf maximal drei Stunden begrenzt bei einem Sprint von einer Dauer von vier Wochen. Bei einem kĂŒrzeren Sprint dauert die Sprint Retrospektive entsprechend kĂŒrzer.

Der SCRUM Master ist fĂŒr die Organisation des Events zustĂ€ndig. Zudem muss er dafĂŒr sorgen, dass alle Teilnehmer den Grund des Events kennen. Er nimmt an dem Event teil, da er fĂŒr die Einhaltung der Regeln verantwortlich ist. Die Sprint-Retrospektive ist eines der wesentlichsten Events, in denen der SCRUM Master die Einhaltung der Regeln ĂŒberprĂŒfen und eventuell coachend aktiv werden kann. Er hat auch dafĂŒr Sorge zu tragen, dass das Event produktiv und positiv verlĂ€uft. Zudem sollte er alle Teilnehmen dazu anhalten, dass das Event im geplanten Zeitrahmen bleibt.

Die folgenden Ziele des Events bestimmen seine Agenda:

ÜberprĂŒfung,wie der letzte Sprint gelaufen ist, mit Fokus auf die Menschen, Beziehungen, Prozesse und Tools.

Identifikation und Strukturierung der Themen, die gut gelaufen sind, und potenzieller Verbesserungsfelder.

Erstellung eines Plans, wie die Verbesserungsfelder umgesetzt werden können, so dass das SCRUM-Teamseine Arbeit am besten erledigen kann.

Im Rahmen der Retrospektive werden verschiedene Methoden genutzt, um Feedback einzuholen. Die einfachste Art und Weise ist es, eine Metaplanwand in drei Felder zu teilen: Liked, Learned, Lacked. Jedes Mitglied des Teams schreibt auf eine Metaplankarte, was ihm zu diesen drei Punkten einfÀllt, und pinnt es an die Wand. Der SCRUM Master moderiert dann das, was an die Wand gepinnt wurde, und erarbeitet mit dem Team die Verbesserungspotenziale und einen Plan, wie diese umgesetzt werden können.

Die Rollen

SCRUM kennt eine sehr einfache und ĂŒbersichtliche Definition der unterschied­lichen Rollen im Rahmen des SCRUM-Frameworks. FĂŒr jede dieser Rollen ist ganz klar beschrieben, was ihre Aufgaben sind und welche Kompetenzen und Verantwortungen sie haben. Es ist wichtig, dass jedes Mitglied des SCRUM-Teams weiß, welche Rolle es hat und welche Erwartungen an diese Rolle gestellt werden. Dies ist notwendig, um SCRUM erfolgreich umzusetzen. Gelten die Werte nach SCRUM fĂŒr alle Mitglieder des SCRUM-Teams einerseits, so definieren die Rollen fĂŒr jedes einzelnes Teammitglied andererseits ganz konkret und individuelle pro Rolle deren Aufgaben.

Das SCRUM-Team

scrum-leitfaden_scrum-rollen

Das SCRUM-Team arbeitet selbstorganisiert und interdisziplinĂ€r. Letztlich geht man gemĂ€ĂŸ SCRUM davon aus, dass das SCRUM-Team hoch motiviert ist und selbststĂ€ndig entscheiden kann, wie es das jeweilige Ziel erreicht. Es erledigt seine Arbeit, ohne dabei auf Personen von außerhalb des SCRUM-Teams angewiesen sein zu mĂŒssen. Zudem sind SCRUM-Teams interdisziplinĂ€r.

InterdisziplinĂ€r bedeutet hierbei, dass die Teams interdisziplinĂ€r bezĂŒglich ihrer FĂ€higkeiten und Fertigkeiten gemischt sind. Oft werden in Projekten, die nicht nach SCRUM gemanagt werden, einzelne Teilprojekte nach FunktionstrĂ€gern oder Fachbereichen gebildet. Ein Beispiel hierfĂŒr ist ein Teilprojekt fĂŒr die Produktstrategie und ein Teilprojekt fĂŒr die IT-Umsetzung. In SCRUM werden diese einzelnen Personen und Themen alle gemeinsam in einem Team vereint. Eine Trennung in Teilprojekte gibt es so nicht mehr. Im SCRUM-Team gibt es eine klare Rollendefinition. Jedes Teammitglied weiß genau, welche Rolle es ausfĂŒhren soll.

Die SCRUM Stakeholder

Das Framework kennt insgesamt drei Rollen, diese werden in ihrer Gesamtheit als Team bezeichnet. Alle diejenigen, die nicht Teil des Teams sind, jedoch ein Interesse an der Entwicklung des Produktes bzw. Wissen ĂŒber das Produkt haben, werden Stakeholder genannt. Stakeholder sind also nicht Teil des Teams selbst. Und dennoch nehmen sie am Prozess in jeweils unterschiedlicher Weise teil. Typische Stakeholder in Projekten sind: Kunden, Benutzer, Managemen.

Weitere Rollen kennt SCRUM im Kern nicht. Dennoch gibt es fĂŒr das Management grĂ¶ĂŸerer Einheiten und mehrerer Teams andere Frameworks, wie beispielsweise das Scaled Agile Framework oder das Large Scale SCRUM. Diese stellen Weiterentwicklungen von SCRUM dar und gehen nur teilweise auf die VĂ€ter von SCRUM zurĂŒck. Wie gesagt, sind diese Frameworks nicht Kern der eigentlichen Methode. Deswegen werden wir auf diese auch nicht weiter an dieser Stelle eingehen. In SCRUM gibt es lediglich drei Rollen, welche sich auch absolut als ausreichend zum Management eines agilen Projekts erwiesen haben.

Die drei Rollen von SCRUM

SCRUM kennt im Kern nur drei Rollen: den Product Owner, den SCRUM Master und das Entwicklungsteam. Die Hauptaufgaben dieser Rollen sind die folgenden:

Product Owner: Er vertritt die Interessen des Auftraggebers oder des Kunden. Er ist verantwortlich fĂŒr den geschĂ€ftlichen Erfolg des Produkts.

SCRUM Master: Er ist die dienende FĂŒhrungsperson (Servant Leader) und verantwortlich fĂŒr die Implementierung der SCRUM-Regeln. Wir sprechen hier gerne vom RegelhĂŒter, Moderator und Coach. In englischer Sprache wir oft von “Servant Leader” gesprochen.

Entwicklungsteam: Dieses entwickelt das Produkt. Es ist verantwortlich dafĂŒr, sich selbst so zu organisieren, um das jeweilige Ziel des Sprints zu erreichen. Das Entwicklungsteam ist das Herz von SCRUM. Es ist fĂŒr den wichtigsten Teil im Rahmen eines SCRUM-Projektes zustĂ€ndig: das Entwickeln des Produktes.

Der Product Owner

Der Product Owner ist fĂŒr das „Was“ zustĂ€ndig. Was wird umgesetzt, um den Wert des Produktes zu maximieren? Er hat die folgenden Aufgaben, Verantwortungen und Kompetenzen:

Aufgaben des Product Owners

Der Product Owner ist wĂ€hrend des gesamten Prozesses sehr aktiv eingebunden. Er hat zu Beginn des Prozesses die Aufgabe, in Abstimmung mit den Stakeholder die Ausstattungsmerkmale des zu entwickelnden Produktmerk­male abzustimmen. Zudem hat er diese Produktmerkmale dann entsprechend auch strukturiert in Form eines Product Backlogs zu managen. Sein wesentliches Werkzeug ist das Product Backlog. WĂ€hrend der Entwicklungsarbeit selbst zieht er sich etwas zurĂŒck und ĂŒberlĂ€sst die wichtigsten Entscheidungen dem Entwicklungsteam selbst.

Nach einem Sprint beziehungsweise zum Ende des Sprints wird er wieder aktiver in der Form, dass er seinen Blick darauf lenkt, ob im Rahmen der Entwicklungsarbeit die wichtigsten Product Backlog Items abgearbeitet wurden. Konkret hat er die folgenden Aufgaben:

Wertmaximierung des Produkts durch Priorisierung des Product Backlogs

Wert der Arbeit des Entwicklungsteams optimieren

Product Ownerkann diese Aufgaben alleine erfĂŒllen oder delegieren

Product Ownerbleibt jedoch verantwortlich

Hat eine Vision fĂŒr das Produkt und brennt fĂŒr das Produkt

Kompetenzen des Product Owners

Der Product Owner hat die Kompetenz fĂŒr die folgenden Themen:

Er hat die Kompetenz, als einziger im SCRUM-Teamdem Entwicklungsteam Aufgaben, in Form von im Backlog definierten Anforderungen zu ĂŒbertragen.

Er handelt im Auftrag der Stakeholder, wie beispielsweise des Kunden oder des Managements, beziehungsweise er vertritt deren Interessen im Rahmen des SCRUM-Prozesses. Und hat alle Vollmachten bezogen auf das Produkt, um es erfolgreich zu machen.

Dem Product Owner„gehört“ quasi das Produkt. Im Idealfall ist er auch derjenige, der ĂŒber das Budget verfĂŒgt, das notwendig ist, um das Produkt zu entwickeln.

Er ist EigentĂŒmer des Product Backlogs und legt die Kompetenz die Backlog Items im Product Backlogfest bzw. priorisiert sie.

Verantwortung des Product Owners

Der Product Owner ist verantwortlich fĂŒr die folgenden Themen:

VerantwortungfĂŒr den finanziellen Erfolg des Produktes

Wertmaximierung des Produktes allgemein und in jedem Sprint

Management und Pflege des Product Backlogs

EintrĂ€ge im Product BacklogmĂŒssen klar formuliert werden

EintrÀge im Product Backlogsollen so sortiert werden, dass Ziele und Missionen optimal erreicht werden

Die gesamte Organisation muss den Product Ownerrespektieren

Entscheidungen des Product OwnermĂŒssen in Inhalt und Reihenfolge des Product Backloks sichtbar sein.

Der Product Owner ist eine Rolle im SCRUM-Team, die nur von einer einzelnen Person durchgefĂŒhrt werden darf. Dies hat den Grund, dass nur so sichergestellt werden kann, dass es immer eine eindeutige Priorisierung der Backlog Items gibt. Zudem gibt es so stets klare Antworten auf Fragen sowohl des Entwicklungsteams als auch der Stakeholder. Er hat zudem die Verantwortung, die Ziele und Anforderungen der Stakeholder zu bĂŒndeln und im Rahmen der Entwicklungsarbeit zu vertreten.

Aus diesem Grund hat der Product Owner quasi zwei Gesichter; eines, das den Stakeholdern zugewandt ist: Hier geht es darum, fortlaufend die Anforderungen der Stakeholder zu verstehen, zu sortieren und bĂŒndeln. Und ein weiteres Gesicht, das dem Entwicklungsteam zugewandt ist: Hier ist seine Aufgabe, die Entwicklungsarbeit durch klare Vorgaben im Product Backlog effizient zu gestalten. Und auch Entwicklungsergebnisse nach klar definierten Abnahmekriterien zu bewerten beziehungsweise abzunehmen.

Der SCRUM Master

Der SCRUM Master ist quasi fĂŒr alles, was ein SCRUM-Projekt fĂŒr ein SCRUM-Projekt charakteristisch macht, verantwortlich: die SCRUM-Regeln. Er stellt sicher, dass alles wĂ€hrend des Sprints nach den Regeln von SCRUM ablĂ€uft.

Aufgaben des SCRUM Masters

Der SCRUM Master wird auch als „Servant Leader“ bezeichnet. Übersetzt heißt dies, dass er eine „dienende FĂŒhrungskraft“ ist. Was bedeutet das? In SCRUM gibt es keinen mit FĂŒhrungskompetenzen ausgestatteten Projektleiter beziehungsweise Projektmanager. Jedoch hat der SCRUM Master viele Aufgaben, die sonst einem klassischen Projektmanager zugesprochen wĂŒrden. Denn er hat den gesamten Prozess und seine Kommunikations- und Eventstrukturen nach den Regeln von SCRUM zu gestalten. Hierbei ist seine Rolle die eines Coachs beziehungsweise eines Moderators.

Er hat die Aufgabe, die anderen Teammitglieder im Team dazu zu befĂ€higen, die Regeln von SCRUM fĂŒr eine möglichst effiziente Projektarbeit anzuwenden. Er hat auch dafĂŒr Sorge zu tragen, allen, die nicht Teil des Teams sind, zu vermitteln, wie die Interaktion mit dem SCRUM-Team erfolgreich sein kann. Zudem unterstĂŒtzt er alle dabei, diese Interaktionen so zu gestalten, dass sie einen maximalen Wert der Arbeit des SCRUM-Teams sicherstellen.

Verantwortung des SCRUM Masters

Der SCRUM Master hat fĂŒr die folgenden Themen Verantwortung: Er ist dafĂŒr verantwortlich, dass alle Beteiligten die SCRUM-Theorie, Praktiken, Regeln und Werte verstehen. Botschafter innerhalb der Organisation fĂŒr alles rund um das Thema SCRUM.

Kompetenzen des SCRUM Masters

Der SCRUM Master hat die folgenden Themen als Kompetenz: Der SCRUM Master hat die Kompetenz, alle SCRUM-Teammitglieder darauf hinzuweisen, wenn SCRUM-Regeln nicht richtig angewendet wurden. Zudem hat er die Kompetenz, jederzeit Maßnahmen zu ergreifen, die dazu notwendig sind, das VerstĂ€ndnis der SCRUM-Regeln im SCRUM-Team zu stĂ€rken und so auch deren Anwendung zu verbessern.

Da der SCRUM Master diese unterstĂŒtzende Funktion im Rahmen des SCRUM-Prozesses hat, werden seine Aufgaben im Folgenden so strukturiert, dass deutlich wird, welche Aufgaben er unterstĂŒtzend fĂŒr die anderen Rollen innerhalb des SCRUM-Teams hat und welche auch fĂŒr alle außerhalb des SCRUM-Teams.

GrundsÀtzliche Aufgaben des Masters

Der SCRUM Master ist somit der RegelhĂŒter im Rahmen des Prozesses. Er hat zu jedem Zeitpunkt im Rahmen der Entwicklungsarbeit, der Events etc. sicherzustellen, dass alle Beteiligten sich an die Regeln gemĂ€ĂŸ Guideline halten, und auch alle Events in der entsprechenden Form stattfinden. Er fungiert hierbei als Moderator und Coach. Dies bedeutet, dass er zu keiner Zeit als Projektmanager oder Projektleiter agiert; seine Aufgabe ist lediglich unterstĂŒtzend im SCRUM-Prozess. Sein Ziel ist es, dass er das Team befĂ€higt, nach den Regeln zu arbeiten und effizient zu sein.

Das Entwicklungsteam

Das Entwicklungsteam ist fĂŒr das „Wie“ verantwortlich: Wie wird das Produkt entwickelt und umgesetzt?

Charakteristiken des Entwicklungsteams

Entwicklungsteams nach haben ganz spezielle Charakteristika, die den Spirit von SCRUM ausmacht. Diese werden im Folgenden beschrieben.

TeamgrĂ¶ĂŸe

Das Entwicklungsteam besteht aus einer Anzahl von drei bis neun Teammitgliedern. Es werden sieben Personen als optimal angesehen. Im Rahmen dieser Berechnung werden der SCRUM Master und der Product Owner nicht mitgezÀhlt. Sie sind zwar Mitglieder des Teams, jedoch nicht des Entwicklungsteams.

Selbstorganisierend

Entwicklungsteams haben keine Projektleiter oder Teilprojektleiter. Sie organisieren sich selbst. Es ist die Aufgabe der Organisation beziehungsweise des Unternehmens, alles dafĂŒr zu tun, dass das Entwicklungsteam sich selbst organisieren und managen kann. Es sorgt fĂŒr alle Kompetenzen und Ressourcen, die hierzu erforderlich sind. Die einzige Vorgabe, die das Entwicklungsteam von Product Owner bekommt, ist die Art und die PrioritĂ€t der Produkteigenschaften, die in allen Sprints umgesetzt werden sollen. Diese sind im so genannten Product Backlog gespeichert. Wie das Team die Produkteigenschaften des Sprint Backlogs und die Ziele des Sprints erreicht, ist allein den Teams ĂŒberlassen.

InterdisziplinÀr

Wie beschrieben, arbeiten die Entwicklungsteams interdisziplinÀr. Das bedeutet, dass verschiedene Kompetenzen und FÀhigkeiten innerhalb des Teams vorhanden sind.

Keine Titel

Innerhalb von Entwicklungsteams gibt es keine Titel. Die Rollen innerhalb des Entwicklungsteams sind alle gleichrangig. Titel sind damit nicht relevant. Das bedeutet jedoch nicht, dass es nicht unterschiedliche Aufgabenverteilungen innerhalb des Teams gibt. Diese Aufgabenverteilung ist jedoch stets durch die jeweilige Aufgabe definiert und manifestiert sich nicht durch die Vergabe eines Titels innerhalb des Teams.

Entwicklungsteam bleibt als Ganzes verantwortlich

Das Entwicklungsteam kann zwar Aufgaben innerhalb des Teams mit unterschiedlichen Kompetenzen organisieren, dennoch bleibt es immer als Ganzes fĂŒr die Erreichung des Ziels eines Sprints verantwortlich. Keiner im Entwicklungsteam trĂ€gt mehr oder weniger Verantwortung als ein anderer im Team. Das Team ist immer insgesamt als Team verantwortlich fĂŒr den Erfolg.

Aufgaben des Entwicklungsteams

Die Hauptaufgabe des Entwicklungsteams ist es, das Produkt richtig zu bauen beziehungsweise zu entwickeln. Die Mitglieder des Entwicklungsteams sind die einzigen, die am Inkrement arbeiten. Alle anderen Aufgaben des Entwicklungsteams haben sich dieser Hauptaufgabe unterzuordnen und sind lediglich unterstĂŒtzend, um dies wĂ€hrend des Sprints sicherzustellen.

Es ist wichtig, dass die einzelnen Aufgaben beziehungsweise Tasks an die verschiedenen Mitglieder des EntwicklungsteamÂ ĂŒbertragen werden. Die Aufgabenverteilung innerhalb des Entwicklungsteams nimmt das Entwicklungsteam selbst vor. Im Idealfall arbeiten möglichst viele Mitglieder des Entwicklungsteams immer an einem Backlog Item. Es sollte vermieden werden, dass zu viele Mitglieder des Entwicklungsteams an zu vielen unterschiedlichen Backlog Items parallel arbeiten. Es gilt also das Prinzip der Fokussierung und der priorisierten Abarbeitung nacheinander. Auch bei der Verteilung unterschiedlicher Aufgaben auf verschiedene Mitglieder des Entwicklungsteams bleibt die Verantwortlichkeit beim gesamten Team.

Verantwortung des Entwicklungsteams

Das Entwicklungsteam hat die folgenden Themen zu verantworten:

VerantwortungfĂŒr die Entwicklung des aktuellen Inkrements

Priorisierung der Aufgabenim Entwicklungsteam

Organisation des Daily SCRUM(RĂ€ume etc.)

TĂ€gliche Teilnahme und Mitwirkung im Daily SCRUM

Leitung des Daily SCRUM nach den Regeln von SCRUM

Tracking des Fortschritts im Sprints inklusive Aktualisierung der Tools die hierfĂŒr verwendet -werden (bspw. Taskboard, SprintBurn-down Chart )

Kompetenzen des Entwicklungsteams

Die folgenden Themen gehören zu den Kompetenzen des Teams:

EigentĂŒmer des Sprint Nur das Entwicklungsteam darf VerĂ€nderungen am Sprint Backlog vornehmen. Dies darf sonst niemand anderes im SCRUM-Team.

Entscheidungskompetenz darĂŒber, „wieviel“, also Menge und Umfang im Rahmen des Sprint Plannings

Optimale TeamgrĂ¶ĂŸe des Entwicklungsteams

Optimal sind zwischen drei und neun Teammitglieder. Bei weniger als drei Teammitgliedern besteht die Gefahr, dass eine LĂŒcke bei den FĂ€higkeiten entsteht. Teams, die grĂ¶ĂŸer als neun Personen sind, haben einen sehr hohen Koordinationsaufwand. Bei diesen Berechnungen werden der SCRUM Master und der Product Owner nicht einberechnet. Diese werden nur dann mitgezĂ€hlt, wenn sie auch bei der Abarbeitung der Backlog Items mitwirken. WĂ€hrend des gesamten Prozesses sollte das Entwicklungsteam möglichst aus denselben Personen bestehen. Grund hierfĂŒr ist, dass sich im Rahmen des Prozesses so eine bessere Lernkurve darstellen lĂ€sst. Zudem kann das Gelernte im Rahmen der Interaktion der Teammitglieder besser fortgefĂŒhrt werden.

Die Artefaktescrum-leitfaden_scrum-artefakte

Wie bereits erwÀhnt, gibt es hier drei Artefakte. Diese sind die folgenden: das Product Backlog, das Sprint Backlog und das Inkrement.

Das Product Backlog

Was ist das Ziel des Product Backlogs?

Das Product Backlog ist eine Auflistung aller Produktfeatures, die das Produkt, wenn es entwickelt ist, enthalten soll. Die Produktfeatures im Product Backlog werden Product Backlog Items genannt. Sie sind in einer bestimmten Reihenfolge nach PrioritĂ€t geordnet. Es stellt die einzige Quelle aller Anforderungen an das Produkt und aller Änderungen, die am Produkt vorgenommen werden, dar. Das Product Backlog besteht, so lange das Produkt besteht. Es beinhaltet auch alle bereits abgearbeiteten Backlog Items bzw. Userstories.

Das Product Backlog ist nie vollstĂ€ndig, es lebt wĂ€hrend des gesamten Entwicklungsprozesses und wird stĂ€ndig ĂŒberprĂŒft und angepasst. Die erste Version des Product Backlogs zeigt die anfĂ€nglich nach besten Wissen und Gewissen bekannten Anforderungen. Das Product Backlog verĂ€ndert sich im Zeitverlauf in dem Maße, wie sich der Einsatzbereich des Produkts und auch das Produkt selbst Ă€ndert. Das Product Backlog ist also sehr dynamisch. Es verĂ€ndert sich stĂ€ndig, um festzustellen, was das Produkt erfordert, um angemessen, wettbewerbsfĂ€hig und nĂŒtzlich zu sein.

Wenn ein Produkt existiert, existiert auch ein Product Backlog. So ist die Welt von SCRUM. Das Product Backlog beinhaltet also langfristig alle Features, Funktionen, Anforderungen, Verbesserungen, Änderungen, die in kĂŒnftigen Versionen des Produkts enthalten beziehungsweise umgesetzt werden sollten. Jeder dieser EintrĂ€ge im Product Backlog wird Product Backlog Item genannt. Jedes Product Backlog Item hat mehrere Attribute: Beschreibung, Priorisierung, SchĂ€tzung etc. Meist enthalten Product Backlog Items auch eine Beschreibung der Abnahmekriterien, die im Rahmen der Abnahme durch den Product Owner das „Done“ definieren.

Wer ist fĂŒr das Product Backlog zustĂ€ndig?

FĂŒr das Product Backlog ist der Product Owner zustĂ€ndig. Er hat die Verantwortung, das Product Backlog zu erstellen und es wĂ€hrend des gesamten Prozesses zu pflegen. Er ist insbesondere fĂŒr seinen Inhalt, seine Struktur, die Priorisierung der Backlog Items und seine VerfĂŒgbarkeit zustĂ€ndig.

Wie kommt das Product Backlog zur Anwendung?

Das Product Backlog kommt wĂ€hrend des gesamten Prozesses zur Anwendung. Es stellt zu jeder Zeit die Basis bezĂŒglich der Transparenz des zu entwickelnden Produktes dar. Das Product Backlog ist die Sammlung mehrerer Back­log Items, die letztlich in ihrer Gesamtheit alle Funktionen, die das zu entwickelnde Produkt umfasst. Im ersten Schritt ist ein Product Backlog Item nur die Bezeichnung einer Anforderung wie beispielsweise „Außen-Pool“.

Das Sprint Backlog

Was ist das Ziel des Sprint Backlogs?

Das Ziel des Sprint Backlogs ist, dem Entwicklungsteam transparent zu machen, welche Backlog Items im Rahmen des Sprints wie umgesetzt werden sollen. Zudem gibt es zu jedem Zeitpunkt des Sprints Auskunft ĂŒber den aktuellen Stand der Entwicklungsarbeit des Entwicklungsteams und darĂŒber, welche Aufgaben noch zu erledigen sind, um das Sprint-Ziel zu erreichen. Um eine kontinuierliche Verbesserung sicherzustellen, enthĂ€lt es auch mindestens eine Verbesserungsmaßnahme, die im Rahmen der letzten Sprint Retrospektive als wichtig beziehungsweise als von hoher PrioritĂ€t identifiziert wurde. Das Sprint Backlog ist letztlich eine Teilmenge der Backlog Items aus dem Product Backlog. Die Auswahl dieser Backlog Items aus dem Product Backlog fĂŒr das Sprint Backlog erfolgt im Rahmen des Sprint Plannings.

Wer ist fĂŒr das Sprint Backlog zustĂ€ndig?

Die Verantwortung fĂŒr das Sprint Backlog liegt einzig beim Entwicklungsteam. Alle Anpassungen und VerĂ€nderungen am Sprint Backlog dĂŒrfen nur durch das Entwicklungsteam durchgefĂŒhrt werden. Die Voraussetzung dafĂŒr, dass ein Backlog Item in das Sprint Backlog ĂŒberfĂŒhrt wird, ist erstens, dass es ausreichend detailliert ist. So detailliert, dass das Entwicklungsteam alle Informationen transparent hat, die notwendig sind, um das Backlog Item im Rahmen des Sprints abzuarbeiten. Und zweitens muss das Backlog Item vom Entwicklungsteam fĂŒr den anstehenden Sprint ausgewĂ€hlt worden sein, so dass dieses das Item als umsetzbar bezĂŒglich ihrer eigenen verfĂŒgbaren KapazitĂ€t wĂ€hrend des Sprints einschĂ€tzt.

Wie kommt das Sprint Backlog zur Anwendung?

Das Sprint Backlog enthĂ€lt einen Plan, wie das Inkrement geliefert und damit das Sprint-Ziel erreicht wird. Konkret enthĂ€lt das Sprint Backlog eine Planung des Entwicklungsteams, welche FunktionalitĂ€t das nĂ€chste Produktinkrement sein wird, und ĂŒber die Entwicklungsarbeit, die erforderlich ist, um die FunktionalitĂ€t in ein „Done“ zu ĂŒberfĂŒhren. Dieser Plan muss so detailliert sein, dass er auch im Daily genutzt und verwendet werden kann.

Das Inkrement

Das Inkrement ist das Produkt in seinem aktuellsten Auslieferungszustand inklusive allem, was im aktuellen Sprint umgesetzt wurde.

Was ist das Ziel des Inkrements?

Das Inkrement wird oft auch Produktinkrement genannt. Es umfasst alle Product Backlog Items, die im Rahmen der vergangenen Sprints umgesetzt wurden. Zudem umfasst es den Wert aller Inkremente, die in den vorherigen Sprints umgesetzt wurden. Das Inkrement ist quasi immer das aktuelle Produkt in seinem letzten Release-Zustand. Das Inkrement stellt einen wichtigen Bestandteil und Anteil zur Erreichung des Projektziels oder der Produktvision dar.

Wer ist fĂŒr das Inkrement zustĂ€ndig?

Das Entwicklungsteam ist fĂŒr die Erstellung eines ĂŒbergabefĂ€higen Inkrements zum Ende jedes Sprints verantwortlich. Nach dessen Fertigstellung ist das Inkrement an den Product Owner zu ĂŒbergeben. Der Product Owner ist dafĂŒr zustĂ€ndig, die Entscheidung zu treffen, ob er das Inkrement releasen beziehungsweise in Betrieb nehmen möchte. Er kann das Produkt zwar abnehmen und dennoch entscheiden, dass er es nicht releasen möchte.

Wie kommt das Inkrement zur Anwendung?

Am Ende jedes Sprints ĂŒbergibt das Entwicklungsteam seine Arbeit in Form des auslieferfĂ€higen Inkrements an den Product Owner. Wichtige Voraussetzung der Übergabe ist, dass das Inkrement auslieferfĂ€hig ist. Hierzu gehört, dass es einerseits der „Definition of Done“ des Teams entspricht und auch in einem potenziell auslieferbaren Zustand ist. Diese ÜberprĂŒfung sollte bei einem gut eingespielten Team nicht erst bei Übergabe des Inkrements an den Product Owner erfolgen, sondern schon im Rahmen des Sprints durchgefĂŒhrt werden. Das Inkrement muss releasefĂ€hig sein. UnabhĂ€ngig davon, ob der Product Owner es fĂŒr geeignet hĂ€lt oder nicht.

Unsere Trainings!

Du suchst Trainings, Informationen und Medien – wie zum Beispiel ein Glossar oder relevante Templates – oder Du willst einfach nur wissen, was es mit dem beliebten Framework auf sich hat? Dann bist Du hier vollkommen richtig! SCRUM ist in den letzten Jahren zur fĂŒhrenden Methodik fĂŒr agiles Projektmanagement herangereift. Über 90 Millionen Menschen weltweit arbeiten inzwischen mit der Erfolgsmethodik. Informiere Dich jetzt oder starte noch heute mit einem Training – Du entscheidest. Informiere Dich jetzt oder starte noch heute mit Deinem Training!

Hier bei den Agile Heroes erhĂ€ltst Du Zugriff auf ein Training, das absolut nach scrum.org konzipiert und in zwei Spezifikationen verfĂŒgbar ist: Professional SCRUM Master (PSM I) & Product Owner (PSPO I). Wichtig: Beide Trainings sind sowohl als zweitĂ€gige PrĂ€senz-Schulung sowie als Online-Kurse verfĂŒgbar. Lediglich die darauf aufbauende Professional SCRUM MASTER (PSM II) Schulung wird derzeit ausschließlich als PrĂ€senz-Workshop angeboten. VerĂ€ndere Deine Arbeitsweise, betrachte Herausforderungen viel kreativer und entwickle LösungsansĂ€tze, die nur im Rahmen einer Gruppendynamik realisierbar sind. SCRUM ist bei uns als Training so ausgelegt, dass keinerlei Vorkenntnisse nötig sind. Einfach loslegen und durchstarten!

Rent your own SCRUM Master!

Projekte und deren Erfolg sind stark abhĂ€ngig von der Grundstruktur, der Interaktion zwischen den einzelnen Akteuren. Im Projektmanagement ist AgilitĂ€t nicht nur Ausdruck von einem offenen, transparenten System, sondern Voraussetzung fĂŒr gutes Gelingen. Du benötigst professionelle UnterstĂŒtzung bei einem Projekt? Dann bist du hier genau richtig. Frage jetzt einen unserer Experten als externe Projekt-UnterstĂŒtzung fĂŒr deinen Projekt-Erfolg an. Unsere Berater sind zertifiziert, erfahren und stehen zum Teil schon morgen fĂŒr dich, dein Team, dein Projekt oder dein Unternehmen bereit. Was wir Dir bieten? Eine erfahrene, durch unzĂ€hlige Projekte geprĂ€gte Perspektive auf Dein Vorhaben. Jeder unserer SCRUM Master ist zertifiziert und steht Dir einzeln oder im Team zur VerfĂŒgung, um Dein Entwicklungsteam bestmöglich zu betreuen.

Welche Vorteile bietet ein externer SCRUM Master?

Ein agiles Projektmanagement auf Basis von SCRUM bietet die einmalige Chance, wertvolle Gruppendynamiken zu entfachen. Die Aufgabe des SCRUM Masters besteht darin, als eine Art „Servant Leader“ zu agieren und ein VerstĂ€ndnis dafĂŒr zu schaffen, Interaktion im Team zu optimieren. Mit unserer Hilfe baust Du effektiv Hindernisse ab, skalierst einzelne Aspekte und schaffst die Basis fĂŒr schnelle, konsequente Erfolge.

Du willst mehr erfahren?

Du möchtest mehr erfahren? Sieh Dich einfach auf unserer Webseite um oder nehme direkt Kontakt zu uns auf, um die AGILE HEROES besser kennenzulernen. Wir beraten Dich zum bestmöglichen Einsatz eines externen SCRUM Masters. Egal ob als Einzel-Projektmanager oder im Team, fĂŒr uns ist keine Aufgabe zu komplex. Wirf einen Blick auf die Profile unserer agilen Spezialisten – wir freuen uns, Dich und Dein Unternehmen besser kennenzulernen!

scrum-playbook-big

Dieser Eintrag wurde veröffentlicht am SCRUM und getaggt .