#441 Scrum-Konferenz: Agilität und Kultur
Diesmal Ralf Westphal über „Agilität und Kultur“ im Interview mit Patrick Fritz. wie gewohnt hier eine Zusammenfassung:
Eine entsprechende Kultur ist die Voraussetzung, damit sich Agilität in einem Unternehmen durchsetzen kann. Ralf zitiert hierzu den Management-Guru Peter Drucker:
Culture eats strategy for breakfast.
Die Kultur spiegelt sich wieder im Umgang mit Zeit, Fehlern, Fokus und Arbeitsbedingungen.
Agilität hat eigentlich nichts mit SW-Entwicklung zu tun. Ralf meint vielmehr:
It´s a way of life.
Um zu Agilität im Unternehmen zu gelangen braucht es einen Veränderungsprozess. Scrum selbst ist ein Prozess, der Weg dahin ist aber ein eigener Prozess. Wir müssen lernen es „kulturell“ auszuhalten, dass auf dem Weg dahin Fehler passieren. Es ist ein Lernprozess, der Monate oder Jahre dauert.
Raum ist in diesem Zusammenhang ein wichtiger Begriff, zum Einen als Spielraum (Tom DeMarco: Spielräume), zum anderen als physischer Raum in dem man (wöchentlich) zusammenkommen kann.
Der Veränderungsprozess braucht eine eigene „Retrospektive“, die Retrospektive in Scrum selbst berücksichtigt dieses Metaperspektive auf den Veränderungsprozess nicht, sondern fokussiert auf das aktuelle Projekt.
Man muss sich für eine Veränderung Zeit nehmen.
Jemand der gerade anfängt mit Scrum, ist nicht in der Position zu beurteilen, ob er den Lehrbuch-Prozess schon verändern kann. Er hat sich noch gar nicht auf den Prozess eingelassen. Es fehlt die Erfahrung.
Fehler sind Teil einer Kultur die Agilität fördert oder auch erst ermöglicht. Ohne Fehler geht es nicht. Es ist ein verantwortungsvoller Umgang mit den eigenen Fehlern, unabhängig von einer organisatorischen Reaktion erforderlich.
Im Umgang mit Fehlern herrscht häufig eine Asymmetrie zwischen Fehlern bei uns und Fehlern bei anderen vor. Liegt es an mir oder an den Umständen, das es zu einem Fehler gekommen ist? Eine „Fehlerkultur“ muss permanent präsent sein und nicht nur in der Retrospektive.
In dem Begriff „Fehler“ steckt immer auch schon der Begriff „Schuld“. Hiervon sollten wir wegkommen. Die Frage nach der Schuld ist unproduktiv. Die Natur kennt keine Schuld, sondern nur Ursachen und Wirkung. Abweichungen sind zu untersuchen. Agile Prozesse sind mit ihren Iterationen schon sehr gut aufgestellt um mit Abweichungen umgehen zu können, weil man sich regelmäßig mit ihnen auseinandersetzt und sie sich nicht aufschaukeln können.
Über Abweichungen muss ich mich durchaus mit meinem Kunden austauschen können. Komplexe Lösungen gehen nicht mit einer losen Kopplung. Ich kann nicht mein Problem einfach über den Zaun werfen und auf das fertige Ergebnis warten. Ich brauche eine partnerschaftliche Zusammenarbeit über Ursache und Wirkung und den Umgang mit der Abweichung. Zum Einen hilft bereits die Sprint-Struktur, zum Anderen kann man selbst innerhalb der Sprints noch überlegen, wie schneide ich meine Features.
Für das richtige Schneiden von Features ist eine entsprechende Haltund die Voraussetzung. Es geht darum dem menschlichen Bedürfnis nach Abschluß/Closure nachzukommen. Nach diesem Ideal sollten wir streben, auch wenn wir es nicht immer erreichen. Ein Featuer sollte einen Nutzen schaffen, den zumindest der Product Owner erkennen kann.
Die Orientierung an menschlichen Bedürfnissen (des Teams) und Kundenorientierung widersprechen sich nicht. Mit einer solchen Haltung kann ich nach innen wie nach außen verkaufen.
Es gibt nur eine Möglichkeit Software-Qualität zu verbessern: Es einfach tun!
Software sollte jeden Tag um neue Anforderungen erweiterbar sein. Die Architektur sollte dies sicherstellen. In der Praxis braucht dies manchmal ein Refactoring. Refactoring steht nicht im Backlog, aber wenn es erforderlich, ist es erforderlich.
Man muss ein Refactoring nicht dem Kunden verkaufen, sondern es aus einer Professionalität heraus einfach tun. Das schlägt sich bei Scrum in der Velocity nieder, aber damit wird diese auch realistischer. Es bringt mir gar nichts bei einem Marathon auf den ersten zwei Kilometern in Führung zu liegen und am Ende der Letzte zu sein. Die passende Durchschnitts-Velocity muss gefunden werden und wenn am Schluß noch Kraft übrig ist, kann ich noch einen Schlussspurt hinlegen.
Refactoring muss in der Komplexitätsabschätzung und Bewertung berücksichtigt sein. Refactoring steht nicht am Ende im Sinne eines Aufräumens, sondern am Anfang im Sinne eines Bereitstellen der Werkzeuge.
Refactoring ist kein Feature, sondern Teil des professionellen Jobs eines Entwicklers.
Nur in Ausnahmefällen, wenn das Refactoring beispielsweise mehrere Wochen benötigt, in denen man nichts anderes mehr auf die Straße bringt, muss es erklärt werden.
Den Focus zu bewahren ist ein weiterer wichtiger Aspekt in unserer agilen Kultur.
Fokus (beim Thema bleiben) ist wichtig, weil SW-Entwicklung eine kreative Tätigkeit ist, die in einem Team umgesetzt wird. Wenn ich das Team immer wieder aus dem Prozess herausreiße (z.B. durch Support-Aufgaben oder Bugfixing), wird dabei der Fokus zerstört. Das Team braucht aber die Ruhe sich auf den Backlog konzentrieren zu können.
Dies gilt auch auf der Ebene des Arbeitsplatzes. Ablenkungen und Behinderungen sind zu vermeiden.
Fazit:
Die Kultur ist die elementare Voraussetzung.
Probleme entstehen erst in den Ritzen von Scrum. Wie finden Entscheidungen im Team statt? Dazu sagt Scrum nichts. Scrum schafft nur einen Rahmen. Um diesen Rahmen erfolgreich auszufüllen braucht es kulturelle Voraussetzungen.
Damit ein Unternehmen agil wird braucht es:
- Raum für Reflektion sollte unabhängig von der Entscheidung zur Agilität geschaffen werden.
- Beschäftigung mit dem Thema (Bücher, Kurs,…)
- Das reicht aber noch nicht. Wer den Kurs besucht hat, das Buch gelesen hat, hat zwar schon eine bewusste Kompetenz, aber das heißt noch nicht dass er Erfahrung hat oder dass er es anderen auch noch vermitteln kann. Hier empfiehlt es sich Hilfe von außen zu holen, sei es als Scrum Master oder Coach, um reflektive Kompetenz zu bekommen.
Tags: Agiles PM, Agilität, Fehler, Kultur, Refactoring, SCRUM