Raus aus der Wasser-Falle

Ab einer bestimmten Unternehmensgröße steigt die Wahrscheinlichkeit, dass die Einführung eines neuen Managementframeworks wie Scrum nicht ad hoc, sondern häppchenweise erfolgt. Neben offensichtlichen Faktoren, wie der Angst davor, dass es die erhoffte Wirkung - spürbare Verbesserung und zwar sofort und überall - verfehlen könnte, spielen auch andere Überlegungen eine Rolle. So zum Beispiel die Fragen: Was passiert mit bestehenden Stellen und Funktionen? Wie halte ich den Betriebsrat bei Laune? Oder ganz einfach: Was ist eigentlich dieses Scrum?Bei allem Verständnis für diese Zurückhaltung muss sich die Organisation jedoch auch über die daraus resultierenden Konsequenzen im Klaren sein: Solange ein Scrum-Team in einer Umgebung arbeitet, die auf seine Termine, Sprints und Rollen keine Rücksicht nimmt - zum Beispiel, weil die Umgebung diesbezüglich nicht geschult wurde - ist es für dieses Scrum-Team unmöglich, erfolgreich zu arbeiten und die erforderliche Qualität zu liefern.Bei den involvierten Parteien führt das unweigerlich zu Frust: Die Scrum-Teams fühlen sich zu Versuchskaninchen degradiert, die ständig ihre Sprint-Ziele reißen, weil andauernd irgendwelche superwichtigen Anforderungsquerschläger das sorgsam priorisierte Sprint Backlog aufmischen und Anforderer verstehen die Welt nicht mehr, weil sie auf einmal auf Zyklen Rücksicht nehmen müssen, die eher an olympische Disziplinen als an Projektmanagement erinnern.Solange zwischen dem agilen und nicht-agilen Teil dieser Unternehmen ein derart spürbares Ungleichgewicht herrscht, arbeiten die Scrum-Teams zwangsläufig weiter um Wasserfall, auch wenn sie sich wegen ihrer Dailies, Weeklies und Retros häufiger sehen. Product Owner bleiben in der Termin-vor-Qualität-Falle stecken, weil sie keine Chance haben, das Product Backlog selbst zu priorisieren und ihnen nicht die versprochene Produktverantwortung übertragen wird. Die Impediment Backlogs der ScrumMaster erinnern vom Umfang an Weihnachtswunschzettel von Vorschulkindern, weil alles was sie bräuchten, um ihre Teams produktiver zu machen, direkt mit Relikten aus der alten Welt kollidiert.Doch was tun? Zunächst einmal muss klar sein, dass es nie zu spät ist, notwendige Veränderungen herbeizuführen. Im skizzierten Fall liegt ein Großteil der Probleme in der mangelhaften Information der involvierten Stakeholder. Wenn die Mitarbeiter eines Fachbereichs keine Ahnung davon haben, welche Bedeutung die Einführung von Scrum für ihre tägliche Arbeit hat, dann müssen die ScrumMaster dafür sorgen, dass sich dieser Zustand schnellstmöglich ändert. Sollten sie dafür Unterstützung vom Management benötigen, so haben die ScrumMaster alles Recht der Welt, diese Unterstützung einzufordern.An dieser Stelle also drei Tipps, wie ScrumMaster, Product Owner und Management sich mit Eigeninitiative aus der Wasser-Falle befreien können:

• ScrumMaster: Identfiziere gemeinsam mit deinem Product Owner die Schnittstellen zur „alten Welt“ und biete, beispielsweise dem Fachbereich, Scrum-Schulungen an. Wichtig: die Meetings und Arbeitsschritte, bei denen das gemeinsame Verständnis besonders wichtig ist, wie zum Beispiel ein Estimation Meeting oder ein Review, sollten in jedem Fall hervorgehoben werden
• Product Owner: Fordere dein Entwicklerteam noch heute dazu auf, alle Anforderungen, die nicht auf dem Taskboard stehen und vom Fachbereich während eines Sprints direkt an die Entwickler gegeben werden, an dich weiterzuleiten. Dein Ziel ist es, den Sprint zu schützen und das Team an den Aufgaben arbeiten zu lassen, zu denen es sich committed hat
• Manager: Schaffe Verständnis in der Organisation, indem du ScrumMaster und Product Owner darin unterstützt, Erwartungen an Stakeholder und die Teams zu kommunizieren. Geh also aktiv auf deine ScrumMaster zu, und sag ihnen, dass du sie beim nächsten Termin mit dem Fachbereich begleiten möchtest.

Grundsätzlich gilt: Je früher die beteiligten Bereiche und Personen mit den Informationen versorgt werden, die für eine reibungslose Zusammenarbeit in einem agilen Umfeld benötigt werden, desto besser.