{"id":1707,"date":"2011-02-11T10:35:37","date_gmt":"2011-02-11T08:35:37","guid":{"rendered":"http:\/\/www.bernhardschloss.de\/blog\/?p=1707"},"modified":"2011-02-11T10:35:37","modified_gmt":"2011-02-11T08:35:37","slug":"441-scrum-konferenz-agilitat-und-kultur","status":"publish","type":"post","link":"https:\/\/www.bernhardschloss.de\/blog\/441-scrum-konferenz-agilitat-und-kultur\/","title":{"rendered":"#441 Scrum-Konferenz: Agilit\u00e4t und Kultur"},"content":{"rendered":"

Diesmal Ralf Westphal<\/a> \u00fcber „Agilit\u00e4t und Kultur“ im Interview mit Patrick Fritz. wie gewohnt hier eine Zusammenfassung:<\/p>\n

Eine entsprechende Kultur<\/strong> ist die Voraussetzung, damit sich Agilit\u00e4t in einem Unternehmen durchsetzen kann. Ralf zitiert hierzu den Management-Guru Peter Drucker:<\/p>\n

Culture eats strategy for breakfast.<\/p><\/blockquote>\n

Die Kultur spiegelt sich wieder im Umgang mit Zeit, Fehlern, Fokus und Arbeitsbedingungen.<\/p>\n

Agilit\u00e4t hat eigentlich nichts mit SW-Entwicklung zu tun. Ralf meint vielmehr:<\/p>\n

It\u00b4s a way of life.<\/p><\/blockquote>\n

Um zu Agilit\u00e4t im Unternehmen zu gelangen braucht es einen Ver\u00e4nderungsprozess<\/strong>. Scrum selbst ist ein Prozess, der Weg dahin ist aber ein eigener Prozess. Wir m\u00fcssen lernen es „kulturell“ auszuhalten, dass auf dem Weg dahin Fehler passieren. Es ist ein Lernprozess, der Monate oder Jahre dauert.<\/p>\n

Raum ist in diesem Zusammenhang ein wichtiger Begriff, zum Einen als Spielraum (Tom DeMarco: Spielr\u00e4ume), zum anderen als physischer Raum in dem man (w\u00f6chentlich) zusammenkommen kann.<\/p>\n

Der Ver\u00e4nderungsprozess braucht eine eigene \u201eRetrospektive\u201c, die Retrospektive in Scrum selbst ber\u00fccksichtigt dieses Metaperspektive auf den Ver\u00e4nderungsprozess nicht, sondern\u00a0fokussiert auf das aktuelle Projekt.<\/p>\n

Man muss sich f\u00fcr eine Ver\u00e4nderung Zeit nehmen.<\/p>\n

Jemand der gerade anf\u00e4ngt mit Scrum, ist nicht in der Position zu beurteilen, ob er den Lehrbuch-Prozess schon ver\u00e4ndern kann.\u00a0Er hat sich noch gar nicht auf den Prozess\u00a0eingelassen. Es fehlt die Erfahrung.<\/p>\n

Fehler<\/strong> sind Teil einer Kultur die Agilit\u00e4t f\u00f6rdert oder auch erst erm\u00f6glicht. Ohne Fehler geht es nicht. Es ist ein verantwortungsvoller Umgang mit den eigenen Fehlern, unabh\u00e4ngig von einer organisatorischen Reaktion erforderlich.<\/p>\n

Im Umgang mit Fehlern herrscht h\u00e4ufig eine Asymmetrie zwischen Fehlern bei uns und Fehlern bei anderen vor. Liegt es an mir oder an den Umst\u00e4nden, das es zu einem Fehler gekommen ist? Eine „Fehlerkultur“ muss permanent pr\u00e4sent sein und nicht nur in der Retrospektive.<\/p>\n

In dem \u00a0Begriff \u201eFehler\u201c\u00a0steckt immer auch schon der Begriff \u201eSchuld\u201c. 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\u00f6nnen, weil man sich regelm\u00e4\u00dfig mit ihnen auseinandersetzt und sie sich nicht aufschaukeln k\u00f6nnen.<\/p>\n

\u00dcber Abweichungen muss ich mich durchaus mit meinem Kunden austauschen k\u00f6nnen. Komplexe L\u00f6sungen gehen nicht mit einer losen Kopplung. Ich kann nicht mein Problem einfach \u00fcber den Zaun werfen und auf das fertige Ergebnis warten. Ich brauche eine partnerschaftliche Zusammenarbeit \u00fcber 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 \u00fcberlegen, wie schneide ich meine Features.<\/p>\n

F\u00fcr das richtige Schneiden von Features ist eine entsprechende Haltund die Voraussetzung. Es geht darum dem menschlichen Bed\u00fcrfnis nach Abschlu\u00df\/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.<\/p>\n

Die Orientierung an menschlichen Bed\u00fcrfnissen (des Teams) und Kundenorientierung widersprechen sich nicht. Mit einer solchen Haltung kann ich nach innen wie nach au\u00dfen verkaufen.<\/p>\n

Es gibt nur eine M\u00f6glichkeit Software-Qualit\u00e4t<\/strong> zu verbessern: Es einfach tun!<\/p>\n

Software\u00a0sollte jeden Tag um neue Anforderungen erweiterbar sein. Die Architektur sollte dies sicherstellen. In der Praxis braucht dies manchmal ein Refactoring<\/strong>. Refactoring steht nicht im Backlog, aber wenn es erforderlich, ist es erforderlich.<\/p>\n

Man muss ein\u00a0Refactoring nicht dem Kunden verkaufen, sondern es aus einer Professionalit\u00e4t heraus einfach\u00a0tun. Das schl\u00e4gt 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\u00fchrung zu liegen und am Ende der Letzte zu sein. Die passende Durchschnitts-Velocity muss gefunden werden und wenn am Schlu\u00df noch Kraft \u00fcbrig ist, kann ich noch einen Schlussspurt hinlegen.<\/p>\n

Refactoring muss in der Komplexit\u00e4tsabsch\u00e4tzung und Bewertung ber\u00fccksichtigt sein. Refactoring\u00a0steht nicht am Ende im Sinne eines Aufr\u00e4umens, sondern am Anfang im Sinne eines\u00a0Bereitstellen der\u00a0Werkzeuge.<\/p>\n

Refactoring ist kein Feature, sondern Teil des professionellen Jobs eines Entwicklers.<\/p>\n

Nur in Ausnahmef\u00e4llen, wenn das Refactoring beispielsweise mehrere Wochen ben\u00f6tigt, in denen man nichts anderes mehr auf die Stra\u00dfe bringt, muss es erkl\u00e4rt werden.<\/p>\n

Den Focus<\/strong> zu bewahren ist ein weiterer wichtiger Aspekt in\u00a0 unserer agilen Kultur.<\/p>\n

Fokus (beim\u00a0Thema bleiben)\u00a0ist wichtig, weil SW-Entwicklung eine kreative T\u00e4tigkeit ist, die in einem Team umgesetzt wird. Wenn ich das Team immer wieder aus dem Prozess herausrei\u00dfe (z.B. durch Support-Aufgaben oder Bugfixing), wird dabei der Fokus zerst\u00f6rt. Das Team braucht aber die Ruhe sich auf den Backlog konzentrieren zu k\u00f6nnen.<\/p>\n

Dies gilt auch auf der Ebene des Arbeitsplatzes. Ablenkungen und Behinderungen sind zu vermeiden.<\/p>\n

Fazit:<\/p>\n

Die Kultur ist die elementare Voraussetzung.\u00a0<\/p>\n

Probleme entstehen erst\u00a0in den Ritzen von Scrum. Wie finden Entscheidungen im Team statt? Dazu sagt Scrum nichts. Scrum schafft nur einen Rahmen. Um diesen Rahmen erfolgreich auszuf\u00fcllen braucht es kulturelle Voraussetzungen.<\/p>\n

Damit ein Unternehmen agil wird braucht es:<\/p>\n