Teil 2/4 aus der Serie „Agilität meets Großgruppenkonferenz: Ein Paradox aus Komplexität und Leichtigkeit“

Kann es erstaunlich leicht sein, die heutigen komplexen Herausforderungen zu erfassen und schließlich auch zu meistern? Kann es uns gelingen, auf uns noch unbekannte Fragen Antworten zu finden, Antworten, die wirklich zur Veränderung führen? Können wir erreichen, dass wir gemeinsam ins Bewegen und Verändern kommen, ohne schon vorher zu wissen, wo es uns hinführt?

Man kann in der Serie mit Teil 1 beginnen, https://carole-maleh.com/blog/mensch-meets-komplexitaet-und-hat-alles-was-er-dazu-braucht-sie-zu-begreifen/ oder gleich in Teil 2 einsteigen.

Was hat Agilität mit der bewussten Steigerung der organisatorischen Komplexität zu tun? Dazu haben wir in Teil 1 ausführlicher gesprochen. Wie lässt sich nun mit dem Ansatz der Agilität die Komplexität unserer heutigen Herausforderungen begegnen? Ich möchte zur Erläuterung agiler Arbeitsweisen einen Sprint eines fiktiven Scrum-Teams schildern, als dessen Scrum-Master ich schreibe.

Sprint-Planning

Das Developer-Team und der Product-Owner kommen heute zusammen, um die Inhalte und Ziele des kommenden Sprints festzulegen. Der Product-Owner vertritt dabei die Perspektive des Kunden und formuliert über sogenannte User-Stories, welche neuen Funktionen entwickelt werden sollen. Ich achte dabei darauf, dass zwischen Product-Owner und dem Developer-Team tatsächlich ein einheitliches Verständnis über die Kundenanforderungen entsteht. Das kann durchaus einmal länger dauern und anstrengend werden.

Über die Priorisierung der User-Stories und dessen Anforderungen an unsere Software legt der Product-Owner fest, in welcher Reihenfolge diese umgesetzt werden sollen. Anschließend trifft das Developer-Team eine Aussage, welche User-Stories es im Sprint umsetzen kann. Dabei handelt es sich quasi um ein verbindliches Versprechen, das nur das Developer-Team abgeben darf. Gelegentlich ist der Product-Owner enttäuscht, weil er sich erhofft hat, dass mehr Kundenanforderungen erfüllt werden können. Ich achte darauf, dass er das Developer-Team nicht drängt, mehr zuzusagen als realistisch. Die Umsetzung der Anforderungen erfolgt während des Sprints eigenverantwortlich durch das Developer-Team.

Daily-Scrum

Erfahrene Developer-Teams brauchen mich zu diesem 15-minütigen täglichen Treffen in der Regel nicht mehr. Anfangs ist es allerdings notwendig, dass ich darauf achte, dass jedes Teammitglied zu Wort kommt und dabei die folgenden drei Fragen beantwortet:

  1. Was habe ich seit dem letzten Daily getan?
  2. Was werde ich bis zum nächsten Daily tun?
  3. Wo bin ich auf Hindernisse gestoßen?

Gibt es weiteren Abstimmungsbedarf, wird das Developer-Team dies außerhalb des Daily-Scrums klären.

Sprint-Review

Heute wird es ernst. Im Sprint-Review präsentiert das Developer-Team dem Product-Owner die Ergebnisse des vergangenen Sprints. Gerne werden zu Sprint-Reviews auch Kunden oder Anwender eingeladen. Ich unterstütze das Sprint-Review darin, darauf zu achten, dass die Ergebnisse verständlich und anschaulich dargestellt werden und dass das Developer-Team ausreichendes und offenes Feedback zu den Ergebnissen erhält. Wertschätzung ist dabei eine wesentliche Voraussetzung. Nach dem Spint-Review sollten alle ein gemeinsames Verständnis über den inhaltlichen Fortschritt, den verbleibenden Schritten und die erreichte Qualität haben.

Christian (46): Product-Owner eines Scrum-Teams

Ich bin zum ersten Mal Product-Owner eines Scrum-Teams. Vorher war ich neun Jahre Projektmanager. Das erste Sprint-Planning vor zwei Wochen hat sich sehr komisch angefühlt. Ich bin skeptisch, was beim heutigen Review wohl zu Tage tritt, schließlich habe ich zwei Wochen lang wenig vom Team gehört. Gewohnt bin ich als Projektmanager wortreiche Erklärungen, warum Leute ihre Aufgaben nicht geschafft haben.

Jan präsentiert heute das Ergebnis des Sprints. Mal gespannt, wo er doch sonst so schüchtern ist. Wow, jetzt steht er mit leuchtenden Augen am Smartboard und demonstriert stolz die Features, die das Team in diesem Sprint implementiert hat. Und getestet ist auch schon alles. Ich bin beeindruckt.

Jetzt bin ich an der Reihe, Feedback zu geben. Ich habe ein paar Anmerkungen an die Details der Benutzerführung, die das Team interessiert aufnimmt. Keine Spur von Ärger, dass ich das Ergebnis nicht uneingeschränkt positiv einschätze.

Das Sprint-Ziel ist geschafft. Ich habe die Software tatsächlich arbeiten gesehen und konnte meine Verbesserungswünsche einbringen. Ich bin begeistert. Am schönsten war es aber, Jans verändertes Auftreten zu erleben.

Retrospektive

Die Retrospektive ist das Event im Sprint, bei dem ich als Scrum-Master am meisten gefragt bin. Zweck der Retrospektive ist die Reflexion der Arbeitsweisen und Zusammenarbeit des Scrum-Teams (Developer-Team, Product-Owner und Scrum-Master) mit dem Ziel, diese kontinuierlich zu verbessern. Meine Rolle dabei besteht im Wesentlichen darin, den Raum für den Austausch zu schaffen, Impulse dafür zu geben, wo nötig, Verbesserungspotentiale sichtbar zu machen, sollten sie nicht erkannt werden und bei der Entwicklung von Zielen und Maßnahmen zu deren Nutzung dieser Potenziale zu unterstützen. Bei fortgeschrittenen Teams findet dieser Arbeitsprozess im Idealfall ohne mein Zutun selbstständig im Team statt. In manchen Fällen inspirieren Impulse aus meinem Erfahrungsschatz oder sind für das Team sogar nötig, um in den nächsten Lernschritt zu kommen.

Die Retrospektive ist in Hinsicht auf die Weiterentwicklung des Teams das wichtigste Event innerhalb des Sprints. Ich bin dabei Moderator, Coach oder auch Berater, abhängig davon, was das Team gerade benötigt. Mental stelle ich mich darauf ein, nach den Bedürfnissen des Teams vorzugehen. Für mich ist es dadurch auch das schönste Event.

Anja (38): Entwicklerin in einem Scrum-Team

Heute ist Retrospektive und der Scrum-Master hat uns dazu aufgefordert, Dinge aufzuschreiben, die uns in unserem letzten Sprint fröhlich, traurig oder zornig gemacht haben. Es gibt da eine Sache, die mich wirklich zornig gemacht hat, aber ich weiß nicht so recht, ob ich sie hier ansprechen soll, wenn alle anderen zuhören. Letzten Montag hatte ich den Eindruck, Thorsten könne meine Unterstützung gebrauchen. Also bin ich nach der Mittagspause zu ihm ins Büro gegangen: „Thorsten, ich habe das, woran du dir anscheinend gerade die Zähne ausbeißt, schon oft gemacht. Lass mich Dir helfen.“ Ich war zunächst überrascht, als er mich sehr barsch abgefertigt hat. Er braucht keine Hilfe, so sagte er. Schon gar nicht von mir. Im Nachhinein habe ich mich sehr darüber geärgert.

Ich fasse mir ein Herz und schreibe eine Karte „Mein Hilfsangebot wurde sehr rüde zurückgewiesen“ und hänge die Karte unter „zornig“ an die Pinnwand. Zerknirscht steht Thorsten auf und hängt seine Karte mit den Worten „Ich habe eine Kollegin sehr ungerecht behandelt“ in die „traurig“-Spalte und sagt: „Anja, ich muss mich bei dir entschuldigen. Ich hätte nicht so reagieren dürfen. Es hatte eigentlich nichts mit dir zu tun, sondern damit, dass ich mich überfordert gefühlt habe.“ Ich bin erleichtert, dass wir den Vorfall noch einmal thematisiert haben.

Fazit

Dieser Scrum-Sprint zeigt, wie ein Team, in sich durch die Unterschiedlichkeit seiner Mitglieder in Kompetenz, Erfahrung und Persönlichkeit vielfältig denkend, mit klarer Struktur, gesetztem Rahmen und vereinbarten Rollen selbstgesteuert, gezielt und fokussiert einen Arbeitsprozess durchläuft, mit dem Ergebnis, zu einer spezifischen Fragestellung, die optimale Lösung zu entwickeln und dies ohne Hierarchie und Anweisungen von außen.

Dieses Konstrukt, multipliziert auf die gesamte Organisation, würde ein Netz vieler solcher Teams offenbaren. Teams, die alle für sich selbstorganisiert, interdisziplinär und zu jeweils konkreten Fragestellungen arbeiten, alle nach dem gleichen „einfachen“ Ablauf mit „einfacher“ Methodik und mit einer passenden Struktur.

Darüber hinaus erfolgt durch diesen Ansatz der Lösungsprozess durch die Mitarbeiter, was wiederum bedeutet, dass in allen Unternehmensbereichen die Mitarbeiter für die Bewältigung der Herausforderungen verantwortlich sind. Nicht nur, dass es dadurch zu einer schnellen Bearbeitung von Fragen im Unternehmen kommt, der Unternehmenserfolg wird darüber hinaus von den Mitarbeitern selbst getragen. Es wird nicht mehr das Top-Management sein, das sich allein in der Verantwortung für den Unternehmenserfolg fühlt. Es wird eine geteilte Führung und Verantwortung sein.

Teil 2/4 aus der Serie „Agilität meets Großgruppenkonferenz: Ein Paradox aus Komplexität und Leichtigkeit“. In Teil 3 geht es um das Thema „Großgruppenkonferenzen meets Komplexität: Ein Paradox aus Struktur und Freiraum“.

„Wenn die Herausforderungen extrem viele Aspekte betreffen, unterschiedliche Abhängigkeiten bestehen, immer wieder neue Impulse eintreffen, der Überblick über dem Ganzen fehlt, man nicht weiß, wo man anfangen soll und viele Menschen gebraucht werden, um schnell ins Handeln zu kommen, dann macht es Sinn, alle Zielgruppen zur gleichen Zeit in einen Raum zu bringen – in eine Großgruppenkonferenz…“

Viel Freude & Inspiration
Ihre
Carole Maleh & Stefan Müller

 

War das für Sie interessant? Sind Sie neugierig auf mehr?
Melden Sie sich gern bei mir!
Tel.: 0173/ 62 61 62 8
cama@carole-maleh.com
www.carole-maleh.com

Write A Comment

fünf × 2 =