ZA098 - Warum agile Methoden das Problem nicht lösen!
Zusammenfassung
Agile Methoden versprechen ganz viele Dinge. Die Realität sieht aber deutlich anders aus. Ich greife in dieser Episode die Frage auf, ob wir mehr Agilität brauchen oder das Ganze nur ein wichtiger Schritt auf eine ganz andere Ebene ist. Am Ende der Episode wirst du erfahren, warum agile Methoden kein „Siver Bullet Aproach“ sind und wo aus meiner Sicht die Zukunft hin gehen muss.
Der Inhalt dieser Episode:
- Warum agile Projekte nicht besser laufen
- Wie kann es besser funktionieren?
Subscription link
Wenn dir der Podcast gefällt, abonniere ihn und erhalte zukünftig kostenlos alle neuen Episoden direkt auf dein Smartphone:
Der Newsletter
Aktuelles, Tipps und Tricks gibt es im Newsletter zum Podcast
Ich wünschte, alle Projekte würden sich auf dem professionellen Niveau das im Beitrag anklingt herumärgern. Die Realität ist weit davon entfernt.
Grundsätzlich stimmt das agiles Vorgehen keine Wunder bewirkt. Für mich ist das Ziel nicht erfolgreicher zu sein, sondern stellt einen geeigneten Ansatz mit unklaren Anforderungen umzugehen – mehr nicht.
Hat mir gut gefallen, besonders die Aussage, dass Projekte nicht an Methoden scheitern sondern an organisatorischen Problemen.
In dem Zusammenhang nehme ich ein stark abweichends Verständnis von Agile zwischen Leuten in Projekten und agilen Anwendern. Als agiler Anwender betrachte ich Agile als einen Bezugsrahmen, um organisatorische Probleme sichtbar zu machen und anzugehen. Insofern geht der anspruch weit über ein Projekt hinaus. Das Projet ist nur der Impuls. Durch den begrenzten Scope eines Projekts ist genau das aber fast nicht möglich, wenn man sich nur auf diesen Rahmen begrenzt.
In den 20 Jahren, in denen ich Projekte mache habe ich unzählige Prozesse, Methoden und Tools in der Entwicklung einsetzen dürfen (müsssen).
Am Ende des Tages bin ich zu dem Schluss gekommen:
Gute und erfahrene Teams entwickeln gute Produkte.
Ich finde diesen Beitrag sehr gelungen, da endlich qualifizierte Kollegen die ihnen gebührende Wertschätzung erhalten.
Hallo Maik,
bei Studien wie dem Chaos Report bzw. dem Chaos Manifesto der Standish Group muss man sehr vorsichtig sein, was deren Macher unter einem agilen Projekt verstehen. Derzeit greift man diesen Begriff sehr gerne auf weil es cool ist und man sich mit ihm gerne schmückt. Bei genauerem Hinsehen aber ist von den agilen Werten und Prinzipien häufig nur ein Bruchteil umgesetzt, entweder weil man es nicht verstanden hat, oder weil man den kulturellen Entwicklungsschritt, der damit verbunden ist, scheut. Nur weil es so etwas wie Iterationen in einem Projekt gibt, ist dieses noch lange nicht agil – schon gar nicht, wenn diese so absurde Längen wie drei Monate o.ä. haben. Und man ist auch nicht gleich agil, wenn man ein tägliches Meeting im stehen abhält. Und ein Product Owner, der dem Team nur 1 Stunde pro Woche zur Verfügung steht, ist nun mal kein Product Owner im Sinne von Agilität. Auch hat dort kein klassischer Projektmanager mit umfangreicher Autorität etwas zu suchen.
Alles das habe ich in freier Wildbahn aber schon gesehen bei Projekten, die sich selbst "Wir sind agil" auf die Fahnen geschrieben hatten. Mein Ratschlag dazu ist immer: Leute, nennt Euren Prozess, wie ihr wollt, und entleiht Euch meinetwegen auch einzelne, für Euch nutzbringende Praktiken aus dem Scrum-Werkzeugkasten, um diese in Euren Prozess einzubauen, aber nennt nicht irgendetwas einfach "Scrum" oder agil, wenn es das nicht ist!
Agilität ist in erster Linie ein Leadership Mindset. Das wird sofort jedem klar, wenn er das agile Manifest und die 12 Prinzipien liest. Die Einführung von Agilität in einer Organisation, das hast Du in Deinem Beitrag sehr schön herausgestellt, ist eine tiefgreifende kulturelle Veränderung. Normalerweise ist dazu auch ein Entwicklungsschritt in der ganzen Organisation notwendig: weg von tayloristischen Command-and-Control-Strukturen hin zu interdisziplinären, selbsorganisierten, eigenverantwortlichen und lernenden Teams.
Und auch das vielgenannte Scrum ist lediglich ein Framework für die Produktentwicklung, welches die agilen Werte und Prinzipien berücksichtigt; Scrum ist agil, aber Agilität bedeutet nicht automatisch, dass man auch immer Scrum macht.
Es stimmt, dass agiles Vorgehen keine Wunder bewirken kann und von heute auf morgen alle Probleme vom Tisch wischt. Es ist aber ein Ansatz, um mit einem hochdynamischen Umfeld angemessen umzugehen, und um das Risiko des Scheiterns zu verringern. Und wenn man trotzdem scheitert, dann möchte man so früh wie möglich scheitern. Dann, wenn es noch billig ist und die wenigsten Schmerzen bereitet.
Etwas irritiert war ich allerdings über Deine Aussage, dass ja normale IT-Systeme und die Embedded Welt so sehr unterschiedlich sein sollen. Das ist für mich vor allem deswegen überraschend, weil Scrum seine historischen Wurzeln in der Produktentwicklung (Systems Engineering) hat (siehe: The New New Product Development Game von Takeuchi, Hirotaka and Nonaka, Ikujiro. 1986). Scrum für Software wurde erst später beschrieben. Und schon beim NASA-Projekt Mercury, einem Programm der bemannten Raumfahrt, gab es halbtägige(!) Iterationen; das war in den 1960er Jahren! Natürlich gibt es im Embedded-Umfeld andere Qualitätsanforderungen als beispielsweise bei einer Software in der Versicherungsdomäne, aber neue bzw. veränderte Anforderungen und Rahmenbedingungen gibt es ja in jedem neuen Projekt.
Ansonsten kann ich vieles unterschreiben: das mit dem Mentoring, dem Lernen, und die Software Craftsmanship Bewegung.
Vielen Dank für den Beitrag. Ich stimme Dir zu, dass agile Methoden nicht alle Probleme lösen. Aber an einigen Stellen wurde mir nicht sauber genugt zwischen dem was agile Methoden propagieren und dem wie sie leider in vielen Unternehmen nur halbherzig umgesetzt werden unterschieden.
So sagst Du zum Beispiel sinngemäß, dass ein Kern des Übels das Projektdreieck mit seinen Parametern Umfang, Kosten und Zeit ist. Da stimme ich Dir auch vollkommen zu, aber genau da setzen die agilen Methoden ja an. Im agilen Manifest heißt es "Reagieren auf Veränderung geht über das Befolgen eines Plans" und der ganze Scrum-Ansatz basiert genau darauf. Das Problem besteht also eher darin, dass viele Unternehmen sich als "agil" bezeichnen, genau diesen zentralen Prozess des Umdenkens aber nicht vollzogen haben, da er sich eben nicht alleine in der Entwicklungsabteilung umsetzen lässt, sondern alle Abteilungen, vom Vertrieb über das Produktmanagement bis hin zum Kunden fordert.
Das heißt übrigens nicht, dass ich es sträflich finde, wenn ein Unternehmen nur einige Elemente von Scrum und nur in der Entwicklungsabteilung umsetzt. Selbst hier habe ich schon deutliche Verbesserungen in Hinblick auf Kommunikation aber auch Funktionalität erlebt. Nur sollten solche Implementierungen von Scrum nicht als Referenz für scheiternde "agile" Projekte herangezogen werden.
An einer späteren Stelle sagst Du sinngemäß, dass viele Projekte an schlechter Kommunikation und Organisation scheitern — da wäre die Methode egal. Bei Scrum ist die Kommunikation aufgrund der definierten Meetings ein zentraler Bestandteil und insofern wird genau dieser Punkt *gerade* durch die Methode adressiert.
Ich habe selber gute, an sich kommunikative Teams erlebt, wo aber im Wasserfallmodell jeder Entwickler wochenlang für sich allein an seiner Aufgabe rumgewerkelt hat. Nach einer erfolgreichen Umstellung auf Scrum war die Kommunikation — alleine durch den Prozess — viel intensiver. Jedes Teammitglied wusste woran die anderen arbeiten und jeder kannte sämtliche Features des Releases anstatt nur seine eigenen. Dadurch konnten diverse (Software-)Konflikte vermieden werden.
Dein Ansatz eines kontroversen Beitrags hat also gut funktioniert und für reichlich Diskussion gesorgt :-)