Die Spring-Edition der IPC (International PHP Conference) fand dieses Jahr vom 03. bis zum 06. Juni 2012 in Berlin statt. Sie hatte – wie auch in den vergangenen beiden Jahren schon – einen eigenen "Agile Day" mit einer Reihe von Talks die sich rund um Themen zur Agilität drehten. Da dieser Themenkomplex zunehmend an Popularität gewinnt und dessen Methodik schon Einzug in die tägliche Arbeit vieler Firmen gefunden hat, gilt es auch auf die Seitenaspekte zu achten. Dies haben sich Sebastian Bauer (Inovex GmbH) und Dominik Jungowski (CHIP Xonio Online GmbH) zum Anlass genommen gleich zu Beginn des Agile Day mit ihrem Vortrag "Stolpersteine agiler Methoden" auf die Probleme rund um die Thematik einzugehen und mit Lösungsansätzen aufzuwarten. Damit möglichst Wenige beim Einsatz agiler Methoden über schon bekannte Steine auf dem Weg stolpern, möchte ich einen kurzen Überblick über den gehaltenen Talk geben…
Folgende Problemfelder haben die beiden Redner dabei identifiziert und vorgestellt:
Faktor Mensch
Der Mensch ist ein Gewohnheitstier. Das macht es ihm oft schwer sich auf Neuerungen in seiner Umgebung einzulassen. Diese Tatsache ist aber historisch bedingt und damit ganz natürlich, da Veränderungen in der menschlichen Vergangenheit häufig Gefahr bedeutet haben. Das sollte man immer im Hinterkopf behalten wenn man agile Methoden einführen möchte.
Innerhalb eines Teams treten für gewöhnlich Alpha-, Beta- und Gamma-Typen auf. Die Alpha-Rolle bedeutet ein gewisses "Führen wollen" der Gruppe, aber auch den Willen Verantwortung zu übernehmen. In Beta-Rollen finden sich die "Nachfolger" und bei Gamma-Rollen handelt es sich um Antagonisten, also Gegenspieler. Das Vorhandensein dieser Rollen birgt zwar immer Konflikte, aber andererseits sind solche Rollen für ein (agiles) Team auch extrem wichtig zum Vorwärtskommen, zur Weiterentwicklung und zum Impulse setzen.
Einzelkämpfer sind für jedes Team eine Gefahr, allerdings können sie innerhalb eines agilen Teams zum größten Störfaktor werden. Hier ist größte Sensibilität bei der Zusammesetzung eines agilen Teams vonnöten.
Manche Menschen, speziell in bestehenden Rollen wie der eines Managers oder Ähnlichem, haben extreme Angst davor austauschbar zu sein, wenn es um das Einführen agiler Methoden geht. Hier ist Behutsamkeit gefragt. Man sollte ganz genau erklären was die einzuführenden Methoden bezwecken sollen und wie die Struktur aufgebaut und umgebaut werden soll oder kann. Nimmt man solche Menschen rechtzeitig an die Hand und bindet sie mit ein, gewinnt man vielleicht eher Mitspieler als argwöhnische Gegenspieler.
Spezialisierung
Man sollte bei agilen Teams immer darauf achten dass Aufgaben gut verteilt sind. Ganz nach dem "Bus-Faktor" (oder auch "Truck-Factor") sollte man sich immer die Frage vor Augen halten: "Was passiert wenn ein Teammitglied von einem Bus angefahren (gefällt mir persönlich besser als überfahren ;-) ) wird?" Das Team sollte in diesem Fall immer die Aufgaben des fehlenden Teammitglieds übernehmen können, ohne dass allzu großes Wissen dabei verloren geht. Deshalb sollte auch niemand an einem Spezialthema alleine arbeiten, selbst wenn er sich damit aktuell am besten auskennt.
Ganz eng grenzt dieser Umstand an die Tatsache, dass Spezialisten alleine kein agiles Team ausmachen sollten. Hier sind eher Generalisten als Spezialisten gefragt. Sonst wird es für das Team schwierig eine gemeinsame Zielsetzung zu finden. Denn Letztere haben meist nicht das gleiche Interesse am gemeinsamen Ganzen, sondern sind oft mehr daran interessiert für ihr spezielles Thema zu arbeiten und hier auch den größten möglichen Einfluss bei Entscheidungen zu nehmen. Hat man aber Spezialisten im Team, gilt es dieses spezielle Wissen möglichst gut zu verteilen. Hier kann man auf agile Methoden wie Pair Programming, Coding Dojos oder Code-Patenschaften zurückgreifen, um einen möglichst breiten Wissensaustausch zu schaffen.
Rollenkonflikte
Rollenkonflikte sind sehr oft verantwortlich für Probleme bei agilen Vorgehensweisen. Beim Scrum gibt es z.B. folgende Klassiker:
-> ScrumMaster + Entwickler als Doppelrolle. Ein ScrumMaster soll versuchen für das Team jegliche Barrieren aus dem Weg zu räumen, die Interessen des Teams "nach außen" vertreten, aber auch Meetings vorbereiten und Konflikte innerhalb des Teams aufspüren und sich um deren mögliche Beseitigung kümmern. Ist der ScrumMaster nun ebenfalls Entwickler, wird es sehr schwer die Rolle eines Entwicklers dabei einzunehmen und Konflikte an sich selbst als ScrumMaster heranzutragen. Geschweige denn mit sich selbst als Vermittler z.B. Konflikte mit einem Teammitglied zu lösen.
-> ScrumMaster + Teamleiter als Doppelrolle. Die eben genannten Aufgaben dürften auch die Arbeit jedes ScrumMasters erschweren der in Personalunion als Teamleiter fungiert. Denn die Rolle des Teamleiters fordert auch von ihm die Interessen der Firma gegenüber seinen angehörigen Teammitgliedern zu vertreten. Diese können unter Umständen im Gegensatz zu den Interessen des Teams stehen, was im Konfliktfall zu einer gegensätzlichen Aufgabenstellung führt.
-> ehemals technischer Leiter als ProductOwner. Dies kann dazu führen dass der ProductOwner bereits zu genaue Vorstellungen davon besitzt, welche Technologien eingesetzt werden sollen. Dadurch kann eine eingeengte Sichtweise auf die eigentliche Aufgabenstellung resultieren. Außerdem besteht die Gefahr dass der ProductOwner dem Team zu viele technische Vorgaben machen will.
-> ehemaliger Manager als ProductOwner. Ähnlich kann es mit einem ProductOwner ergehen, der zuvor eine Managerrolle innehatte. Hier ergibt sich die Gefahr eines versuchten Micromanagements des ProductOwners versus der Selbstorganisation des Teams.
Schwierigkeiten zwischen bestehenden Rollen und neuen Rollen können sich speziell dann ergeben, wenn ein Team in der Firma als erstes Team agile Methoden einführt. Dieses wird es schwer haben wenn alle anderen Teams oder auch alle anderen Bereiche noch "anders" arbeiten. Hier kann externe Hilfe angebracht sein, etwa in Form eines Workshops um Sinn und Zweck agiler Prozesse richtig zu vermitteln und damit mehr Verständnis in der Firma zu schaffen. Hierfür kann auch hilfreich sein, ebenso wie gegenüber dem Kunden, kleine "agile Spiele" durchzuführen. Eine weitere Möglichkeit besteht auch darin über einen Zwischenschritt erst einmal die agilen Prozesse innerhalb des Teams umzusetzen und mit dem Erfolg etwa die agilen Methoden als Ursache anzuführen.
Inspect & Ignore
Ebenfalls im Scrum kann es z.B. vorkommen dass sich der ProductOwner querstellt, etwa wenn sich innerhalb einer Retrospektive Probleme herausstellen, die der ScrumMaster an den ProductOwner heranträgt, dieser sich aber weigert sie zu beheben. Dann sollte der ScrumMaster versuchen dem ProductOwner klarzumachen dass ein effektiveres Produkt bzw eine effektivere Arbeit durch ein effektiveres Arbeiten im Team zustande kommt.
Analog gilt Selbiges falls ein ScrumMaster Impediments vom Team ignoriert.
Was sich auch immer wieder beobachten lässt, ist, dass Verbesserungen zwar vorgeschlagen und gewünscht, aber nicht umgesetzt werden. Um dem Abhilfe zu schaffen, bietet sich beispielsweise ein kleines Board mit Feldern an, auf denen man die Verbesserungen festhält. Man kann sie etwa in ein Feld "Try" hängen, ausprobieren ob sie sich als nützlich erweisen und bei anschließender Beurteilung entweder in das Feld "Keep" hängen oder sie wieder abhängen. Damit bleiben sie besser im Bewusstsein, und erfolgreiche Verbesserungen können sich eher etablieren. Man kann sich auch beliebige Erweiterungen eines solchen Boards vorstellen, etwa wie lohnenswert oder auch nicht lohnenswert eine Verbesserung ist, falls man sie noch etwas modifizieren und sich anschließend für oder gegen ein "Keep" entscheiden möchte.
Retrospektiven
In unserer heutigen Gesellschaft ist es zur Gewohnheit geworden Emotionen nicht zu sehr nach außen dringen zu lassen, weil wir gelernt haben dass dies meist als "nicht professionell" angesehen wird. Allerdings ist das gerade im agilen Umfeld nicht förderlich. Hier sollte man in Retrospektiven bewusst versuchen die Teammitglieder zu ermuntern deutlich auszudrücken was sie in welchem Zusammhang empfinden, aber darauf achten nicht verletzend zu sein. Etwa durch Sätze wie "Es hat mich traurig gemacht dass all die Arbeit umsonst war." oder "Es hat mich wütend gemacht als ich eine schöne Lösung programmiert hatte, diese aber verworfen wurde.". Das Ausdrücken von Gefühlen ist hilfreich für ein besseres gegenseitiges Verständnis.
Retrospektiven laufen sehr häufig nach einer gewissen Zeit nach "Schema F" ab. Das sollte vermieden werden indem man die Retrospektive immer wieder etwas variiert. Beispiele wie sich dies beeinflussen lässt finden sich etwa in folgenden, von den Speakern empfohlenen Büchern: "Agile Retrospectives: Making Good Teams Great" von Derby und Larsen und "Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers" von Gray, Brown und Macanufo.
Retrospektiven sollten immer im Konsens mit dem Team verbessert werden. Nicht jede Retrospektive funktioniert in jedem Team.
Eine Retrospektive funktioniert nur mit einer vernünftigen Vorbereitung durch den ScrumMaster.
Insgesamt sollte viel experimentiert werden, z.B. indem die Tische aus dem Raum entfernt werden und/oder ein Stuhlkreis gebildet wird. Auch ein Ortswechsel kann gut tun, z.B. wenn es auch mal raus an die frische Luft geht. Alles was die Atmosphäre auflockert ist hilfreich.
Daily Standup
Das Wichtigste beim Daily Standup ist, dass sich nicht das übliche 3-Fragen-Dogma manifestiert. Man sollte das tägliche "Was habe ich seit dem letzten Standup erreicht?", "Was will ich bis zum nächsten Standup erreichen?", "Was hindert mich momentan daran meine Arbeit zu machen?" nicht einfach immer starr durchziehen, sondern das Meeting wirklich als tägliches Planungsmeeting nutzen. (Anmerkung: Ein Vorschlag in einem Blog lautet etwa, hin und wieder eine vierte Frage zu stellen, etwa nach der Risikoeinschätzung der Zielerreichung jedes Entwicklers. Dadurch kann der ScrumMaster für ihn wichtige Zusatzinformationen erhalten und das Meeting wird ein wenig aufgelockert, indem Diskussionen angeregt werden.)
Damit nicht jeder durcheinander redet, kann es förderlich für das Daily Standup sein ein Redetoken zu benutzen.
Review
Auch für ein Review gilt analog schon das unter Retrospektiven und Daily Standup Genannte.
Hier kann ebenfalls ein Commit-Token nützlich sein.
Kill the messenger
Oftmals werden agile Methoden dann verworfen, wenn etwas nicht funktioniert. Dann wird daraus die falsche Schlussfolgerung gezogen, dass die Ursache dafür sein muss dass die agile Methode nicht funktioniert, anstatt sich den eigentlichen Problemen anzunehmen und sie zu beheben bzw zu verbessern.
Abschließend mit ihrem Vortrag haben die beiden Speaker den Hörern noch folgende Schlagworte ans Herz gelegt, die man sich permanent ins Gedächtnis rufen sollte:
-> Selbstreflexion
-> Selbstkritik
-> Alles hinterfragen
Danke für den interessanten Vortrag!
Schreibe einen Kommentar