Agile Ignoranz

Ich sitze so da und stelle fest, dass ich vor lauter Agilität kaum noch laufen kann. Nun soll man sich ja tunlichst öfter mal einer kleinen Reflection unterziehen und nachsehen, ob der eigene Quellcode zumindest in den Basisklassen noch stimmig ist. Ein Bisschen Refactoring hier ein wenig Patterns-Anwendung dort und schon stellt man fest: Das stimmt hinten und vorne nicht! So ging es mir neulich beim Thema Agiles Projektmanagement im Allgemeinen und Einbindung des Kunden darin im Besonderen.

Ich habe etwas länger gebraucht, bevor ich diesen Artikel zu Papier brachte. Diesmal nicht nur, weil ich wie immer kaum Zeit hatte, sondern auch, weil ich das Thema erstmal in Ruhe durch meinen Schädel kreisen lassen musste. Jetzt glaube ich, dass ich soweit bin. Doch was ist eigentlich geschehen?

Tja, eigentlich einfach nur das, was immer passiert. Die Projekte laufen einfach nicht so, wie ich und einige Dutzend Buchauthoren, hunderte Agile-Enthusiasten und wer-weiß-wie-viele Scrum-Master sich das so denken. In der Regel fängt man artig an, sein Grüppchen zu sammeln und ja aufzupassen, dass auf jeden Fall fähige Kräfte von Kundenseite mit an Bord sind. Nachdem man denen zum hundersten Mal versichert hat, dass agile Vorgehensweise diese und jene Vorteile bringen und nachdem man dann so Dinge, wie „Nein, agil ist nicht chaotisch!“, oder „Nein, die Entwickler brauchen dafür keinen Kicker im Büro.“ von sich gegeben hat, sitzt man also in der Kickoff-Runde.

Gehen wir mal davon aus, dass hier 10 Leutchen rumsitzen, die sich bereits aus diversen (allesamt aus dem Ruder gelaufenen) Projekten kennen. Eigentlich ist nur neu, dass in diesem Development-Team jetzt auch ein sog. Product Owner rumhängt. Man merkt als Berater erstmal gleich, dass dies nicht unbedingt zur Erheiterung der Runde als solcher beiträgt. Wo die Entwickler in wissender Routinesse geduldig auf den Beginn der Veranstaltung warten und sich vorsorglich mit Getränken versorgt haben, geht dieser neue Produktbesitzer (nehmen wir an, es ist ein Abteilungsleiter vom Vertrieb) ganz anders an die Sache ran.

Zunächst meint er offensichtlich, es wäre der Teamfindung und dem agilen Ansatz dienlich, ausführlich und lautstark zu kolportieren, wie er letztens seinen Jungs die Hölle heiß gemacht hat, weil sie einen Termin nicht einhalten konnten. Die Auswirkungen dieser Rede sind natürlich dem geübten Auge sofort offenbar. Die aus Erfahrung eher schweigsamen und abwartenden Jungs vom Development reagieren subtil aber unmissverständlich indem ihre Blicke noch stärker als zuvor auf den Bereich 2 cm direkt vor Ihrem Kaffee-Pott gerichtet sind. Auch ist ein Absinken der Schulterlinie um 20% wahrzunehmen, sodass man meint, nur noch Köpfe auf Hälsen hätten sich am Tisch eingefunden. Sorgenfalten und unheilige Visionen zeichnen Spuren auf 9 Gesichern von Leuten, die eigentlich lieber wie Sheldon wären. Super, denke ich. Der Auftakt hat schonmal 1a funktioniert.

Eigentlich könnte es jetzt losgehen. Natürlich nicht! Denn der Mittvierziger vom Vertriebs-Zentrum hat noch so einiges zu erzählen. Begonnen damit, dass er bereits so einige Projekte in seiner beruflichen Laufbahn „gewuppt“ hätte (wuppen muss in den 80ern ein absolutes Buzz-Word gewesen sein) kommt er über eher philosophische Lapidarien, wie etwas, dass alle Menschen irgendwie unterschiedlich sind nach 15 Minuten zum Kern: Er hat heute nicht so viel Zeit zum meeten. Noch während man versucht, den nahezug unauflöslichen Widerspruch zwischen gesprochenen Worten und gelebter Realität zu entwirren, beschließt der Product Owner in spe weiterhin seinem natürlich Trieb zu folgen und die avisierten Teamkollegen autoritär weich zu klopfen.

Irgendwann gelingt es einem, die Rede an sich selbst reißen. Trotz der offenkundigen Diskrepanz zwischen der agilen Lehre und der wahrgenommenen Realität, beschließt man wacker, dem Team zu erläutern, nach welchen Regeln das Ganze demnächst abgehen soll. Da hätten wir regelmäßige Treffen kürzerer Dauer, abgestimmte Anforderungen, Testen von Anfang an, direktes Feedback durch die Fachbereiche und freiwilliges Übernehmen von Arbeitspakten. Während dieser Rede wandelt sich der Gemütszustand der kleinen Gruppe merklich.

In dem Maße, in dem sich die Code-Schubser wieder beruhigen, nimmt die Besorgnis im Blick des Umsatz-Jockeys zu. Ihm wird anscheinend jetzt erst klar, dass sich das hier zu einem echten Arbeitspaket für ihn entwickelt. Instinktiv sieht er sich nach opferbereiten Assistenten um, nur um festzustellen, dass es ja in agilen Teams nicht gerade von denen wimmelt. Kaum hat man dann geendet und ein 9-köpfiges Nicken geerntet, meldet sich der Bedenkenträger vom Dienst.

Da müsste er ja jetzt regelmäßig auf Abruf stehen. Auch hätte er irgendwie herausgehört, er müsse sich im Vorfeld über seine Wünsche klar sein. Beides scheint weit jenseits seines Ereignishorizonts zu wabern, merke ich. Nicht, das mich das irgendwie bestürzen könnte. Mittlerweile habe ich ja gelernt, dass das agile Manifest vor allem von den Autoren selbst sowie den Beratungshäusern gelesen wird. Alles unter dem Aspekt, dass man hier neuen Wein in alten Schläuchen verkaufen könnte. Dabei ist es ja eigentlich ganz einfach, wenn nur außer den Entwicklern noch irgendwer mitmachen würde.

Eigentlich ist der Projekt-Start jetzt schon im Eimer. Ich überlege noch, ob ich über das Thema exploratives Testen oder vielleicht auch die kleinen Sümmchen für Lab-Management reden soll, da wird mir klar, dass allein der TFS mit seinem Taskboard die Kapazitäten des Sells-Brain sprengen werden. Was nun aus diesem Projekt wird, ist eigentlich klar.

Ein Sprint verkommt zu einem mit Angst erwarteten PowerPoint-Feuerwerk. Nur 5 Minuten nach diesem Sprint-Auftakt werden die Anforderungen durch die Ergänzungsversionen 1-16 per Mail nachverteilt, weil die Anforderungsseite dann doch mal mit der Geschäftsführung geredet hat. Auch werden wir viele lustige Extra-Schleifen drehen, weil wir gleich zu Beginn merken werden, dass Fragen, wie z.B. „Wie machen Sie das denn heute?“ schnell in ratlosen Sich-Angucken enden. Zum Schluss wird dann getestet, wie eben immer getestet wird. Spätestens, wenn einer der „Tester“ vorsichtig nachfragt, warum er den Login-Bereich nur deswegen neu testen muss, weil das Development gestern ein neues Release rausgegeben hat, wird klar: agil läuft hier eigentlich nix.

Nun lässt das Ganze mehrere Schlüsse zu. Einer könnte sein, dass ich die falschen Kunden habe. Das Problem ist, dass mit zunehmender Projekterfahrung das Eis langsam dünn wird. Ich weiß nicht mehr, unter welchem Branchenbuch-Eintrag ich eine Firma suchen soll, die wirklich bereit ist, agil zu arbeiten – mit allem drum und dran. Und da reden wir ja noch nicht mal über Geld- und Zeit-Investments. Es geht einfach darum, dass die viel gelobte Flexibilität vor allem bei den Entwicklern erlebbar wird, kaum jedoch bei den hochgezüchteten Provisions-Hechtern der vielen anderen Abteilungen.

Aber auch in der IT tummelt sich bei genauerem Hinsehen so einiges an – na sagen wir mal – Achtelwissen. Redet man mit einigen Leuten über Agil, kommt prompt sowas wie: „Nee, wir machen das mit Git.“. Aha! Verstehe! Und die Arbeitsaufgaben? Das Bug-Tracking? Der automatische Build? Eine Auflistung von mindestens 12 Open-Source Tools verwaltet von einem einzigen Halbtagsmitarbeiter (ein Linux-Fan) und ursprünglich eingerichtet von einem Praktikanten (kein Linux-Fan) in einer nicht näher bekannten als greisenhaft zu vermutenden Versionsvielfalt wird nun heruntergerattert. Das dabei zur Schau getragene Augenleuchten rührt offensichtlich eher von der Ehrfurcht her, dass das Monster überhaupt läuft, als von der Begeisterung über laufende Prozesse.

So gern ich selbst mit den agilen Methoden im allgemeinen und dem TFS im speziellen arbeitet: Ich erlebe selbst kein laufendes agiles Management auf dieser Ebene. Man möge mich korrigieren oder einen Ketzer oder Ignoranten nennen! Mir egal. Es passiert einfach nicht. Sprinten tun mittlerweile anscheinend alle, aber das ganze halt ohne Sprint Meeting, Iterationen oder Testing.

Vielleicht ist das Ganze auch ein kulturelles Problem und im Land der jährlich drohenden Staatspleiten gehen die Leute hier lockerer oder verständiger vor? Vielleicht hat es auch damit zu tun, dass außer bei Google, MS und Facebook keine coolen Firmen-Campi (oder wie ist die Mehrzahl von Campus?) eingerichtet werden – so mit Parks und Starbucks und WLAN und allem. Vielleicht liegt es einfach daran, dass den Managern immer wieder ITIL, Prince und die anderen wasserfall-verursachenden Features zur Seite gegeben werden, die jedem agilen Verfechter sofort das Leuchten aus den Augen schleudern. Ich weiß nicht, was es ist, nur dass es so ist.

Eine Sache darf man jedenfalls auf keinen Fall aus den Augen verlieren: Auch nicht-agile Projekte funktionieren. Dass da hinten irgendwie 9 Developer hocken und Deployment-Pakete per Hand über Dropbox verteilen und am Tag 10mal mehr Haare lassen, als ein Kernphysiker am CERN, interessiert das wirklich jemanden? Ich meine: wirklich?!?!? Man darf nämlich nicht außer Acht lassen, dass Scrum, XP und wie sie alle heißen vor allem von den Medien der Developer propagiert werden. Das ist ungefähr so, als würde ein Top-500-Unternehmens-CEO sich das Abo von „Hausmeister Heute“ besorgen und aufgeregt deren Artikel verschlingen. Ok, ein wenig überzogen schon, aber ich glaube, nich allzuweit entfernt.

Es wäre halt an der Zeit, die theoretischen Ansätze mal einer ordentlich Realitäts-Prüfung zu unterziehen und vor allem, die anderen Beteiligten auch mit ins Boot zu holen. Ich kenne Projekte, in denen sich die Developer halt allein agil planen, damit sie es halt wenigstens machen dürfen.

Naja, oder man muss halt mal ein neues agiles Manifest entwerfen. Dann können wir uns wenigstens dafür zertifizieren lassen.

Eine Antwort auf „Agile Ignoranz“

  1. Gut, dass du über deine Erfahrungen berichtest, damit bist du nämlich nicht alleine.

    Wortwörtlich gesagt: Das Grundproblem sind immer ein paar hirnlose Leute oder Diktator im Team. Die wollen nicht mitmachen, und dann funktioniert das auch nicht.

    Der Marketingleiter sieht sich jetzt als klassischer Chef des Entwicklerteams, allerdings ist er der Kunde, so wie ich das herausgelesen habe. Deswegen muss man ihn auch als Kunde behandeln. Der Product Owner sollte ein Vermittler zwischen Team und Kunde sein. D.h. evtl. jemand aus eurem bisherigen Team, der in die Rolle des Product Owners umziehen will, aber dann nicht mehr im Entwickler-Team dabei ist. Dann sollte man die Aufgaben gut trennen:

    Der Marketingleiter ist der Kunde und wird interviewt. Er will eine Software haben, dann muss er natürlich seine fachlichen Anforderungen dem Product Owner beibringen. WIE das Entwicklerteam arbeitet, geht ihn nichts an. Das einzige was er wissen muss ist, dass nach dem internen Sprint Planning herauskommt, welchen Anteil er in 3 Wochen kriegt. Da der erste Sprint oft Grundlagenarbeit ist, wird erst nach dem zweiten Sprint (also 6 Wochen) etwas Vorzeigbares herauskommen. In der Zwischenzeit muss er auf das Ergebnis warten.

    Der Product Owner sammelt die Anforderungen, und priorisiert sie mit dem Kunden. Wenn er das z.B. in User Stories verpackt hat, dann startet das Sprint Planning mit dem Team.

    Das Team bespricht mit dem Product Owner die Anforderungen und schnürt ein Paket, dass sie in z.B. 3 Wochen schaffen. WIE sie es entwickeln, und WIE sie es lösen, das ist ihre Sache.

    Wenn du mehr Details wissen willst, dann empfehle ich dir am besten das video2brain-Training: ‚Agile Softwareentwicklung mit Scrum‘. Da werden die Zusammenhänge erklärt, aber auch gängige Fehler gezeigt.

    Allerdings ist die Erde jetzt schon fast verbrannt, weil man den Marketingleiter nicht so einfach vom Teamchef in einen Kunden verwandeln kann. Wenn ihr das schafft, dann kriegt ihr noch die agile Kurve.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.