Kommunikation zwischen agilen Projektteams und Shared Services

Erstellen Sie Visuals für gemeinsames Verständnis und große Bilder

Erstens, keine Panik, agil oder nicht, dies ist ein Problem bei jeder Lieferung, die Koordination erfordert.

Was Sie suchen sollten, sind Tools, die dabei helfen, ein gemeinsames Verständnis zu schaffen und die Menschen dabei unterstützen, das große Ganze zu diskutieren. Obwohl User Stories hilfreich sind, können sie dennoch einschränkend sein. Ich würde vorschlagen, dass Sie Ihr Produkt mithilfe einer Story oder Journey Map darstellen. Diese Karten fungieren als visuelle Erzählung, die festhält, wie ein Produktteam glaubt, dass sich eine allgemeine Benutzererfahrung entwickeln wird, und kann dann mit Teams erkundet und aufgeschlüsselt werden, um herauszufinden, wie Teams sie koordinieren werden.

Hier ist ein Link zur Website von Jeff Patton, um mehr zu erfahren. Ich empfehle, seine Powerpoint-Präsentation herunterzuladen, die Sie durch den Prozess führt, damit Sie es ausprobieren können. Es wird Ihnen helfen, das Erstellen einer Feature-Karte zu vermeiden.

https://www.jpattonassociates.com/storymappingslides/

TL;DR

Die [K]Kommunikation der Anforderungen lässt zu wünschen übrig.

Dies ist sowohl der Kern Ihres Problems als auch Ihr Weg zur Prozessverbesserung. Es scheint wahrscheinlich, dass Ihnen Product Owner und Product Backlogs für jedes Team fehlen und Sie keine angemessene Koordination auf Scrum-of-Scrums-Ebene haben.

Neben der Besetzung fehlender Rollen und der Generierung der erforderlichen Scrum-Artefakte kann Ihr Unternehmen User Stories nutzen, um die Kommunikation zwischen den Teams zu verbessern.

Verbesserung der Kommunikation zwischen Teams mit User Stories

Auch ohne die richtigen Rollen und Artefakte zur Koordination der Teams können Sie Ihre Prozesse erheblich verbessern, indem Sie sicherstellen, dass Sie keine „Anforderungen“ zwischen den Teams über den Haufen werfen. Stattdessen sollten Teams User Stories austauschen , die verwendet werden können, um die direkte Kommunikation zwischen den Mitgliedern jedes Teams zu erleichtern.

Wenn beispielsweise ein Projektteam, das eine neue Website erstellt, Datenbankdienste benötigt, könnte es eine User Story geben, die besagt:

Als Benutzer einer Website
brauche ich die Datenbank, um die Größe meines eingebetteten Widgets in Ellen zurückzugeben
, damit ich eine Bestellung für ein gemütliches Widget aufgeben kann.

Diese Story wird dann mit dem Datenbankteam geteilt, die der DBA Product Owner in das Product Backlog des Datenbankteams aufnehmen und in Abstimmung mit dem Product Owner des Webteams priorisieren kann. Das ist das Ideal, das Sie anstreben sollten.

Andernfalls dient die User Story immer noch als Ausgangspunkt für Gespräche zwischen Mitgliedern des Webteams und des Datenbankteams. Es ist keine vollständige Spezifikation und soll es auch nicht sein. Es ist ein Mechanismus, um Kontext zwischen den Teams bereitzustellen, sodass beide Teams einen gemeinsamen Bezugsrahmen haben, während sie die Implementierungsdetails ausarbeiten.

In meiner täglichen Arbeit habe ich mich mit dem Thema verteilter agiler Teams und der Kommunikation innerhalb / zwischen Teams beschäftigt. Ich habe kürzlich ein paar (meiner Meinung nach) nützliche Hinweise dargestellt. Details finden Sie im Beitrag .

Dieser Artikel fasst mehrere Verbesserungen in der Kommunikation zusammen, die in einem der großen Projekte eingeführt wurden, an denen ich gearbeitet habe. Um Ihnen ein wenig Kontext zu geben – es geht um die Zusammenarbeit im Offshoring-Modell , bei dem sich Teams in verschiedenen europäischen Ländern befinden.

In dem Beitrag schlage ich vor, folgende Verbesserungen einzuführen:

• Scheuen Sie sich nicht, Kunden zu besuchen und an Land zu arbeiten
• Machen Sie alle Beteiligten mit dem Prozess vertraut
• Regelmäßiges Feedback zu Prozessen
• täglicher und wöchentlicher Besprechungsrhythmus
• kompetente Kommunikationsrollen
• klare Richtlinien zum Aufbau von Backlogs (User Stories, Storys Maps etc.)
• die Product Owner Proxy Institution – richten Sie diese intern auf Ihrer Seite ein
• robustes Projektverfolgungstool für den Austausch zwischen den Teammitgliedern

Reorganisieren Sie sich in Feature-Teams

Sie können diese Kommunikationsprobleme vermeiden, indem Sie sich in Funktionsteams neu organisieren. Hier sind zwei gute Referenzen:

• Die Abkehr von Komponententeams ist ein schwieriger, aber notwendiger Schritt für diejenigen, die einen agilen Projektmanagementansatz verfolgen möchten.
• Ohne eine Feature-Team-Struktur (aber stattdessen eine Komponenten-Team-Organisation ...) wird Ihre Organisation wahrscheinlich zahlreiche Verschwendungen und Teiloptimierungen schaffen, die zu einem sequentiellen (Wasserfall, ...) Entwicklungszyklus führen.

Wenn das überhaupt nicht möglich ist, richten Sie Scrum-of-Scrum-Meetings ein, wie von @CodeGnome vorgeschlagen. Mehr dazu hier:

• Obwohl dies nicht das Einzige ist, was für die Skalierung von Scrum erforderlich ist, ist eine bekannte Technik die Verwendung eines „Scrum of Scrums“-Meetings. Bei diesem Ansatz geht jedes Scrum-Team wie gewohnt vor, aber jedes Team bestimmt eine Person, die am Scrum of Scrums-Meeting teilnimmt, um die Arbeit mehrerer Scrum-Teams zu koordinieren. Diese Meetings sind analog zum Daily Scrum Meeting, finden aber nicht unbedingt jeden Tag statt. In vielen Organisationen reicht es aus, zwei- oder dreimal pro Woche ein Scrum of Scrums-Meeting abzuhalten.

Beim Lesen Ihres ursprünglichen Beitrags ist mir aufgefallen, dass Sie sagten: „Die Produktteams haben Bibliotheken erstellt, die dupliziert haben … was die Shared-Services-Teams vor einem Jahr getan hatten.“ Im Fall von Shared Services ist es sehr wichtig, dass jeder genau sehen kann, welche Shared Services verfügbar sind und was genau sie bereitstellen oder bereitstellen werden.