🙈 🙉 🙊 oder warum Scoping wichtig ist

dreipol wurde mit der Weiterentwicklung eines Projekts beauftragt, das wir im UX & UI Design mitaufgebaut hatten. In der Zwischenzeit hatte der Kunde das Projekt sechs Jahre lang selber gepflegt und erweitert. Trotz Stolperfallen und Risiken, entpuppte sich das Projekt für mich als Lehrstück im Scoping.

Wenn auch die spezifischen Inhalte jeweils anders sind, jedes Projekt hat so seine Gemeinsamkeiten. Meistens sind es die Herausforderungen. So treffe ich auf fast allen Projekten dieselben Schwierigkeiten in einer neuen Form wieder an.

Mein Job als Projektleiter bei dreipol ist zwar abwechslungsreich, aber im Detail geht es vorwiegend um irgendeine Form von Expectation Management, Terminfindung oder Containment möglicher Fallouts. Das liest sich wie ein Project-Manager-Buzzword-Bingo — und ist es meist auch. Ich würde behaupten, dass es, vereinfacht gesprochen, eine infernale Dreifaltigkeit gibt, die sich in einer sich wandelnden Form wiederholt:

🙈 — Vage Anforderungen, die sich während der Projektarbeit verändern.
🙉 — Das Budget ist nicht immer zu klein, aber es ist immer zu wenig.
🙊 — Meistens weiss die rechte Hand nicht, was die linke macht.

Klar, wir Project Managers brauchen das Adrenalin wie den Kaffee am Morgen. Und im Kommunizieren verpasster Deadlines oder gesprengter Budgets liegt ein gewisser Nervenkitzel. Doch der Adrenalinpegel, der sich nach einer geglückten Demo vor versammelter Sponsoren- & Stakeholderschaft einstellt, fühlt sich massiv besser an, als die schweissigen Hände vor einer Nachverhandlung.

Vage To-dos — harte Deadline

Ebendiese Gedanken holten mich ein, als ich im letzten Sommer das Briefing für ein neues Projekt durchlas: Der Atlas der Schweiz, für den dreipol vor langer Zeit ein Design-System erarbeitet hatte, sollte aktualisiert werden. Der Kunde wollte einen kompletten Refresh der Codebasis, konnte sich aber nicht auf ein einzelnes Ziel festlegen, sondern es waren deren drei:

• Eine Migration der Codebasis von Vue2 auf Vue3 mit Typescript
• Aufbau einer Komponenten-Library zur Wiederverwendung auf der Webseite (die Applikation war bisher nur mit Installation nutzbar)
• Eine neue Komponente, die interaktives Storytelling erlaubt

Das waren nicht gerade «Low-hanging fruits», die man einfach so mal mitnimmt, wenn man gerade schon dabei ist. Es ging eher um ein Refactoring und eine Erweiterung einer ganzen Applikation – kombiniert mit einer harten und knappen Deadline, denn die neue Komponente sollte an der letzten International Cartographic Conference in Florenz gezeigt werden können.

Wenn Komplexität auf Unsicherheit trifft

Wie kommen wir nun von diesen Anforderungen zu einem zufriedenen Kunden? Es war offensichtlich, dass die Prioritäten und die damit verbundenen Ziele während des Projektverlaufs mehrmals diskutiert und angepasst werden mussten. Wasserfall kam für mich daher kaum infrage. Oder, um das Projekt anhand der «Stacey Matrix» einzuordnen: Die Anforderungen waren mehrdeutig und das Vorgehen unklar (Lesetipp zur Stacey Matrix vom wunderbaren Andreas Diehl). Ich entschied mich daher für ein agiles Vorgehen, trotz oder eben gerade wegen des fixen Budgets und der harten Deadline.

Fühlt sich kontraintuitiv an? Die Alternative wäre für mich noch viel weniger einleuchtend gewesen. Hätte ich lieber alles in eine Roadmap packen sollen, mit klaren Milestones und vordefinierten Zielen? Danach «Durchspezifizieren», was das Zeug hält, um dann kurz vor Deadline zu merken, dass weder Zeit, noch Budget vorhanden ist und kein konkretes Ziel erreicht wurde? Da bekomme ich umgehend wieder schwitzige Hände.

You don’t have to see the whole staircase. Just take the first step.
— Martin Luther King Jr.

Glücklicherweise stand das Team hinter meiner Idee und auch der Kunde reagierte sehr offen auf den agilen Vorschlag. Es gab keine Einwände, sodass die Roadmap und Lieferergebnisse gemeinsam im Projektverlauf diskutiert und die Prioritäten jeweils neu verhandelt werdenkonnten. Ich hatte wohl einen guten Tag erwischt, die Projektleitungs-Götter waren mit mir. Wir machten uns umgehend an die Arbeit und erstellten direkt nach dem Kick-off einen ersten rudimentären Backlog mit drei Epics, die den Projektzielen entsprachen.

Ein kleiner Backlog ist auch ein Backlog (©Atlas der Schweiz)

Agile — habe ich Scrum gehört?

Ich würde gerne sagen, wir haben Scrum gemacht — kann ich aber nicht. Denn im Agenturalltag sind wir weit von einem naturbelassenen Scrum entfernt. Beispielsweise sind Mitarbeiter:innen nie nur mit einem Projekt beschäftigt. Die effektive Arbeitszeit pro Sprint beträgt nie zehn Arbeitstage. Wir müssen bei jedem Projekt einen Weg finden und pragmatische Rosinenpickerei betreiben, welche Zeremonien sinnvoll sind. Daher reduzierte ich die Zeremonien auf ein Minimum. Zwei Stand-ups pro Woche, eine Stunde für das Review und Planning. Hauptsache, wir konnten A-S-A-P loslegen. Jeglicher administrativer Overhead? Weg damit. Zeremonien? Wer braucht das schon. 😉

Just do it!
— Nike

Jira ist ein Storytelling-Tool

Für den Backlog einigten wir uns, dass wir innerhalb des Projekts konsequent auf User Stories setzen würden. Ein:e externe:r Entwickler:in benötigte einen VPN-Zugriff für das lokale Repository auf Kundenseite? User Story. Der Product Owner brauchte eine Präsentation für die International Cartographic Conference? User Story. Dadurch wurde das Projektwissen direkt verteilt, ganz ohne missverständliche Arbeitsanweisungen.

User Story Mapping, by Jeff Patton (©O’Reilly, 2014)

Die verschiedenen Mitglieder des Teams — obwohl aus unterschiedlichen Fachbereichen und Organisationen– sprachen von denselben Dingen. Gleichzeitig können wir noch heute auf diesen Backlog zurückgreifen und es ist umgehend klar, was wir mit den einzelnen Stories erreichen woll(t)en. Die Teammitglieder diskutierten über Lösungen und verpackten die effektiven Arbeitsschritte in einzelne Tasks. Und die Tasks wiederum schrieben sie als Experten:innen selber.

It doesn’t make sense to hire smart people and then tell them what to do. We hire smart people and they tell us what to do.
— Steve Jobs

Vergiss den Sprint 0, auf los geht’s los!

Warum es so wichtig ist, dass alle Fachbereiche interdisziplinär arbeiten? Erst im Austausch der verschiedenen Experten:innen entsteht echte Magie. Wenn die rechte Hand weiss, was die linke macht, dann kann die rechte Hand reagieren. Wenn das linke Bein und der rechte Fuss auch noch Bescheid wissen, sind erste Schritte möglich. Ein Fuss alleine läuft keinen Sprint (pun intended).

Darum starteten wir direkt in allen Fachbereichen gleichzeitig. Es gab keinen vorgelagerten Sprint, denn mit einem Konzeptions-Sprint oder einem Sprint 0 wäre das Vorgehen unnötig verkompliziert worden. Das schnelle Prototypisieren minimierte das Risiko, dass sich das Projektteam in der Konzeption verrennen und eine pragmatische Lösung unmöglich würde. Auch wurden so keine Features konzipiert, die für die Lösung eines Problems nicht notwendig waren. Sobald die Requirements bekannt und ein Backlog worden waren, stand dem gemeinsamen Sprint-Start nichts im Weg.

So lässt sich konferenzen; die ICC in Florenz (©René Sieber)

Ende gut, alles gut?

Ganz ohne Stress ging es dann doch nicht. Auch wir mussten unsere Prioritäten mehrmals neu aufstellen. Gegen Sprintende wurde jeweils die Zeit knapp. Und die gesteckten Projektziele konnten nicht alle vollumfänglich erreicht werden. Aber der Kunde wusste laufend Bescheid. Es wurde kommuniziert, weshalb etwas nicht ging und der Product Owner war in alle Entscheidungen involviert.

Finaler Videoprototyp des Userflows für die Präsentation (© Atlas der Schweiz)

Am Ende hatten wir das bestmögliche Ergebnis, das wir mit der investierten Zeit und verfügbaren Ressourcen erreichen konnten. Abgesehen davon können wir auf einem bestehenden Backlog und einem Set von Best Practices aufbauen, wenn das Projekt in die nächste Runde gehen wird — was hoffentlich demnächst geschehen wird. Ich freue mich darauf.

Ein grosses Dankeschön an dieser Stelle an René Sieber, Michael Schmuki und das ganze Team vom Atlas der Schweiz für das entgegengebrachte Vertrauen und die tolle Zusammenarbeit.

TL;DR

• Wer Expertise möchte, darf keine Lösungen vorgeben. Die besten Lösungen entstehen gemeinsam und im interdisziplinären Austausch.
• Requirements müssen erhoben und kommuniziert werden. Das Team legt die Prioritäten gemeinsam fest und löst Probleme iterativ.
• Die Requirements lassen sich direkt als User Storys erfassen und damit den Backlog füllen. Dadurch erhöht sich das gemeinsame Verständnis und das Team nutzt eine einheitliche Sprache.

. . .

Gerne darfst du diesen Post liken, teilen und mir oder dreipol auf Social Media folgen:

ch.linkedin.com/in/retobeeler
medium.com/@reto.beeler
twitter.com/dreipol
www.dreipol.ch