Suche
Error 404: Agile not found

5 Warnzeichen für anti-agile Muster

Ann-Cathrin Klose

© Shutterstock.com / Trendy Vector

Wenn niemand über den „Elephant in the Room“ spricht, steht es schlecht um die Agilität. Denn: keine offene Kommunikation, kein Agile! Und das ist bei weitem nicht das einzige Warnzeichen für Probleme mit der agilen Arbeitsweise.

Eigentlich ist Agile ja eine ganz einfache Sache: Am Ende ist das alles nur eine Frage der richtigen Einstellung. Selbstorganisation, Verantwortungsbewusstsein und flache Hierarchien funktionieren dann, wenn alle hinter dem Konzept stehen, vom Chef bis zum Praktikanten. Das ist aber auch die größte Stolperfalle für agile Projekte – der Faktor Mensch steht dem Erfolg oft im Weg. Auch fehlende Kenntnisse über agile Methoden können zum Problem werden.

Fünf Warnzeichen für defektes Agile

Um mit einem agilen Framework wie Scrum zu arbeiten oder andere agile Arbeitsweisen anzuwenden, muss man die Methode nämlich auch beherrschen – und das heißt eben nicht, dass man sie stur getreu der Anleitung umsetzen soll. Für Anfänger kann das ganz schön kompliziert werden. Klappt die richtige Umsetzung agiler Arbeitsweisen nicht, scheitern agile Projekte aber leider ganz schnell.

Zum Glück gibt es zumindest einige Warnzeichen, die bereits früh darauf hinweisen, dass sich das agile Arbeiten in die falsche Richtung entwickelt. Je früher im Projektverlauf klar ist, dass etwas ganz und gar nicht stimmt, desto kleiner ist der daraus resultierende Schaden. Wer die folgenden fünf anti-agilen Muster aber vermeidet, kann vielen Problemen vorbeugen.

1. Falsche Aufgabenverteilung

Nicht jeder Beteiligte an agilen Projekten muss Entwickler sein. Gerade bei der Arbeit mit Scrum kann es sogar sinnvoll sein, einen Scrum Master zu wählen, der vor allem menschlich etwas auf dem Kasten hat! Programmierkenntnisse sind dann nicht notwendig. So kann er optimal auf das Team eingehen und sich ganz auf seine Aufgabe konzentrieren.

Allerdings muss dann darauf geachtet werden, dass keineswegs die Nicht-Entwickler das Sagen im Team haben dürfen. Leitet ein Scrum Master das Meeting, läuft etwas falsch! Als Berater sollte er nämlich dem Team dienen, nicht zum Anführer werden. Gleiches gilt für jeden, der nicht an der eigentlichen Softwareentwicklung beteiligt ist und ebenfalls für das Konzept der „geleiteten“ Meetings. Gibt jemand vor, wer welche Aufgabe zu übernehmen hat, hat das nicht mehr viel mit einem selbstorganisierten Team zu tun. Ein Meeting, das von einem nicht am Entwicklungsprozess beteiligten Teammitglied geleitet wird, ist also ein Warnzeichen, das niemand ignorieren sollte.

2. Falsche Maßstäbe

Es ist gar nicht so einfach, die Arbeit eines agilen Teams zu bewerten. Vor allem bei Teams, die neu mit der agilen Softwareentwicklung beginnen, ist es normal, dass erst einmal viel Zeit für die Selbstorganisation benötigt wird. Es entsteht also häufig weniger Code als zuvor. Auch nach der Anfangszeit gibt es ferner unzählige Faktoren, die zu Schwankungen der Velocity, also der Menge an entwickelten Features in einem bestimmten Zeitraum, führen können. Insgesamt sollte die Velocity allerdings sowieso ein Maßstab zur Planung von Iterationen sein, kein Instrument zur Bewertung der Arbeit von agilen Teams.

Das sehen manche Chefs aber anders. Immer wieder wird die Velocity als täglicher oder sogar individueller Maßstab genutzt, um die Arbeitsleistung eines Teams oder sogar eines Entwicklers zu beurteilen. Letzteres kommt vor allem im Rahmen des Micromanagements vor – was aber absolut kontraproduktiv ist, wenn es um agile Projekte geht. In einem solchen Fall wird das Team nämlich überwacht. Kleinste Leistungsschwankungen, die ganz normal sind, werden sichtbar und die Entwickler entwickeln Angst vor Konsequenzen. So wird der agile Ansatz missbraucht und zum Überwachungsinstrument gemacht. Bereits dann, wenn die Velocity erstmalig zur Beurteilung des Teams heranzogen wird, sollte das also als Warnsignal verstanden werden.

3. Kommunikative Umwege

Falsche Kommunikationsmuster kommen ebenfalls häufig vor, wenn Agile nicht gut läuft. Sie können sowohl auf ein mangelhaftes Verständnis der agilen Arbeitsweise als auch auf eine falsche Einstellung hinweisen. Agile bedeutet ganz einfach, dass das Team direkt kommuniziert – am besten Face to Face, sagt das agile Manifest. Aber das ist nun mal nicht immer möglich. Virtuelle Kommunikationstools wie Chats und Boards sind darum auch nicht aus dem agilen Alltag wegzudenken und erst mal kein Zeichen dafür, dass etwas schief läuft.

Je nachdem wie sie verwendet werden, können digitale Kommunikationstools aber durchaus einen Hinweis auf Probleme mit der agilen Arbeitsweise geben. Das ist dann der Fall, wenn niemand mehr weiß, was der andere tut, weil das ja bestimmt in der täglichen Rundmail erklärt werden wird. Oder auch schon dann, wenn es überhaupt eine tägliche Rundmail gibt, die das Standup-Meeting zusammenfasst. Eigentlich soll nämlich der Kontakt zu den Kollegen, gemeinsam mit den allen Teammitgliedern zugänglichen Tools, ausreichen, damit jeder auf dem neusten Stand ist. Wenn das nicht klappt, läuft also was gewaltig schief, sagt Joseph Nielsen.

4. Elefanten ignorieren

Genau so schlecht ist es natürlich, wenn der eingangs erwähnte Elefant im Raum einfach ignoriert wird. Irgendetwas läuft nicht gut – aber niemand spricht darüber, obwohl jeder davon weiß. Das ist ein Zeichen dafür, dass dem Team das Vertrauen fehlt, offen seine Meinung äußern zu können. Agile funktioniert aber nur, wenn offen kommuniziert wird.

Bis zu einem gewissen Grad sind solche Hemmungen natürlich normal. Immerhin denken nicht wenige Menschen von sich, dass sie eigentlich gar nicht gut in ihrem Job sind. Sie haben Angst davor, dass jemand diesen Umstand bemerken könnte und halten sich darum lieber zurück. In einem agilen Umfeld sollte es jedoch gelingen, diese Ängste zu überwinden. Auch die bereits genannte Angst vor negativen Konsequenzen bei Fehlern kann dazu beitragen, dass Menschen lieber schweigen. Die Ursachen können auf Team- oder Unternehmensebene liegen und sollten so früh wie möglich ausgemerzt werden.

Jake Calabrese hat diesem Problem sogar einen eigenen Cartoon gewidmet. Spricht niemand über den Elefanten im Raum, schlägt er vor, einmal die Perspektive des Elefanten einzunehmen. Wie fühlt sich der Elefant, wenn alle ihn sehen, aber ignorieren? Ängstlich, angespannt und traurig? So könnte es auch den Kollegen gehen, die sich nicht trauen das Problem zu benennen und das wäre wohl mal ein guter Grund, über den eigenen Schatten zu springen, nicht wahr?

5. Unglückliche Entwickler

Wenn „ängstlich, angespannt und traurig“ zur Grundstimmung des agilen Teams wird, stimmt erst recht etwas nicht. Stressige Phasen treten auch mit agilen Methoden auf, dennoch sollten sich alle Teammitglieder jederzeit wohlfühlen – im Team und mit ihrem Projekt. Immerhin sollte Agile zu schnellen Erfolgen führen, Fortschritte sichtbar machen und jedem Entwickler ermöglichen, den Wert der eigenen Arbeit jederzeit zu erkennen. Wie können Entwickler da unglücklich sein?

Das kann viele Gründe haben. Manchmal liegt es an nicht erreichten Sprintzielen, manchmal an zu vielen Überstunden, mal daran, dass die Anforderungen unklar sind oder daran, dass das Team einfach nicht so recht zusammenpasst. Das alles ist allerdings erneut ein Merkmal dafür, dass etwas schief läuft – somit können unglückliche Entwickler wohl als ultimatives Zeichen für fehlgeleitete agile Projekte gelten.

Fehler rechtzeitig erkennen

Insgesamt zeigt sich, dass ein mangelndes Verständnis für agile Methoden und eine falsche Einstellung oft Hand in Hand gehen, wenn Probleme mit der agilen Arbeitsweise entstehen. Eine gute Ausbildung oder zumindest Begleitung durch geübte Anwender agiler Methoden während der Einführung neuer Arbeitsweisen kann dabei helfen, solchen Problemen vorzubeugen. Andererseits liegt aber beispielsweise der Wunsch, immer zu wissen, ob ein Team „gut genug“ arbeitet, in der Natur des Managers: In dieser Hinsicht und bezüglich anderer Probleme, wie falscher Kommunikation, kann eine kontinuierliche Reflexion des eigenen Verhaltens in regelmäßigen Retrospektiven dabei helfen, anti-agile Muster früh zu erkennen.

Verwandte Themen:

Geschrieben von
Ann-Cathrin Klose
Ann-Cathrin Klose
Ann-Cathrin Klose hat allgemeine Sprachwissenschaft, Geschichte und Philosophie an der Johannes Gutenberg-Universität Mainz studiert. Bereits seit Februar 2015 arbeitete sie als redaktionelle Assistentin bei Software & Support Media und ist seit Oktober 2017 Redakteurin. Zuvor war sie als freie Autorin tätig, ihre ersten redaktionellen Erfahrungen hat sie bei einer Tageszeitung gesammelt.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.