Warum ich kein Freund von Agile bin.

Warum ich kein Freund von Agile bin.

Im Geschäftsumfeld versucht man, alles so planbar wie möglich zu gestalten, langfristige Budgets bereit zu stellen, Risiken im Vorfeld weitestgehend zu minimieren. Macht Sinn, oder?

Ich bin begeisterter Koch und verbringe jeden Tag bei mir in der Küche. Als ich mich damals selbständig gemacht habe, hatte ich am Wochenende als Koch in der Gastro gearbeitet, um einen stabilen Cash Flow zu haben und mich mit Dingen wie der Krankenkasse nicht rumschlagen zu müssen.

Meine Wochenplanung fällt von daher schnell, einfach und extrem akkurat aus, da ich die meisten Gerichte schon extrem oft zubereitet habe, Zeit und Aufwand daher sehr genau abschätzen kann, meine Supermärkte und ihre Preise kenne, usw.

Wenn mich jetzt aber jemand darum bittet, ein ganz bestimmtes Gericht, das ich davor noch nie zubereitet habe, zu kochen, dann wird es schwieriger. Ich kann bestimmte Sachen ableiten, etwas wie lange ein Schmorgericht wohl dauert, basierend auf einem anderen Schmorgericht, trotzdem muss ich auch erst mal Kochbücher und das Internet konsultieren.


Sprung rüber zu uns in die IT:

In den meisten Fällen, erschaffen wir etwas absolut neues, auch wenn wir immer wieder zu bestimmten Basics und Standards zurückgreifen.

Ein großes Problem: Wir arbeiten meist nie wirklich agil. Projekte werden meist ganz normal geplant, budgetiert, mit Personal ausgestattet, erhalten PO und PM, das ganze Gerüst wird von Außen vorgegeben, nur die Methodik innerhalb des Projekts ändert sich leicht.

Wie groß ist der Wolkenkratzer dort drüben in cm? Ich habe keine Ahnung, weder habe ich bisher einen Wolkenkratzer gebaut, noch kann ich von hier aus die Entfernung einschätzen, von daher kann ich nicht ableiten, wie ich die Größe von dem, was ich da gerade sehe, umrechnen könnte.

Agil: Wir wissen, wo wir hin wollen, wir wisen aber nicht, wie wir dort hin kommen, von daher versuchen wir also in relativ kurzen Zyklen etwas zu erschaffen, schnell Feedback zu bekommen, unsere Ausrichtung neu zu justieren und dann wieder von Vorne, so lange, bis wir irgendwann das Ziel erreichen und die Burndown Chart bei Null angelangt ist.

Pseudo-Agil: Hier ist das Ziel, erreicht das in x Manntagen innerhalb eines Budget von y oder das Projekt war ein Fehlschlag.

Agiles Vorgehen: Wir versuchen, jede Aufgabe in die kleinsten möglichen Schritte zu zerlegen und diese dann anzugehen um darauf aufbauen zu können. Das versuchen wir ja als Entwickler generell und ist ja eh schon unsere Vorgehensweise, nennt sich Imperativ.

Pseudo-Agiles Vorgehen: Wir treffen uns zu regelmäßigen Meetings, in denen wir von unserem Fortschritt zu berichten haben. Das ist ein Krampf, denn bei einigen Dingen gibt es halt einfach einen Status, nicht aber einen Fortschritt. Mehr als genug Aufgaben erweisen sich auch als komplexer, benötigen mehr Recherche, oder funktionieren in der ersten Implementierung doch nicht so, wie man es sich gedacht hat, oder lassen sich einfach beim besten Willen nicht klein genug herunter brechen um der Konvention zu entsprechen.


Dieser Unterschied ist dabei sehr wichtig. Mats Alvesson hat in "The Stupidity Paradox" mal etwas sehr zutreffend formuliert: "You avoid thinking too much about exactly what you are doing, why you are doing it, and its potential implications. You hope to avoid punishments and many worries that might come from deviation. You sidestep the burdens of having to think too much and upsetting others by asking difficult questions".

Gibt es den Begriff "Meta Arbeit"? Wenn nicht, erhebe ich jetzt auch keinen Anspruch darauf.

Wir sollten alle in der Lage sein, zu kommunizieren, uns auszutauschen, pro-aktiv Team Synch Termine anzusetzen, wenn es notwendig ist, besonders sollten wir in der Lage sein, einzuschätzen, welchen Aufwand eine Aufgabe jetzt hat, ohne sie künstlich in Mikro-Aufgaben herunter zu brechen.

Besonders sollten wir uns mit den Mitteln der asynchronen Kommunikation auskennen und auch bereit sein, dort einen teil unserer täglichen Arbeitszeit hinein zu investieren, etwa in dem man relativ klassisch und langweilig seine Arbeit dokumentiert, ohne sich auf den beständigen Statusreport zu verlassen und den Fortschritt die absolute Priorität zu geben.

Im schönen Xerox PARC wurden bei der Erfindung des Personal Computers einigen Prinzipien festgelegt. Darunter "Ein Computer soll helfen, Arbeit erledigt zu bekommen, und keine zusätzliche Arbeit benötigen".

Deswegen der Hinweis auf "Meta Arbeit". Eine Pseudo-Agile Vorgehensweise schafft den kompletten Overhead um wirklich agil zu arbeiten, da dieser aber im Prinzip im klassischen Wasserfall eingebettet ist, finden wir uns in einer Situation wieder, in der man mehr über Arbeit, über Organisation, über Meetings und Termine, über vieles redet und es plant, aber im Prinzip nicht arbeitet.

Zum Anzeigen oder Hinzufügen von Kommentaren einloggen

Weitere Artikel von Florian Klima

Ebenfalls angesehen

Themen ansehen