Mit maximaler Geschwindigkeit und Flexibilität zu einem nutzbaren Produkt – das ist, wofür Scrum steht. Sie haben von Scrum noch nicht gehört? Macht nichts. Kurzum handelt es sich um einen bewährten Standard für agiles Projektmanagement, der ursprünglich aus dem Bereich der Softwareentwicklung kommt. In der Fachsprache des Projektmanagements spricht man auch von einem Framework. Es hilft dabei, die Anforderungen eines Projektes zu priorisieren und diese dann gemäß ihrer Priorität nach und nach in Sprints umzusetzen. So erreichen Sie genau das, was der Einstieg des Artikels plakativ vorgibt. Außerdem erhöht Scrum die Produktivität und die Zufriedenheit Ihrer Mitarbeiter. Möchten Sie Scrum kennenlernen und verstehen? Mithilfe dieses Artikels steigen Sie einfach und fachlich korrekt in das Framework ein. Danach werden Sie in der Lage sein, zu beurteilen, ob die Projektmanagement-Methode etwas für Sie ist oder nicht – und wenn ja, dann werden Sie diese unmittelbar in Ihrem Unternehmen anwenden können.

Dieser Artikel ist geeignet für: Jeden, der schon einmal von Scrum gehört hat und sich näher damit beschäftigen möchte, um es gegebenenfalls im eigenen Unternehmen anzuwenden.

Schwierigkeitsgrad:*1234

*Vorausgesetzt werden Kenntnisse im Projektmanagement und dessen praktischer Anwendung. Wir empfehlen, vorab die verlinkte Lektüre hierzu zu lesen.

Scrum in Kürze

 

  • Scrum ist keine Methode, sondern ein Framework, in dem sich die Mitarbeiter eines Teams weitestgehend frei bewegen können.
  • Ein Scrum-Team besteht immer aus einem Product Owner, einem Scrum Master und dem nicht-hierarchischen Entwicklungsteam.
  • Das Entwicklungsteam besteht aus Fachleuten für die einzelnen Umsetzungsbereiche, ist allerdings auch interdisziplinär ausgebildet.
  • Scrum ist nicht auf die Softwareentwicklung beschränkt, hat hier aber seinen Ursprung. Es kann domänenunabhängig eingesetzt werden. So können Entwicklungsteams auch aus Marketing-, Finanz- oder Einkaufsexperten bestehen.
  • Der Ablauf eines Projektes ist durch zwei- bis vierwöchige Sprints sowie durch eine ausgeprägte Austauschkultur mit Meetings gekennzeichnet.
  • In der Regel werden bei den Sprints zunächst „Minimum Viable Products“ entwickelt, also  inkrementelle Versionen des zu entwickelnden Produkts.
  • Bei Scrum gibt es originär keine definierten Methoden. Allerdings stellen Tools wie die klassischen Klebezettel oder das Planungspoker einen Quasi-Standard dar.
  • Mit Offenheit, Mut, Respekt und Fokussierung setzt das Framework vier Grundwerte voraus, um den Projektmanagement-Prozess erfolgreich umsetzen zu können.
  • Scrum ist eine exzellente Art des Projektmanagements, aber es hält auch Risiken vor.

Was versteht man unter Scrum und wofür ist es gut?

Die Methodik von Scrum basiert auf einem Framework, das in den frühen 90er Jahren von den Amerikanern Jeff Sutherland und Ken Schwaber entwickelt wurde. Sie hatten die Idee, Projektabläufe aus den starren Strukturen des klassischen Projektmanagements herauszuheben und flexibler zu machen. Gleichermaßen sollten Projektanforderungen priorisiert werden, um wichtige Entwicklungen den unwichtigeren vorziehen zu können. Dazu später noch mehr. Scrum wurde für den Softwarebereich entwickelt, zog danach aber auch in viele andere Branchen ein. Die Methode funktioniert in allen Branchen und Unternehmen, in denen ein agiles Projektmanagement vorteilhaft ist. Das ist der Fall, wenn die Unsicherheit bezüglich externer Marktgegebenheiten und / oder des konkret anzuwendenden Verfahrens groß ist. Scrum zeichnet sich durch schnelle agile Umsetzungsschritte aus, die zu belastbaren Erfahrungswerten führen und Klarheit über die Unsicherheiten schaffen.

Hinweis: In unserem Beispiel eines Staudammbaus sowie im Beispiel zur Hamburger Hochbahn wird deutlich, dass insbesondere in der Baubranche kein agiles Projektmanagement funktioniert. Sehen Sie hiervon unbedingt ab, wenn Sie in der Baubranche arbeiten und passende Projektmanagement-Methoden evaluieren.

Scrum ist die weitverbreitetste agile Projektmanagement-Frameworks, die allerdings ohne einen klassischen Projektmanager auskommt. Internet-Startups sind zum Beispiel typische Kandidaten für agiles Projektmanagement mit Scrum. Oder wie erklären Sie sich den bahnbrechenden und schnellen Erfolg von Facebook oder Google? Geht es um Software, digitale Innovationen und kreative Dienstleistungen, dann ist Scrum in der Regel nicht weit entfernt. Im Bereich des agilen Projektmanagements fällt neben dem Namen des Frameworks auch immer wieder der Begriff „Kanban“. Dabei handelt es sich um eine Projektmanagement-Methode, die sich in dieses Framework einbinden lässt oder auch allein stehen kann. Ob sich Ihr Unternehmen ausschließlich Kanban, beiden oder nur Scrum annehmen sollte, hängt vom spezifischen Anwendungsfall und auch vom Unternehmen selbst ab. Dazu später noch mehr.

Eine Einführung in die Akteure und die Scrum-Struktur

Der Aufbau von Scrum besteht aus drei Rollen, fünf sich wiederholenden Ereignissen und zwei Listen. Die drei Rollen sind der Product Owner, der Scrum Master und das Development Team. Auch hier ist wieder der Einfluss der Softwarebranche zu spüren. Das Development Team kann kurz auch einfach Team genannt werden, womit es branchenübergreifend funktioniert. Diese drei Rollen durchlaufen immer wieder den Daily Scrum, das Sprint-Planning-Meeting, den Sprint selbst, das Sprint-Review-Meeting und die Sprint-Retrospektive. Dabei stehen mit dem Product Backlog und mit dem Sprint Backlog zwei Listen stets im Fokus der Arbeit.

Scrum-Akteure

Am Ende eines Projektes soll ein Produkt stehen. Für dieses Produkt ist der Product Owner verantwortlich. Er definiert die Anforderungen seines Produkts und ist als Ergebnisverantwortlicher des Projekts fest in diesem verankert. Mit Blick auf das klassische Projektmanagement, ist der Product Owner am ehesten mit dem Projektleiter zu vergleichen. Er nimmt nicht an der täglichen Projektumsetzungsarbeit teil, sondern ist weiter entfernt und führt über Vorgaben.

Die Rolle des Scrum Masters mag im ersten Moment fragwürdig klingen. Dabei handelt es sich um einen zertifizierten Coach, die darauf achtet, dass während des Projekts sämtliche Leitlinien von Scrum beachtet und eingehalten werden. Außerdem kümmert sie sich darum, den Scrum Prozess innerhalb des Unternehmens stets zu optimieren und Hindernisse zu erkennen sowie zu vermeiden. So hält er dem Development Team den Rücken frei, damit es sich auf die Ziele des Projekts konzentrieren kann. Um das Zertifikat zu erhalten, muss man sich tatsächlich zum Scrum Master ausbilden lassen. Und dass es ihn braucht, lässt auch darauf schließen, dass Scrum keine ganz einfache Methode ist, die sich nebenbei einführen und umsetzen lässt. Zwar kann jeder das Grundprinzip von Scrum interpretieren und anwenden. Wenn es jedoch in die tiefsten Details des Frameworks geht, ist der Einsatz eines Scrum Masters von Vorteil.

Das Development Team ist zum Schluss die Organisation aus allen Mitarbeitern, die an der Entwicklung des Produkts beteiligt sind. In der Regel besteht es aus fünf bis neun Mitgliedern, die alle eine Fachkraft für ihren jeweiligen Bereich darstellen. So ist das Team in der Lage, sich multidisziplinär selbst zu steuern und alle erforderlichen Aufgaben des Sprints zu übernehmen. Diese große Eigenverantwortung des Teams ist eine Besonderheit von Scrum. Im Gegensatz zu anderen Projektmanagement-Methoden gibt es hier keinen Projektmanager, der das Team zentral steuert und die Aufgaben verteilt.

Weitere Akteure

Neben den drei Hauptrollen in Scrum können noch weitere Akteure in dem Prozess eine Rolle spielen. Etwa externe Kunden, Manager, Stakeholder oder sogar die Öffentlichkeit und Behörden. Das kommt ganz auf das Projekt an. 

Sprints & Meetings

Der Prozess von Scrum wird durch Sprints und viele Meetings charakterisiert. Sprints sind die Arbeitsphasen, in denen jeweils eine Produktneuerung entwickelt und abgeschlossen wird. Dafür stehen zwei bis maximal vier Wochen bereit, je nach Zeitbedarf, den das Development Team eigenständig einschätzt. Der Product Owner gibt die Anforderungen an den Sprint vor. Das geschieht in Form eines Sprint-Planning-Meetings, das vor jedem Sprint einmal stattfindet. Grundsätzlich werden in den ersten Sprints eines Projekts die wichtigen Produkteigenschaften umgesetzt. Entwicklungen, die für das Produkt nicht von wesentlicher Bedeutung sind, verschiebt man auf hintere Sprints. Normalerweise ist das gesamte Team bei einem Sprint involviert. Zwar besteht das Team aus Fachkräften für jeweils einen Bereich, doch die Mitglieder können dank interdisziplinärer Ausbildung zwischenzeitlich auch die Aufgaben von anderen übernehmen.

Scrum Sprint ZeichnungEin Sprint ist stets ummantelt von einem Sprint-Planning-Meeting sowie von einem Sprint-Review-Meeting und einer Sprint-Retrospektive. Im vorbereitenden Meeting definiert der Product Owner zusammen mit dem Team die Ziele des bevorstehenden Sprints. Aus diesen Zielen leitet das Development Team seine Aufgaben ab, um diese anschließend intern zu planen und zu verteilen. Das Sprint-Review-Meeting findet nach Abschluss des Sprints statt. Hier stellt das Team seine Ergebnisse vor, normalerweise am Live-System und ohne Präsentation und man bespricht diese Ergebnisse. Im Anschluss daran kommt das Team in einer Sprint-Retrospektive zusammen. Sie ist dazu da, festzustellen, was im vergangenen Sprint gut gelaufen ist und was nicht. Gemeinsam mit dem Scrum Master beschließt das Team Maßnahmen, um kommende Sprints zu optimieren.

Das Daily Scrum ist abschließend ein tägliches Meeting, in dem sich das Development Team synchronisiert. In 15 Minuten werden die Aufgaben besprochen, denen sich jeder einzelne nachfolgend annimmt. So wissen alle Beteiligten, was die anderen machen. Ausführliche Problembesprechungen werden idealerweise in die Retrospektive verschoben, sofern sie sich verschieben lassen. Bei dringenden Problemen werden separate Besprechungen mit einem flexiblen Teilnehmerkreis angesetzt. Das Daily Scrum dient zur Ansprache derartiger Aspekte, auch der Scrum Master nimmt hieran teil.

Backlogs

Mit dem Product Backlog und dem Sprint Backlog existieren zwei zentrale Dokumente, die im gesamten Projektverlauf eine Rolle spielen. Das Product Backlog gehört zum Product Owner. Er pflegt und priorisiert darin die Anforderungen, Funktionen und Features des Produkts, die dann in Sprints verpackt zur Arbeitsgrundlage für das Entwicklungsteam werden. Teile des Product Backlogs werden in das jeweilige Sprint Backlog übernommen. Das heißt, der Product Owner schreibt auf, was ihm für das Produkt im nächsten Schritt wichtig ist. Das Development Team (oder auch eine andere Rolle) übersetzt diese Punkte dann in die zu erledigenden Aufgaben.

Wichtige Merkmale von Scrum

  • Das Development Team organisiert sich allein, es gibt weder einen Projektmanager noch Anweisungen zur genauen Aufgabenbearbeitung – einzig die Anforderungen an Ergebnisse werden durch den Product Owner vorgegeben
  • In einem Scrum-Team herrscht eine hohe Interaktionskultur mit vielen Meetings
  • Ein Sprint mit der Entwicklung eines sogenannten Inkrements dauert zwei bis maximal vier Wochen
  • Planungen beziehen sich ausschließlich auf den jeweils folgenden Sprint, eine Planung über den folgenden Sprint hinaus gibt es nicht
  • Neben dem kleinen Scrum-Team gibt es keine weiteren Sub-Teams oder Beteiligten, außerdem gibt es keine besonderen Personentitel innerhalb des Teams, die Hierarchien sind äußerst flach

Was hat es mit dem „Minimum Viable Product“ auf sich?

Das „Minimum Viable Product“ ist ein Kernbestandteil von Scrum und seinen Entwicklungsprozessen. Dabei handelt es sich um den geringsten Reifegrad eines Produkts, das aber schon  marktreif ist. Dementsprechend bietet es dem Kunden einen Mehrwert, für den er eine Zahlungsbereitschaft besitzt. Das MVP ist häufig auf seine absoluten Grundanforderungen und die nötigsten Funktionen minimiert.

Scrum Minimum Viable Product ReviewBei der Entwicklung einer Landingpage einer Webseite könnte das MVP beispielsweise ein einfaches Dokument sein, aus dem die groben Strukturen und Funktionen der Seite hervorgehen. Ohne, dass das Dokument aber mit allen Texten, Bildern und Designdetails befüllt ist. Dieses Produkt hat gewiss noch viel Potenzial nach oben, kann aber bereits veröffentlicht werden. Durch die frühe Herausgabe von MVPs erhält ein Unternehmen wichtiges Feedback zu den gewünschten Produkteigenschaften. Dieses Feedback kommt vom Markt beziehungsweise bei internen MVPs von anderen Mitarbeitern, die als interne Kunden fungieren. Schließlich ist es weitaus ärgerlicher, wenn der Auftraggeber beim fertigen Produkt nach dem Sprint viele Sachen geändert haben möchte, als wenn die Änderungswünsche zwischendrin bereits klar werden. Das Minimum Viable Product kann während des Sprints beispielsweise auf einer Testumgebung vorgestellt werden. Denkbar ist im Falle einer solchen Landingpage sogar, dass jeden Abend eine geupdatete Version der Seite hochgeladen wird, die man sich ansehen kann.

Außer für Feedbackzwecke ist das MVP in Scrum auch sehr gut für eigene Testzwecke innerhalb des Entwicklungsteams geeignet. So kann es anhand eines rudimentären Ergebnisses testen, ob das Konzept wie geplant aufgeht oder ob es noch Veränderungen braucht. Das Team ist in seiner Arbeitsweise und im Finden der Zwischenaufgaben absolut frei. Es kann also testen und optimieren so viel es möchte. Der Vorteil von einem Minimum Viable Product ist gleichzeitig einer der Hauptvorteile von Scrum. Nämlich, dass es Zeit und Geld spart sowie das Risiko des Scheiterns aufgrund einer zu starren Planung minimiert.

Welche Methoden werden in Scrum angewandt?

Tatsächlich gibt es in Scrum keine direkten Methoden, Vorlagen, Werkzeuge oder gar Softwares. Scrum ist vielmehr ein Framework für agiles Projektmanagement im Unternehmen. Eine grundsätzliche Linie wird ausschließlich mit Vorlagentypen vorgegeben, die es konsequent umzusetzen und einzubinden gilt.

  • Product Backlog: Es enthält wie oben beschrieben alle möglichen Produktmerkmale und deren Prioritäten, wobei die im nächsten Sprint umzusetzenden Features eine besonders hohe Detaildichte besitzen – das Backlog ist dynamisch und wird während des gesamten Projekts immer wieder angepasst
  • Sprint Backlog: Es enthält wie ebenfalls oben beschrieben alle wesentlichen Eigenschaften des Produktes, die es im aktuellen Sprints umzusetzen gilt
  • Inkrement: Hierbei handelt es sich um die Entwicklungsstufe des Projekts nach jeweils einem abgeschlossenen Sprint

Neben den  Vorlagetypen gibt es bestimmte Tools, die in den Teams häufig angewandt werden.

Klebezettel

Scrum KlebezettelSofern Sie Scrum in Ihrem Unternehmen einführen, sollten Sie darauf achten, eine ausreichende Menge an Klebezetteln auf Lager zu haben. In den Scrum-Meetings spielen sie eine wichtige Rolle. Die Teilnehmer notieren Fragen, Anmerkungen und Aufgaben auf ihnen und kleben sie an ein Board. Dort werden die Klebezettel gemeinsam geordnet, gerne auch mithilfe der Kanban-Methodik. Abgeschlossene Punkte werden wieder entfernt, neue aufkommende Punkte dazu geklebt. Nach den Meetings bleiben die Zettel normalerweise kleben, um sie beim nächsten Mal wieder aufzugreifen. Kurioserweise finden Klebezettel trotz ihrer sehr weiten Verbreitung in Scrum-Teams keine Erwähnung im Scrum-Guide. Übeigens spielen Klebezettel auch bei der Methodik von Kanban eine zentrale Rolle.

Elektronische Aufgabensysteme

Neben diesen papierhaften Tools kommen in fast allen Teams elektronische Aufgabensysteme zum Einsatz. Das am meisten verwendete Tool nennt sich Jira. In Jira kann das Team während des Sprints Aufgaben definieren, mit Deadlines sowie Prioritäten versehen und sie einzelnen oder auch mehreren Mitgliedern des Teams zuweisen. Das Tool bildet so eine zentrale Schnittstelle innerhalb des Teams, auch die Nutzung von Trello ist denkbar, wobei sich dieses Tool stark an der Kanban-Methodik orientiert und hier nur zur Aufgabenorganisation anzuwenden wäre, nicht als ganzheitliche Projektmanagement-Methode. Arbeitsergebnisse können hier hochgeladen und geteilt werden. Selbstverständlich gibt es noch weitere Tools, die in Ihrem Unternehmen genutzt werden könnten. In der Regel haben Ihre Mitarbeiter schon mit verschiedenen Tools gearbeitet und werden sich gemeinsam für eines davon entscheiden. Letztendlich ist das Tool nur zur Nutzung innerhalb des Scrum-Teams gedacht und nicht für das gesamte Unternehmen. Sie können Ihr formiertes Team deshalb „einfach machen lassen“.

Impediment Backlog

Inoffiziell gibt es in Scrum außerdem noch ein weiteres Backlog, welches Sie auch als das gemeinsame Backlog des Scrum Masters und des Entwicklungsteams beschreiben können – das Impediment Backlog. Hierin hält das Team etwaige Hindernisse fest, die es bei der effizienten Erledigung seiner Aufgaben oder beim Erreichen des Sprint-Ziels gestört haben. Es ist die Aufgabe des Teams, beim Daily Scrum oder in der Retrospektive von den Hindernissen zu berichten. Sie werden dann in das Impediment Backlog aufgenommen und der Scrum Master hat sich zusammen mit dem Team darum zu kümmern, die Hindernisse zu beseitigen und so eine stets effiziente und zielführende Arbeit zu gewährleisten.

Planungspoker

Scrum PlanungspokerBeim Planungspoker findet innerhalb des Scrum-Teams eine Art kleines Kartenspiel statt. So sehr der Begriff aber auch an Glücksspiel erinnert, hat er mit diesem nichts gemein. Genauso ist das „Kartenspiel“ nicht zu Belustigungszwecken gedacht. Es geht vielmehr darum, den Aufwand einzelner Aufgaben innerhalb eines bevorstehenden Sprints einzuschätzen, um so wiederum die erforderliche Dauer dieses Sprints festzulegen. Das Planungspoker ist demnach Bestandteil des Sprint-Planning-Meetings. Im Mittelpunkt stehen Karten mit sich steigernden Zahlenwerten. Jedes Mitglied des Scrum-Teams erhält einen Kartensatz. Dann nennt idealerweise der Product Owner eine Aufgabe und die anderen wählen eine der Karten aus. Karten mit hohen Zahlenwerten bedeuten „hoher Aufwand“, Karten mit kleinen Zahlenwerten bedeuten „niedriger Aufwand“. Jeweils zwei Personen mit den niedrigsten und höchsten Karten erläutern, weshalb sie sich für diese Karten entschieden haben. So entsteht eine Diskussion und es entstehen auch Mittelwerte. Diese Mittelwerte werden herangezogen, um den Sprint zeitlich einzugrenzen und zu kalkulieren.

Projektmanagement-Methoden

Neben den anderen Tools ist es dringend zu empfehlen, auch die typischen (paradigmenunabhängigen) Methoden des Projektmanagements anzuwenden und einzubinden. So sind eine realistische Budgetsteuerung, ein stringentes Risikomanagement und ein Turnus für Lenkungsausschüsse auch bei Scrum unbedingt erforderlich beziehungsweise mindestens zu empfehlen. Es ist so, dass die Inhalte und Risiken beim Projekt an sich liegen und nicht bei der verwendeten Methodik, dieses umzusetzen. Scrum ist nur das Framework um ein Projekt herum. Der Kern dieses Projektes bleibt aber gleich. Auch wenn es in Scrum keinen Projektmanager gibt, so sollte der Product Owner das Wissen und die Methoden eines Projektmanagers beherrschen. Denn auch bei Scrum sollte zwischen dem Ergebnis, der Zeit und den Kosten stets eine gesunde Balance herrschen. Wenn Sie sich noch nicht sicher sind, ob Sie ein agiles Projektmanagement dem klassischen Projektmanagement vorziehen sollten, lesen Sie in diesem Artikel Dort finden Sie auch ein umfangreiches Projektbeispiel aus dem Bauwesen.

Das Projektbeispiel aus dem Bauwesen zeigt auch, dass in einigen Fällen kein agiles Projektmanagement möglich ist. Wenn es um die Errichtung eines Hochhauses geht, steht (plakativ beschrieben) von vornherein fest, wann man das Fundament gießt, die Wände hochzieht, ein Dach draufsetzt und die Fenster und Türen einbaut. Ein agiles Projektmanagement wäre hier fehl am Platz und insbesondere Scrum wäre es. So ist Scrum und agiles Projektmanagement ausschließlich für Unternehmen geeignet, die etwas mit Digitalisierung und Softwareentwicklung zu tun haben beziehungsweise in deren Branche agile Prozesse grundsätzlich denkbar sind, weil sich Arbeitsergebnisse auf mehreren verschiedenen Wegen erreichen lassen.

Welche Regeln und Werte sind in Scrum einzuhalten?

Scrum Werte und Regeln PPTDie genaue Methodik, wie das Scrum-Team mit diesen Vorlagetypen und Tools arbeitet, entscheidet es selbst. Nur von wenigen Grundregeln wird es dabei „eingeschränkt“. Wobei die Regeln auf die Meetings abzielen und nicht auf die Arbeitsweisen. So zählt im Projektmanagement mit Scrum beispielsweise das sogenannte Timeboxing. Das bedeutet, dass alle Meetings pünktlich anfangen und pünktlich enden sollen. Außerdem darf das Daily Scrum nicht länger als 15 Minuten dauern und die Sprints dürfen nur mindestens zwei und maximal vier Wochen gehen. In den Sprints selbst kann sich das Development Team seine Zeit frei einteilen, aber drum herum in den Meetings herrscht Disziplin. Auch was den Treffpunkt angeht. Denn Meetings haben immer am selben Ort stattzufinden und zudem öffentlich oder mindestens einem breiten Interessentenkreis zugänglich zu sein.

Bis hierhin sind die Regeln tatsächlich nicht im offiziellen Framework-Guide enthalten, die nachfolgenden Grundwerte dagegen schon. In Scrum existieren vier Grundwerte, die das Team zu leben und seine Arbeitsweise auszuzeichnen haben. Nur dann geht der Ansatz dieses agilen Projektmanagements auf.

Offenheit

Einerseits muss jeder einzelne offen für neue Herangehensweisen und Denkweisen sein. Andererseits betrifft das auch die Transparenz im Umgang mit Informationen. Nur wenn jeder Beteiligte diese Offenheit mitbringt, ist ein vernünftiger Scrum-Prozess umsetzbar.

Mut

Agiles Projektmanagement bringt grundsätzlich Veränderungen mit sich, insbesondere bei Scrum. Sämtliche Beteiligten müssen dafür nicht nur offen sein, sondern auch bereit sein, sich den bis dato unbekannten Herausforderungen zu stellen, die solche Veränderungen mitbringen.

Respekt

In einer so ausgeprägten Teamarbeit wie mit Scrum braucht es großen gegenseitigen Respekt. Es gibt keine Hierarchien und somit sollte sich auch niemand höher stellen, als er eigentlich steht. Genauso sollten die anderen nicht ihren Mund halten, wenn es doch einmal dazu kommt, dass einer etwas abhebt.

Fokussierung

Im Mittelpunkt steht das Ziel, das mit einem Sprint erreicht werden soll. Jeder hat sich in seiner Arbeit auf das Ziel zu fokussieren. Es sollen nur Arbeiten erledigt werden, die dem Ziel des Sprints tatsächlich dienen. Andere Arbeiten, die nichts konkret mit dem Sprint-Ziel zu tun haben, werden nach hinten verschoben. Auch wenn sich dadurch die Menge nicht getaner Arbeit maximiert – aber das ist durchaus ein gern gesehener Effekt in Scrum.

Commitment

In die Mitte aller Grundwerte könnte man noch einen ganz zentralen fünften Grundwert einsetzen. Nämlich das Commitment, dt. Einsatz, Engagement, Verpflichtung. Wie bereits an vorigen Stellen geschrieben, muss jeder im Team den Scrum-Prozess leben. Das bedeutet, jeder muss sich einsetzen, engagieren und verpflichten. Das Team verteilt seine Aufgaben eigenständig und jeder gibt einen Beitrag dazu. Dazu muss man bereit sein. Hilfreich ist, hinter dem Produkt zu stehen, welches man entwickelt – so kommt die Verpflichtungsbereitschaft von ganz allein. Sowie eine Leidenschaft, die das Produkt im wahrsten Sinne des Wortes lebendig werden lässt.

Worauf muss sich Ihr Unternehmen bei Scrum einlassen?

Das Scrum-Team inklusive Product Owner und Scrum Master ist eine autarke und sich selbst organisierende Gruppe. Außerhalb dieser Gruppe hat niemand Einfluss auf die Prioritäten des Projekts und deren Arbeitsweisen. In kleinen Unternehmen und Startups ist es denkbar, dass der Geschäftsführer und Inhaber selbst in die Rolle des Product Owners schlüpft und somit aktiv im Scrum-Prozess teilnimmt. Bei größeren Unternehmen mit gegebenenfalls mehreren Scrum-Teams müssen Sie sich als Vorstand, Geschäftsführer oder Inhaber jedoch darauf einlassen, die Prozesse der Teams (im ersten Schritt) in keiner Weise beeinflussen zu können.

Außerdem müssen Sie sich darauf einlassen, dass formale Aufgaben der disziplinarischen Führung aufkommen. Sie müssen beurteilen, befördern und auch versetzen, um ein gut funktionierendes Scrum-Team auf die Beine zu stellen. Insgesamt fallen hier deutliche Parallelen zur agilen Organisation beziehungsweise in Softwareunternehmen zu DevOps auf. Zur Erinnerung: Jeder im Team ist eine Fachkraft für das, was er tut, soll aber interdisziplinär auch die Aufgaben der anderen übernehmen können. Gegebenenfalls müssen Sie also über Fortbildungsmaßnahmen einiger Mitarbeiter nachdenken – ein Mitarbeiter ist zudem als Scrum Master auszubilden oder einzustellen.

Scrum bedeutet als agiles Projektmanagement aber nicht nur Umstrukturierung und Kontrollverlust. Im Gegenteil. Sie können den Handlungsspielraum des Scrum-Teams selbstverständlich mit festlegen. So legen Sie gemeinsam mit dem Team anfangs Produkt-Zyklen fest und regeln den Punkt der monetären und personellen Ressourcen.

Außerdem können sich Entscheider in den gesamten, im Projekt stattfindenden Austausch einbringen. Alle Projekt-Meetings sollen laut Scrum-Regeln stets einem breiten Interessentenkreis zugänglich sein. Das heißt, dass Sie natürlich teilnehmen und sich einbringen können. Sofern die Spielregeln klar sind, lassen sich mit Scrum exzellente Ergebnisse erzielen.

Hinweis zum Steuern durch das Management

Beim Festlegen von monetären und personellen Ressourcen ist es wichtig, dass die Rahmenbedingungen für das Projekt aus übergreifenden Unternehmenszielen abgeleitet werden. Es ist Aufgabe des Managements, dies zu kommunizieren und die Erwartungshaltung des Unternehmens an das Projekt formulieren. Dies unterbleibt in der Praxis häufig mit dem Hinweis, dass es im agilen Projektmanagement nicht vorgesehen ist. Aber es ist falsch, da das agile Projektmanagement eine Ebene tiefer ansetzt und eine effiziente Umsetzung sicherstellt.

Tipp für Entscheider: Formulieren Sie Ihre Erwartungshaltung, insbesondere an ein Scrum-Projekt, zu Beginn klar und präzise.

Wie sieht der Ablauf eines Scrum-Projekts aus und wer ist wann beteiligt?

Grundsätzlich besteht ein Scrum-Projekt aus beliebig vielen zwei- bis vierwöchigen Sprints. Pro Sprint erarbeitet das Development Team ein neues Inkrement des Produkts, das sich an den Anforderungen und Prioritäten des Product Backlogs orientiert. Diese werden vor dem Sprint im Meeting besprochen und ins Sprint Backlog übersetzt. In jedem Sprint wird  typischerweise ein Minimum Viable Product entwickelt, also eine embryonische Inkrement-Version für erste Tests, Feedbacks und somit Erfahrungen. Dieses Produkt wird dann bis zum Sprint-Ende fokussiert ausgearbeitet. Einmal täglich findet morgens das Daily Scrum statt, das zur Synchronisation des Teams sowie zur Tagesplanung dient und höchstens 15 Minuten dauern sollte. Mit Abschluss des Sprints kommt das Sprint-Review-Meeting. Hier stellt das Team dem Auftraggeber sein fertiggestelltes Inkrement vor. Innerhalb des Teams findet außerdem noch eine Retrospektive statt, in der Erfahrungen aus dem Sprint besprochen und Herangehensweisen optimiert werden – bevor es wieder von vorn losgeht.

Die Sprint-Retrospektive dient dazu, die Arbeit des Teams effizienter zu machen.  Man will von Sprint zu Sprint immer besser werden. Die Lernkurve von guten Teams ist steil und typischerweise deutlich besser als beim klassischen Projektmanagement. Dafür ist das Startniveau durch den notwendigen Teamfindungsprozess tiefer.

Beim Sprint-Planning-Meeting und beim Sprint-Review-Meeting sind alle Scrum-Beteiligten anwesend, im Review auch der Auftraggeber. Darüber hinaus kommen weitere Interessierte wie beispielsweise der Geschäftsführer, Vorstand oder andere Stakeholder dazu. Beim Sprint, Daily Scrum und bei der Retrospektive sind ausschließlich die Mitglieder des Entwicklungsteams beteiligt. Der Scrum Master ist dabei aber zumindest im Hintergrund aktiv, um darauf zu achten, dass die Regeln des Scrum-Frameworks eingehalten werden. In Ausnahmefällen kann der Product Owner während des Sprints mit einbezogen werden, um zwischenzeitlich die ersten Arbeitsentwürfe zu begutachten und zu beurteilen. 

Weitere Informationen zur Durchführung eines Scrum-Projektes lesen Sie im How-to-Guide zu Scrum. Informationen zur Verbindung mit einer agilen Organisation lesen Sie im How-to-Guide zur agilen Organisation

Gibt es Risiken bei Scrum?

Grundsätzlich ist Scrum eine exzellente Projektmanagement-Methode. Ihre Brillanz zeigt sich vor allem dann, wenn sich selbstorganisierende Teams in Situationen von großer Unsicherheit beweisen. Und diese unsicheren Situationen kommen bestimmt, schon allein dadurch, dass das Finden von alternativen Vorgehens- und Denkweisen fest zum Scrum-Prozess dazugehört. Das ist ein Risiko, das Unternehmen verstehen müssen – sogleich aber auch eine Chance. Denn das Team ist stets dabei, Herausforderungen als solche zu überwinden, sowie in Zukunft zu vermeiden. So geht das Framework mit einer starken Delegation von Verantwortung einher. Dies kann (je nach spezifischer Situation) zu einem erhöhten Risiko in Bezug auf die typische Balance des Projektmanagements – bestehend aus Ergebnis, Budget und Zeit – führen. Deshalb ist Scrum vielleicht zu Beginn risikoreich, doch das Risiko vermindert sich mit jedem Sprint und mit jeder zugewonnenen Erfahrung. Die zeitnah gewonnen Erfahrungswerte sind vom Management zu nutzen, um seine Erwartungshaltung zu konkretisieren und konkrete Zielvorgaben festzulegen.

Doch die unsicheren Situationen sind nicht das einzige Risikothema bei Scrum:

 

  • Faktor Mitarbeiter:
    Ihre Mitarbeiter müssen Scrum leben und voll hinter dem Produkt und Unternehmen stehen. Sie müssen Verantwortung übernehmen wollen und das Framework verstehen. Tun sie es nicht, dann kann Scrum als agiles Projektmanagement recht schnell nach hinten losgehen. Wählen Sie Ihre Mitarbeiter mit Bedacht aus und fragen Sie sie vorab nach Ihrer Meinung zur Einführung des neuen Projektmanagements. Expertentipp: Sammeln Sie außerdem harte Belege und erörtern Sie die Vorteilhaftigkeit des einzuführenden Frameworks in Ihrem Unternehmen.
  • Faktor Unternehmenskultur:
    Ein hippes agiles Projektmanagement wie Scrum kann in einem klassisch orientierten Unternehmen mit seinen klaren Hierarchien entweder großen Zuspruch oder auch große Abneigung hervorrufen. Befragen Sie Ihre Mitarbeiter, ob Sie sich eine Veränderung wünschen würden.
  • Faktor „Kontrollverlust“:
    Auch wenn Sie sich recht nah an den Scrum-Prozess heranbewegen können, haben Sie keine volle Projektmanagement-Kontrolle mehr. Vor allem in großen Unternehmen sollte eine Definition von klaren Spielregeln stattfinden. Insbesondere dann, wenn das Unternehmen über mehrere Scrum-Teams verfügt, die alle an einem zentralen Produkt arbeiten. Auch Scrum ist zu skalieren.

Fazit

Scrum bringt große Flexibilität und großes Verantwortungsbewusstsein der Mitarbeiter in Ihr Unternehmen. Sofern sich die Mitarbeiter auf Ihre Rolle und das Vorgehen einlassen. Der zentrale Vorteil von Scrum ist, dass ein Produkt nach und nach wachsen kann. Der Fokus liegt immer auf einem bestimmten Inkrement des Produkts, sodass das Entwicklungsteam seine ganze Konzentration auf dieses eine Inkrement legen kann, um es perfekt zu machen. Sollten dabei Hindernisse auftreten, setzt der Scrum-Prozess voraus, dass sich das Team mit diesen beschäftigt und sie in Zukunft vermeidet. Dahingehend ist Scrum besser als jedes klassische Projektmanagement.

Dennoch bringt Scrum nicht nur Vorteile ins Unternehmen, sondern auch einige Risiken mit. Möchten Sie Scrum in Ihrem Unternehmen einführen und etablieren, dann müssen Sie verschiedene Faktoren beachten, an denen es scheitern kann. Kurzum müssen Ihre Mitarbeiter dem Prozess gegenüber insgesamt offen sein. Außerdem muss es zur allgemeinen Unternehmenskultur passen. Niemals sollte Scrum aufgesetzt sein. Entscheider müssen sich darüber hinaus klarwerden, dass sie im ersten Schritt weite Teile der Kontrolle aus der Hand und in das Team geben. Zudem stellt Scrum sehr hohe Anforderungen an die Mitarbeiter in Bezug auf Eigenverantwortung, Disziplin und Teamfähigkeit. Somit ist von vornherein abzuwägen, ob Scrum zum Unternehmen passen wird oder nicht. Ein Gespräch  mit ausgewählten Mitarbeitern, die Sie in ein erstes Framework-Team integrieren würden, ob sie dahinterstehen und Lust darauf haben, ist ebenfalls erforderlich. Um zu testen, ist ein erster kleiner Pilot sinnvoll. Sofern bestätigt, kann Scrum seine ganze Exzellenz in Ihrem Unternehmen entfalten.