Überwindung der Kluft zwischen Geschäftsinteressenten und Entwicklungsteams

Einführung

Wie oft kann sich Ihr Unternehmen rühmen, einen stetigen und vorhersehbaren Produktivitätsfluss zu haben?

In der heutigen Geschäftswelt ist die Synergie zwischen Interessengruppen, Produktmanagement und Entwicklungsteams von größter Bedeutung. Eine angenehme Zusammenarbeit sorgt für reibungslose Prozesse und rechtzeitige Lieferungen mit qualitativ hochwertigen Ergebnissen. In der Praxis ist diese gewünschte Synergie jedoch oft schwer zu erreichen und führt im schlimmsten Fall zu einer isolierten Arbeitsumgebung.

Lassen Sie uns über eine Situation sprechen, in der die scheinbare Produktivität eine zugrundeliegende Unstimmigkeit überdeckte, und wie Xebia versuchte, die Situation zu lokalisieren und zu verbessern.

Das Problem des Kunden

Bei einem unserer großen Kunden bei Xebia beschwerten sich die Kunden, dass die Projektgeschwindigkeit inkonsistent war, während das Entwicklungsteam ständig beschäftigt schien. In einer Woche konnte das Entwicklungsteam zum Beispiel fünf wichtige Funktionen fertigstellen, während es in einer anderen Woche trotz ähnlicher Arbeitsbelastung nur zwei fertigstellen konnte. Das Unternehmen war oft unzufrieden mit dem Entwicklungsteam und dessen langsamen Fortschritten - und das Gefühl beruhte auf Gegenseitigkeit. Das Entwicklungsteam kommentierte, dass es dem Unternehmen an aktiver Beteiligung zu mangeln schien, da es oft wichtige Meetings verpasste und die notwendigen Ressourcen nicht bereitstellte.

Nachdem Xebia dem Projekt beigetreten war und mit den Beteiligten gesprochen hatte, begann das Unternehmen, harte, kalte Daten zu sammeln - indem es sich die Aktivitätsmetriken im Issue Tracker (JIRA) des Kunden und die Commit-Historien in seinem Versionskontrollsystem (GIT) ansah. Das anfängliche Ziel war es, widersprüchliche oder unterstützende Beweise für die Aussagen der Projektteilnehmer zu finden.

Es stellte sich heraus, dass große Teile der Arbeit verschwendet und weggeworfen wurden. Oft mussten Arbeiten, die für die Produktion vorbereitet waren, komplett neu erstellt werden:

• Das lag vor allem daran, dass die Beteiligten während der Sprint-Prüfungen die Arbeit als ungeeignet für die Produktion befanden. Infolgedessen wurde ein beträchtlicher Teil der ursprünglichen Arbeit aufgegeben und musste neu erstellt werden, unabhängig davon, ob es sich um Probleme mit der Benutzeroberfläche, der Benutzerfreundlichkeit oder um Ungenauigkeiten in der Datendarstellung handelte.
• Noch beunruhigender war jedoch die Ineffizienz, die sich durch den gesamten Prozess zog. Nicht nur, dass das Entwicklungsteam wertvolle Zeit auf Funktionen verwendete, die nicht genehmigt wurden, auch das Produktteam musste Rückschläge hinnehmen. Sie investierten viel Mühe in die Vorbereitung, Verfeinerung und Detaillierung der User Stories, nur um dann festzustellen, dass die Hälfte davon nie in die Implementierungsphase gelangte.

Bei näherer Betrachtung und Vertiefung in den Sitzungen zusammen mit den Mitgliedern des Entwicklungsteams wurden diese Wiederholungen auf die folgenden Ursachen zurückgeführt:

• Zweideutige Anforderungen: Oft waren die Spezifikationen, die dem Entwicklungsteam vorgelegt wurden, unklar. Ohne klare Richtlinien mussten der Product Owner und die Entwickler Annahmen treffen, die manchmal von den Erwartungen der Beteiligten abwichen. Und die Beteiligten waren oft "zu beschäftigt" oder zu weit weg, um sie aufzuklären.
• Mangel an regelmäßiger Kommunikation: Die Kommunikationskanäle zwischen den Stakeholdern und den Entwicklern waren selten und unregelmäßig und erfolgten meist über Kommentare in JIRA oder E-Mail-Korrespondenz über einen Product Owner. Das bedeutete, dass Missverständnisse nicht rechtzeitig geklärt werden konnten, was zu mehr Arbeit als nötig führte.
• Verzögerungen beim Feedback: Wenn das Entwicklungsteam eine Funktion oder ein Modul (oder einen Teil davon) fertigstellte, gab es erhebliche Verzögerungen beim Erhalt von Feedback. Das führte oft dazu, dass das Team von einem Irrtum ausging und sein Feedback erst bei der Sprint-Überprüfung am Ende des Sprints erhielt.
• Sich ändernde Prioritäten: Die Geschäftsseite änderte manchmal ihre Prioritäten mitten in der Entwicklung, was dazu führte, dass zuvor wichtige Aufgaben überflüssig wurden und das Entwicklungsteam daher seinen Schwerpunkt verlagern und die geleistete Arbeit verwerfen musste.
• Fehlen einer Vermittlerrolle: In vielen erfolgreichen Projekten fungiert ein Business Analyst oder ein Product Owner als Brücke zwischen dem technischen Team und den Geschäftsinteressenten. Noch wichtiger ist, dass sie als Gatekeeper fungieren und eine Person sind, die über die Annahme oder Ablehnung einer Anfrage, die Klärung von Fragen oder die Einhaltung von Standards entscheiden kann. In diesem Szenario war diese Person nicht effektiv genug. Sie fungierte eher als Sekretärin oder Planerin, anstatt ein Produkt zu besitzen.

Ansatz zur Verbesserung

Obwohl der Prozess eindeutig vorhanden war (zumindest auf dem Papier), litt das Team immer noch unter der schlechten Leistung und Vorhersehbarkeit seiner Planung. Um die Herausforderungen anzugehen und zu überwinden, setzte Xebia gemeinsam mit dem Kunden die folgenden Maßnahmen um:

1. Stärkung der Vermittlerrolle: Der Product Owner und die Business Analysten nahmen an einer Schulung teil, um ihr Verständnis für ihre Aufgaben und ihr Mandat aufzufrischen. Außerdem haben wir die Unterstützung des Managements eingeholt, um sicherzustellen, dass der PO die Macht hat, Entscheidungen zu treffen und die Verfügbarkeit der Stakeholder einzufordern, wenn diese benötigt wird.
2. Verfeinerte Anforderungsdokumentation: Wir führten mehrere Workshops zum Thema "Specification by Example" durch - ein kollaborativer Ansatz zur Definition von Anforderungen und geschäftsorientierten Funktionstests, gemeinsam mit dem Entwicklungsteam und den Interessengruppen. Den Teilnehmern gelang es, die Erwartungen der anderen kennenzulernen und sich auf Formate und Regeln für ihre Anforderungsanfragen zu einigen. Infolgedessen nahm die Mehrdeutigkeit bei der Aufgabenverfeinerung deutlich ab, was zu einer genaueren Entwicklungsabschätzung und einer einfacheren Planung führte.
3. Durchgesetztes Format für die Anforderungserfassung und den zugehörigen Prozess: Im Anschluss an den Workshop haben wir einen standardisierten Prozess für die Anforderungserfassung zusammen mit einer gemeinsamen Vorlage eingeführt (und durchgesetzt). Wir leiteten die ersten Verfeinerungssitzungen aktiv an, um sicherzustellen, dass alle Beteiligten - von den Geschäftsinteressenten bis zum PO - denselben Prozess und dasselbe Format verstanden, befolgt und eingehalten haben. Dadurch wurde nicht nur der Prozess der Anforderungserfassung gestrafft, sondern auch sichergestellt, dass alle, von den Entwicklern bis zu den Stakeholdern, die Anforderungen auf dieselbe Weise verstanden und interpretiert haben. Das Ergebnis war eine deutliche Reduzierung der Hin- und Her-Kommunikation und der Nacharbeit aufgrund von Missverständnissen.
4. Etablierung regelmäßiger Kommunikationskanäle: Wir haben vorübergehend (6 Wochen lang) wöchentliche Stand-up-Meetings zwischen dem Entwicklungsteam und den Stakeholdern (unter der Leitung des PO) eingeführt, um die laufenden Arbeiten zu demonstrieren und Feedback einzuholen. Nach dieser vorübergehenden Lösung begannen die Beteiligten und der PO, häufiger und regelmäßiger zu kommunizieren, um sich über den Fortschritt abzustimmen.

Fazit

Die Diskrepanz zwischen den Interessengruppen des Unternehmens und den Entwicklungsteams kann den Erfolg eines Projekts erheblich beeinträchtigen und zu vergeblichen Anstrengungen, Verzögerungen und allgemeiner Unzufriedenheit führen. Diese Reibereien sind oft auf unklare Anforderungen, inkonsistente Kommunikation und wechselnde Prioritäten zurückzuführen. Sie werden durch verzögertes Feedback, das Fehlen einer befähigten Vermittlerrolle oder das Fehlen einer klaren Anweisung durch die Unternehmensleitung noch verschlimmert.

Der schwierigste Teil dabei ist zu erkennen, woher die Probleme kommen. In dieser Situation hat Xebia dem Kunden erfolgreich dabei geholfen, die Ursachen für seine Probleme zu erkennen und zu beheben. Die Daten und alle notwendigen Informationen waren jedoch bereits vorhanden - und einige Beispiele für die Erkenntnisse, die Sie daraus gewinnen können, können Sie diesem wunderbaren Artikel von Lennart Tange entnehmen.

Durch sorgfältige Beobachtung der Betriebsabläufe und Identifizierung von Hindernissen können sich viele Unternehmen selbst verbessern, vorausgesetzt, sie haben den Willen und die Notwendigkeit dazu. Wenn Sie also proaktiv vorgehen, können Sie viele dieser Probleme vermeiden. Klare Kommunikation, schnelles Feedback und die Sicherstellung einer leicht zugänglichen Beobachtbarkeit Ihrer End-to-End-Prozesse sind einige der besten präventiven Lösungen, die Sie ergreifen können.

Dieser Blog ist Teil unserer Serie " Ganzheitliche Horizonte ". Sehen Sie sich den vorherigen Eintrag an - "API-Sicherheit ist mehr als Testen" von Yianna Paris. Oder lesen Sie weiter zum nächsten Artikel - " Einblicke aus Ihren JIRA-Daten zur Verbesserung Ihres Teams " von Lennart Tange.