Agiles Vorgehen

„Den größten Fehler, den man im Leben machen kann, ist, immer Angst zu haben, einen Fehler zu machen.“ (Dietrich Bonhoeffer)

Ich möchte aus aktuellen Anlass, den Unterschied, den agilen und klassischen Vorgehen für mich hat, aufzeigen. Ich bin derzeit mal wieder in einem Projekt bzw. Team, wo man mit Hilfe der klassischen Einstellung meint, agil arbeiten zu können. Das fängt schon damit an, dass man meint, dass wenn man ein Scrum-Zertifikat hat, es ausreichend ist, ein agiles Projekt durchzuführen. Was will man denn da grossartig zertifizieren? Scrum besteht aus 3 Artefakten, 3 Rollen und 3 Ereignissen.

Ich bin gerade mal durch die Inhalte von Scrum-Schulungen durchgegangen: Ich bin sprachlos, es gibt sogar Anbieter, die meinen, dass ein Scrum Master 2 Tage braucht, um ein Zertifikat zu bekommen. Es gibt unter anderem den Professional Scrum Master, der „die Teamproduktivität steigert, die Produktivität in der Produktentwicklung optimiert sowie die des „Total Cost of Owenership“ optimiert und dann damit es richtig gut klingt kommt ein „etc.“

Damit sind wir auch schon voll im Thema: Wenn man in solche Kurse geht, muss man sich nicht die Frage stellen? Habe ich das agile Vorgehen richtig verstanden? Denn in dieser Schulung versuche ich ja mit Hilfe von „Werkzeugen“ wieder Kontrolle zu erhalten. Warum Kontrolle? Die Idee ist doch, dass man Vertrauen in die Fähigkeiten des Projektteams hat und dass das Team sich selbst organisieren kann und auch selber lernen möchte. Jede Art von Kontrolle führt wieder zur Irritationen und zu Vertrauensverlust.

Man kann nicht agil tun, sondern man ist entweder agil oder eben nicht. Meinen Studierenden des Projektmanagement habe ich die Unterschiede zwischen klassischen und agilen Vorgehen folgendermassen bewusst gemacht: Ich habe zunächst in 8 Vorlesungen das klassische Projektmanagement mit seinen Werkzeugen vorgestellt. Ich hatte das Gefühl, dass ich durch die schiere Anzahl von Werkzeugen, die Studierenden beeindrucken konnte. Die letzte Vorlesung habe ich dem agilen Projektvorgehen gewidmet und mit den Worten gestartet: dass alles, was sie vorher gelernt haben im agilen Umfeld (fast alles) nicht mehr benötigt wird. Der Unterschied besteht in Kontrolle und Vertrauen. Kontrolle brauche ich nur, wenn ich kein Vertrauen habe. Das Misstrauen drückt sich beispielsweise darin aus, dass man das Gefühl hat, dass das Projektziel in der Zeit und dem Budget in der geforderten Qualität nicht zu erreichen. Dann fange ich an zu planen. Irgendwann, ab einer bestimmten Grösse von Projekt findet man heraus, dass es nicht reicht nur einen Plan zu haben, sondern dass es durchaus passieren kann, dass einen die Realität einholt und den Plan zunichtemacht. Also führt man Risikomanagement ein, um das Gefühl zu haben, mehr Kontrolle zu erhalten. Und so weiter und so weiter… Also versucht man immer mehr, ein lebenden Projekt zu einer Maschinerie werden zu lassen, was sich durch das Ausmass von ewig vielen Diskussionen über auch schon geringfügige Abweichungen von KPIs deutlich wird.

Agiles Vorgehen dagegen bedeutet, dass man Vertrauen in seine Mitarbeiter/Team hat, und dass man weiss, dass ein Projekt und die Menschen darin keine Maschinen sind. Natürlich gibt es schon Pläne, aber ein Ziel soll eigentlich nicht erreicht werden, sondern umso weiter es in die Zukunft geht, umso gröber wird der „Plan“. Man weiss, wohin die Reise ungefähr gehen soll. Damit hat man auch die Möglichkeit Richtungen zu ändern.

Zusätzlich nimmt man durch Vertrauen den Druck aus Projekten und Teams raus. Ich versuche nicht mehr, mein Team zu einem bestimmten Ziel in der Zukunft zu drücken. Ich gebe lediglich Ziele für den nächsten Sprint vor und das Team entscheidet, ob es die Ziele in dem Sprint schafft und bestimmt auch wie es die Ziele umsetzt. Damit schaffe ich es im agilen Umfeld, dass Ruhe und Zeit für Kreativität, Innovation, Transparenz, Wissensaustausch wieder verfügbar ist. Also brauche ich kein Innovationsmanagement, kein Kommunikationsmanagement und auch kein Wissensmanagement – zumindest schon mal innerhalb des Projekts/Teams nicht. Am Ende eines Sprints erhalte ich ein lauffähiges Produkt, was ich wiederum meinen Stakeholdern (Kunden, Anwendern) vorstellen kann und erhalte wieder Feedback, was durchaus zu Richtungsänderungen führen kann.

Also bevor ich agile Vorgehensweisen einführe muss ich mir Gedanken machen, ob ich das Vertrauen in meinen Mitarbeitern habe. Wenn ich uneingeschränkt ja sagen kann, dann führt die Einführung von agilen Methoden zum Erfolg. Wenn auch nur man nur der geringste Zweifel vorhanden ist, dann sollte man prüfen, ob man mit den bisherigen klassischen Methoden die Kontrolle nicht besser behält. Ansonsten werden zwar die Leute auf Schulungen geschickt, oder ein externer Berater wird geholt, die Methoden, Artefakte und Rollen eingeführt, aber man sieht den Sinn dahinter nicht. Dass der Sinn in Frage gestellt wird, sieht man schnell daran, dass Meetings als Overhead bezeichnet werden, die Retrospektive das erste Meeting ist, welches fallen gelassen wird. Ein Scrum Master fehlt, oder Projektleitungsaufgaben erhält; in der Planung wird die Komplexität gerne mit Zeitaufwänden geschätzt; wenn nicht, werden Verbindungen zwischen Komplexität und Zeitaufwänden hergestellt; die Velocity wird genutzt, um zu argumentieren, dass das andere Team ja viel schneller ist; der Produkt Owner muss Ziele in der Planung durchdrücken und schiebt mehr User Stories in den Sprint, als wozu sich das Team committed und so weiter. Diese Misstrauen spüren die Mitarbeiter. Denen ist es dann lieber, dass man mit den klassischen Methoden arbeitet, da dann ein Vertrauen nicht vorgespielt wird.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s