Lesezeit:
20 Min
  1. Home
  2. /
  3. SCRUM
  4. /
  5. SCRUM: Anleitung fĂŒr Einsteiger

SCRUM: Anleitung fĂŒr Einsteiger

von | Okt 21, 2020 | SCRUM | 0 Kommentare

Inhaltsverzeichnis

  1. Einleitung
  2. GrĂŒnde fĂŒr den Erfolg
  3. Grundlagen
  4. Wie funktioniert Scrum?
  5. Unsere Trainings
  6. Agiles Consulting

 

Scrum ist der absolute agile Superstar. 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 85 Prozent aller agilen Projekte wird Scrum angewandt. Obwohl das Scrum Framework bereits vor mehr als 20 Jahren entwickelt wurde, erleben wir in Deutschland erst seit kurzem 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 am Zahn der Zeit: das hierarchische Projektmanagement hat ausgedient. 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 Mitarbeiterinnen und 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 und Experten darangemacht, die Methodik weiterzuentwickeln, zu verĂ€ndern und zu ergĂ€nzen. So entstanden viele Varianten und Abwandlungen von Scrum. Die beiden GrĂŒnder des Frameworks Jeff Sutherland und Ken Schwaber betonen aber in ihrem Scrum Guide, dass das Framework nur in seiner Reinform angewendet den erwĂŒnschten Effekt liefern kann. Der Guide wurde 2010 zum ersten Mal herausgegeben und fasst auf wenigen Seiten die Regeln und Prinzipien des Scrum Frameworks zusammen. Zuletzt wurde er 2020 aktualisiert und hat dabei auch wieder ein paar Seiten abgespeckt. Denn die beiden GrĂŒnder wollen das Framework immer leaner gestalten.

In der RealitĂ€t muss das Framework allerdings oft adaptiert werden, um in allen Branchen und Teams zu funktionieren. Das muss aber jedes Scrum Team fĂŒr sich selbst herausfinden. In dieser Anleitung beschrĂ€nken wir uns deshalb auf die offiziellen Regeln des Frameworks und gehen dabei in die Tiefe.

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

9 von 10 Projekten in Handelsunternehmen, die agil gemanagt werden, werden mit Scrum gemanagt. AgilitĂ€t ist im Trend – und Scrum ist es umso mehr. Weltweit nutzen mehr als 12 Millionen Menschen das Framework als Methode im Projektmanagement. Jedes zweite Großunternehmen setzt auf agile Methoden. 65% der deutschen Unternehmen hĂ€lt Projekte, die agil gemanagt werden fĂŒr erfolgreicher. (https://www.bitkom-research.de/de/pressemitteilung/scrum-koenig-unter-den-agilen-methoden). Die Zahlen sprechen fĂŒr sich, nicht wahr? Doch was ist das Geheimnis hinter dem Erfolg des Frameworks? Wir haben dafĂŒr einige GrĂŒnde gefunden.

Scrum ist einfach …

Scrum besteht aus nur sehr wenigen Regeln und ist somit sehr einfach. Konkret besteht es aus nur drei Verantwortlichkeiten, 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 allerdings auf mittlerweile lediglich 14 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 das Scrum Framework. Wie schon beschrieben, setzen 85 Prozent aller agil gemanagten Projekte Scrum ein. Von MarktfĂŒhrerschaft zu sprechen wĂ€re hier schon untertrieben. Zumal man davon ausgehen kann, dass die 15 Prozent, die von sich behaupten, dass sie nicht Scrum einsetzen, zumindest teilweise Aspekte von 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“ zu Managen und Organisieren an das Team zurĂŒck. Projektmanager und Projektmanagerinnen im klassischen Sinne gibt es nicht mehr. Die Annahme, die dem zugrunde liegt, ist, dass die Teams selbst ausreichend 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 Accountabilities (frĂŒher genannt: Rollen). Jeder und jede respektiert jeden und jede als gleichwertig und kennt die eigene Rolle ganz genau. So funktioniert Scrum.

Scrum ist pragmatisch …

Scrum kommt mit erstaunlich wenig Administration aus. Denkt man daran, wie viel Energie klassischen Wasserfall-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 GrĂŒnder 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 grĂ¶ĂŸ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 GrĂŒndern 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 des Frameworks 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 erfolgreichen Framework ihren wirtschaftlichen Anteil abhaben wollten. So wurde der Kern dessen, was Scrum ausmacht, immer stĂ€rker verfĂ€lscht. Dieses Problem haben auch die beiden Scrum-GrĂŒnder, Jeff Sutherland und Ken Schwaber, erkannt und aus diesem Grunde im Jahr 2010 den Scrum-Guide veröffentlicht. Dieser wurde letztmalig in Jahr 2020 ĂŒ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 regelmĂ€ĂŸig ĂŒberprĂŒft werden. In einem nach Scrum gemanagten Projekt bedeutet dies, dass das Team in regelmĂ€ĂŸigen AbstĂ€nden 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 behindert. 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 Rahmenbedingungen, um nach jedem Sprint 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 kurzfristig, ohne unnötigen Zeitverzug entschieden werden, um unnötige weitere Abweichungen 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. Wir finden, hier ist es jedem Scrum-Team selbst ĂŒberlassen, wie es diese Values konkret 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, wie gesagt 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-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 der Methode ist 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-rules
Accountabilities

Die Accountabilities regeln die Aufgaben jedes einzelnen Teammitglieds, je nachdem, welche der drei festgelegten Accountabilities jemand einnimmt. Jede Verantwortlichkeit hat konkrete Aufgaben, Rechte und Pflichten. Die drei Accountabilities, die frĂŒher Rollen genannt wurden sind: Product Owner, Scrum Master und Developers.

Artefakte

Dies sind bestimmte Tools und Techniken, die die Anwendung von Scrum erfolgreich machen und notwendig sind, den Projektablauf effizient zu gestalten. Die Artefakte sind: Sprint Backlog, Product Backlog und Inkrement.

Events

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

Rules

Regeln bestimmen das Zusammenspiel und die Wechselwirkungen der Accountabilities, 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 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 hingegen durchaus Sinn machen.

Die einzelnen Accountabilities 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.

Charakteristik von Events

Events nach Scrum haben eine ganz spezielle Charakteristik, die Events nach Scrum erst „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 vorgesehen. 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.

Der Sprint

Das Ziel des Sprints ist es, die jeweiligen Ziele beziehungsweise das jeweilige Ziel, das sich die Developers fĂŒr den jeweiligen Sprint vorgenommen haben, 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, die Developers (Entwickler*innen) 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 die Developers. 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 die Developers die Aufgaben nacheinander abarbeiten und im Idealfall gemeinsam und gleichzeitig am gleichen Backlog Item arbeiten. 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 die Developers abstimmen und synchronisieren.

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. Die Developers besprechen hierbei den Fortschritt der letzten 24 Stunden mit Hinblick auf das Sprint-Ziel. 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 die Entwicklerinnen und Entwickler das Sprint-Ziel auch erreichen.

Die Agenda des Events wird von den Developers 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 Developer Teams, die strukturierte Fragen nutzen, wie die folgenden:

  1. „Was habe ich gestern fĂŒr die Developers getan, um das Sprint-Ziel zu erreichen?“
  2. „Was werde ich heute fĂŒr die Developers tun, um das Sprint-Ziel zu erreichen?“
  3. „Gibt es irgendwelche Hindernisse, die mich oder die Developers dar­an hindern, das Sprint-Ziel zu erreichen?“

Andere Developer Teams 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:

  • Die Developers stellen die Arbeit vor, die erledigt, „Done“ ist und beantworten Fragen ĂŒber das Produktinkrement.
  • Der Product Owner lĂ€utert, welche Items des Product Backlog erledigt, also „Done“ sind und welche nicht.
  • Der Product Owner diskutiert 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-Team und 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ĂŒfung des 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 zur erzielten 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 nimmt 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 oder sie alle Teilnehmen dazu anhalten, dass das Event im geplanten Zeitrahmen bleibt.

Die folgenden Ziele des Events bestimmen seine Agenda:

  • ÜberprĂŒfung des vergangenen Sprints mit Fokus auf die Menschen, Beziehungen, Prozesse und Tools.
  • Identifikation und Strukturierung der Themen, die gut gelaufen sind, und potenzieller Verbesserungsfelder.
  • Erstellung eines Plans, um die Verbesserungsfelder umzusetzen.

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 Accountabilities

Scrum kennt eine sehr einfache und ĂŒbersichtliche Definition der unterschied­lichen Accountabilities im Rahmen des Scrum-Frameworks. FĂŒr jede dieser Verantwortlichkeiten 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 Verantwortlichkeit er oder sie hat und welche Erwartungen an diese (frĂŒher genannt) Rolle gestellt werden. Dies ist notwendig, um Scrum erfolgreich umzusetzen. WĂ€hrend die Werte nach Scrum fĂŒr alle Mitglieder des Scrum-Teams gelten, so definieren die Accountabilities fĂŒr jedes einzelnes Teammitglied andererseits ganz konkret und individuelle Aufgaben.

Das Scrum-Team

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 und bestehen aus maximal 10 Personen.

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Ă€ger*innen 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.

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: Kund*innen, Benutzer*innen, Management.

Überblick der Scrum Accountabilities

Weitere Accountabilities 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 UrsprĂŒnge 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 Accountabilities, welche sich auch als absolut ausreichend zum Management eines agilen Projekts erwiesen haben.

Scrum kennt im Kern also nur drei Accountabilities: den Product Owner, den SCRUM Master und die Developers. Die Hauptaufgaben dieser Accountabilities 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.
  • Developers/Entwickler*innen: Die Developers entwickeln das Produkt. Sie sind verantwortlich dafĂŒr, sich selbst so zu organisieren, um das jeweilige Ziel des Sprints zu erreichen. Die Entwicklerinnen und Entwickler sind zusammen das HerzstĂŒck von Scrum. Sie sind 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 den Developers 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 der Developers optimieren
  • Product Owner kann diese Aufgaben alleine erfĂŒllen oder delegieren
  • Product Owner bleibt 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-Team den Developers 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 Backlog fest bzw. priorisiert sie.
Verantwortung des Product Owners

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

  • Verantwortung fĂŒr den finanziellen Erfolg des Produktes
  • Wertmaximierung des Produktes allgemein und in jedem Sprint
  • Management und Pflege des Product Backlogs
  • EintrĂ€ge im Product Backlog mĂŒssen klar formuliert werden
  • EintrĂ€ge im Product Backlog sollen so sortiert werden, dass Ziele und Missionen optimal erreicht werden
  • Die gesamte Organisation muss den Product Owner respektieren
  • Entscheidungen des Product Owner mĂŒ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 den Developern 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 Vorgaben von Scrum ablĂ€uft.

Aufgaben des Scrum Masters

Der Scrum Master wird auch als „Servant Leader“ bezeichnet. Übersetzt heißt dies, dass er oder sie 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 Event-Strukturen nach den Regeln von Scrum zu gestalten. Hierbei ist seine Rolle die eines Coachs beziehungsweise eines Moderators.

Der Scrum Master 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

Die Rolle des Scrum Master ist dafĂŒr verantwortlich, dass alle Beteiligten die Scrum-Theorie, Praktiken, Regeln und Werte verstehen. Der Scrum Master verbreitet also die Scrum Botschaft innerhalb der Organisation.

Kompetenzen des Scrum Masters

Ein 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 Scrum Masters

Der Scrum Master ist somit ein RegelhĂŒter im Rahmen des Prozesses. Er oder sie 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 oder sie fungiert hierbei als Moderator*in und Coach. Dies bedeutet, dass der Scrum Master zu keiner Zeit als Projektmanager oder Projektleiter agiert; die Aufgabe ist lediglich unterstĂŒtzend im Scrum-Prozess. Das Ziel ist es, das Team zu befĂ€higen, nach den Regeln zu arbeiten und effizient zu sein.

Die Developers 

Die Developers sind fĂŒr das „Wie“ verantwortlich: Wie wird das Produkt entwickelt und umgesetzt?

Charakteristiken der Developers

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

TeamgrĂ¶ĂŸe

Die Developers bilden zusammen ein Team bestehend aus 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 der Developers.

Selbstorganisierend

Die Developers haben keine Projektleiter oder Teilprojektleiter. Sie organisieren sich selbst. Es ist die Aufgabe der Organisation beziehungsweise des Unternehmens, alles dafĂŒr zu tun, dass die Developers sich selbst organisieren und managen können. Es sorgt fĂŒr alle Kompetenzen und Ressourcen, die hierzu erforderlich sind. Die einzige Vorgabe, die die Entwicklerinnen und Entwickler von dem 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 die Developers die Produkteigenschaften des Sprint Backlogs und die Ziele des Sprints erreichen, ist allein den Teams ĂŒberlassen.

InterdisziplinÀr

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

Keine Titel

Innerhalb der Developers 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 der einzelnen Developers gibt. Diese Aufgabenverteilung ist jedoch stets durch die jeweilige Aufgabe definiert und manifestiert sich nicht durch die Vergabe eines Titels innerhalb der Developers.

Die Developers bleiben als Ganzes verantwortlich

Die Entwicklerinnen und Entwickler können zwar Aufgaben innerhalb des Teams mit unterschiedlichen Kompetenzen organisieren, dennoch bleiben sie immer gemeinsam fĂŒr die Erreichung des Ziels eines Sprints verantwortlich. Keiner der Developers trĂ€gt mehr oder weniger Verantwortung als ein anderer im Team. Sie sind immer gemeinsam als Team verantwortlich fĂŒr den Erfolg.

Aufgaben der Developers

Die Hauptaufgabe der Developers ist es, das Produkt richtig zu bauen beziehungsweise zu entwickeln. Die Developers sind die einzigen, die am Inkrement arbeiten. Alle anderen Aufgaben der Developers 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 Developers ĂŒbertragen werden. Die Aufgabenverteilung unter den Entwickler*innen nehmen diese selbst vor. Im Idealfall arbeiten möglichst viele der Developers 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 der Developers bleibt die Verantwortlichkeit beim gesamten Team.

Verantwortung der Developers

Die Developers haben die folgenden Themen zu verantworten:

  • Verantwortung fĂŒr die Entwicklung des aktuellen Inkrements
  • Priorisierung der Aufgaben der einzelnen Developers
  • 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 der Developers

Die folgenden Themen gehören zu den Kompetenzen der Developers:

  • EigentĂŒmer des Sprint Backlogs. Nur das Entwicklungsteam darf VerĂ€nderungen am Sprint Backlog vornehmen.
  • Entscheidungskompetenz darĂŒber, „wie viel“, also Menge und Umfang im Rahmen des Sprint Plannings
Optimale Anzahl an Developers

Optimal sind zwischen drei und neun Developers. Bei weniger als drei 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 sollten die Developers 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 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, den Developers 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 der Developers 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 bei den Entwicklerinnen und Entwicklern. Alle Anpassungen und VerĂ€nderungen am Sprint Backlog dĂŒrfen nur durch die Developers 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 die Developers alle Informationen transparent haben, 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?

Die Developers sind 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 ĂŒbergeben die Developers ihre 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!

Du möchtest die Scrum Zertifizierung ablegen?

Ein 2-tĂ€giges Scrum Training ist die perfekte Vorbereitung, um eine erfolgreiche Scrum PrĂŒfung zu absolvieren. Mit einem Training bei den Agile Heroes erlernst Du an 2 Tagen die vollstĂ€ndige Scrum Theorie, spannende Praxiseinblicke und hilfreiche Tipps fĂŒr die PrĂŒfung! Und das von jahrelang erfahrenen Scrum Mastern und Agile Coaches!

Beitrag teilen:
Agile-Heroes-Logo

Willkommen bei den Agile Heroes – deinen Experten fĂŒr agiles Projektmanagement. Wir sind einer der MarktfĂŒhrer fĂŒr agile Trainings und Coachings.

Beitrag teilen:
Scrum Training
Scrum Training

So hast Du noch nie gelernt

HOL DIR DAS GRATIS PLAYBOOK

Formular

ÄHNLICHE BEITRÄGE

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.