Im Zuge des Projekts „ICE Entertainment Portal“ bin ich mit einer Arbeitsweise konfrontiert worden, die mir zwar bekannt war aber auf die ich mir noch keine differenzierende Meinung bilden konnte. Mittlerweile ist diese Methode auch in der Kreativbranche angekommen und nach fast 2 Jahren Projekterfahrung kann ich ein kleines Fazit ziehen. Die Rede ist von dem agilen Prozess SCRUM. 

Was ist Scrum?

Die meisten Kreativen und Kunden arbeiten nach dem Wasserfall Prinzip. Man bekommt das Briefing, entwickelt ein Konzept, stimmt es ab und setzt es dann technisch um. Nun verdienen immer mehr Unternehmen mit ihren Services im Internet Geld und immer mehr Unternehmen bieten ähnliche wenn nicht sogar redundante Leistungen an. Es gibt unzählige Apps und Internetseiten über die ich mir eine Pizza bestellen kann. Die Frage welchen Service ich nutze ist nicht mehr ganz so trivial? Lieferando? Lieferheld? Pizza.de?

Die Usability und die User Experience werden jetzt zum wichtigsten Alleinstellungsmerkmal.

Jetzt könnte man zwar argumentieren das die Emotionalität und die damit einhergehende Identifikation mit der Marke schon ausreicht, aber spätestens wenn der Bestellprozess 2 Klicks mehr braucht wechsle ich den Service, denn das spart Zeit. Einmalig nur 8 Sekunden aber nach 100 Pizzen sind das immerhin 13,3 Minuten meines Lebens. Die Usability und die User Experience werden jetzt zum wichtigsten Alleinstellungsmerkmal. Leider weiß die Agentur davon nichts, da sie mit dem Kunden des Auftraggebers nichts zu tun hat. Der Auftraggeber erfährt von diesem und vielen anderen kleinen Problemen erst wenn das Produkt am Markt ist und das ist für viele Online Startups oder Services ein KnockOut.

Im Gegensatz zum klassischen Wasserfall Prinzip, versucht Scrum einen Prozess transparent, überprüfbar und anpassbar zu machen. Der Kunde bekommt schon während des Prozesses die Möglichkeit sein Produkt zu testen, zu verändern und anzupassen. Merkt er während des Prozesses dass das Produkt eigentlich schon ausreicht um live zu gehen, kann er ihn unterbrechen und alles überflüssige eliminieren. Kleinkonzepte können schon früh überprüft und gegebenenfalls verändert werden.

 So geht Scrum

Voraussetzung  für Scrum ist ein Kunde der will und eine Agentur die kann. Bei Scrum gibt es Rollen die das Scrum-Team bilden. Es ist essentiell das diese standardisierten Rollen eingehalten werden, da es sonst zu immensen Komplikationen im Projektablauf kommen kann. Folgende Rollen gibt es:

Product Owner (PO)

Der Product Owner repräsentiert den Projektverantwortlichen. Er steht dafür gerade was das Team produziert. Er ist für das Produkt Backlog verantwortlich (eine Sammlung der Userstoieres) und priorisiert diese. Am Ende jedes Sprints (Zeitraum in dem Userstories umgesetzt werden)  nimmt er diese ab und gibt sie frei oder lehnt sie ab. Der Product Owner muss nicht zwingende der Kunde sein, repräsentiert aber innerhalb der Agentur den Kunden. Er steht im ständigen Kontakt mit dem Auftraggeber und dem Scrum Master. Er ist verantwortlich dafür dass das Projekt nach jedem Sprint live gehen könnte und optimiert mit seinen Entscheidung den Business-Value (Wie rentabel ist das Produkt) und den Customer-Value (Wie nützlich ist Produkt). Der PO mischt sich niemals in den Arbeitsablauf ein oder versucht das Team zu beeinflussen.

Scrum Master

Der Scrum Master ist Moderator(!). Er hat keinerlei Entscheidungsgewalt und beeinflusst Entscheidungen nur mit Tipps und dann nur äusserst zurückhaltend. Er ist verantwortlich für den Prozess und räumt Hindernisse aus dem Weg. Er hat das Backlog im Blick und dient als Schnittstelle zwischen Team und Product Owner. Idealerweise ist er jemand der sich mit dem technischen Aspekt auskennt aber nicht an diesem beteiligt ist. Er hält dem Team den Rücken frei und tritt in Konfliktfällen als Mediator auf. Er ist weder Teamleiter noch Chef.

Scrum Team

Der Scrum Team ist ein interdisziplinäres Team. Es wird zwar darüber diskutiert ob das sinnvoll ist hat aber einen durchaus gerechtfertigten Grund. Fällt jemand im Team aus, kann ein anderer zweitweise seine Position einnehmen. Nach meiner Erfahrung ist es sinnvoll das jeder alles kann aber zusätzlich eine starke Profilkompetenz mit sich bringt. Ein Team besteht aus 5-10 Personen (z.B Designer, Texter, Frontendentwickler, Backendtwickler, Systemarchitekt, Tester). Das Team organisiert sich selbst und hält täglich ein Daily Scrum (5-10 Minuten) um sich gegenseitig auf den aktuellen Stand zu bringen. Es ist verantwortlich nach jedem Sprint ein Increment of Potentially Shippable Functionality abzuliefern. Das Team ist steht in der Hierarchie weder unter noch über dem PO oder dem Scrum Master.

Vision

Der PO definiert eine Vision der alle Teammitglieder folgen. Eine Vision für eine Pizza Lierferapp wäre z.B.: „Immer einen Klick schneller als die Konkurrenz“. Dieser Satz ist der rote Faden der sich durch die Entwicklung des Produktes zieht und worauf man immer wieder zurückgreift um sicherzustellen das man auf der richtigen Spur ist. Nun wird ein sehr grobes technisches Konzept aufgestellt um die nötige Infrastruktur zu definieren. Das technische Grobkonzept ist kein Bestandteil im klassischen Scrum Prozess, bietet aber den Vorteil Abhängigkeiten im Vorfeld zu klären die den Prozess lahmlegen könnten.

Userstories

Ist das gemeinsam geklärt worden, kommt der wichtigste Teil – die Userstories. Eine Userstory beschreibt einen Wunsch aus der Sicht des Nutzers.* „Als Nutzer möchte ich eine Pizza mit meinem iPhone bestellen“. Die Story sollte so genau wie nötig und so vage wie möglich sein. Der PO präsentiert diese Story zusammen mit den anderen priorisierten Stories im Sprint-Planning, das vor jedem Sprint stattfindet. Darin entscheidet das Scrum welche Stories umgesetzt werden. Das Bahnprojekt hatte insgesamt über 450 Stories und in jedem Sprint wurden, je nach Kapazität und Leistungsfähigkeit des Teams, 3-6 Stories umgesetzt. Um die Einschätzung zu erleichtern hat das Team Kapazitätspunkte, Kappa, die es demokratisch auf die Stories verteilen kann. Die Kappa kann sich erhöhen je eingespielter das team wird.

* Die Userstories werden vom PO zusammengetragen und im Backlog gesammelt. Viele Scrum Projekte visualisieren den Scrum-Prozess an einer Wand und sammeln die Stories auf Postits, sodass jeder jederzeit den Überblick hat wie der Projekt Status ist.

Sprints

Alle Stories werden in sogenannten Sprints umgesetzt. Ein Sprint ist ein fest definierter Zeitraum (time boxed). Üblicherweise 14 – 31 Tage. Zum Start des Projekts wird die ungefähre Anzahl an Sprints eingeschätzt, die das Projektteam braucht um das Produkt abzuschließen. Ein Sprint besteht aus 4 Phasen. Dem Sprint-Planning, der Umsetzung, dem Sprint-Review und der Retrospektive. Das Review dient dazu die umgesetzten Userstories zu präsentieren. Der PO entscheidet an dieser Stelle ob eine Story den definierten Akzeptanzkriterien entspricht und lehnt sie entweder ab oder nimmt sie an. Lehnt er sie ab fließt sie wieder in den Backlog und muss in dem nächsten Sprint fertiggestellt werden. Das Scrum Team hat sich verpflichtet bei jeder Review ein „Increment of Potentially Shippable Functionality“ zu liefern, ein releasefähiges Teilprodukt.

Logischerweise ist das meist nach dem ersten Sprint nicht der Fall aber wenigstens nach drei Sprints sollte ein Produkt stehen das man veröffentlichen kann.

Auch Apple setzt Produkte nach dem Scrum-Prinzip um. Die Idee dahinter nennt sich First-to-market-Strategy.

Hier ein Beispiel: Auch Apple setzt Produkte nach dem Scrum-Prinzip um. Die Idee dahinter nennt sich First-to-market-Strategy. Als erster am Markt sein. Das erste iPhone war Anfangs nur ein Prototyp. Die Apps, der Appstore und die heutigen Features lagen noch alle im Backlog. Sie waren geplant aber noch nicht implementiert. Aber um als ersten am Markt zu sein hat man sich entschlossen schon den ersten realeasefähigen Prototypen zu verkaufen. Der Vorteil liegt klar auf der Hand. Man platziert sich beim Kunden und man kann testen welche Features ankommen und als nächstes implementiert sollten.

Retrospektive

Nach jedem Sprint trifft sich das Team und bespricht was gut gelaufen ist und was nicht. Wird dabei ein  Problem festgestellt, wird es identifiziert, eine Lösung vorgeschlagen und ein Zeitraum sowie eine Person die es aus dem Weg räumt definiert. Das löst nach jedem Sprint die Spannungen und macht das Team produktiver.

Fazit

Scrum ist modern und macht Spaß wenn man sich an die Regeln hält. Es entspricht dem Geist der heutigen Startup Pioniere. Für Agenturen bietet es die Möglichkeit sich zu differenzieren und für den Kunden einen Weg strategischer und kundenorientierter an den Markt zu kommen. Für Unternehmen und Agenturen die starke und tief gewachsene Hierarchien leben ist Scrum allerdings schwer, da man sich von dem klassischen Prozessen lösen muss.