Agilität manifestieren

Und schon wieder ein Begriff, der mir persönlich wichtig ist und der meiner Meinung nach oft falsch verstanden oder sogar missbraucht wird.

Agiles Vorgehen ist schon seit Jahren in aller Munde als die Methode, um sich auf das Wesentliche zu konzentrieren, Planungsaufwände zu minimieren und schnell zum Ziel zu kommen. Ob SCRUM, Design Thinking, Lean Startup oder Kanban ist letztendlich egal. Hauptsache agil. Der Grundgedanke ist derselbe. In den kommenden Zeilen findet die geneigte Leser*in ein Kondensat der Vorteile, Herausforderungen und und ein paar Best Practices.

Agil arbeiten

Planung ersetzt Zufall durch Irrtum

Quelle unbekannt

Wer agil vorgeht, der versucht Planungsaufwände zu minimieren. Das erreicht man, indem man nur den Zeithorizont detailliert plant, in dem mehr oder weniger garantiert werden kann, dass die Dinge, die geplant sind, auch tatsächlich durchgeführt werden. Das bedeutet, dass es keine detaillierte langfristige „Roadmap“ mehr gibt, in der haarklein aufgeführt ist, wann welches Projekt/Feature/User Story fertig gestellt wird. Wer denkt, dass so eine Roadmap auch nur ansatzweise eingehalten werden kann, der lügt sich in die Tasche. Ich habe noch nie erlebt, dass zum Beispiel eine Produkt-Roadmap oder eine IT-Projekt-Roadmap auch nur ansatzweise über einen Planungshorizont von einem Jahr stabil geblieben ist. Warum also Stunden oder gar Tage verschwenden, um sie aufzustellen?

Leben wir Agilisten dann munter in den Tag hinein und machen, was uns gerade vor die Füße fällt? Mitnichten. Statt eines Wasserfallartigen Plans, der abgearbeitet wird, existiert irgendeine Art von priorisiertem Backlog. Auf diesem sind alle Dinge zu finden, die das Team erledigen möchte. Im Falle meiner IT-Abteilung sind das Dinge wie Infrastrukturprojekte, regelmäßige Wartung und Überprüfung von Systemen, Zertifizierungsaufwände, Dokumentation… Die Sache, die am wichtigsten ist, hat den obersten Listenplatz. Und was weiter oben steht, wird auch detaillierter geplant. Während das letzte Projekt noch in der Umsetzung ist, beginnt für das nächste, meist schon die detaillierte Planungs- und Anforderungsphase. Für Projekte, die auf Listenplätzen weiter unten stehen, wird wenig oder nichts getan. Höchstens mal kleine Explorationen und Versuche zur Umsetzbarkeit.

Die Priorisierung der Listenelemente wird regelmäßig überprüft. Das Projekt, das gerade bearbeitet wird, wird nur im allergrößten Notfall ausgetauscht. Also ständig😉. Das, das in Vorbereitung ist, am liebsten auch nicht. Alles andere kann „wild“ umpriorisiert werden.

Agile Haltung

Je mehr Personen die agilen Prinzipien verinnerlichen, desto runder läuft es. Wenn in einem Unternehmen ein Bereich agil arbeitet, der Rest aber nicht, dann sind Konflikte vorprogrammiert. Es ist wichtig, dass alle anerkennen, dass die Geschwindigkeit, mit der Dinge erledigt werden können einfach von vielen Dingen abhängt und nicht konstant ist. Dinge, die immer dazwischen kommen sind

• Teammitglieder sind krank, im Urlaub oder auf Weiterbildung.
• Irgendwas geht kaputt.
• Es muss doch noch was ganzganzganz wichtiges (Prio AAA+++++) dazwischengeschoben werden.
• Jemand kündigt.
• Jemand muss eingearbeitet werden.

Natürlich könnte man einen Puffer einplanen, der groß genug ist, wenn man den Plan erstellt. Dieser Puffer müsste ungefähr 50% der verfügbaren Arbeitszeit betragen. Macht das irgendwer? Hat das jemand schon mal gesehen?

Wenn man eine agile Haltung hat, dann erkennt man an, dass es Prioritätsänderungen, neue Erkenntnisse und sonstige Zwischenfälle gibt.

Agil und trotzdem ambitioniert zu planen ist übrigens kein Problem. Agilität ist keine Methode, um Faulheit zu fördern, sondern um schnell und effizient ans Ziel zu kommen.

Es gibt auch agile Praktiken, die Mitarbeiter*innen ausnutzen, überfordern und überlasten. Das will ich nicht verschweigen. Hier ist maßvolles Vorgehen gefragt, wenn man sich aus dem agilen Baukasten bedient.

Sand im agilen Getriebe

Mal angenommen, in einer Firma würde jemand behaupten, dass „man das doch so nicht machen kann. Man muss sich doch mal festlegen, wann was fertig wird“. Oft kommt sowas von Personen, die sich nicht ausreichend mit der Thematik beschäftigt haben. Oder es wird behauptet, dass das „die Kunden fordern“.

Dazu entgegne ich folgendes: Hört auf, Euch selbst zu belügen und Aufwand zu investieren, wo es sich nicht lohnt. Viel Spaß dabei, den Kunden klarzumachen, dass der versprochene Zeitplan doch nicht eingehalten werden konnte. Aus meiner Sicht ist alles eine Frage der Kommunikation. Lieber Kunde, wir arbeiten agil. Hier ist unser Backlog. Dein gefordertes Feature ist momentan an Stelle X. Wenn wir von der aktuellen Entwicklungsgeschwindigkeit ausgehen, wird es vermutlich in Release X.Y fertig. Wenn nichts dazwischenkommt und sich keine Prioritätsänderungen ergeben.

Ehrlich währt am längsten. Ehrlich.

Ich sehe ein, dass es schwierig ist, dem Kunden zu erklären, dass man nun anders arbeitet und die Wasserfall-Releaseplanung über den Haufen geworfen hat. Aber ist es wirklich schwieriger und erzeugt mehr Aufwand, als dem Kunden drei mal im Jahr zu erklären, warum schon wieder alles anders ist und die Termine nicht gehalten werden können?

Und wenn man für interne Kunden arbeitet (als IT-Abteilung zum Beispiel), dann ist es super, wenn man den Chef auf seiner Seite hat, der einem die quengelnden Kunden ein bisschen vom Hals hält und allen erklärt, dass genaue Angaben der Fertigstellungszeit nicht möglich sind. Die Dinge werden fertig wenn sie fertig werden. Irgendwann kann man Schätzungen abgeben, die naturgemäß immer genauer werden, je näher ein Projekt zur Fertigstellung kommt. Bei großen Projekten auf der Roadmap geht das jedoch nicht. Keine Ahnung, wann das ERP und das CRM fertig eingeführt ist. Wir bekommen das hin, haben es aber noch nie vorher gemacht. Wie sollen wir also sagen, wann? Riesenprojekt, extrem komplex. Dauert ein Jahr. Oder zwei. Genauer wird es erst mal nicht. Selbst wenn man versucht, einen genauen Projektplan aufzustellen. Der macht erst mal ein gutes Gefühl, weil man denkt, dass man alles unter Kontrolle hat. Hat man aber nicht.

Agile Wasserfälle

Eine besondere Herausforderung, sind die Schnittstellen zwischen agilen und „klassischen“ Methoden.

Ein Beispiel:

Ein Unternehmen existiert schon seit vielen Jahren und hat einen etablierten Prozess zur Planung von Budgets und Zielen mit jährlichem Planungshorizont. In diesem Unternehmen gibt es eine Entwicklungsabteilung und eine IT-Abteilung. Die beiden Bereiche haben schon erkannt, dass man mit agilen Methoden besser zum Ziel kommt. Die restliche Firma hängt noch am liebgewonnenen Wasserfallmodell. ❤️

Wasserfallbudget

Was passiert also ungefähr in der zweiten Januarwoche? (Oder sogar schon früher…) Genau. Aus einem guten Grund haben sich die Prioritäten geändert. Ein neues, wichtiges IT-Projekt ist hinzugekommen, ein anderes wird verworfen. Das Geld wird aus einem Budget in ein anderes verschoben. Was bleibt, ist verbrannte Arbeitszeit und ein mieses Gefühl. Hat man das richtige Budget geplündert? Schafft man die andere Sache nicht vielleicht doch? Wo soll dann das Geld dafür herkommen?

Genauso führt das wasserfallartige Vorgehen bei der Budgetplanung dazu, dass sich die Budgets aufblähen. Wie das? Es gibt einfach wahnsinnig viele Dinge, die getan werden müssen. Dafür muss Budget zur Verfügung stehen. Man schätzt also Beträge, für alle wichtigen und dringenden Themen. Dass das aber viel mehr ist, als in einem Jahr schaffbar ist, steht auf einem anderen Blatt. Nun werden die Budgets gekürzt. Entweder wird jedes Budget prozentual zusammengestrichen, oder man versucht die Dinge zu identifizieren, die man dann doch nicht macht. Beides führt dazu, dass man wieder Geld hin und herschiebt. Man verbrennt Hirnschmalz und Arbeitszeit, wenn dann das Geld auf einzelnen Budgets nicht reicht, oder für ein Thema, das plötzlich doch wieder wichtig ist, kein Budget mehr existiert.

Minimalistischer agiler Ansatz

Wundert es eine*n meiner geneigten Leser*innen nun, dass man auch Budgets agil planen kann? Hier ein Vorschlag, wie ich es machen würde:

• Aus vergangenen Jahren gibt es Erfahrungswerte, wie viel Geld ein Team sinnvollerweise ausgeben kann.
• Feste Posten (Softwarelizenzen, Strom, Miete, Internetanschluss, Heizkosten…) plant man detailliert.
• Für den Rest gibt es eine Budgetposition „Projekte“, die einen festen Betrag enthält, der ungefähr dem entspricht, was in den letzten Jahren für die Umsetzung von Projekten sinnvollerweise ausgegeben werden konnte. Oder weniger, wenn nicht so viel Budget zur Verfügung steht. Oder mehr, wenn das Geld zur Verfügung steht und vielleicht das Team gewachsen ist.
• Wenn ein Projekt startet, wird ein Unterbudget angelegt, um einfach feststellen zu können, welche Kosten tatsächlich entstanden sind.

Unterm Strich führt das zu einer realistischeren Schätzung und zu geringerer Notwendigkeit, sich unterjährig mit Umplanung zu beschäftigen.

Ein Beispiel unter vielen. Wer Unterstützung braucht, es auf seine Situation zu übertragen, darf mich gerne ansprechen.

Fazit

Aus meiner Sicht ist es vernünftig und effizient, agil zu arbeiten. Ich arbeite weiter daran, möglichst viele Menschen zu überzeugen, es mal zu versuchen. Ich hoffe, dass ich mit diesem Blogpost den einen oder anderen erreiche. Vielleicht sogar ein paar Kollegen von meinem aktuellen Arbeitgeber. Schönen Gruß, falls Du Dich angesprochen fühlst. 😉