In unserem ersten Artikel zu agilem Projektmanagement mit Scrum haben wir bereits ein wenig erläutert, wie Projekte mit Scrum vorbereitet, geplant und umgesetzt werden. Und so aufwändig es sein kann, ein Projekt erfolgreich agil im eigenen Haus umzusetzen (zumal dies ein klares Commitment aus dem Management erfordert und oft auf interne Widerstände stößt), so sehr ist es eine Herausforderung, agil mit einer Agentur zusammenzuarbeiten.
In diesem Artikel geht es darum, wie die Zusammenarbeit mit einer Agentur möglichst entspannt funktioniert, wenn sie (oder ein anderer Dienstleister) für Ihr Unternehmen ein Projekt in agiler Arbeitsweise umsetzt. Schnallen Sie sich an, es wird ein spannender Ritt!
Überblick
- Ist eine agile Umsetzung nach Scrum überhaupt sinnvoll?
- Es geht los: Vision und User Stories statt Briefing
- Zeit und Geld
- Zusammenarbeit
- Wofür der ganze Aufwand?
Ist eine agile Umsetzung nach Scrum überhaupt sinnvoll?
Bevor es überhaupt an die Umsetzung geht, wird eine gute Agentur gemeinsam mit Ihnen prüfen, ob eine agile Umsetzung für Ihr Projekt überhaupt sinnvoll ist. Als Faustregel gilt: Je kleiner und übersichtlicher das Projekt ist, umso weniger eignet es sich für eine agile Vorgehensweise nach Scrum.
Insbesondere Routineaufgaben, die zum wiederholten Mal auf die immergleiche Weise umgesetzt werden, produzieren zu viel Overhead: Überflüssige Meetings, unnötige Abstimmungen zu Themen, die allen Beteiligten eigentlich schon klar sind.
Wenn die Ausgangsbasis des Projekts also bekannt ist, das Endergebnis bereits allen klar vor Augen steht und sie Verlauf und Ende des Projekts schon kennen, dann ist eine agile Umsetzung weder nötig noch sinnvoll.
Projekte klassifizieren: Die Stacey-Matrix
Ein Hilfsmittel, das bei der Entscheidung zu Rate gezogen werden kann, ist zum Beispiel die Stacey-Matrix, benannt nach dem britischen Management-Professor Ralph Douglas Stacey, der damit die Komplexität von Problemen bzw. Projekten zu beschreiben versucht hat. Auf der horizontalen x-Achse dieser Matrix wird dazu beschrieben, wie ein Problem gelöst werden soll („wie“- oder „Technologie“-Achse), in der Vertikalen („was“- oder „Anforderung“-Achse) wird beschrieben, welche Ziele erreicht, welche Anforderungen erfüllt werden müssen.
Je eher sich alle Beteiligten einig und sicher sind, welche Vorgehensweisen, welche Methoden zur Lösung des Problems anzuwenden sind und welche Anforderungen und Ziele eigentlich erfüllt bzw. erreicht werden müssen, desto näher ist das Projekt in der linken unteren Ecke (dem „Nullpunkt“) der Matrix anzusiedeln.
Dem Chaos agil Struktur schenken
Herrscht jedoch Unklarheit darüber, auf welchem Wege das Problem gelöst, das Projekt abgeschlossen werden kann, rutscht das Projekt in der Matrix nach rechts. Wenn größere Uneinigkeit darüber besteht, welche Ziele eigentlich erreicht werden sollen, bewegt es sich nach oben. Projekte können so von „Einfach“ über verschiedene – mehr oder minder arbiträr benannte – Stufen bis hin zu „Chaotisch“ eingestuft werden. Je „chaotischer“ ein Projekt zu Beginn wirkt, umso sinnvoller ist eine Umsetzung mit agiler Vorgehensweise.
Das mag zunächst kontraintuitiv wirken, weil von außen betrachtet auch das agile Vorgehen ja leicht chaotisch wirkt – tatsächlich macht es aber die agile Vorgehensweise viel leichter, hier schrittweise Ordnung ins Chaos zu bringen.
Zugleich besteht die Möglichkeit, mit der Arbeit schon zu beginnen, auch wenn noch nicht alle Anforderungen vollständig bekannt oder definiert sind – ein Umstand, der vor allem bei größeren Projekten vorkommt und sonst schnell zu Verzögerungen führen kann. Die Anpassungsfähigkeit, die Agilität eines mit Scrum durchgeführten Projekts kann diese Unsicherheiten und selektiven Verspätungen auffangen. Sollten sich die Anforderungen im Lauf des Projektes noch ändern, kann das Projekt bei agiler Arbeitsweise in der Regel leicht angepasst werden.
Scrum braucht Bereitschaft
Die wichtigste Voraussetzung für ein agiles Projekt ist allerdings, dass Sie bereit sind, sich auf die damit verbundenen Änderungen in Ihrer Arbeitsweise einzulassen. Wenn Ihr Projekt von einer externen Agentur agil nach Scrum umgesetzt wird, müssen Sie nicht Ihre ganze Arbeitsweise umstellen oder gar Ihr ganzes Unternehmen agil arbeiten lassen – das wäre oft auch nicht wirklich sinnvoll.
Aber Sie und alle direkt beteiligten Personen – das sind insbesondere alle Stakeholder, die für und über das Projekt Entscheidungen treffen müssen – sollten die Bereitschaft mitbringen, sich auf die Dynamik der Sprints einzulassen. Sie sollten von Anfang an mitwirken, zum Beispiel bei gemeinsamen Workshops, müssen aber insbesondere bereit sein, die regelmäßig stattfindenden Termine für die Sprint Reviews wahrzunehmen und daran aktiv teilzunehmen.
Was die Agentur von Ihnen braucht:
- den Willen und die Fähigkeit (auch die Berechtigung), in den Sprint Reviews kurzfristig Entscheidungen zu treffen,
- den Willen und die Bereitschaft, für den jeweils folgenden Sprint Aufgaben und umzusetzende User Stories zu priorisieren sowie
- ausreichend Zeit und Ressourcen dafür, sich eng und kurzfristig mit dem Product Owner abzustimmen, der auf Seite der Agentur die Anforderungen bzw. User Stories verstehen muss.
Nur so kann das Team kontinuierlich weiterarbeiten, nur so funktioniert die Aufteilung in Sprints wirklich in dem dynamischen Sinn, den Scrum anstrebt.
Es geht los: Vision und User Stories statt Briefing
Vielleicht haben Sie sich, bevor Sie nach einer Agentur gesucht haben, schon sehr ausführliche Gedanken gemacht, haben sich die Mühe gemacht, mit allen Stakeholdern im Unternehmen zu sprechen, haben schließlich ein ausführliches Briefing verfasst, in dem Ihr Projekt, vielleicht ein Website-Relaunch, ausführlich beschrieben ist. Da steht also drin, welche Funktionen die neue Website braucht, wie sie aussehen soll, welche Zeitrahmen zu beachten sind, welche Zielgruppen es zu beachten gibt usw.
Und nun möchte die Agentur mit Ihnen nicht im Detail über das Briefing sprechen, sondern vielleicht eine Reihe von Workshops machen, um die „Vision“ zu besprechen, um „User Stories“ zu entwickeln. Was soll das denn?
Kann ich mein Briefing jetzt wegwerfen?
Die „Vision“, das hatten wir im letzten Artikel schon beschrieben, ist eine klare, in wenigen Sätzen umrissene Vorstellung davon, was das Endprodukt, zum Beispiel Ihre neue Website, erreichen soll.
Die Vision beschreibt wirklich nur den Kern der Zielsetzung, nicht einzelne Anforderungen. Vielleicht haben Sie diese im Vorfeld schon selbst erarbeitet – umso besser! Aber das bedeutet keineswegs, dass ein bereits vorhandenes Briefing sinnlos ist. Im Gegenteil! Eine Vision und die detaillierten User Stories – also Anforderungen an das Projekt aus Sicht ganz konkreter Benutzer – werden Sie sinnvollerweise gemeinsam mit der Agentur in Workshops erarbeiten. Eine gute Agentur wird den Inhalt eines schon existierenden Briefings natürlich aufnehmen und dafür sorgen, dass Anforderungen und Wünsche, die im Briefing schon formuliert wurden, auch in die Workshops eingehen.
Von Anfang an miteinander sprechen
Agiles Arbeiten nach Scrum ist wesentlich durch Kommunikation bestimmt. Also auch dadurch, dass alle gemeinsam ein Verständnis davon entwickeln, wie das aussehen soll und kann – und auch, welche Beschränkungen es womöglich gibt, welche widerstreitenden Interessen. Es kann gut sein, dass zwei Personen oder Abteilungen in Ihrem Unternehmen ganz unterschiedliche Vorstellungen davon haben, was Ihre neue Website können und leisten soll – vielleicht sind dies auch Ideen, die sich zunächst zu widersprechen scheinen.
Solche Konflikte möglichst frühzeitig sichtbar zu machen ist für agiles Arbeiten enorm wichtig, damit aus Widersprüchen nicht wirkliche Probleme entstehen. Moderierte Gespräche und Diskussionen sind dafür genau der richtige Rahmen – ob das dann konkret in einem Workshop passiert oder in einer anderen Form, können Sie gemeinsam mit Ihrer Agentur bestimmen
Auf jeden Fall bietet sich so die Möglichkeit, dass sich alle Beteiligten kennenlernen und bereits miteinander abklären, wie genau das agile Arbeiten anschließend organisiert werden soll. So lassen sich die regelmäßigen Abläufe der Sprints frühzeitig organisieren und abstimmen, damit sie wirklich für alle Stakeholder und das Team gleichermaßen passen. Die wichtigsten Entscheidungen dafür sollten vorab getroffen sein, bevor es wirklich losgeht.
Wer muss mitmachen?
Damit ein Scrum-Projekt reibungslos ablaufen kann, ist es wichtig, dass von Anfang an und kontinuierlich alle entscheidenden Stakeholder eingebunden sind. Es sollten also alle Menschen an den Tisch geholt werden, die beispielsweise für ihren Website-Relaunch Wichtiges beizutragen haben: Menschen aus dem Marketing, dem Personalbereich, der Sales-Abteilung.
Alle entscheidenden Stakeholder müssen von Anfang an eingebunden sein.
Sie sollten bei den Workshops zu Beginn dabei sein und sich auch während der ganzen Projektdauer immer wieder Zeit für die regelmäßigen Sprint Review-Termine freiräumen – oder jemanden beauftragen, der auf diesen Terminen dann aber auch Entscheidungen treffen darf.
Wir formulieren gemeinsam eine Vision
Die gemeinsame Vision des Projekts, das „Big Picture“ soll, wie oben gesagt, in wenigen Sätzen eine Vorstellung davon wiedergeben, was das Endprodukt erreichen soll. Dafür sollte sie sich im Wesentlichen aus drei zentralen Informationsclustern speisen:
- Zielgruppe(n): Wen wollen Sie mit ihrer neuen Website ansprechen?
- Bedürfnisse: Welche Probleme der Zielgruppe sollen mit der Website angesprochen, gar gelöst werden?
- Produktskizze: Wie soll – in sehr groben Zügen – das Produkt am Ende verfasst sein? Hier genügt es zum Beispiel schon, von einer „Website“ zu sprechen und eine kleine Handvoll an zentralen Features anzureißen.
Zugleich soll die Vision über das reine Produkt hinausweisen, soll also tatsächlich im Wortsinn „visionär“ sein: Wo wollen wir in naher Zukunft stehen? Warum tun wir das, was wir tun? Wo wollen wir damit hin? Sie kann deshalb durchaus emotional, auch mitreißend formuliert sein.
Auf keinen Fall darf die Vision sich in Details verlieren, zu genau geraten; Ihr Zweck ist es, das zentrale Ziel des Projektes so zu fassen, dass sie als Perspektive dienen kann, an der sich das gesamte Projekt – und damit: alle am Projekt Mitarbeitenden – orientieren kann.
Zuweilen wird empfohlen, sich die Vision als „Elevator Pitch“ vorzustellen, wie man ihn etwa aus der Startup-Szene kennt: Sie haben 30 Sekunden Zeit, um Ihrem Chef oder Investor während einer Aufzugfahrt von Ihrem Projekt zu begeistern. Wie formulieren Sie das knackig?
SHIELD: Kriterien für eine Vision
Die wünschenswerten Kriterien für eine Vision werden oft im Akronym SHIELD (engl. für Schild, Schutz) zusammengefasst:
- Simple (einfach): Die Vision ist in einfachen Worten formuliert.
- Huge (groß): Die Vision soll das Potential einer Idee widerspiegeln, Platz für Wachstum lassen.
- Important (wichtig): Die Vision enthält nur Wichtiges.
- Engaging (einnehmend): Die Vision begeistert und überzeugt.
- Long-Term (langfristig): Die Vision ist nicht auf kleinteilige, nahe Ziele ausgerichtet, sondern auf die Zukunft.
- Distributed (verteilt): Die Vision ist relevant für alle, die an der Realisierung der Vision beteiligt sind.
Ihre Agentur wird sich mit geeigneten Hilfsmitteln und Ansätzen darauf verstehen, Ihre unterschiedlichen Vorstellungen und Ideen für die Vision zusammenzutragen, so dass am Ende ein „Big Picture“ dasteht, mit dem nicht nur alle zufrieden sind, sondern dass auch als Basis für die gemeinsame Arbeit dienen kann.
Bei länger andauernden Projekten werden Sie gemeinsam mit allen Beteiligten immer wieder gemeinsam überprüfen, ob die Produktvision noch dem entspricht, was von allen Stakeholdern erwünscht wird.
Was die Nutzer brauchen: User Stories und Anforderungen
Das Konzept der „User Stories“ gehört zwar nicht ursprünglich zu agilem Vorgehen oder der Scrum-Methode, hat sich aber inzwischen für viele Anwendungen durchgesetzt, weil es sich als nicht nur praktisch, sondern auch überaus sinnvoll erwiesen hat.
Eine User Story wird üblicherweise in einer sehr klaren Form formuliert: Als PERSON A will ich HANDLUNG B machen können, um ZIEL C zu erreichen. Damit wird sie zu einer Problembeschreibung, die sehr konkret, übersichtlich und damit verständlich ist. Auf diese Weise bekommen User Stories, wenn sie richtig formuliert und kondensiert sind, zwei wesentliche Vorteile:
- Sie sind konsequent aus der Perspektive der Nutzer gedacht. Nutzer sind dabei nicht nur Ihre Kunden, sondern zum Beispiel auch Ihre Mitarbeiter, freie Außendienstler oder Sie selbst. Das hat den Vorteil, dass das Produkt von Anfang an immer an den Bedürfnissen konkreter Nutzer entlang entwickelt wird.
- Sie erfordern Arbeit von klar überschaubarem Umfang. Idealerweise lässt sich eine User Story innerhalb eines Sprints umsetzen, so dass es also nach dem Sprint ein überprüfbares Ergebnis gibt.
Es gibt eine Reihe von Kriterien (“INVEST-Kriterien”), wie gute User Stories formuliert werden sollten, damit sie diese Vorteile wirklich entfalten können:
- Independent (unabhängig): Die User Story ist prinzipiell unabhängig von anderen Stories, kann also abgearbeitet werden, ohne dass andere Bedingungen dafür erfüllt sein müssen.
- Negotiable (verhandelbar): User Stories sind keine unberührbaren Texte. Sie können durch das Team, den Product Owner, und die Stakeholder immer noch verändert und präzisiert werden, bis sie in den Sprint-Backlog aufgenommen wurden.
- Valuable (nützlich): Die Story muss so formuliert sein, dass ihr Ergebnis für den Anwender sinnvoll und nützlich ist.
- Estimable (schätzbar): Das Team muss in der Lage sein, den Arbeitsaufwand für die Umsetzung der User Story abschätzen zu können. Das erfordert insbesondere:
- Small (klein): Die Story muss vom Umfang so eng gefasst sein, dass sie sich in einem Sprint realisieren lässt.
- Testable (testbar): Das Ergebnis jeder Story muss ein Artefakt sein, dessen erfolgreiche Umsetzung sich testen lassen kann. Daran wird der erfolgreiche Abschluss der Story-Umsetzung festgemacht.
Wenn man User Stories nicht gewohnt ist, fällt zuweilen die Umstellung schwer, nicht mehr nur in Anforderungen zu denken. Den nun heißt es nicht mehr: „Ich will auf der Startseite eine Teaserbox mit den neuesten Unternehmens-News haben“ – stattdessen müsste man gezielt beschreiben, welche Nutzer aus welchen Gründen in welcher Situation sich über Neuigkeiten aus Ihrem Unternehmen informieren wollen. Ob diese User Story dann am Ende als eine Teaser-Box auf der Startseite umgesetzt wird oder eine ganz andere, für den Nutzer viel sinnvollere Lösung findet, ist dann noch offen.
Wie aus User Stories das Product Backlog entsteht
In einem möglichen gemeinsamen Workshop mit Ihrer Agentur ginge es darum, möglichst viele dieser User Stories schon vor Beginn der Umsetzung zu sammeln. Es gehört zu den Vorzügen des agilen Arbeitens, dass zum Projektbeginn noch nicht alle Anforderungen bekannt sein müssen. Wie oben beschrieben: Je komplexer und unklarer die Anforderungen des Projektes zu Beginn sind, desto besser ist es sogar für eine agile Vorgehensweise geeignet.
Dennoch ist es natürlich wichtig, sich anfangs über möglichst viele Nutzerbedürfnisse klar zu werden, möglichst viele Anforderungen zu formulieren – vor allem dies aber gemeinsam im Rahmen eines Workshops zu erarbeiten. Dafür gibt es mehrere Gründe:
- Die Vision wird konkretisiert, das Projekt greifbarer.
- Die Komplexität des Gesamtprojektes wird in den User Stories gespiegelt und damit auch allen Stakeholdern noch einmal deutlich. Dies verbessert jetzt und zu späteren Zeitpunkten die Diskussionen.
- Die Diskussion einzelner User Stories führt dazu, dass
- diese User Stories im Gespräch noch einmal reflektiert, überarbeitet und verbessert werden und
- andere Nutzerbedürfnisse angesprochen werden, die sonst womöglich vergessen worden wären.
- Nur mit einem gut gefüllten Product Backlog lassen sich sinnvoll die unterschiedlichen Aufgaben priorisieren und sortieren.
- Je vollständiger das Backlog gefüllt ist, umso zuverlässiger kann die Agentur abschätzen, wie lange das Projekt voraussichtlich dauern und vor allem, was es kosten wird.
In den Prozess des Workshops werden schließlich alle Überlegungen mit einfließen, die Sie im Vorfeld womöglich schon gemacht haben, alle Nachforschungen, die Sie schon durchgeführt haben: Marktforschung, Personas, Bedürfnisse, grundlegende Anforderungen wie Barrierefreiheit usw.
Sollten Sie also schon ein Briefing geschrieben haben: Hier wird all das berücksichtigt werden.
Zeit und Geld
Die Vision ist formuliert, die Wünsche, Bedürfnisse und Anforderungen sind in User Stories umgesetzt – jetzt kann die Arbeit ja eigentlich losgehen. Aber wie genau läuft sie ab, was ist anders als beim „Wasserfall“-Prinzip, und was soll das kosten?
Wie lange wird das Projekt dauern?
Die Erfahrung zeigt: Agile Projekte nach Scrum dauern keineswegs länger als „herkömmlich“ organisierte Aufgaben. Stattdessen werden Sie wahrscheinlich schon deutlich früher sehen, wie das Ergebnis Gestalt annimmt.
Grundsätzlich wird sogar angestrebt, möglichst früh eine erste, funktionsfähige Fassung zu veröffentlichen, um diese dann sukzessive durch die Rückmeldungen und Anmerkungen der echten Nutzer zu verbessern – das Prinzip „release early, release often“.
Ob dieses Prinzip für Ihr Projekt geeignet oder wünschenswert ist, können Sie aber natürlich zusammen mit Ihrer Agentur selbst entscheiden. Gerade bei einem Website-Relaunch wollen Sie möglicherweise nicht von einer zwar veralteten, aber voll funktionsfähigen Website auf eine schöne neue umschalten, die allerdings noch nicht alle Funktionalitäten aufweist.
Die Natur agiler Projekte macht es schwierig, eine feste Terminzusage für einen Launch zu geben – eine erfahrene Agentur kann jedoch abschätzen, in welchem Zeitraum das Projekt voraussichtlich abgeschlossen werden kann. Dennoch ist es hilfreich, eher in Zeitfenstern als in konkreten Terminen zu denken.
Wie werden die Kosten berechnet? Gibt es einen Fixpreis?
Es gibt verschiedene Möglichkeiten, die Kosten für ein agiles Projekt nach Scrum abzuschätzen – und jede Agentur wird dabei etwas unterschiedlich vorgehen. Manche Agenturen wählen eine Abrechnung je Sprint und stellen damit sicher, dass es auch für spätere Erweiterungen des Projektes eine klare finanzielle Perspektive gibt. Andere werden sich vielleicht sogar auf einen Fixpreis einlassen, der an bestimmte Konditionen gebunden ist: eine maximale Projektdauer zum Beispiel – aber zugleich natürlich eine Liste an Mindestanforderungen, in denen zum Beispiel definiert wird, welche Funktionalitäten Ihres Website-Relaunches damit sicher abgedeckt sind.
Natürlich müssen auch Sie für sich abklären, auf welche Konditionen Sie sich einlassen möchten – eine sinnvolle Preisabschätzung kann in der Regel erst nach Abschluss der Workshops zu Vision und User Stories erfolgen, wenn die Rahmenbedingungen für das Projekt wirklich klar sind.
Zusammenarbeit
Ein nach Scrum organisiertes Projekt stellt an die Zusammenarbeit mit Ihrer Agentur etwas andere Anforderungen, als Sie das womöglich von „Wasserfall“-Projekten gewohnt sind.
Wie genau sieht die Zusammenarbeit mit dem Team aus?
Alle Beteiligten in einem Scrum-Projekt erfüllen, wie in unserem ersten Artikel beschrieben, klare Rollen mit sehr spezifischen Aufgaben. Während der einzelnen Sprints arbeitet das Entwicklungsteam eigenständig – und die Tasks, zu denen sich das Team zu Beginn des Sprints verpflichtet hat, werden nun auch nicht mehr abgewandelt.
Ihre Kontaktperson für einzelne Fragen ist nun der Product Owner, der Themen, Anfragen und Wünsche aufnimmt, diese in der Regel aber während eines laufenden Sprints nicht ins Team trägt. Nur so kann gewährleistet bleiben, dass die Sprint-Ziele auch wirklich umgesetzt werden, denn die Planung der einzelnen Sprints beruht wesentlich darauf, dass das Team ungestört arbeiten kann.
Zugleich ist es wichtig, dass es in Ihrem Unternehmen eine Person gibt, an die sich der Product Owner wenden kann, wenn es konkrete Fragen gibt – und die dann unter Umständen auch sehr kurzfristig Antworten geben und Entscheidungen treffen kann.
Sprint Review: All hands on deck
Antworten und Entscheidungen werden vor allem beim Sprint Review benötigt. Zu diesem Termin am Ende jedes Sprints – also je nach vereinbarter Sprintdauer alle ein bis vier Wochen – sollte nicht nur der Ansprechpartner aus Ihrem Unternehmen unbedingt anwesend sein, sondern idealerweise alle wichtigen Stakeholder.
Beim Sprint Review präsentiert das Team die im Sprint erarbeiteten Ergebnisse (das sog. „Produktinkrement“). Dieses Inkrement muss daraufhin getestet und geprüft werden, ob es die Aufgabe erfüllt, die in der User Story verlangt wurde.
Einbringen – Entscheiden – Priorisieren
Da der nächste Sprint unmittelbar an dieses Meeting anschließt, müssen im Rahmen des Sprint Reviews direkt Entscheidungen getroffen werden. Sind an diesem konkreten Produktinkrement noch Veränderungen und Verbesserungen notwendig? Welche User Stories haben für den nächsten Sprint höchste Priorität?
Nur wenn diese Entscheidungen während des Sprint Reviews getroffen werden, kann das Team beim nächsten Sprint Planning schließlich auch die für Sie als Kunde drängendsten Tasks berücksichtigen.
Prioritäten setzen! Warum ist das so wichtig?
Gerade das Priorisieren und Gewichten der einzelnen User Stories ist anfangs oft ungewohnt. Natürlich sind für Sie alle Anforderungen eigentlich gleich wichtig – unwichtige würden Sie gar nicht ins Product Backlog mit aufnehmen.
Manche Prioritäten ergeben sich notwendigerweise aus dem Projektablauf – Konzeptionelles muss geklärt werden, bevor sinnvoll weitergearbeitet werden kann. Zudem gibt es technische Voraussetzungen, die vorab geschaffen werden müssen, wenn man z.B. einen Relaunch plant: Hosting, Datenbank, Grundfragen für die Entwicklung, solche Dinge.
Das kann dazu führen, dass es zu Beginn der Projektumsetzung zunächst ein oder zwei Sprints gibt, in denen sich das Team vor allem auf Fragen von Konzeption und Design fokussiert und noch keine technische Entwicklung stattfindet – auch da stehen am Ende fertige Artefakte, aber eben noch keine technische umgesetzten Teilprodukte.
Auch darüber hinaus ist klar, dass nicht alle User Stories gleichzeitig abgearbeitet werden können. Stattdessen sollten jene vorgezogen werden, die für den Kern der Vision entscheidend sind – also jene, die entscheidend dafür sind, dass Ihre Website am Ende genau das tut, was Sie für ihre Zielgruppe machen soll
Im Laufe der Sprints werden solche Entscheidungen immer wieder kommen: Was ist wirklich wichtig? Wichtiger als das andere?
Aufeinander einstimmen
Für Ihren Website-Relaunch werden in der Agentur idealerweise jene Mitarbeiter ausgewählt, die für Ihr Projekt die besten Voraussetzungen mitbringen und in den kommenden Wochen keinen großen Urlaub geplant haben.
Der Erfahrung nach dauert es in etwa zwei bis drei Sprints, bis sich ein neu zusammengestelltes Team ganz aufeinander eingespielt hat, Missverständnisse nicht mehr so leicht entstehen und alle die Arbeitsweise der anderen kennen. Diese Prozesse sind normal und kein Grund zur Beunruhigung – Sie erhalten vielleicht nur durch die Sprint Reviews und Ihren engeren Kontakt mit der Agentur mehr Einblick in die Arbeitsweise des Teams, als das sonst oft der Fall ist.
Vertrauen und Verantwortung: Scrum-Werte
Das zeigt sich unter anderem dadurch, dass das Team in den Sprint Reviews seine Ergebnisse selbst vorstellt, nicht der Projektmanager oder Product Owner. Zentral für die agile Projektorganisation mit Scrum ist es nämlich, dass alle Beteiligten Verantwortung für ihre eigene Arbeit und Arbeitsweise übernehmen, und damit auch für das ganze Projekt.
Damit das funktionieren kann, ist es wichtig, dass alle Beteiligten – und das schließt auch Sie als Auftraggeber ein – Vertrauen in die Arbeit der anderen mitbringen.
Dem entspricht auf der anderen Seite Offenheit und Transparenz, die nicht nur die zentralen Pfeiler der Arbeit im Team sind, sondern auch gegenüber Ihnen, dem Kunden, gelebt werden sollten. Das bedeutet: Sie bekommen in einem Sprint Review auch offen gesagt, wenn im Sprint etwas schiefgegangen ist, der Zeitbedarf falsch eingeschätzt wurde oder ein bestimmtes Problem auf die versuchte Weise nicht lösbar ist.
Experimentieren und immer besser Scheitern – das ist durchaus gewünscht.
Es ist wichtig, diese Offenheit zu würdigen und entsprechend zu reagieren: nämlich konstruktiv und ergebnisorientiert. Durch die direkte Rückmeldung am Ende jedes Sprints entstehen ja auch keine großen Verzögerungen oder zusätzlichen finanziellen Aufwände, eine Richtungskorrektur kann leicht vorgenommen werden. Anders als bei „Wasserfall“-Projekten können sich agile Projekte durch die regelmäßigen Termine nicht unbesehen in eine ganz falsche Richtung entwickeln.
Experimentieren und immer besseres Scheitern sind in agilen Projekten durchaus gewünschte Vorgehensweisen – auf diese Weise entstehen bessere, auch ungewöhnlichere Lösungen und Ergebnisse.
Wofür der ganze Aufwand?
Irgendwie klingt Ihnen das alles nach sehr viel Aufwand an Zeit und Nerven? Wie soll sich das lohnen oder, ganz betriebswirtschaftlich gedacht, wirklich rechnen?
Ein besseres Produkt, näher am Menschen
Bei einem Scrum-Projekt sind die entscheidenden Stakeholder von Anfang an und durchgehend am Entstehungsprozess beteiligt. Da sie gefordert sind, ihre Anforderungen in User Stories zu denken, entsteht ein Produkt, dass sich stärker an konkreten Bedürfnissen orientiert. Mit anderen Worten: Es richtet sich stärker an den Menschen aus.
Und mehr noch: Das Endergebnis passt mit großer Wahrscheinlichkeit auch besser zu Ihnen und Ihrem Unternehmen und bietet insgesamt ein harmonischeres Gesamtbild.
In einem einmal abgeschlossenen Briefing können Anforderungen unterschiedlicher Stakeholder, die miteinander in Konflikt stehen, leicht nebeneinander stehen bleiben. In einem Workshop, in dem man sich gemeinsam abstimmt, sind alle Beteiligten angehalten, sich genau mit solchen Schwierigkeiten zu beschäftigen und idealerweise eine für alle brauchbare Lösung zu erarbeiten.
Weniger Änderungen, weniger Ärger, weniger Verzögerung
Am Ende eines konventionellen „Wasserfall“-Projekts stehen oft noch zahlreiche „Change Requests“: Änderungswünsche, die erst während der Projektlaufzeit entstanden sind. Bei einem agilen Projektverlauf werden solche Änderungen direkt in den Prozess eingebracht.
Die Scrum-Sprints geben zudem einen klaren, gemeinsamen Rhythmus und Zeitplan vor, in dem keine Pausen entstehen – wenn die Entscheidungen für bestimmte einzelne Themen und Tasks doch etwas länger dauern, werden in der Regel erst andere User Stories abgearbeitet. Alles eine Frage der Prioritäten.
Keine Angst, wir lösen das für Sie!
Wenn Ihnen das Ihre Sorgen nicht nimmt, sprechen Sie die Agentur Ihres Vertrauens einfach einmal an. Schließlich machen Sie diese Reise nicht allein, und eine gute Agentur wird ein Webprojekt mit Scrum so ausgestalten, dass es für alle Beteiligten zu einer erfolgreichen Entdeckungstour wird.
Agil arbeiten nach Scrum ist nicht schwer, wir sind es oft nur nicht gewohnt.
