Wie ermögliche ich ein effektives Planungsmeeting mit einem Remote-Team?

Hintergrund Ich bin Scrum Master für ein Team bestehend aus einem PO, Teamleiter und 3 Entwicklern. Der Teamleiter und 3 Entwickler sind Offshore in einer völlig anderen Zeitzone. Der PO ist im selben Büro wie ich.

Probleme

  • Das Backlog-Grooming-Meeting funktioniert nicht, da die Lösung während des Meetings entworfen werden soll. Sie wollen erst schätzen, wenn sie die Lösung verstanden und weitgehend entworfen haben
  • Sie wollen „Pausen“ einlegen, um Dinge in ihrer Muttersprache zu besprechen
  • Sie möchten nicht selbst User Stories erstellen, was in Ordnung ist, aber sie sind auch nicht damit einverstanden, wie der PO die Stories aufteilt.

Frage

  • Wie ermögliche ich angesichts dieses Szenarios ein effektives Planungs-/Grooming-/Refinement-/Triage-Meeting?

Ich habe versucht, mein Problem zu lösen, und das ist, was ich herausgefunden habe:

  • Der PO und ich führen eine User-Story-Mapping-Sitzung nur für uns 2 durch und erstellen eine erste Reihe von User-Storys und Aktivitäten und nutzen dann das Planungsmeeting, um mit dem Team zu ratifizieren und zu schätzen.
Würden Sie sagen, dass Ihre Geschichten „technischer“ Natur sind, dh sie enthalten einige Implementierungsdetails? Gibt es auch Managementdruck auf das Team, um genau zu schätzen?
@BarnabyGolden die Geschichten, die von der PO erstellt werden, sind es nicht, aber das Team erstellt auch Geschichten, die eher technischen Aufgaben ähneln, ja. Ich versuche herauszufinden, ob es sich um Managementdruck handelt, von dem ich vermute, dass er besteht.
Sie sagten, dass "sie nur schätzen wollen, wenn sie verstehen". Können Sie bitte sagen, was das Problem ist, das Sie darin sehen? Und wie sollen sie genau schätzen, wenn sie das Problem nicht vollständig verstehen?
Ok, also hast du diese Worte aus dem Zusammenhang gerissen. Wenn Sie das Ganze lesen, werden Sie sehen, dass ich mich darauf beziehe, ein vollständiges Verständnis der Lösung zu haben, bevor Sie schätzen.

Antworten (5)

TLDR: Sprechen Sie mit dem Team.

Denken Sie an die vier Kernprinzipien des Agilen Manifests , insbesondere an das allererste:

Individuen und Interaktionen über Prozesse und Tools

Von den vier Prinzipien ist das erste das einzige, das direkt unter einem verteilten Team leidet. Und Ihrer Frage nach scheint es, als würden Sie versuchen, dieses Problem durch die Implementierung eines Prozesses zu lösen. Wenn Sie sich das erste Prinzip noch einmal ansehen, sollte deutlich werden, warum dies problematisch ist.

Lassen Sie uns mit diesem Gedanken Ihre drei Probleme durchgehen:

Das Backlog-Grooming-Meeting funktioniert nicht, da die Lösung während des Meetings entworfen werden soll. Sie wollen erst schätzen, wenn sie die Lösung verstanden und weitgehend entworfen haben

Am besten, denke ich, brechen Sie dies zuerst auf, warum dies ein Problem ist. Was ist der Zweck Ihres Backlog-Grooming-Meetings? Und, was wichtig ist, finden Sie heraus, was Ihr Entwicklungsteam als seinen Zweck betrachtet , da dies möglicherweise anders ist. Ist es nur, Ihrem Verfahren zu folgen, wie es von ... Ihrem Verfahren vorgeschrieben wird? Wenn ja, dann werden die Probleme offensichtlich. Ist es ein anderer, tatsächlich nützlicher Zweck, zum Beispiel, wie @Mark C. Wallace vorgeschlagen hat, Pläne, Prioritäten und/oder Architekturen zu entwickeln? Wenn dies der Fall ist, teilen Sie dem Entwicklungsteam Ihre Bedenken mit, warum dieser Zweck nicht erfüllt wird, und bitten Sie das Team um Vorschläge zur Behebung des Problems. Jeder Vorschlag, der intern oder gemeinsam erstellt wird, wird weitaus bereitwilliger akzeptiert als einer, der dem Team von oben aufgezwungen wird.

Sie wollen „Pausen“ einlegen, um Dinge in ihrer Muttersprache zu besprechen

Abgesehen davon, dass Sie ein neues Team bekommen, das Englisch spricht, gibt es dafür wirklich nur zwei Lösungen. Entweder verbessert das Team sein Englisch (Sie könnten es zum Beispiel zu einer Art Kurs schicken, idealerweise auf Kosten der Firma). Oder Sie verbessern Ihre (Fremdsprache hier einfügen). Oder beides.

Sie möchten nicht selbst User Stories erstellen, was in Ordnung ist, aber sie sind auch nicht damit einverstanden, wie der PO die Stories aufteilt.

Wie immer zusammenarbeiten . Finden Sie heraus, warum es dem Team nicht gefällt, wie der Product Owner die Geschichten aufteilt. Vielleicht liegen sie falsch. Vielleicht ist die PO falsch. Vielleicht liegen beide falsch. Der einzige Weg, dies herauszufinden, ist eine offene Diskussion ohne Vorurteile. Ein Ziel, das Sie wahrscheinlich angehen sollten, ist, ein gemeinsames Verständnis darüber zu erlangen, wie Stories aufgeteilt werden sollten . Ein Ansatz besteht einfach darin, sie so klein wie möglich zu schneiden, während sie dennoch in der Lage sind, einen geschäftlichen Mehrwert zu bieten. Ein anderer Ansatz besteht darin, der INVEST -Mneumik zu folgen.

Hier sind einige Probleme, wie ich sie sehe:

  • Natürliche Sprachbarriere
  • Meinungsverschiedenheiten über die angemessene Aufteilung der Arbeit
  • Meinungsverschiedenheiten oder Unklarheiten über das gewünschte Ergebnis des „Backlog Grooming“

Es hört sich so an, als hätten Sie als Scrum Master jetzt einige Verantwortlichkeiten:

  • Führen Sie das Team zu einem detaillierteren gemeinsamen Verständnis dessen, wie wünschenswertes Slicing aussieht
  • Gehen Sie dem Ergebnis der Pflegesitzung auf den Grund. Wenn das Team sich ohne einen detaillierten Plan nicht in der Lage fühlt, eine Schätzung vorzunehmen, warum ist das so? Was würde passieren, wenn Sie zu diesem Zeitpunkt keinen Kostenvoranschlag benötigen würden?
  • Das Team sollte seine Erwartungen an die Sprache deutlicher machen. Vielleicht brauchen Sie eine Arbeitsvereinbarung darüber, wann welche Sprachen verwendet werden sollen.

Ich vermute, dass jede Arbeit mit Geschichten, die Sie persönlich mit dem PO machen, nicht in die richtige Richtung führt; Das Team muss die richtige Balance zwischen PO und Entwicklungsteam finden.

Es fühlt sich an, als ob die richtige Antwort darin besteht, dass der Scrum Master in den Meetings energischer vorgeht, um das Team dazu zu bringen, sich an die „Agenda“ zu halten, die Stories so zu dimensionieren, wie sie geschrieben sind (oder das Problem mit der Story so zu erklären, wie sie aktuell geschnitten ist).

Klingt, als würden Sie sich von Agilität entfernen. Da das Team Ihren Prozesserwartungen nicht folgt, schlagen Sie vor, seine Rolle auf die des Ratifizierers zu reduzieren. Das wird ihr Engagement untergraben.

Ich würde den anderen Weg gehen. Fragen Sie das Team, wie das Problem gelöst werden kann. Wenn wir den Rückstand nicht pflegen, werden wir uns immer mit Bäumen und nicht mit Wäldern befassen. Wenn wir in den Backlog-Sessions entwerfen ( anstelle der beabsichtigten Aktivität der Backlog-Session), werden wir in technischen Schulden ertrinken. Wie können wir auf dieser Grundlage als Team unser Verhalten ändern, um das Problem zu lösen?

„Wenn wir in den Backlog-Sessions entwerfen, werden wir in technischen Schulden ertrinken.“ Warum? Was ist da die Ursache-Wirkung?
Wenn Sie den Rückstand nicht in den Rückstandssitzungen verwalten, sind Sie dann nicht in einer ewigen Reaktion gefangen, ohne Plan, ohne Prioritäten und ohne Architektur? Wie können Sie sich aus Schulden befreien, wenn Sie nicht wissen, wohin Sie gehen?
Wenn ich das richtig verstehe... lautete Ihre Aussage also nicht "wenn Sie Design machen", sondern eher "wenn Sie sich auf Design statt Pflege konzentrieren"?
Genau. Wenn Sie zulassen, dass das Design die Planung verdrängt ... (wird auf die Frage bearbeitet, wenn ich nicht auf einem Mobiltelefon tippe.)
Ah ich sehe. Das macht dann Sinn.

Einige sagen, dass Agile nicht funktioniert, wenn das Team nicht an einem Ort ist. Ich würde sagen, damit Agile funktioniert, sollte ein guter Prozess etabliert sein. Denken Sie daran, dass Agile für die meisten Teams einzigartig ist, da sie unterschiedliche Hintergründe haben.

Die meisten Teams enden damit, die Ansätze zu hybridisieren, Scrumbans zu erstellen, oder ein Teil des Arbeitsablaufs für die Anforderungserhebung / das Entwerfen von Geschichten erfolgt in einem iterativen Wasserfall. Denn Scrum / oder Agile insgesamt ist kein Allheilmittel (besonders da man irgendwann Deadlines haben wird).

Wir haben auch ein Remote-Team zusammengestellt und uns den folgenden hybriden Ansatz ausgedacht, bei dem:

  1. BA / PO entwirft die Geschichten für eine vorläufige Analyse, da sie mit Kunden kommunizieren

  2. Später sitzen sie zusammen und diskutieren (wir haben 9-13 Stunden Unterschied zwischen den Teammitgliedern) den Plan für das nächste Feature mit dem Entwicklungsteam. Es gibt immer eine Moderation, wenn es um Meetings geht, damit niemand aus dem Rahmen fällt. Diese frühe Ausarbeitung spart Zeit, da nicht die ganze Geschichte ausgeschrieben wird, sodass keine Zeit verschwendet wurde, wenn Entwickler die Idee torpedieren.

  3. Die Zerlegung wird zusammen mit Entwicklern durchgeführt, da zerlegte Bits von Entwicklern durchgeführt werden. Das letzte Wort liegt also bei ihnen (vorausgesetzt, sie sind zur Zusammenarbeit bereit). Die Aufgabe von BA / PO besteht darin, sicherzustellen, dass das Problem klar genug dargestellt wird

  4. Nachdem das gesamte Team die zerlegten Bits genehmigt und bewertet hat (wir üben keine Story Points), verschieben wir die Storys auf „Ready for Implementation“ und beginnen mit der Arbeit daran. Wir verwenden keine Sprints, sondern haben ein Kanban-Board, daher ist hier keine Sprintplanung erforderlich, ebenso wie Iterationen.

Vielleicht hilft dir das ein wenig :) Lang. Barriere ist unlösbar, bis Ihre Entwickler zu einem Englischcamp kommen, um fließend zu sprechen und zu verstehen, aber für 90% der Diskussionen reicht einfaches Englisch immer aus, um die Vorstellung von der Geschichte zu verstehen und Anmerkungen zur Implementierung hinzuzufügen.

Das ist interessant und ich denke, es ist für mich am praktikabelsten, es zu versuchen. Würde es Ihnen etwas ausmachen, die Schritte ein wenig auszuarbeiten, dh wie sieht die Ausgabe des BA/PO aus und wie sehen die endgültigen Bits aus?
Zunächst einmal haben wir getrennte Prozesse für IDEAS (Tickets, die noch nicht implementiert werden können) und Entwicklung. Der Arbeitsablauf für IDEAS ist der folgende ( spacekimo.files.wordpress.com/2017/07/pre-dev-workflow.png ). Sie können es in meinem Blog lesen (ich habe dieses Thema kaum berührt, aber es gibt ein bisschen Verständnis < kiniabulatov.com/2017/07/17/why-we-finally-ditched-scrum , beginnend mit dem IDEAS-Board-Bereich bis Abschnitt Entwicklungsplatine>.
Grundsätzlich haben wir ein paar Phasen: Vorläufige Analyse (Ziele und Gesamtansatz, welche Vorteile bringt uns diese Funktion) -> Abmelden (durch Stakeholder und verantwortliche Personen, kann auch durch Teamleiter erfolgen) -> Detaillierte Analyse (an dieser Stelle Sie erhalten eine Wiki-Seite mit Feature-Beschreibung, Zielen) -> User Stories & UX (Formalisierung und Zerlegung, zusammen mit dem Entwicklerteam) -> Ready to Schedule. Das Entwicklungsteam kommt ins Spiel, wenn wir den Schritt „Detaillierte Analyse“ haben. Da wir dort beginnen, die Implementierung und allgemeine Lagerprozesse zu diskutieren, sehen Sie, welche zugrunde liegenden architektonischen Änderungen übersprungen werden müssen.

Meiner Meinung nach ist es ziemlich schwierig, Agile zum Laufen zu bringen, es sei denn, es gibt ein Team. Ein Team arbeitet in einem Raum in einer Zeitzone. Sie können die Zeitzone nicht steuern, aber die Technologie kann beim Erstellen eines virtuellen Raums helfen.

Sie sollten auf jeden Fall versuchen sicherzustellen, dass Sie in jedem Büro eine Webcam haben, die während der Arbeitszeit eingeschaltet ist, und sehen, ob Sie mindestens 4 bis 6 Stunden zusammen arbeiten können. Wenn dies nicht möglich ist, beenden Sie Scrum und wechseln Sie zur alten Schule.

PO muss die Anforderungen detailliert dokumentieren. Versuchen Sie, eine Kombination aus Anwendungsfällen und Wireframes zu verwenden. Der aktuelle Scrum Master wird dies überarbeiten und sicherstellen, dass es detailliert genug ist, bevor er es dem Offshore-Team vorlegt.

Sie können dennoch sicherstellen, dass PO kurzfristig verfügbar ist, wenn das Entwicklerteam Klärungsbedarf hat. Sie können das Projekt sogar in Teile aufteilen und das Entwicklerteam bitten, höchstens monatlich Dinge zu veröffentlichen.

Diese Antwort mag kontrovers sein, aber ich habe noch nie gesehen, dass Teams, die zumindest über eine Webcam nicht zusammenarbeiten können, mit Agilität Erfolg haben. Agile Teams sind wie Armeeeinheiten oder Fußballmannschaften. Sie haben keine Fußballmannschaft oder Armeeeinheit, wenn die Hälfte von ihnen vor der Küste liegt.

Ich höre dich! Ich habe ein paar Leute gehört, die dasselbe sagen oder zumindest sagen, dass es erheblich schwieriger ist, eine agile Arbeitsweise zu erreichen. Wir arbeiten in der Regel etwa 2 Stunden zusammen. Wir machen zusammen ein „Standup“- und ein Grooming-Meeting.
Ich bin anderer Meinung, ich arbeite mit einem Team in Dallas, Texas, Wisconsin, und drei verschiedenen polnischen Standorten sowie einem Büro in Dublin. Alle arbeiten von zu Hause aus, außer dem Irish Scrum Master. Es klappt. und viele der Probleme können durch gute Collaboration-Tools wie Skype for Business und eine Webcam gelöst werden!
Ich schrieb: „Diese Antwort mag kontrovers sein, aber ich habe noch nie gesehen, dass Teams, die zumindest über eine Webcam nicht zusammenarbeiten können, mit Agilität Erfolg haben.“ Ihre Nutzung von Skype und Webcam scheint meiner Meinung nach die Mindestanforderung zu sein. Fragt sich nur, warum der arme SM nicht auch von zu Hause aus arbeitet :?
„Agile kann nur funktionieren, wenn […] ein Team in einem Raum arbeitet […]“ und „Skype und Webcam nutzen […] ist die Mindestanforderung“ scheinen sich zu widersprechen. Vielleicht möchten Sie Ihren Wortlaut ändern - es ist nicht so sehr, dass sie nicht funktionieren können, sondern dass zusätzliche Anforderungen hinzugefügt werden, um dazu in der Lage zu sein, oder?
OK. Stolz geschluckt. Ich habe die Bearbeitung vorgenommen :)