Verbesserung von Flow und Fokus bei Innovationsteams für Finanzprodukte durch Transparenz über Probleme und deren Dauer

Einführung

Finanzproduktinnovationen sind oft mit harten Herausforderungen verbunden, beispielsweise in einer organisatorischen, technologischen sowie persönlichen Dimension von Teams, Stakeholdern und Individuen eines Teams. Viele Teams kennen ihre größten Blockaden in Bezug auf eine gute Interaktion mit den Stakeholdern nicht und messen nicht ihre Problemzeit. Die Management-3.0-Praxis „Problem Time“ kann daher helfen, die Kollaboration und den Fokus auf eine hohe Kundenzufriedenheit zu fördern.

Die Praxis kurz erklärt

Zunächst muss Transparenz über die relevanten Probleme geschaffen werden. Dies kann zum Beispiel durch ein Team-Brainstorming und mithilfe des Team-Facilitators unterstützt werden, damit darauf aufbauend ein Improvement Backlog abgeleitet werden kann. Zudem sollten in diesem Zuge auch das Problemaufnahmedatum sowie die geschätzte Dauer zur Beseitigung notiert werden. Wichtig ist, sich im Fall von Finanzproduktinnovationen auch auf die Kundenzentrierung zu konzentrieren, das heißt also, die Probleme hierauf bezogen zu ordnen und zu priorisieren. Berechnen Sie dann gemeinsam die durchschnittliche Problemzeit, damit diese regelmäßig hinsichtlich des Ist-Zustandes, der ursprünglichen Schätzung und dem noch bestehenden Aufwand überblickt werden kann. Das entstandene Improvement Backlog sollte jede Woche überprüft und angepasst werden, damit es regelmäßig aktualisiert wird und gegebenenfalls neue notwendige Maßnahmen zur Lösung der Probleme gemeinsam abgeleitet beziehungsweise bestehende Maßnahmen angepasst werden können. Dann kann das Improvement Backlog regelmäßig verwendet werden, um mit den Stakeholdern abzustimmen, was besser gemacht werden sollte beziehungsweise welche Probleme existieren, und um diese ins Improvement Backlog mit entsprechender Priorität aufzunehmen.

Warum habe ich mich für diese Praxis entschieden?

Mein Team hatte große Probleme im Umgang mit den Stakeholdern und ich spürte während des Sprint-Reviews, dass eine Art Misstrauen wuchs. Die Stakeholder waren mit den Ergebnissen unzufrieden und gaben auch im Rahmen der Zusammenarbeit dem Product Owner kein gutes Feedback. Es schienen einige nicht transparente Probleme in der Luft zu liegen. Ich wollte mehr Transparenz schaffen, um Vertrauen aufzubauen und eine Überprüfung und Anpassung des Prozesses in meinem Team für Finanzproduktinnovationen zu ermöglichen.

Wie habe ich diese Praxis genutzt?

Ich habe in der kommenden Sprint-Retrospektive ein Experiment durchgeführt, bei dem alle Teammitglieder zusammen waren. Wir haben an einem Online-Whiteboard über die aktuellen Probleme unseres Teams und insbesondere mit unseren Stakeholdern gebrainstormt. Dann haben wir die Probleme ins Issue-Tracking-Tool Jira aufgenommen, um ein Improvement Backlog zu erstellen und uns durch ein Aufnahmedatum zu merken, wann die Probleme hinzugefügt wurden. Wir haben die Problemzeit für jeden geschätzt. Dann konnte ich als Moderator die durchschnittliche Zeit für das gesamte Board berechnen, sodass ich vor dem Team Transparenz über die Gesamtproblemzeit schaffen konnte. Danach habe ich mir jede Woche eine wiederkehrende Aufgabe erstellt, um das Improvement Backlog zu überprüfen und anzupassen. Wichtig war dabei, die Stakeholder unserer Produktinnovation zu fragen, was wir als Team besser machen können, und dadurch Transparenz und Vertrauen zu stärken.

Meine Erkenntnisse als Moderator

Die Problemzeit war für mich bisher eine der effektivsten Methoden, um den Fokus und die Zusammenarbeit mit unseren Stakeholdern und innerhalb unseres Teams zu fördern.

Wie hat sich das Team bei der Implementierung des Tools gefühlt?
Das Team hatte zunächst Zweifel, ob die neue Transparenz der Zusammenarbeit mit unseren Stakeholdern hilft oder mehr schadet. Daher war es nützlich, dass ich eine kurze Erfolgsgeschichte aus meiner früheren Arbeitserfahrung in einem meiner anderen Teams erzählte, in dem ich ebenfalls Facilitator war. Ich erklärte dem Team, dass das Vertrauen und die Produktivität gestiegen waren, nachdem wir die Messung der Problemzeit durchgeführt hatten. Diese eigene Erfahrung hat mir sehr geholfen, das Eis für diesen neuen Ansatz für mein aktuelles Team zu brechen.

Als Experiment betrachtet, was lief richtig und was ist schiefgelaufen?
Wir haben gelernt, dass es sinnvoll ist, regelmäßige Refinement-Events für unser Improvement Backlog mit den Stakeholdern zu fördern, um offen zu sprechen und die Klarheit der dokumentierten Probleme zu verbessern. Diese Kadenz und Synchronisation ermöglichten es uns auch, die Probleme in besser handhabbare und verständliche Stücke aufzuteilen – bevor es manchmal schwierig war, den Überblick über nur grob beschriebene größere Probleme zu behalten.

Wie war das Feedback der Leute?
Mein Team hat mir als Moderator sehr gutes Feedback gegeben und das Vertrauen der Stakeholder in unsere Arbeitsweise hat sich deutlich verbessert. Der Flow wurde erhöht und die Verzögerungen wurden reduziert.

Was könnte ich beim nächsten Mal besser oder anders machen?
Ich kann Ihnen raten, mit Beginn der ersten Sprint-Retrospektive die Problemzeit zu messen und das Improvement Backlog zu überprüfen und anzupassen. Als weiteres Experiment werde ich diese Technik in den nächsten vier Wochen für eines unserer Kanban-Teams während der nächsten Lessons-Learned- oder Inspect-and-Adapt-Veranstaltung anwenden, da die Methode bereits bei einem meiner Scrum-Teams, wie oben beschrieben, sehr gut funktioniert hat.