Vor einigen Wochen starteten wir eine neue Meetup-Gruppe in Berlin mit dem Namen "Coach Me If You Can". Als agile Coaches, die in einer digitalen Agentur arbeiten, hatten wir das Gefühl, dass in der Berliner Meetup-Szene etwas fehlt, und sahen den Bedarf für eine neue Plattform, auf der erfahrene Agile Coaches und Scrum Praktizierende sich über ihre Situationen austauschen und gemeinsame Themen diskutieren können. Obwohl die meisten Ideen und Verbesserungen in den Gesprächen während des Meetups zum Vorschein kamen, spiegelt dieser Artikel meine Sichtweise zu diesen Themen wider und wie ich unsere Ergebnisse sehe. Ich hoffe, ihr stimmt mir zu oder noch besser: stellt meine persönlichen Ansichten in Frage.

Die Teilnehmer von "Coach Me If You Can" legen die Tagesordnung fest, und wir sammeln einen Überblick über die Themen. Die Gruppe wählte "Feedback Culture" und "Constant Change in Scope or Priority" als die interessantesten. Dann teilten wir uns in Gruppen auf und sprachen über einzelne Fälle. Hier ist meine Zusammenfassung aus der Constant-Change-Gruppe:

Zunächst einmal sind Veränderungen in agilen Projekten sehr willkommen. Manchmal kann jedoch der ständige Wandel ein Symptom für Probleme im Prozess sein.

Fall 1: Schlecht geschriebene Storys

Die Protagonisten des ersten Falls waren ein kleines, verteiltes Team, das mit Scrum arbeitete. Sie standen vor einer großen Herausforderung: Der Scope änderte sich nach jedem einzelnen Sprint. Nach einigen Nachforschungen unserer Gruppe stellten wir fest, dass die Stakeholder ihre Meinung während ihrer Überprüfungen im Allgemeinen nicht änderten, sondern tatsächlich andere Ergebnisse erwarteten.

Wir formulierten schnell eine Hypothese:

Storys von geringer Qualität ermöglichen ein breites Spektrum an Ergebnissen. Ein unerwartetes Ergebnis zwingt die Beteiligten, nach einem Sprint das zu präzisieren, was sie eigentlich wollten. Das Team hat das Gefühl, dass der Stakeholder unentschlossen ist und den Umfang ständig verändert.

Hier sind die Tipps, die unser Team ausgearbeitet hat:

1. Lass die Entwickler ihre Definition von "bereit" überprüfen . Wenn sie Unsicherheit in den Storys sehen, lass sie die Story ablehnen. Bei Turbine Kreuzberg benötigen wir zwei Devs, um eine Geschichte zu bestätigen, bevor sie als bereit für einen Sprint betrachtet wird.

2. Prüfe, wo dein PO seine Zeit verbringt. Rein physisch. Wo ist der Schreibtisch?

Wenn die Informationen nicht den Weg von den Stakeholdern zu den Entwicklern finden, finde heraus, wo sie sich verdünnen. Sollte man mehr Zeit mit den Stakeholdern verbringen, um das Geschäft zu verstehen, oder sollte man mehr Zeit mit den Entwicklern verbringen, um die Unklarheiten zu erklären und zu beseitigen? Denk über den Tellerrand hinaus (in diesem Fall: Teller = Büro). Es wäre völlig in Ordnung, den PO im Büro zu verschieben. Schick sie oder ihn gegebenenfalls sogar ins Büro der Interessenvertreter. Alles ergibt mehr Sinn, als einen weiteren Sprint des Teams zu verschwenden.

3. Prüfe, ob der PO Zugang zu den richtigen Personen hat. Vielleicht ist sie oder er gezwungen, sich mit dem auseinanderzusetzen, was ich "glorifizierte Boten" nenne. Das ist eine Person ohne Entscheidungsbefugnis, die jede Frage mit "Darauf muss ich noch einmal zurückkommen" beantwortet. Einige Stakeholder zögern manchmal, Zeit und Aufmerksamkeit während eines Projekts zu investieren, es sei denn, sie sehen, dass etwas nicht in ihre Richtung geht. Dies sind klare Anzeichen dafür, dass das Team in einer nicht-agilen Umgebung arbeitet. Im dritten Fall geht es um ein ähnliches Szenario.

Fall 2: Keine Zeit für einen MVP

In einem anderen Fall wurde uns von einem Hardware-Team berichtet, das ebenfalls Scrum verwendet. Obwohl das Team aussagekräftige Inkremente produzierte, stieg die Frustration aufgrund des veränderten Scopes. Auch hier brachte unsere Gruppe mehr Details an die Oberfläche. Die Stakeholder sprangen von Idee zu Idee, bevor die Projekte eine MVP-ähnliche Reife erreichen konnten. Berücksichtige die Besonderheiten bei der Hardware: Man muss Material bestellen, tatsächlich auf den Versand warten oder manchmal mit Subunternehmern zusammenarbeiten!

Wir haben zwei Ansätze zur Bewältigung dieser Herausforderung identifiziert:

1. Hab längere Sprints. Es ist keine Schande, einen vierwöchigen Sprint zu haben. Agiles Arbeiten begrüßt Veränderungen - aber sie sollten aus neuen Informationen und nicht aus dem Bauchgefühl eines Stakeholders kommen. Wenn man den Plan ändert, bevor man den MVP* testen kann, hat man das Gefühl, dass man die letzte Änderung gar nicht erst gebraucht hat. Wenn das Team also vier Wochen braucht, um etwas Testbares zusammenzustellen, sollte es sich vier Wochen Zeit nehmen.

*{Ich höre schon die Schreie. "Auf unserem Gebiet können wir nicht testen!", "Es ist anders, weil wir für unsere Kunden bauen!" und so weiter. Ich persönlich mag diese Aussagen nicht, weil sie so leicht zu postulieren sind, ohne dass man sich überhaupt um neue Informationen bemüht. Man könnte zum Beispiel argumentieren, dass es ein gültiger Ersatz ist, dem Kunden einen Arbeitszuwachs zu geben und damit zu "testen", ob man seine Erwartungen erfüllt hat. Den Auftraggeber zu drängen, einige seiner Nutzer in die Überprüfung einzubeziehen, war unserer Erfahrung nach ebenfalls hilfreich.}

2. Release-Pläne verwenden. Wie oft habe ich geschaudert, wenn jemand sagte: "Wir sind agil - wir brauchen nichts zu planen! Wir planen viel, wir halten uns nur nicht blind an den Plan! Planung ist vielleicht nicht auf dem Cover des Buches, aber sie ist ein wichtiger Teil der Agilität.

Die Planung von mehr als einem Sprint und die Erstellung eines Release-Plans als Fahrplan für das Produkt ist vollkommen in Ordnung. Stell nur sicher, dass alle Beteiligten wissen, dass der Plan eine Vorhersage ist, die jederzeit geändert werden kann, und kein Diktat.

Fall 3: Der PO als Marionette des CEO

Der nächste bitte! Hier haben wir ein mehr oder weniger typisches Scrum-Team. Die Leute wissen, was sie tun, und das Team liefert Arbeitsergebnisse. Alles ist toll, außer dem PO, der im Grunde genommen als Sprachrohr des CEO fungiert. Der CEO fühlt sich wie der Produzent der Band "Backlog and the High-Priorities" und pfeift jede zweite Woche ein anderes Lied. Der Product Owner ownt das Produkt nicht und stellt Ideen von höheren Stellen direkt oben auf den Backlog. Ein Teilnehmer fragte, warum dies ein so großes Problem sei. Als Leiter/in des Unternehmens weiß die/der CEO sicherlich am besten, wie der nächste Schritt aussehen sollte, und solange sie oder er den Sprint-Backlog nicht verändert, ist es in Ordnung, dass sie oder er das Team direkt steuert.

{Wenn das für dich vernünftig klingt, lese nicht weiter! Lehn dich stattdessen zurück und nimm dir eine Minute Zeit, um darüber nachzudenken.}

Meiner Meinung nach gibt es eine präzisere Frage:

Welche Informationen stehen dem CEO nicht zur Verfügung, die notwendig sind, um einen Backlog zu priorisieren?

Was sollte oben auf dem Backlog stehen: Die einfache Antwort ist der Punkt, der dem Produkt den größten Value verleiht. Ich sage einfach, weil es verlockend ist, das Wort Value als eine Black Box zu behandeln, ohne zu klären, was es bedeutet.

{Zur Verdeutlichung möchte ich das folgende Beispiel verwenden: Wenn man ein Restaurant betreibt und eine Beraterin gefragt haben, wie man das Geschäft verbessern könnte, liefert sie Ihnen zwei Feststellungen.

1. Die Speisekarten fühlen sich billig an und stehen im Widerspruch zu den Preisen der Gerichte. Ein besseres Design könnte die Ausgaben und die Zufriedenheit der Kunden erhöhen.
2. In der Nähe des Restaurants gibt es kein Hotel. Die Umwandlung des Gebäudes über dem Restaurant in ein Hotel könnte eine zusätzliche Einnahmequelle darstellen.

Was würden wir als Erstes tun? Den einfachen und schnellen Erfolg oder das lange und kostspielige Unterfangen?}

Du verstehst, was ich meine. — es geht nicht nur um die Gewinne, sondern auch um die Anstrengungen.. Die beiden kommen von den Stakeholdern bzw. dem Entwicklungsteam. Der PO gibt diesen einzelnen Informationen Bedeutung, indem er sie in Beziehung zueinander setzt. Die komplexere Antwort auf unsere Ausgangsfrage lautet daher: Das Element mit dem besten Verhältnis von Wert und Aufwand sollte oben auf dem Backlog liegen. Wenn der CEO nicht zuerst Informationen über den notwendigen Aufwand sammelt, sollte er nichts oben auf den Backlog setzen. Im Gegenteil, der PO sollte den Backlog neu priorisieren, nachdem alle neuen Elemente vom Entwicklungsteam geschätzt wurden. Es kann sogar noch mehr Einschränkungen geben, die die Top Items irrelevant machen. Dies kann z.B. der Fall sein, wenn eine Story von einer anderen abhängt und nicht gestartet werden kann, bevor die erste von beiden fertig ist.

Zu diesen Themen wurde noch viel mehr gesagt, und einige Themen wurden in diesem Artikel nicht berührt. Dennoch hoffe ich, dass er einige der Erkenntnisse zusammenfassen konnte, und ich freue mich auf Ergänzungen und Kommentare.