Methoden bei Scrum

Welche Methoden werden in Scrum angewandt?

Email
Twitter
LinkedIn
Facebook
Whatsapp

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

Sofern 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. Übrigens spielen Klebezettel auch bei der Methodik von Kanban eine zentrale Rolle.

Die Rolle der Klebezettel
Rolle der elektronischen Aufgabensysteme bei Scrum

Backlogs gemäß Scrum

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.

Aufgaben bei Scrum

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.

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. 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“.

Planungspoker

Beim 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.

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.

Bei 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 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.

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 des 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.

Email
Twitter
LinkedIn
Facebook
Whatsapp

Sprints & Meetings
Regeln

Weitere Inhalte: