Scrum Teams im Startup: Agiles Projektmanagement für deine Geschäftsidee

Scrum wird oft als Synonym für agile Entwicklung verwendet und beschreibt eine flexible bzw. agile Methode des Projektmanagements – im Gegensatz zum beispielsweise sehr populären Wasserfall-Modell. Beim Wasserfallmodell sind die Projektphasen linear und aufeinander folgenden organisiert, in Kaskaden.  Daher auch der Begriff Wasserfall. Scrum hingegen ist keine lineare Vorgehensweise sondern sehr viel beweglicher – deshalb nennt man es auch eine agile Arbeitsweise.

Der Begriff Scrum stammt aus der Sportart Rugby, wo es einen dichten Haufen von Spielern meint, die sich um das Spielgerät drängen. Dieses Bild wird auf das Projektmanagement übertragen. Scrum steht für Flexibilität, Dynamik und tägliche Meetings, in denen die Projektmitarbeiter ihre Aufgaben abstimmen.

Was ist Scrum?

Scrum kennen die meisten Gründer, wenn überhaupt aus IT-Unternehmen, weil es sich hier zuerst im großen Stil durchgesetzt hat. Allerdings ist das Modell auch auf die Entwicklung von Hardware bzw. von Produkten generell anwendbar, weshalb Scrum in eigentlich traditionellen Industrie- und Gewerbebetrieben im Zuge der Digitalisierung und Interdisziplinarität immer mehr an Bedeutung gewinnt.

Für Startups ist eine Scrum Team mitunter sogar erfolgsentscheidend: Eine tragende Rolle dabei spielt der sogenannte Product Owner bzw. PO.

So profitieren Startups von agilen Entwicklungsmethoden

Es ist eigentlich naheliegend: Startups sind in der Regel klein und bestehen meist aus nur sehr wenigen Beteiligten. Daraus resultiert eine gewisse Aufgabenvielfalt des Einzelnen und eine Art Selbstverständlichkeit für Agilität.

Bleibt bei einem Startup der Projekterfolg aus, kann das schnell das Aus der gesamten Unternehmung bedeutet. Agile Entwicklungsmethode wie Scrum sind also auch Risikominimierung und erhöhen so die Wahrscheinlichkeit des Projekterfolgs bzw. den Erfolg des Startups selbst.

Warum also nicht auch agile Entwicklungsmethoden verwenden!

Flexibilität und Feedbackschleifen

Agile Methoden erlauben entsprechend ihrer Bezeichnung eine maximale Flexibilität durch eine schnelle Steuerung und kurze Feedbackschleifen. Im Gegensatz zu keiner oder einer nicht-agilen Projektentwicklungsmethode hat die nicht nur den Vorteil, auf äußere Einflüsse schneller reagieren zu können – sie führt auch schneller zu sichtbaren Ergebnissen und erhöht damit das Interesse an der Geschäftsidee, sei es für neue Investoren oder für Kunden.

Regelmäßige Präsentation und Feedback

Gearbeitet wird beim Scrum in Zyklen, in welchen immer wieder Zwischenergebnisse präsentiert und Feedback eingeholt wird. Der große Vorteil: mögliche negative Entwicklungen werden schneller erkannt.

Agile Entwicklung fördert erfolgreiche Zusammenarbeit

Probleme in der Kommunikation und im Verständnis innerhalb der Projektbeteiligten zählen neben ungesicherter Finanzierung zu den häufigsten Gründen für das Scheitern eines Projekts. Das Risiko dafür erhöht sich, wenn die Beteiligten aus gänzlich verschiedenen Bereichen kommen – zum Beispiel aus der IT, aus dem Maschinenbau, dem Marketing und weiteren Bereichen. Eine agile Entwicklungsmethode führt durch die engen Produktivitätszyklen dazu, dass sich Beteiligte schnell aufeinander einstimmen, da in kurzer Zeit weite Teile der Zusammenarbeit durchlaufen werden – von der Problemfindung über die Kooperation bis hin zur gemeinsamen Präsentation des Zwischenergebnisses gegenüber den Stakeholdern.

Überschaubar Zyklen ermöglichen Prognose von Zeit und Budget

Durch die Zyklen lässt sich mit Scrum z.B. auch die Zeit und das benötigte Budget für ein Projekt genauer vorhersagen, als mit anderen Methoden – vorausgesetzt, es wurden bereits einige Zyklen durchlaufen.

Gibt es noch keine Erfahrungen aus durchlaufenen Zyklen, also zu Beginn der Arbeit, ist es mit Scrum schwieriger, Zeit und Budget zu definieren. Hier steht die Methode bezüglich Vorhersage von Zeit und Budget anderen Methoden wie z.B. dem Wasserfallmodell nach. Allerdings spielt es bei Startups gerade zum Start keine große Rolle, die Investments klar beziffern zu können: die Risikobereitschaft ist sowieso viel größer und eine genaue Zeit- und Budgetprognose gleich am Anfang ist schon auf Grund der Natur des Startups praktisch nicht möglich.

So setzt ihr ein Scrum Team auf

Angenommen, das Geschäftsmodell eures Startup beinhaltet es, Dienste über eine Website anzubieten. Diese Entwicklung der Webseite kann über Scrum erfolgen: Die meisten Mitarbeiter des Startups sind die Entwickler im Scrum Team, einer wird hingegen zum Product Owner (PO) ernannt – idealerweise der Gründer bzw. der Visionär und Kommunikator. Er managt den Kontakt zu Stakeholdern wie Investoren und Kunden und generiert aus deren Anforderungen und Feedback die zu implementierenden Arbeitspakete. Dabei behält er immer das Team bzw. die Entwickler im Blick und sorgt für einen reibungslosen Ablauf der Zyklen.

Scrum Team: Im Zentrum steht der Product Owner

Der PO bzw. Product Owner ist der Visionär im Team: Er oder Sie weiß, wie das Produkt bzw. Projekt später aussehen soll, was es können muss und wie es im Einsatz funktioniert bzw. welcher Sinn dahintersteht. Damit hat der PO stets den Blick über das ganze Projekt, er „besitzt“ es mehr oder weniger bzw. ist dafür im hauptsächlichen Maße verantwortlich und damit ein wichtiger Teil des Scrum Teams.

Hauptteil des Team bilden die Mitarbeiter

Zum Team gehören außerdem die Entwickler bzw. Mitarbeiter, welche das Produkt entsprechend ihres Jobs im Startup letztendlich entwickeln, testen und ausliefern. Folgende Faktoren solltet ihr bei der Aufstellung eures Scrum Teams beachten:

• zwischen fünf und zehn Mitarbeitern
• Teammitglieder organisieren alle Aufgaben selbst
• keine Hierarchie im Team, jeder hat dieselben Rechte und Pflichten aber verschiedene Kompetenzen
• alle für die Lösung wichtigen Bereiche (Sales, Marketing, Programmierung, usw) sind vertreten

Die Mitarbeiter können nicht unendlich viel Arbeit verrichten – bekommen sie zu viele Aufgaben, sorgt das für Überlastung und Frust, was das Risiko für ein Scheitern des Projekts erhöht.

Team führen mit Kanban-Board & Storming

Der PO wirkt dem entgegen, indem er die Anforderungen der Stakeholder spezifiziert, filtert, kanalisiert und aus dem sogenannten Backlog portionsweise dem Entwicklerteam zuführt. Hier lässt sich Scrum sehr gut mit Kanban und im speziellen dem Kanban-Board zusammenführen, welches den Status der Arbeitspakete übersichtlich darstellt und auch eine Limitierung ermöglicht. Außerdem kann der PO Stategien zur Problembewältigung beschließen, z.B. das Storming, bei dem viele Mitarbeiter von anderen Gebieten abgezogen werden und sich um ein Problem bzw. Arbeitspaket kümmern.

Wo steht der Product Owner bei Scrum?

Ein Product Owner übernimmt die Rolle der Moderation zwischen dem Entwicklerteam und den Stakeholdern bzw. den anderen Projektbeteiligten. Er vereint die Wünsche der Stakeholder mit den Möglichkeiten des Entwicklerteams und hat dabei nur ein Ziel: Den Erfolg des Projekts. Daraus folgt natürlich verwundernd die Frage: Möchten das nicht alle?

Nein! Vor allem die Stakeholder, häufig Investoren oder beteiligte Firmen, verfolgen immer auch eigene Ziele – und das muss nicht immer der Projekterfolg sein, sondern z.B. die Durchsetzung der Verwendung eigener Technologie im Projekt oder das Hinzufügen eines bestimmten für einen selbst notwendigen Features, welches für andere jedoch keinen Mehrwert bringt. Ein Product Owner steht dem Projekt mit dem nötigen Abstand gegenüber und vereint die Interessen der Projektbeteiligten in einem sogenannten Backlog bzw. einer Liste mit allen Features, die bei Zeiten implementiert werden. Er verteilt diesen Features Prioritäten und teilt sie dem Entwicklerteam zu.

Der PO braucht Macht

Damit ein Product Owner so wie vorgesehen agieren kann, braucht er die dazu nötige Macht. Es hilft dem Projekterfolg nicht, wenn eine Firma durch einen direkten Draht ins Entwicklerteam die Entscheidungen des POs umgeht oder wenn dieser auf irgendeinem Weg dazu gezwungen wird, z.B. ein Feature zu implementieren, welches er eigentlich abgelehnt hätte. Daher ist die Wahl des POs eine der wichtigsten Aufgaben bei der Initialisierung eines agilen Entwicklungsprojekts.

Der Scrum-Prozess Schritt für Schritt

Viele der Schritte des Scrum-Prozesses klingen so logisch, dass man diesen Vorgang als üblich im Projektmanagement erwarten könnte. Ist aber gar nicht so – viele Prozesse (selbst wenn sie bewusst gesteuert werden) folgen nicht dieser Logik. Deswegen solltet ihr euch vorab diese Routinen bewusst als Prozessabläufe klar machen und gemeinsam festlegen.

Schritt 1: Produkt-Vision

Am Anfang jedes Scrum-Prozesses steht eine Produkt-Vision. Ihr solltet eine klare Idee eures Produktes ausarbeiten. Diese Vision solltet ihr in Story Cards formulieren, auf denen ihr aus Sicht des Anwenders/eurer zukünftigen Kunden die Elemente, Merkmale und Funktionen eures Produktes beschreibt.

Schritt 2: Product Backlog

Im sogenannten Product Backlog sammelt ihr von Anfang an alle Funktionen und Merkmale, die euer Produkt haben soll. Dieses Log führt ihr immer weiter fort und damit wird die Beschreibung im Projektverlauf immer genauer.

Außerdem vergebt ihr im Product Backlog Prioritäten, welche Funktionen am wichtigsten sind. Weniger wichtige können verschoben, mit anderen fusioniert oder sogar aussortiert werden.

Schritt 3: Sprint Planning

Der große Unterschied zu anderen Projektmanagements ist die Agilität von Scrum. Der Sprint ist der Kern eines Scrum-Projekts. Deshalb sind Projekt-Teilerfolge kleinteiliger – aber eben dann in einem Sprint auch zu erreichen. Der jeweilige Sprint (also Projekt-Teilschritt) sollte in einer vorgegebenen Zeitdauer von maximal einem Monat geschafft sein.

Beim Sprint Planning (quasi dem Meeting für den nächsten Sprint) plant ihr die Aufgaben für den anstehenden Sprint und formuliert das Sprint-Ziel. Klar sollte werden, was ihr im nächsten Sprint entwickeln wollt und wie die Aufgaben erledigt werden.

Schritt 4: Sprint Backlog

Auch die Sprint Plannings werden dokumentiert und zwar im Sprint Backlog. Genau genommen ist der Sprint Backlog dasselbe wie der Product Backlog ergänzt mit dem Umsetzungsplan. Und hier findet sich auch die sogenannte „Definition of Done“ – also die Beschreibung, wann der Sprint erfolgreich beendet ist. Die einzelnen Aufgaben im Sprint Backlog nennt man Tickets. Jedes Teammitglied übernimmt eigenverantwortlich einzelne Tickets und arbeitet daran, bis diese fertig sind.

Schritt 5: Daily Scrum

Wesentliches Zentrum der Abläufe im Scrum Team ist ein möglichst tägliches Meeting von 15 Minuten. In diesem sogenannten Daily Scrum berichtet jeder der Reihe nach von seiner Arbeit seit dem letzten Daily Scrum, was er bis zum nächsten vor hat und welche Herausforderungen er sieht.

Gemeinsam sollte abgeschätzt werden, ob und wie die Sprint Ziele erfolgreich erreicht werden können. Der Scrum-Master sollte die Herausforderungen bzw Hindernisse aufgreifen und bei der Bewältigung helfen.

Schritt 6: Sprint Review

Zum Ende jedes Sprint trifft sich das Scrum-Team zu einem Sprint Review Meeting, dort werden die Ergebnisse präsentiert und dem Produkteigner vorgestellt. Er muss prüfen, ob die Ergebnisse der  Definition of Done entsprechen und nimmt sie ab.

Vergesst nicht, im Product Backlog die Daten zu aktualisieren.

Es folgt ein weiterer Sprint … und immer so weiter.