Rebranding? Scrum-Methode oder klassischer Ansatz?

Zusätzliche Vorteile sind, dass die Scrum-Methode Mitarbeitenden mehr Freiheit und Verantwortung gibt. Aber wie lässt sich die Scrum-Methode in einem Unternehmen einführen? Geschieht das von selbst? Für Start-ups, die sich von Grund auf neu erfinden können, ist die Einführung von Scrum zu Beginn einfach. Für bestehende Unternehmen ist es das nicht – besonders nicht während eines Rebrandings. Die Scrum-Methode klingt attraktiv, verlangt jedoch erhebliche Veränderungen in der Organisation: eine neue Organisationsstruktur, eine neue Arbeitsweise, eine neue Kultur und ein neues Arbeitsumfeld. Warum also sollten Sie sich während eines Rebrandings für Scrum entscheiden? Schauen wir auf das Pro und Contra:

Vorteile der Scrum-Methode bei einem Rebranding

Die Scrum-Methode verlangt von den Teammitgliedern engste Zusammenarbeit, was viel Wissensaustausch ermöglicht. Das kann äußerst hilfreich sein, gerade bei einem Rebranding mit einem neuen Team und einer engen Deadline. In der Scrum-Methode werden Ziele nicht nur pro Sprint* festgelegt, sondern auch pro Tag, was dem Team mehr Flexibilität gibt. Das ist sowohl für die Steuerung des Teams als auch für die einzelnen Teammitglieder von Vorteil. Jeder Sprint wird vom Team und gemeinsam mit dem Kunden bewertet, was Feedback und Offenheit fördert. Während es früher nur wöchentliche Update-Meetings mit dem Hauptauftraggeber und zweiwöchentliche Termine mit dem Steerco gab, bieten die zusätzlichen Sprint Reviews und Sprint Retrospectives nun ausgezeichnete Gelegenheiten, dem Team weiteres Feedback zu geben und gleichzeitig die Qualität der Arbeit zu prüfen.

Nachteile der Scrum-Methode bei einem Rebranding

Wie jede Methode hat auch Scrum Nachteile. Das Arbeiten nach Scrum bietet nur begrenzte Möglichkeiten für Reporting. Ein Rebranding ist ein komplexes, multidisziplinäres Projekt, bei dem der Fortschritt auf einer sehr großen Zahl von Komponenten verfolgt werden muss. Ein Rebranding besteht aus vielen Aspekten, die sich nicht leicht in Product-Backlog**-Items übersetzen lassen. All diese Items haben ihre eigene Beschreibung, Gruppierung, Schätzung und ihren Wert, und es würde zu viel Aufwand bedeuten, jedes einzelne Item zu beschreiben und in ein Product Backlog zu übertragen. Häufig muss die Beschreibung generisch bleiben, um handhabbar zu sein. Auch die Budgetsteuerung kann mit Scrum anspruchsvoll sein, denn es ist schwierig zu planen, welches Ergebnis zu welchem Datum und gegen welches Budget realisiert werden soll.

Ein hybrider Ansatz

Aus eigener Erfahrung bin ich ein Anhänger einer hybriden Arbeitsweise, bei der die Scrum-Methode mit einigen klassischeren Projektmanagement-Praktiken kombiniert wird. Ein tägliches Stand-up ist ganz sicher eine ausgezeichnete Gelegenheit, sich untereinander abzustimmen, was an diesem Tag zu tun ist. Um ein detaillierteres Verständnis vom Stand der Dinge zu bekommen, würde ich zusätzlich das klassische Status-Meeting und eine Statusliste empfehlen. Das lässt sich gut mit Scrum verbinden. Für Budgetierung und Budgetsteuerung ziehe ich es vor, die Kosten vorab mit unserer Impact Analyse zu ermitteln und das Budget anschließend im Projektverlauf zu steuern und anzupassen. Selbstverständlich braucht es Flexibilität, damit unterwegs oder bei neuen Erkenntnissen nachjustiert werden kann. Der Projektumfang ändert sich häufig, was unvermeidlich Folgen für das Budget hat. Von Fall zu Fall bespreche ich mit dem Kunden, welche Projektmethode für das jeweilige Projekt am besten passt. Alle bisherigen Erfahrungen mit allen Projektmanagement-Methoden fließen dabei ein. Da alle unsere Projektmanager sowohl Prince- als auch Scrum-(Product-Owner-)zertifiziert sind, können wir dem Kunden für jede Situation und jede Ambition eine passende Projektmanagement-Methode anbieten.

*Ein Sprint ist ein Zeitraum von einem Monat oder weniger, in dem etwas produziert oder geliefert wird, das der Definition von „done“ entspricht. Über die gesamte Entwicklungszeit richtet sich die Länge jedes Sprints nach dem vorangegangenen Sprint.

**Das Product Backlog ist eine Liste von Items, die sich auf die Funktionalität der Deliverables beziehen. Es ist das zugrunde liegende Gerüst der Nutzeranforderungen für das Projekt.