Teil 10: Veränderung macht agil, auch wenn sie weh tut

Der Scrum Master: Agiler werden ohne Scrum
1 Kommentar

Wie erhält man die Motivation eines Teams aufrecht, auch wenn die Aufgaben weniger spannend sind? Jürgen Knuplesch zeigt im 10. Teil seiner Serie zum Scrum Master anhand einer erfundenen und doch sehr realen Geschichte, wie man Teams motiviert – und warum Scrum nicht immer mit Agile gleichzusetzen ist.

Wir leben im Zeitalter der Komplexität. Dabei ist Komplexität hier das Maß der Vorhersagbarkeit und nicht das Maß der Verständlichkeit. So ist eine Uhr im obigen Sinne nicht komplex, da das Verhalten der Uhr sehr gut vorhersagbar ist.

Ein Mensch dagegen ist ein komplexes adaptives System, das wir nicht komplett vorausbestimmen können. Der Zusatz „adaptiv“ bezieht sich darauf, dass solche Systeme auch noch anpassungsfähig sind und auf den gleichen Reiz beim zweiten Mal anders reagieren können. Bei Menschen nennt man das häufig „dazulernen“. So ist der „Markt“ ein komplexes adaptives System. Sobald ein Unternehmen ein innovatives Produkt auf den Markt bringt, stellen sich andere Unternehmen darauf ein und entwickeln konkurrierende Produkte.

Hinzu kommt einer der wichtigsten agilen Denkansätze: Es kommt auf den Kontext an. Je nach Kontext reagieren komplexe Systeme unterschiedlich. Wird ein Mann von seinem siebenjährigen Sohn beschimpft, so reagiert er sicher anders als bei einer Beschimpfung durch seinen Chef. Folglich ist die Frage „Was solltest du tun, wenn dich jemand beschimpft?“ ohne den entsprechenden Kontext nicht sinnvoll zu beantworten.

Mehr vom Scrum Master

Alle Teile der Fortsetzungsgeschichte „Der Scrum Master“:

Gute agile Beratung kommt deshalb nicht mit allgemeinen Antworten daher, sondern fast immer mit der Frage: „Was ist hier der Kontext? Bitte erzähl’ mir mehr!“. Agile Beratung setzt auf die Selbstorganisation von Teams, da diese den Kontext ihrer Herausforderungen besser verstehen als der Scrum Master oder der Manager.

Lange Zeit wurde und wird versucht, allgemeingültige Prozesse zur Durchführung komplexer Projekte und zur Entwicklung innovativer Software zu definieren. Der agile Ansatz verneint jedoch die Möglichkeit eines allgemeingültigen Prozesses. Darum nennen die Scrum-Erfinder Scrum auch nicht „Prozess“, sondern „Framework“. Die Idee dahinter ist, dass sich das Team mit Hilfe von Scrum dem Kontext nähert und durch flexible Anpassung sogar hochkomplexe und sehr kontextabhängige Aufgaben zu lösen vermag. Die Magie entsteht also durch die kontinuierliche Veränderung, für die sich das Team öffnet und die es umsetzt. Leider denken viele Unternehmen, dass die Einführung von Scrum sie bereits agil macht. Agil wird Scrum erst dann, wenn sich das Team mit Hilfe der Zyklen und der Retrospektiven immer besser an die Herausforderung anpasst. Das Team ist ein komplexes adaptives System, das sich der gegebenen Herausforderung anpasst.

Genug philosophiert. Schauen wir uns das einmal im Alltag des Scrum Masters an.

Team Ui oder die gelangweilte Cash Cow

Es läuft ganz gut. Ich habe wieder in die Spur gefunden und ich bin dabei, als Scrum Master meine Aufgaben zu erfüllen. Mein Team Ui hat jede Menge Maintenance-Aufgaben zu erledigen, weil die von uns betreuten Produktbestandteile schon lange und bei vielen Kunden in Betrieb sind. Entsprechend viele Bugs sind geöffnet: Zu viele! Hinzu kommen die Bugs, die unsere unermüdlichen Tester finden. Alles geht seinen gewohnten Gang. Mein Team ist nur zu kleinen Teilen davon begeistert, langfristig Bugs zu fixen. Zum Glück gibt es auch ein wenig Neuentwicklung. Eine müde und gelangweilte Routine hat sich wie ein Schatten über das Team gelegt. Nur ab und zu wird es durch die gebetsmühlenartigen Aufforderungen des Managements aufgeschreckt: Die Bugs sollen reduziert werden die Bugs zu reduzieren. Ich merke, wie ich mich von der uninspirierten Langeweile anstecken lasse und reflektiere für mich selbst, warum Wartung per se unter Entwicklern als langweilig gilt. Heldenhaft beschließe ich, eine Vision für unser Team zu finden und die Prozesse zu optimieren. Das Ziel ist es, die Bugs nicht nur im Ticketsystem, sondern auch in der Wirklichkeit in den Griff zu bekommen. Die Schlacht hat begonnen.

Als Erstes stelle ich fest, dass WabelTech sehr viel Geld durch unsere Wartungsverträge verdient. Das wusste ich zwar schon lange, doch nun wird mir auch die Bedeutung des Ganzen für Team Ui klar: Wir sind die Cash Cow für WabelTech. Wir erfüllen die Wartungsverträge, wodurch die Neuentwicklungsteams die finanzielle Basis für die Neuentwicklung erhalten. Die Geschichte vom armen Entwickler, der zu den langweiligen Wartungsarbeiten verdonnert wird, muss also umgeschrieben werden. In Wirklichkeit sind wir die Helden, die das Überleben aller sichern. Ich verbreite diese Sichtweise in jeder Kaffeepause und in jedem Meeting, sofern sich mir die Gelegenheit dazu bietet. Ich vertrete diese Ansicht gegenüber unseren Neuentwicklungsteams, um sie etwas von ihrem hohen Ross zu holen. In einigen Augen meines Teams sehe ich bereits eine gesteigerte Motivation. Ich bin also auf der richtigen Spur. Und die Jungs und Mädels machen auch einen guten Job dabei, Bugs zu fixen und immer neue Patch Releases termingerecht für unsere Kunden zur Verfügung zu stellen. Ich vergesse nicht, ihnen für ihre gute Arbeit zu danken und ihnen mitzuteilen, dass sie dadurch das Geld erwirtschaften.

Der Abschied von Scrum

Dann schaue ich mir den Bug-Abwicklungsprozess an. Sofort sticht mir ins Auge, dass wir hier viel Zeit und Geld sparen können, indem wir uns so organisieren, wie es der Realität entspricht und damit aufhören, die Wirklichkeit an unsere Prozesse anzupassen. Die Wahrheit ist, dass wir für jeden Bereich immer genau einen Entwickler haben. Das agile Ideal der crossfunktionalen Gewaltenteilung ist zwar nach wie vor auch mein Ideal, doch in diesem Kontext derzeit nicht realisierbar. Wir sind schlicht zu wenige Entwickler angesichts der Größe der Aufgaben. Das machen mir auch meine Entwickler unmissverständlich klar. Also entscheiden wir mit dem Product Owner, dass wir die aktuellen Backlogs auch entsprechend themenbezogen bzw. personenbezogen umgestalten. Das tut mir zwar innerlich etwas weh, aber die Effekte sind positiv. Das Backlog wird viel übersichtlicher und man weiß, für welchen Bereich welche Aufgabe die wichtigste ist. Unser Product Owner ist auch nicht der ideale Product Owner, weil er über geringere fachliche Kenntnisse als die Entwickler verfügt. Darum konzentriert er sich auf Priorisierung aus Sicht des Kunden und klärt die fachlichen Themen in Absprache mit dem jeweiligen Entwickler. Fachlich besitzen hier also die Entwickler eine höhere Verantwortung als üblich.

Wir verabschieden uns sogar davon, unser Framework „Scrum“ zu nennen, da wir auch auf die Planung verzichten. Zudem sind unsere Inkremente Patch Releases, die wir immer zu unterschiedlichsten Terminen und nicht zum Sprintende liefern müssen. Also fokussieren wir uns für die Patch-Inkremente auf die Termine, die unser „Patch Manager“ mit den Kunden ausgehandelt hat. Der „Patch Manager“ wird unser wichtigster Stakeholder und steht in engem Austausch mit dem Product Owner, um die Release-Termine und den Release-Inhalt mit meinem Team abzustimmen.

Bug ist nicht gleich Bug

Als nächstes wenden wir uns dem Analyseprozess zu, der sehr stringent gehandhabt wird. Zuerst muss unser Support einen eröffneten Kundenbug reproduzieren, bevor der Bug bei den Entwicklern ankommt. Oft ist das für die Leute vom Support gar nicht möglich. Zudem gibt es Bugs, die der Entwickler mit einem Blick als Anwendungsfehler enttarnt. Bug ist nicht gleich Bug, das wird uns klar. Darum ist ein fixer Prozess an dieser Stelle kontraproduktiv. Wir müssen die Bugs kontextabhängig betrachten. Wir ändern den Prozess. Unser Support-Mitarbeiter im Team nimmt weiterhin als Erster den Bug an. Dann versucht er, den Bug zu reproduzieren. Gelingt ihm das nicht in „vernünftiger“ Zeit, dann gibt er den „Bug“ für eine 15-Minuten-Analyse an den verantwortlichen Entwickler weiter.

DevOps Docker Camp

Sie lernen die Konzepte von Docker und bauen Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf.

Dieses Verfahren erweist sich als wesentlich effizienter als das bisherige Vorgehen. Zusätzlich schulen der Product Owner und ich die Entwickler darin, direkt mit den Kunden über unser Ticketsystem zu kommunizieren. Einige sträuben sich anfangs ein wenig. Wir zeigen ihnen daher, dass die Kunden Menschen sind, die unsere Hilfe benötigen. Nach wenigen Wochen kommen die Entwickler auch damit gut zurecht. Sie fangen damit an, beim Daily die Kundenkontakte namentlich zu erwähnen und haben Spaß daran, ihnen weiterzuhelfen.

Das magische Rezept: Motivation, Effizienz und Flexibilität

Das Ganze geschah in einem Zeitraum von wenigen Monaten. Zusammenfassend halfen folgende Veränderungen dabei, sich der Aufgabe besser anzupassen und dadurch erfolgreicher zu werden:

  • Gesteigerte Motivation durch Vision („Cash Cow“)
  • Gesteigerte Motivation durch aktiv ausgedrückte Dankbarkeit (Wertschätzungskultur)
  • Gesteigerte Effizienz durch verbesserte Kommunikation mit den wichtigsten Stakeholdern
  • Gesteigerte Fokussierung und Effizienz durch Konzentration auf „Patch Releases“
  • Gesteigerte Übersicht und Motivation durch verbesserte Transparenz (Backlog-Organisation)
  • Gesteigerte Effizienz durch flexibleren Analyse-Prozess der Bugs (15 Minuten für die Erstanalyse)
  • Gesteigerte Effizienz durch direkte Kommunikation der Entwickler mit den Kunden
  • Gesteigerte Effizienz durch Weiterentwicklung der Mitarbeiter

Die Magie der agilen Arbeitsweise ergibt sich vor allem aus der Bereitschaft zur Veränderung und nicht der dogmatischen Umsetzung des Scrum-Frameworks. Dabei stehen der Mensch (Motivation), die Effizienz (Verbesserung der Prozesse) und die Flexibilität (kontextabhängige Behandlung der Bugs) im Fokus der Veränderung.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

1 Kommentar auf "Der Scrum Master: Agiler werden ohne Scrum"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Karin
Gast

Vielen, vielen Dank für diese Serie von erfrischenden und erheiternden Einblicken in die Arbeit eines Scrum Predigers. Ich habe gespannt alle Artikel in einem Zug durch gelesen um mich damit auf meine bevorstehende Online Prüfung zum PSM I vorzubereiten..;-)
Ich freue mich schon auf weitere Beiträge!

X
- Gib Deinen Standort ein -
- or -