Scrum @Mothership

Einführung und Ausblick

Als E-Commerce-Agentur begegnen uns vielseitige und stetige Herausforderungen. Ob es sich hierbei um ein klassisch-planbares Projekt handelt, aus dem Tagesgeschäft heraus entstandene Anforderungen im Sinne eines Feature-Request, Änderungen durch rechtliche Rahmenbedingungen, oder vielleicht auch einfach nur ein dringender Bug der behoben werden muss.

Letztendlich benötigt es eine geeignete Methodik, um den Umgang mit diesen Herausforderungen zu bewältigen. Nicht nur im Agenturumfeld, sondern insgesamt in der IT-Branche ist die Planung von Projekten nach einem agilen Vorgehensmodell zum de-facto-Standard geworden. Auch wir arbeiten agil, haben jedoch in jahrelanger Erfahrung so einige Erkenntnisse und Erfahrungen gewonnen, die wir im Folgenden mitteilen möchten.

Unsere Ausgangssituation ist das Scrum-Framework, welches wir im Folgenden kurz erläutern, um im Anschluss auf die Besonderheiten im Agenturumfeld und uns im Speziellen einzugehen. Wir geben einen Einblick wie wir die Methodik anwenden, wo sie abweicht und wie wir durch sie unsere Stärken besser ausbauen konnten, aber erörtern auch ihre Limitierungen im täglichen Doing.

Warum wir uns auf das Scrum-Framework eingelassen haben

Die Vorteile von agilen Methoden wie Scrum werden groß beworben und das Framework freut sich damit immer größerer Begeisterung: mit einer kurzen Vorausplanungsphase kann die Entwicklung zeitnah begonnen werden, auch wenn noch nicht alle Anforderungen im Detail final definiert sind. Man sieht bereits nach kurzer Zeit die ersten Resultate und es werden kontinuierlich weitere (Teil-)Ergebnisse durch kompakte Entwicklungszyklen ausgeliefert. Auf mögliche (Markt-)veränderungen die während des Projekts auftreten, kann somit kurzfristig reagiert und das Ziel somit immer weiter ohne großen Overhead angepasst werden. Die im Wasserfall-Modell gefürchteten Änderungswünsche (Change Requests) sind somit nicht nur einfacher möglich, sondern sogar erwünscht, um die gemeinsame Produktvision zu realisieren. Auch wenn nur ein Ausschnitt, sind das für uns alles wichtige Vorteile die auch uns in seinen Bann gezogen haben um uns näher an das Scrum Framework anzunähern. Mögliche Nachteile wie der gefühlte „Kommunikations-Overhead“ durch die vielen Termine, die in der Theorie definiert sind, die zu kurz-kommende Gesamtprojektplanung mit einer einhergehender Kosten- und Zeiteinschätzung, sowie dem erhöhten Testaufwand während der gesamten Projektlaufzeit werden daher oft in den Hintergrund gestellt. Wichtige Punkte die auch wir zum Teil für uns als Nachteile erkannt haben, insbesondere als Dienstleister, aber dazu mehr im Folgenden.

Das agile Manifesto als Grundpfeiler

Ausgehend vom „Scrum Guide" von Ken Schwaber und Jeff Sutherland, dem Basisdokument des Frameworks könnte man annehmen, dass die von uns auserkorene Methode nicht das ideale Mittel ist, um im Agenturumfeld eingesetzt zu werden. Es scheint mehr ausgelegt zu sein für:

• Ein in sich abgeschlossenes, abgestecktes Produkt pro Team.
• Ein Entwicklungsumfeld ohne ungeplante, dringende Anforderungen die während eines Live Betriebs aufkommen und nicht bis zum nächsten Sprint warten können.
• Eine Vollzeit-Besetzung und unantastbare Authorität und Gleichstellung der Rollen, insbesondere des einen Product Owners, unabhängig eines Dienstleister-Kunden-Verhältnisses.
• Ein autonomes Teamgefüge, welches keine Abhängigkeiten beherbergt wie es der limitierte Einfluss auf außenstehende Ressourcen wie den Kunden als Input- und Feedback-Ressource oder weiteren Drittanbietersystemen darstellen.

An dieser Stelle möchten wir im Kurzen auf die Grundidee der agilen Entwicklung eingehen, insbesondere das Agile Manifest, welches das agile Verständnis wie folgt ausdrückt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans


• Es wurde schon oft erwähnt, aber auch das Scrum-Framework ist und bleibt ein Toolset. Intern sagen wir gerne: „Wir machen uns nicht zu den Sklaven unserer Prozesse“. Und genau das ist auch unser agiles Verständnis. Im Folgenden zeigen wir, wie wir unsere täglichen Herausforderungen mit der Hilfe und trotz des Frameworks bewältigen.

  „Unser Produkt“

  Als Dienstleister mit mehreren Kunden scheint es natürlich die jeweiligen zu betreuenden Systeme der Kunden als unabhängige „Produkte“ zu sehen. Diese in unabhängigen Subteams voneinander zu betreuen, ggf. sogar mit unterschiedlichen Projektmanagement-Methoden zu begleiten. Auch wir haben hier die Systemlandschaften der Kunden als weitestgehend voneinander unabhängig gemanagt, uns je nach Projektphase an Scrum oder Kanban angelehnt und diese auch in unabhängigen Projektteams und -boards verwaltet.
  Mit der Zeit haben wir aber erkannt, dass wir dadurch unter anderem eine übergreifende Gesamtplanung für uns als Team benötigen um unsere interne Ressourcenplanung und grundsätzliche Kommunikation/Abstimmungsabläufe zu vereinfachen, sowie auch besser von den Synergieeffekten der verschiedenen Projekte zu profitieren, bzw. diese Effekte besser an unsere Kunden weiter geben zu können. Wir haben somit einen Gesamtsprint mit allen Kundenprojekten geschaffen, den wir als komplettes Team gemeinsam planen. Kein Silodenken in der Projektplanung mehr. Diesem für uns wichtigen Schritt an die Annäherung des Framework-Ideals ist eine noch wichtigere Entscheidung vorausgegangen: Wir haben uns von dem reinen umsetzenden Dienstleister-Dasein-Gedanken verabschiedet und verstehen uns als E-Commerce-System Beratung inklusive Umsetzung. „Unser Produkt“ ist daher nicht auf ein Shop System allgemein, wie Shopware, oder gar ein Shop System von Kunde X limitiert. Unsere Produktvision ist es das bestmögliche E-Commerce-Erlebnis für unsere Kunden aus den jeweiligen Systemen hervor zu holen. Dabei lassen wir uns nicht von einem System limitieren, berücksichtigen unterschiedliche Best-Practices und übertragen diese sinngemäß auf die verschiedenen Umgebungen. Die Kundenprozesse stehen bei uns im Vordergrund und wir beraten und personalisieren diese entsprechend von der Auswahl des Shopsystems bis zur Anbindung an bestehende Drittsysteme wie einem ERP. Ob Magento in der Community Version, Magento 2, Shopware 5, Shopware 6 oder BigCommerce, jede durchgeführte Migration von einem zum anderem Shopsystem wie z.B. Magento 1 zu Shopware 6, jedes Neu-Aufsetzen von einem System auf einer grünen Wiese, jede kleine und große Kundenanforderung innerhalb des E-Commerce Systems, jeder noch so kleine Bugfix und auch jedes kundenunabhängige Plugin welches wir im Store zur Verfügung stellen, trägt dieser Vision bei. Wir haben uns von dem Standpunkt der komplexen Herausforderung mit mehreren Kunden parallel zu arbeiten verabschiedet und schätzen stattdessen durch diese Anpassung in unserer Arbeitsweise die Erfahrung mit verschiedenen Kunden in verschiedenen Stadien, mit verschiedenen Anwendern, Business Prozessen und innerhalb unterschiedlichster Systemlandschaften zu arbeiten. Die daraus gewonnenen Synergieeffekte unter so vielen diversen Begebenheiten am gleichen Core Gedanken zu arbeiten, geben wir auch direkt an den Kunden zurück, welcher dadurch unseren reichen Erfahrungsschatz mit „unserem Produkt“ schätzt und sich über reduzierte Aufwände bei ähnlichen Anforderungsumsetzungen, Früherkennungen von Bugs und Problemen sowie unserem eingespielten Maintenance-Modus erfreut.

Das Team, der Projektmanager, die Rollen des Product Owners und Scrum Masters

Die Aufgaben der drei Rollen - des Entwicklers, des Scrum Masters und des Product Owners - in die sich das Scrum Team herunter bricht, sind in unserer Interpretation, entgegen des theoretischen Ideals, dezentralisiert aufgeteilt. Entgegen einer klassischen Aufgaben- und Rollenverteilung verstehen sich bei uns Führungskräfte, Entwickler und Projektmanager gleichermaßen alle als E-Commerce-Consultants die gemeinsam mit dem „erweiterten Team“, welches sich durch die Kundenansprechpartner ergänzt, die Maximierung des Werts des Kundenshops zum Ziel hat. Ein simples Abarbeiten gestellter Aufgaben entspricht nicht unserer DNA und zahlt nicht auf die Vision unseres Produktes ein.
Im täglichen Doing sieht das dann so aus, dass insbesondere die Aufgaben des Product Owners auf das eben benannte erweiterte Team fällt. Kundenansprechpartner, unsere Führungskräfte und je nach Projektstand Projektmanager und Entwickler sind in engem Kontakt über unser Ticketsystem aber auch in persönlichen, regelmäßigen Absprachen. Alle Parteien erstellen neue Stories und Bugtickets für den Product-Backlog und teilen Projektideen zur Maximierung des Product Values. Die erstellten Tickets werden dann gemeinsam besprochen, priorisiert und die grobe Sprintplanung übernommen. Mehr dazu in den nächsten Abschnitten. In einer weitestgehend unterstützenden Kapazität beraten wir proaktiv hinsichtlich geänderter Rahmenbedingungen, potentielle Wettbewerbsgefahren- und Chancen sowie Sicherheitsthemen des Online Shopsystems. Der Hauptanteil des Stakeholdermanagement innerhalb der Kundenunternehmen hingegen obliegt hierbei den Kundenansprechpartnern. Diese Aufteilung und enge Abstimmung auf jeweiliger Team-Kunden-Ebene lässt uns unsere Beratungsstärke am Besten entfalten und ist somit bewusst im eindeutigen Gegensatz zur einen Person welche den Product-Owner für das Entwicklungsteam Kundenübergreifend im Ideal Szenario besetzt.

Anders ist unsere Aufgabenteilung bei der Rolle des Scrum-Masters, welche hauptsächlich im Projektmanagement bei uns angesiedelt sind. Insbesondere die Einführung und Begleitung der Methodik sowie die Moderation der Meetings liegen beim Projektmanager bzw. dem Scrum-Master, wobei das Beseitigen von Hindernissen bei uns recht selbstständig angegangen und somit weniger vom Scrum-Master initiiert und geführt wird.

Unser tägliches Doing – (Kunden)Kommunikation und Termine

Neben den beschriebenen Rollen haben wir uns auch mit dem definierten Bündel an Terminen, also der geplanten Kommunikation befasst. Von Anbeginn der Teamformation bei Mothership haben wir Wert auf einen regen Austausch mit unseren Kunden gelegt, da uns die Transparenz und Nachvollziehbarkeit unserer Tätigkeit sehr wichtig ist. Intern ist hierfür ein wichtiges Tool dabei das Daily-Standup, welches wir recht nah am Ideal jeden Werktag, morgens für ca 10-15 Minuten nutzen um uns gegenseitig über unseren Fortschritt, Ziele und Hindernisse auszutauschen.
Auch eine Form des Sprint-Plannings hat es in abgewandelter Form schon jeher gegeben und wurde speziell im vergangenen Jahr sehr an das Scrum-Ideal angenähert. In den Jour Fixes mit den Kunden werden dafür regelmäßig der aktuelle, sowie auch die kommenden „vorgeplanten“ Sprints besprochen, die endgültige Planung, wie sich der Sprint Backlog dann zusammenstellt, erfolgt jedoch ausschließlich intern. Durch das im Refinement stattfindende Schätzen der Aufgaben in Story Points gibt uns die Sprint Velocity Berechnung bereits für die Kundenabstimmungen einen Ausblick wieviele Tickets im Sprint umgesetzt werden können. Zum Abschluss des Entwicklungszyklus gibt es bei uns kein klassisches Review Meeting. Dieses wird teilweise durch die Vorstellung des Entwickelten in den Jour Fixes mit dem Kunden ersetzt. Wo es Sinn macht machen wir auch Sprintunabhängige interne Wissenstranstranfers- oder externe Schulungstermine. Auch die Retrospective ist bei uns nicht regelmäßig und auf den jeweiligen Sprint bezogen sondern wird ad hoc bei Bedarf, bzw. nach größeren Projekten mit oder ohne den Kunden abgehalten. Insbesondere die Nicht-Regelmäßigkeit der Retro wird jedoch teilweise durch die aktive Kommunikation ersetzt, Prozessverbesserungen werden im Team besprochen und meist gleich ausprobiert.

Projektmanagement innerhalb des Frameworks

Insbesondere als Dienstleister ist es sinnvoll und meist auch vom Kunden gewünscht, einen Projektplan mit Abhängigkeiten, Aufwänden und Zeitangaben als Basis vor Projektstart bzw. upgedated jederzeit während der Entwicklung zur Verfügung zu haben. Ein Overhead der nicht wirklich in Scrum vorgesehen ist, aber eine Notwendigkeit für uns bei der wir unterschiedliche Methoden und Dokumentationsvarianten für die kurz- mittel- und langfristige Projektplanung im Einsatz haben.
Für ein klassisches abgeschlossenes Projekt bis es in den Maintenance-Modus übergeht, bietet sich insbesondere als Basis für die Aufwandschätzung ein klassischer Projektplan an. Dieser beinhaltet unter anderem die Hauptfeatures, Input-Tasks für den Kunden und uns, aber auch Deadlines. Alles auf einem top-level ohne zu viel Zeit für die Detailplanung zu investieren. Ist dieser Plan abgestimmt wird er bei Projektstart in unser Ticketsystem Jira in Form von Epics (eine Zusammenfassung mehrerer Anforderungen auf höherer Ebene) übertragen um dann in die Detailplanung durch die Erstellung der einzelnen Tasks und Stories über zu gehen. Um aber im agilen Mindset zu bleiben, limitiert sich die Detailplanung erst einmal für den bzw. die ersten Sprint(s). Die kurzfristige Planung basiert somit auf dem aktuellen bzw. nächsten Sprint und geht in die mittelfristige Planung durch die Vorausplanung auf die darauffolgenden 2-3 Sprints weiter. Ein fortlaufender Prozess der es uns erlaubt vorausschauend jedoch gleichzeitig flexibel zu planen, denn nur ein aktiver Sprint wird in seinem Umfang im Idealfall nicht geändert.
Um aus Projektmanagement-Sicht den Prozess zu vervollständigen, werden Abhängigkeiten und Deadlines auf Ticket- oder Epic-Ebene festgehalten und verwaltet, und verschiedene Tools helfen bei der Darstellung eines „lebenden“ Projektplanes als Basis für die Meilensteinbetrachtung.
Um die Agilität zu bewahren und schnell auf Änderungen reagieren zu können haben wir uns für einen 2-wöchigen Sprintzyklus entschieden. Sprintziele helfen uns hierbei "On Track" zu bleiben und sind auf Kundenebene formuliert bzw. teilweise auch auf Teammitgliedebene wie es zum Beispiel bei Maintenance-Aufgaben sinnvoll ist.

Was bleiben weiterhin Herausforderungen und wie gehen wir damit um?

Wie beschrieben haben wir die wohl bekannteste Methode schon sehr ergänzt, umgebogen und das Beste daraus für uns im Einsatz und dennoch bleiben für uns Herausforderungen an denen wir immer weiter arbeiten, um auch hier eine für uns und unsere Kunden passende(re) Lösung zu finden. So ist unser begrenzter Einfluss auf das Sprint Committment alle eingeplanten Aufgaben im geplanten Sprint zu schließen ein Punkt den wir nicht ganzheitlich im Team beeinflussen können. Zum einen sehen wir den Kunden als Teil des Teams, der mittestet, wertvolles Feedback bei aufkommenden Fragen geben muss und auch seine eigenen Aufgaben im Sprint hat und zum Anderen ist die Abhängigkeit von Drittsystemen die an das Shopsystem angebunden sind ein stetiger Begleiter im Sprint. Ein autarkes Abarbeiten ist daher selten möglich und wir haben die Situation, dass wir auf externe Teammitglieder auf Kundenseite als Ressourcen keinen volle Verfügbarkeit haben. Es gibt ein gemeinsames Ziel und doch hat jeder sein eigenes Tagesgeschäft welches ggf. einer anderen Priorisierung unterliegt. Vorbereitung und Verständnis schaffen erleichtert die Planung und Umsetzung bis zu einem gewissen Punkt, kommt aber auch an seine Limitierungen.
Eine weitere Eigenschaft aus unserem Agenturleben welche uns stetig begleiten wird ist die Priorisierung in den Plannings. Nicht innerhalb des einzelnen Kundenprojektes, aber zwischen den meist unabhängig-voneinander jedoch parallel-laufenden Projekten. Aber das dürfte auch für jedes andere, auch interne Team eine bewährte Herausforderung sein, denn insbesondere Entwicklerressourcen sind nun einmal begehrt und begrenzt, daher ist dies nicht unbedingt auf das Agenturumfeld einzugrenzen. Unsere Erfahrung ist hier der Schlüssel zur Einschätzung um die Aufgaben zu priorisieren und einen ausgewogenen Sprint Backlog zu erstellen. Die gemeinsame Vorausplanung der Sprints mit dem Kunden sowie die stetige Kommunikation haben uns einen Vertrauensvorsprung gewährt, dass die wichtigsten, dringendsten Themen vorgezogen werden und große Konflikte können dadurch vermieden werden.

Fazit – Nicht ganz Scrum aber für uns ideal agil

Wir befinden uns auch weiterhin noch auf der Reise der Agilität, getreu dem Motto: Die Reise ist das Ziel. Wir werden weiter an Prozessen, Definitionen und Abläufen optimieren, getroffene Entscheidungen immer wieder hinterfragen. Ja, auch das Scrum Toolset was den größten Einfluss auf unsere tägliche Arbeit hat wird weiter auf dem Prüfstand bleiben, ob es uns weiterhin von unseren Stärken profitieren lässt. Was uns bisher klar geworden ist, wir fühlen uns mit dem agilen Mindset sehr verbunden und sehen aktuell weitestgehend das Scrum Famework für uns passend, wenngleich auch dieses nicht zu 100% sitzt. Scrum in seiner „Rohform“ zeigt uns einige Eigenschaften welche uns einschränken. Der Terminoverhead den wir auf unsere Bedürfnisse reduziert haben, die Rollen deren Aufgaben auf mehrere Personen verteilt wurden, sowie gewisse Voraussetzungen, wie das „eine“ Produkt, ein übergreifendes Sprintziel und andere Definitionen die so bei uns nicht klassisch interpretiert werden. Doch bisher arbeiten wir alles in allem gerne, effektiv und für uns optimiert im „scrumish way“.