Scrum ist eines der populärsten Produktmanagement-Frameworks und fand seinen Anfang in den 1990ern unter anderem durch Jeff Sutherland und Ken Schwaber. Bis dato war das Wasserfallprinzip in der Softwareentwicklung vorherrschend. Das bedeutet, am Anfang des Prozesses stand der Kunde und der Teamleiter oder Anforderungsmanager, die über die Anforderungen für die Software sprachen. Danach wurden die Anforderungen designt, implementiert, getestet und erst wenn das ganze Projekt fertig war, wurde es dem Kunden vorgestellt. Aus Kundenperspektive muss das Ganze wie eine riesige Blackbox gewirkt haben, wo man Anweisungen reinwirft und nach ein paar Jahren kommt das fertige Produkt raus.

Das Problem mit der Wasserfallmethode war, dass sie oft auch zu Schwierigkeiten führte. Sobald einmal die Anweisungen in der „Blackbox“ waren, gab es keine Möglichkeit diese abzuändern. Dazu konnte man nicht ein oder zwei Jahre im Voraus absehen, wie das Projekt am Ende aussehen würde und ob es noch dem Zeitgeist entsprach. Wenn dann am Ende doch etwas verändert werden sollte, dann musste umständlich alles umgebaut werden und das kostet nicht nur viel Zeit, sondern auch sehr viel Geld.

Wie ist Scrum aufgebaut?

Aus diesem Problem entstand SCRUM. SCRUM ist ein Projektmanagement-Framework, welches inkrementell, also immer wieder die gleichen Aufgaben durchläuft – auch Sprint genannt. Am Anfang steht das Aufnehmen der Anforderungen, genauso wie bei dem Wasserfallmodell. Der Teamleiter, hier Product Owner genannt und der Kunde setzen sich zusammen hin und besprechen, was das Produkt können muss.

Der Product Owner setzt sich dann hin und definiert die User Stories, die aus diesen Anforderungen entstehen. Diese User Story baut sich wie folgt auf: „Als ein X, möchte ich Y, deshalb brauche ich Z.“. Die User Story soll dazu beitragen, dass die Anforderung, die eingebaut werden soll, auch in diesem Sprint durchgeführt werden können. Dafür braucht es eine Definition of Done oder auch die INVEST-Kriterien.

Independent (unabhängig): es wird keine andere Story benötigt, um diese abzuschließen.

Negotiable (verhandelbar): muss verändert werden können.

Valuable (wertvoll): muss für den Kunden oder den User von Wert sein.

Estimable (schätzbar): der Aufwand, der mit der Entwicklung einhergeht, muss einschätzbar sein.

Small (klein): damit der Aufwand einschätzbar und planbar ist, muss die Anforderung klein sein. Wenn sie zu groß ist, sollte sie auf das Wichtigste runtergebrochen werden.

Testable (testbar): damit die Aufgabe als abgeschlossen gilt, müssen alle Tests für die Anforderung abgeschlossen sein.

Diese User Stories, werden in einem Refinement überprüft und, wenn sie für fertig befunden werden (nach den INVEST-Kriterien), in dem Produkt Backlog abgelegt. Darin sind alle aufgenommenen Anforderungen zu dem Projekt vorhanden. Dieses Backlog wird vom Product Owner nach Dringlichkeit in eine Liste (oben = wichtig zu unten = unwichtig) sortiert.

Ein Sprint kann eine variable Zeitlänge haben, aber meistens sind es zwei Wochen. Für diese zwei Wochen braucht es dann genügend Aufgaben. Diese werden im Sprint Planning herausgesucht. Dann schaut man sich im Team das Backlog an und entscheidet, was im nächsten Sprint angegangen werden soll. Dabei ist das ganze Team mit dabei und darf mitentscheiden. Besonders wichtig sind dabei die Story Points. Jede Aufgabe wird vorgestellt, diskutiert und dann zeitlich eingeschätzt. Dafür kann das Planning Poker verwendet werden. Wenn du mehr zu dem Ablauf von Planning Poker erfahren möchtest, dann schaue dir diese informative Seite an.

Nachdem alle Aufgaben in den neuen Sprint Backlog gewandert sind, kann sich das Team an die Arbeit machen. 2 Wochen lang holt sich jeder Aufgaben aus dem Sprint Backlog, implementiert und testet diese, bittet um Feedback und schließt die Aufgabe dann ab.

Damit die Transparenz hoch bleibt und jede:r weiß, woran die anderen gerade arbeiten, werden tägliche Meetings abgehalten – Daily genannt. Ein Daily ist ein kurzes (meistens 15-minütiges) Meeting, wo jede:r erklärt, woran sie oder er gerade ist und ob er oder sie Hilfe benötigt. Dies führt zu mehr Transparenz innerhalb des Teams.

Das Endergebnis eines Sprints ist ein benutzbares Produkt (working increment). Jede Anforderung ist eingebaut, getestet und funktioniert ohne große Probleme. Dieses Produkt wird dann dem Kunden vorgestellt und sein Feedback wird eingeholt – das Review. Falls etwas verändert werden muss, ist der Prozess schneller und kostengünstiger als beim Wasserfallmodell. Dazu hat der Kunde die Möglichkeit, weitere Anforderungen zu definieren. Diese werden in das Produkt Backlog eingefügt und wenn nötig für das nächste Sprint Planning ganz oben angeordnet.

Auch das Team hat ein abschließendes Meeting, welches sich Retrospektive nennt. In diesem werden zuerst die abgeschlossenen Anforderungen besprochen. Danach wird festgehalten, wie der Sprint verlief. Was ist gut gelaufen, was hätte besser laufen können und was haben wir daraus gelernt, um es das nächste Mal besser zu machen.

Nachdem die Retrospektive abgeschlossen ist, wird in das nächste Sprint Planning übergegangen. Diese Zyklen wiederholen sich so oft, bis ein Produkt hergestellt wurde, mit dem der Kunde zufrieden ist.

Der Nachteil an dem Wassermodell ist der Vorteil von SCRUM. Durch die Agilität von SCRUM kann sich die Produktion flexibel an die Kunden anpassen. Dazu führen die Schritte Backlog, Refinement, Sprint Planning, Sprint Backlog, Sprint, Daily, Sprint Review und Retrospektive zu einem besseren Produkt, da die Kunden nah am Entwicklungsprozess beteiligt sind und so dazu beitragen Fehlkommunikation früh aufzudecken. Dazu ist es für den Kunden von Vorteil, da er sein Produkt zukunftssicher entwickeln und sich auf neue Gegebenheiten sehr schnell einstellen kann.

Scrum in kleinen Firmen

Wirkliches Scrum, so wie es beschrieben wird, ist für uns nicht möglich. Wir sind ein modernes Unternehmen, in dem viele Teilzeitkräfte arbeiten. Eines unserer wichtigsten Anliegen ist, die Flexibilität unserer Mitarbeitenden zu gewährleisten. Diese Freiheit bringt es mit sich, dass jede:r Mitarbeitende zu jeder Zeit an jedem Ort arbeiten kann. Das bedeutet für einige Morgens, für andere spät in der Nacht. 100 % remote oder doch ab und zu im Büro, das ist jedem oder jeder freigestellt. Das ermöglicht vieles – nur nicht immer zur selben Zeit wie andere zu arbeiten. Deshalb mussten wir das Framework für uns anpassen. Manche würden sagen, dass wenn man sich nicht genau an Scrum hält, dass es dann kein Scrum sei. Ich würde sagen, wir machen Scrum(ish).

Wir haben für jedes Projekt einen Product Owner, der mit dem Kunden spricht, das Product Backlog aufbaut und die User Stories verfeinert. In kleinen Refinements werden Repräsentanten aus dem Team eingeladen, um die User Stories zu einer Definition of Done zu optimieren.

In unseren Sprint Plannings werden die Aufgaben nicht geschätzt, wir besprechen nur welche Anforderungen mit in den Sprint müssen. Dabei kann das Team gemeinsam entscheiden, wann genügend Tickets in das aktuelle Planning übernommen wurden. Als Ausweichmethode haben wir, dass in der Mitte des Sprints weitere Aufgaben nachgeschoben werden können.

Unsere Sprints laufen zwei Wochen lang. Dabei unterscheiden wir uns kaum von dem Framework. Wir holen uns die Aufgaben aus dem Sprint Backlog, implementieren diese, testen sie und holen uns Feedback ein. Wenn das Feedback abgearbeitet ist, wird die Aufgabe als erledigt gesehen. Eine Unterscheidung gibt es dennoch. Wie gesagt, können wir kein Daily machen. Deshalb machen wir ein Weekly. Einmal in der Woche kommt das ganze Team (abgekoppelt von den einzelnen Produkten) zusammen und bespricht den Stand der Dinge. Dabei gehen wir wie beim Daily vor. Jeder erzählt, woran er oder sie gerade ist und ob er oder sie gerade Hilfe benötigt. Zusätzlich werden allgemeine interne Sachverhalte geklärt. Somit ist immer jede*r vollends informiert und auf dem aktuellen Stand. Eine weitere Besonderheit, die wir alle zwei Wochen durchführen, ist ein Speed Dating. Hierbei treffen sich zwei zufällig ausgewählte Personen in einem Chat und sprechen über ihre nächste anstehende Aufgabe. Dadurch schaffen wir bessere Motivation, Austausch, eine schnellere Einbindung von neuen Teammitgliedern und Teamzusammenhalt.

Am Ende unseres Sprints haben wir ein benutzbares Produkt (working increment). Dieses wird auch in einem Review vom Product Owner dem Kunden vorgestellt. In unseren Retrospektiven kommt dann das ganze Team zusammen und spricht über den vergangenen Sprint. Jede/r Entwickler/in stellt sein oder ihr Ticket vor. Im Anschluss stellen wir uns die Frage, was wir gut fanden, was wir nicht weiter machen möchten und was wir anfangen möchten (bspw. ich möchte mehr Erklärung zu den einzelnen Anforderungen haben).

Nach unserem Retro gehen wir direkt wieder in das Sprint Planning von dem nächsten Sprint und der Kreislauf wiederholt sich von neuem.

Unsere weitreichende Erfahrung um agile Produktentwicklung nutzen wir, um unsere eigene App zu erstellen - Bookyp. Diese ermöglicht dir und deinem Unternehmen die höchstmögliche Flexibilität, wenn es um den Arbeitsort geht. Ob es das Arbeiten im Büro oder in einem Coworking Space ist, wir bieten ein Netzwerk, ein einfaches Buchungssystem über einen Raumplan und die Möglichkeit der Analyse von Bürofläche. Dazu wird Bookyp ständig weiterentwickelt und ist jetzt schon verfügbar, dabei ohne Performance-Verlust für die Nutzer.

Du und dein Unternehmen interessieren sich für agile Methoden, ihr wisst aber noch nicht, wie ihr diese umsetzen könnt? Oder ihr habt ein Projekt (eine App, eine Schnittstelle, etc.), welches ihr gerne umsetzen möchtet und so schnell wie möglich testen könnt? Dann lass uns darüber reden.