Der Übergang zu einer agilen Arbeitsweise ist mehr als eine Prozessänderung. Er erfordert eine andere Art der Interaktion und des Verhaltens sowie eine andere Denkweise. Bei einer großen (etwas weniger als 200 Personen) Agile-Implementierung haben wir eine Agile Mindset-Sitzung organisiert, um die agilen Prinzipien zu erläutern und die agilen Teams aus der Bequemlichkeit ihrer traditionellen Muster herauszuholen.
Erfolgreich auf die agile Schiene kommen...
Im Rahmen eines großen agilen Transformationsprojekts haben 11 Teams vor weniger als 2 Monaten begonnen, nach der agilen Methode zu arbeiten. Wir haben sie auf einen 3-wöchigen Iterationskurs gesetzt, so dass sie sich jetzt in ihrem
3. Die Teams arbeiten erstaunlich gut: Sie haben es geschafft, die Software innerhalb des Sprints bis zur Produktionsreife zu bringen, und die Retrospektiven bestätigen, dass sich die Interaktion und der Teamgeist sehr schnell entwickeln. Und wir können Ihnen sagen, dass das bei der "alten" Arbeitsweise, die sehr traditionell, wasserfallartig, silozentrisch und hierarchisch kontrolliert war, ganz anders war.
Aber ist es agil?
Gleich zu Beginn des 1-wöchigen Sprints 0 nahmen die Teammitglieder an einem 1-tägigen Agile-Einführungskurs teil, in dem das Agile Manifest etwa eine Stunde lang besprochen wurde. Während der ersten beiden Sprints lag der Schwerpunkt des täglichen Team-Coachings auf der Zusammenarbeit im Team, der Lösung von Problemen im Team und natürlich der Lieferung der Software. Wie bereits erwähnt, schlugen sich die Teams sehr gut, aber die Problemlösungen lagen eher auf der 'rechten Seite' des Manifests und waren weniger effizient als aus agiler Sicht wünschenswert.
Deshalb beschlossen wir, die Teams in Sprint 3 einer Agile Mindset-Behandlung zu unterziehen.
Die Agile Mindset-Sitzung erklärt
Der Aufbau der Agile Mindset-Sitzungen ist recht einfach:
- Was ist das und warum machen wir das jetzt?
- Wir erklären Ihnen die 4 Agile-Werte
- Das Team erhält die Aufgabe, die Teamerfahrungen mit den 4 Werten in Verbindung zu bringen, und
- Wir diskutieren darüber, wie Probleme mit einer agilen Denkweise gelöst werden sollten.
Wir beginnen jede Sitzung mit einer kurzen Erklärung: Wir wollen Ihnen die agilen Werte noch einmal ins Bewusstsein rufen, weil wir glauben, dass sie Ihre Arbeitsweise effizienter machen können. Und ja, wir glauben, dass es so wichtig ist, dass wir Sie in Ihrem Sprint stören...
Wir haben das Team dann gebeten, sich die 4 Agilen Werte ins Gedächtnis zu rufen und ein wenig über deren Bedeutung zu sprechen. Es war interessant herauszufinden, dass Teams agil arbeiten, ohne sich an die agilen Werte erinnern zu können ...
Als nächstes schrieb jedes Teammitglied seine Erfahrungen, die es mit den Werten in Verbindung brachte, auf einen Zettel und erklärte sie dem Team kurz.
Das alles dauerte etwa 30 Minuten.
Für die zweite Hälfte der Sitzung wählte der Moderator die am häufigsten genannten Probleme aus und diskutierte sie mit dem Team. Er forderte das Team auf, die Lösungen zu erläutern, die sie bisher ausprobiert hatten, und "zwang" das Team, nach einer "linken", agilen Denkweise zu suchen. Das frustrierte das Team eindeutig und sorgte für Unbehagen. Im Raum regte sich Widerstand, und der Moderator wurde aufgefordert, gnadenlos an seinen Werten festzuhalten, um das Team aus seiner Komfortzone herauszuholen und eine neue Denkweise kennenzulernen.
Die interessanteste Diskussion betraf ein Team, das mit einem Kunden mit mehreren Gesichtern umgehen musste. Sie waren davon überzeugt, agil zu sein, weil sie dieses Problem mit viel Energie über 'Individuen und Interaktion' und 'Zusammenarbeit mit dem Kunden' bekämpften. Das war zwar eine gute Idee, löste aber nicht ihr Problem. Sie verloren in jedem Sprint (zumindest in den ersten 3) wertvolle Zeit, um die Anforderungen zu klären. Das Team gab an, dafür bis zu 10 Entwicklungstage im Sprint zu verwenden! Als nächste Schritte schlugen sie vor, die Kunden zum Ausfüllen von Checklisten zu drängen und die Dokumentation zu verbessern. Nicht um der Dokumentation an sich willen, sondern um die verschiedenen Geschäftsbereiche zu zwingen, mehr miteinander zu interagieren und ihre Entscheidungen zu dokumentieren.
Es bedurfte einer heftigen Diskussion, um dem Team zu zeigen, dass das Prinzip der 'Arbeitssoftware' ebenfalls eine Lösung bieten kann: Wenn man zu Beginn des Sprints eine Arbeitssoftware erstellt und sie dann allen verschiedenen Geschäftsbereichen vorführt, beschleunigt das den Prozess, die Anforderungen zu klären und die Lösung zu definieren. Ja, das wird sicherlich zu Refactoring oder vielleicht sogar zu weggeworfenem Code führen, aber das passiert doch auch in der aktuellen Situation, oder nicht? Und Software mehrfach anzufassen, bevor sie akzeptiert wird, ist doch nichts Schlechtes, oder?!
Ein empfohlener Schritt, um den Unterschied zu machen
Prozesse zu ändern ist eine Sache, aber die Umstellung auf eine agile Arbeitsweise erfordert auch eine Änderung der Denkweise. Bei einem großen Projekt zur agilen Implementierung haben wir beschlossen, für jedes Team Sitzungen zum Thema agile Denkweise zu organisieren. Wir taten dies nach ein paar Sprints, um den Teams Zeit zu geben, sich erst einmal aufzubauen und sich an die grundlegenden Scrum-Muster zu gewöhnen. Die Agile Mindset-Sitzung ist sicherlich eine herausfordernde, unangenehme Erfahrung für die Teammitglieder, aber sie ist eine gute Möglichkeit, sie für einen anderen Ansatz zu öffnen.
