Wie Sie sich denken können unterscheidet sich der Alltag einer Digitalagentur wesentlich zu jenem in der Software- oder Produktentwicklung. Daher haben wir zu Beginn unserer Scrum Einführung (*natürlich unter Berücksichtigung der Scrum Regeln) einige Rahmenbedingungen geschaffen, um unsere Projekte erfolgreich umzusetzen und den Support sowie die fortlaufende Weiterentwicklung garantieren zu können.
1. Arbeitswoche: 40 Stunden I Projektanzahl: Trillionen
Unsere Scrum Teams müssen täglich gefühlte 100 Projekte gleichzeitig behandeln und diese haben - wie könnte es anders sein - oft ähnliche Dringlichkeitsstufen. Deshalb wird der Fokus in den Sprints auf jeweils einige wenige Projekte gelegt. Die Ressourcen unserer Entwickler müssen bestmöglich gebündelt werden. So liefern wir, trotz höchster Projektvielfalt, Premiumqualität - in time and budget.
2. Verschiedene Projekte - verschiedene Kompetenzen
Innerhalb eines Sprints kann es schon einmal vorkommen, dass bestimmte Kompetenzen häufiger benötigt werden, als andere. Damit die Entwickler in den Scrum Teams möglichst gleichmässig ausgelastet sind, versuchen die Product Owner das Sprint Backlog so zu priorisieren, dass die Auswahl der User Stories nach den verfügbaren Kompetenzen erfolgt. Grundsätzlich gilt: die Teams sind so zusammengestellt, dass möglichst alle erforderlichen Kompetenzen vorhanden sind. In Ausnahmefällen übergeben wir einzelne Stories auch an andere Umsetzungsteams.
3. x Kunden - 1 Tool
Jeder unserer Product Owner betreut eine Vielzahl von Kunden und steht laufend mit ihnen im Austausch. Für eine transparente und geordnete Kommunikation - sowohl intern als auch extern - haben wir Trello als Waffe der Wahl auserkoren. Natürlich begnügen wir uns zwischendurch auch Mal mit E-Mails oder Telefonaten, aber jeder Task resultiert in einer Trello-Karte. Je nach Dringlichkeit als User Story, Support Task oder Impediment.
4. Due date: Yesterday
Ein Schlüssel zum Erfolg ist die Einhaltung von Fristen und Regeln sowie eine intensive Zusammenarbeit mit unseren Kunden. Anforderungen, Abnahmen und Sprint Priorisierungen müssen fristgerecht mit den Kunden vorgenommen werden, damit der Scrum Prozess nicht aufgehalten wird. Daher klären wir diese Rahmenbedingungen bereits im Vorfeld mit unseren Kunden ab. Diese müssen allerdings auch von beiden Seiten eingehalten werden, ansonsten kann dies darin resultieren, dass Stories nicht in den kommenden Sprint aufgenommen werden können. Die Folge davon:
- Verzögerungen,
- unglückliche Kunden,
- gestresste Entwickler und Product Owner sowie
- Mehraufwände für alle Beteiligten.
5. Impediments: Shit happens
Und zwar wortwörtlich. Impediments sind schwerwiegende, geschäftsschädigende Probleme. Sie beeinträchtigen die Funktionstüchtigkeit eines Systems gravierend. Wenn ein Kunde zornentbrannt versucht den “Bezahlen”-Button im Online Shop anzuklicken und nicht weiter kommt - sagen wir Mal so: am Schluss ist der User nicht der Einzige der fluchend vor dem Computer sitzt. Impediments treten unangekündigt und immer dann auf, wenn man sie am wenigsten brauchen kann.
Tritt ein Impediment auf, unterbricht das Umsetzungsteam die Arbeit an den geplanten User Stories und kümmert sich sofort um die Behebung des Problems.
Ein Vorteil von Scrum ist, dass es durch
- die Definition von Akzeptanzkriterien,
- der gemeinsamen Planung der Stories im Umsetzungsteam,
- der Einhaltung des Levels of Done,
- dem Review und
- der Abnahme durch den Kunden
zu einer signifikanten Qualitätssteigerung des Produktes kommt und infolgedessen zu weniger Impediments. Anhand unserer Erfahrungen mit Scrum können wir dies auch absolut bestätigen.
6. Support: You call, we make it work.
Unter Support fallen Aufgaben, welche nicht direkt die Funktionstüchtigkeit eines Systems beeinflussen, aber dennoch für unsere Kunden eine hohe Dringlichkeit besitzen (z.B. Aktualisierung einer Übersetzungsdatei oder die Anpassung an einer bestehenden Funktionalität). In der Regel treten Supportfälle unerwartet auf: zumindest auf unserer Seite.
Gemeinsam versuchen Product Owner und Kunde die Dringlichkeit und Wichtigkeit des gemeldeten Supportfalls zu ermitteln. Dieser ist offensichtlich immer “dunkelrot”, sonst hätte uns der Kunde ja nicht kontaktiert. Wenn innerhalb eines Sprints unerwartet viele Supportfälle anfallen, kann der Aufwand für diese zu Lasten des Commitments gehen. Das bedeutet, dass nicht alle zugesagten User Stories umgesetzt werden können.
Deswegen versuchen unsere Product Owner Supportfälle als Story in den kommenden Sprint einzuplanen, um das Commitment – auch anderen Kunden gegenüber – einhalten zu können. Stories haben gegenüber Supports den Vorteil, dass die Anforderungen genau erhoben und im Backlog Refinement und im Planning ausführlich erörtert werden, damit wir unserem Qualitätsanspruch gerecht werden und alle Eventualitäten abdecken.
7. Beeinflussung des Commitments durch Impediments und Support
Im Sprint Planning setzen sich die Umsetzungsteams die Erfüllung einer bestimmten Anzahl von Stories zum Ziel, welche sie innerhalb eines Sprints erreichen wollen. Dieses Commitment beruht auf den geplanten User Stories und berücksichtigt zu einem gewissen Grad auch eventuell auftretende Supportleistungen - just to be safe! Wenn jedoch die Impediments und Supports in einem Sprint Überhand nehmen, dann stellt dies eine Gefahr für die Erreichung des Commitments dar. Wir können daher nie zu 100 % gewährleisten, dass das Commitment erreicht werden kann. Wir geben aber natürlich immer unser Bestes!
8. Mitwirkungspflicht des Kunden: We work together
Wie die letzten Punkte zeigen, ist die Mitwirkung des Kunden bei der Durchführung unserer Projekte mit Scrum unerlässlich. Es müssen:
- die Anforderungen an User Stories kommuniziert,
- die Akzeptanzkriterien (inkl. UX/ UI) freigegeben,
- die umgesetzten Lösungen bzw. Erweiterungen abgenommen und
- das Backlog priorisiert werden.
Bei MASSIVE ART stehen unsere Product Owner daher in engem Kontakt mit unseren Kunden, um diese Abstimmungen in Form von regelmässigen Terminen vor und nach jedem Sprint mit unseren Kunden vorzunehmen.
Bedeutung der Akzeptanzkriterien
Die Akzeptanzkriterien beschreiben alle Aspekte die mit der User Story erreicht werden sollen und müssen vom Kunden geprüft und freigegeben werden. Auf Basis dieser plant das Umsetzungsteam anschliessend die User Story und setzt diese um. Nach der Freigabe sollten Änderungen an den Akzeptanzkriterien oder Zusatzanforderungen unbedingt vermieden werden. Ansonsten müssen neue Schätzungen vorgenommen werden und das hat Auswirkungen auf das Budget und die Planung.
Abnahme durch den Kunden
Nach der Umsetzung wird die User Story dem Kunden zur Abnahme präsentiert. Sie wird dann innerhalb eines definierten Zeitraums vom Kunden geprüft und abgenommen.
Backlog Priorisierung mit dem Kunden
Eine regelmässige Organisation und Priorisierung zwischen Kunde und Product Owner ist unerlässlich, um zu bestimmen welche User Stories aus Kundensicht vorrangig umgesetzt werden sollen.
Fazit
Obwohl uns diese Herausforderungen manchmal wirklich zu schaffen mach(t)en, sind wir dennoch von Scrum überzeugt. Wir sehen Scrum als DIE bewährte Methodik, um komplexe Webprojekte in time and budget umzusetzen.
*Für alle die mit Scrum (noch) nichts am Hut haben, gibt es im Blogbeitrag "Flexibilität statt starrer Reglen: Projektmanagement mit Scrum bei MASSIVE ART" alle wichtigen Begriffe erklärt.
