Sie sprechen schon seit Monaten davon, aber Sie kommen einfach nicht dazu: mit Scrum zu beginnen. Es scheint so bequem zu sein, nicht mehr über die Struktur von Meetings nachdenken zu müssen und wirklich Schritte zu unternehmen, aber Sie wissen nicht, wo Sie anfangen sollen, um Ihren ersten Sprint auf die Beine zu stellen. Kennen Sie das? Dann ist dies der ideale Artikel für Sie, denn in diesem Beitrag helfen wir Ihnen in 6 Schritten, mit Scrum zu beginnen!
Schritt 1: Definieren Sie Ihr Ziel
Warum wollen Sie überhaupt mit dem Scrummen beginnen? Werden Sie ein neues Produkt oder eine neue Dienstleistung entwickeln? Wollen Sie die Weiterentwicklung eines bestehenden Produkts vorantreiben? Beginnen Sie mit einem Projekt, in welcher Form auch immer?
Ziele sind das Herzstück des Scrum Frameworks. Das wichtigste Ziel ist das Product Goal: der Punkt am Horizont. Wenn Ihr Produktziel erreicht ist, ist Ihr Produkt oder Projekt „fertig“. Das bedeutet oft, dass ein bestimmtes Problem gelöst wurde. Indem Sie in allen nachfolgenden Schritten deutlich machen, dass Sie letztendlich dieses eine Problem lösen wollen, fällt es Ihnen leichter, Entscheidungen zu treffen und die richtigen Leute in Ihr Projekt einzubeziehen.
Sie können auch Sprint-Ziele auf Ihr Produktziel aufbauen: kleine, aber wertvolle Schritte, die auf das Erreichen Ihres Produktziels hinarbeiten. Wenn Sie bereits Ideen für diese Schritte haben, können Sie sie in diesem Schritt beschreiben. Auf diese Weise erstellen Sie eine einfache Roadmap. Wenn Sie diese Schritte noch nicht im Kopf haben, ist das kein Problem. Das kommt später.
Die Festlegung eines Produktziels ist ein guter erster Schritt, aber legen Sie sich nicht zu sehr darauf fest. Wenn Sie am Anfang eines Projekts stehen, ist es ganz logisch, dass Sie noch nicht viel wissen. Wenn Sie während des Projekts Grund haben, Ihr Produktziel anzupassen, können Sie das tun. Es muss nicht auf einmal perfekt sein.
Schritt 2: Stellen Sie ein Team zusammen
Ein Scrum Team besteht aus bis zu 10 Personen, darunter 1 Product Owner, 1 Scrum Master und Entwickler. Auch hier ist es sinnvoll, dass Sie zu Beginn Ihres Projekts noch nicht alles wissen. Obwohl Sie ein Scrum Team so stabil wie möglich halten wollen, ist es in Ordnung, wenn Sie im Laufe des Projekts Personen hinzufügen oder entfernen.
Gehen Sie von dem aus, was Sie bereits wissen. Welche Fachkenntnisse werden Sie vermutlich brauchen? Finden Sie diese Leute und prüfen Sie, ob sie hinter Ihrem Produktziel stehen. Je mehr das Team intrinsisch motiviert ist, das Produktziel zu erreichen, desto leichter wird es sein, tatsächlich Fortschritte zu machen.
In dieser Phase ist es auch wichtig, die Rollen gut zu trennen. Wir sehen oft, dass die Rollen von Product Owner und Scrum Master kombiniert werden, oder dass der Product Owner auch ein wichtiger Entwickler ist. Das wirkt sich negativ auf die volle Nutzung des Scrum Frameworks aus. Wenn eine Person Entscheidungen über Prioritäten trifft und den Prozess leitet, sieht das schon verdächtig nach einem Teammanager aus.
Schritt 3: Schulung des Teams und der Stakeholder in Scrum
Die Arbeit mit dem Scrum Framework unterscheidet sich wirklich ein wenig vom traditionellen Projektmanagement. Stellen Sie deshalb sicher, dass das gesamte Scrum Team und die direkten Stakeholder das Scrum Framework verstehen. Indem man gemeinsam über die Bedeutung von Rollen, Events und Artefakten nachdenkt, fällt es leichter, zu einem späteren Zeitpunkt darauf zurückzugreifen.
Eine Schulung ist eine gute Möglichkeit, allen das Scrum Framework zu vermitteln. Vor allem, wenn sie die Theorie mit einer Simulation verbindet, in der jeder auf zugängliche Weise erfährt, wie Scrum funktioniert.
Auch wenn jemand bereits Erfahrung mit Scrum hat, ist ein gemeinsames Training sinnvoll. Die Erfahrung zeigt, dass Menschen oft ihre eigene Interpretation der Terminologie haben, die mit demselben Wort etwas anderes meint.
Schritt 4: Product Backlog Items sammeln
Es ist an der Zeit, die Arbeit ein wenig zu konkretisieren! Gemeinsam mit den Entwicklern und Stakeholdern können Sie nun einen ersten Entwurf für ein Product Backlog erstellen. Der Product Owner hat hier die Federführung inne. Durch die gemeinsame Bestandsaufnahme aller Wünsche und ersten Ideen im Vorfeld des Projekts erhalten Sie ein gemeinsames Bild über den Gesamtumfang des Projekts.
Ein Product Backlog ist eine lebendige Sache. Das bedeutet, dass immer wieder Items hinzugefügt, Items gestrichen und Items weiter ausgearbeitet werden können. Die Prioritäten können sich von Tag zu Tag ändern, und das ist völlig in Ordnung. Halten Sie sich daher nicht zu lange mit dem ersten Entwurf Ihres Product Backlogs auf. Er ist ein Ausgangspunkt, er muss nicht vollständig sein. Solange Sie genügend Anhaltspunkte für einen ersten Sprint haben, ist das der Ausgangspunkt für diesen Schritt.
Wie Sie den ersten Anstoß geben können, hängt davon ab, wie viele Informationen Sie bereits haben. Wenn Sie bereits eine Lösungsrichtung haben, könnten Sie einen Story Mapping Workshop veranstalten. Darin sammeln Sie alle Ideen und das Wissen, das die Entwickler und Stakeholder derzeit haben, und ordnen sie nach Prioritäten.
Wenn Sie noch keine einzige Idee für eine mögliche Lösung haben, können Sie einen Design Sprint dazu durchführen. In wenigen Tagen sammeln Sie dann eine Menge Wissen und validieren ein mögliches Konzept.
Schritt 5: Bestimmen Sie die Dauer eines Sprints
Sie können jetzt fast loslegen. Das Einzige, was noch feinabgestimmt werden muss, ist die Dauer eines Sprints und die Timeboxen der verschiedenen Events. Einerseits möchten Sie einen Sprint so kurz wie möglich halten, um so oft wie möglich einen Feedback-Zyklus zu durchlaufen, und gleichzeitig sollte er lang genug sein, um die Arbeit tatsächlich zu erledigen.
Wenn Ihre Organisation bereits eine Standard-Sprintdauer hat, können Sie diese als Ausgangspunkt verwenden. Wenn nicht, sollten Sie vor allem darauf achten, was machbar erscheint. Falls Sie es noch nicht spüren, beginnen Sie mit einem relativ kurzen Sprint von 1 oder 2 Wochen. Das können Sie später immer noch anpassen. Aber tun Sie das nicht zu schnell und zu oft, denn Sie brauchen auch Zeit, um herauszufinden, was Sie in einem bestimmten Zeitraum schaffen können.
Als Ausgangspunkt für die Timeboxen werden sie oft von den „offiziellen“ Timeboxen auf der Grundlage eines einmonatigen Sprints zurückgerechnet. Zum Beispiel können Sie für das Sprint Planning 4 Stunden verwenden, wenn Sie einen 2-Wochen-Sprint haben. Aber das müssen Sie nicht. Eine Timebox – die Sie zwingt, nach einer bestimmten Zeit mit der Arbeit zu beginnen – ist wichtiger als die genaue Dauer.
Schritt 6: Beginnen Sie!
Der erste Sprint beginnt mit einem Sprint Planning. Darin legen Sie das erste Sprint Goal fest und wählen eine Anzahl von Product Backlog Items aus, die dazu passen. Beim ersten Mal müssen Sie eine grobe Schätzung des Arbeitsumfangs vornehmen, den Sie als Team bewältigen können. Sie können während des Sprints immer wieder Anpassungen vornehmen; das Daily Scrum ist das ideale Meeting dafür.
Beim Teilzeit-Scrum ist es eine gute Idee, den Fokus sicherzustellen. Feste Tage oder Teile des Tages als Team für die Arbeit am Sprint zu reservieren, funktioniert im Allgemeinen besser als gelegentlich dazwischen. Das macht auch die Planung von Daily Scrums einfacher: Wenn alle dienstags und donnerstags an dem Sprint arbeiten, haben Sie an diesen Tagen ein Daily Scrum. Montags, mittwochs und freitags arbeitet jeder an anderen Dingen, sodass ein Daily Scrum irrelevant ist.
Während des ersten Sprints kann der Product Owner das Product Backlog ausarbeiten und bereits über die nächsten Sprint Goals nachdenken. Dazu braucht der PO gelegentlich Entwickler und Stakeholder. So können Sie im Sprint weniger Arbeit erledigen, aber die Zeit ist wichtig, um in den folgenden Sprints weiterarbeiten zu können. Ohne gründliche Vorbereitung werden die Sprints zunehmend starr.
Ist Scrum etwas für Sie?
Mit der obigen Roadmap können Sie in wenigen Tagen mit Scrum beginnen. Kommt Ihnen bei einem dieser Schritte der Gedanke: Das wird bei uns nie funktionieren? Dann ist Scrum vielleicht nicht das am besten geeignete Framework für Ihre Situation. Schließlich ist Scrum für komplexe Situationen konzipiert, was bedeutet, dass Scrum in einem Kontext, in dem Sie bereits genau wissen, was wann zu tun ist, vielleicht ein bisschen zu viel des Guten ist. In solchen Situationen könnte Kanban besser geeignet sein.
Dennoch kann Scrum auch in einer solchen Situation sinnvoll sein, zum Beispiel um den Flow aufrechtzuerhalten. Vermeiden Sie es deshalb, das Scrum Framework nur halb zu implementieren; das wird Ihnen schaden. Scrum ist nur Scrum als Ganzes. Die Kombination von Rollen, Events und Artefakten sorgt dafür, dass es gut funktioniert. Anpassungen sind sicherlich möglich, aber immer mit Bedacht und es bedeutet, dass Sie nicht mehr nach Scrum arbeiten.
