Kommentierte Links (LXXVI)
Zu den Fallstricken die eine agile Transition scheitern lassen können gehört auch die Budgetierung. Wenn diese weiterhin so verläuft als wäre die Zukunft vorhersehbar und planbar helfen alle neuen Prozesse, Rollen und Regeln wenig bis gar nicht. Der Ansatz von Jutta Eckstein, Eric Abelen und Hendrik Esser ist naheliegend, dürfte aber den meisten klassisch geprägten Unternehmen sehr schwerfallen: wenn es mit hoher Wahrscheinlichkeit dazu kommen wird, dass die Realität sich anders entwickelt als geplant, sollten lediglich grobe Rahmen und Grenzwerte gesetzt werden, innerhalb derer die Umsetzungs-Verantwortlichen weitgehende Freiheit haben. Die Voraussetzung dafür ist, wie so oft, Vertrauen. Aber dort wo das nicht gegeben ist, ist die Budgetierung auch nicht das grösste Problem.
Zum Thema agiles Change Management habe
ich selbst schon einiges geschrieben, Jeff Kavanaugh und Rafee Tarafdar geben dem Ganzen aber einen schönen neuen Namen: Microchange Management. Hinter diesem Begriff verbirgt sich ein Framework das ähnlich aufgebaut ist wie OKRs oder agiles Backlog-Management - grosse Vorhaben werden so lange in immer kleinere heruntergebrochen bis diese in kurzen Zeiträumen umsetzbar sind, und selbst in diesen Zeiträumen findet in kurzen täglichen Synchronisationsmeetings ein kontinuierliches Abarbeiten und Überprüfen statt, bei Bedarf auch ein Anpassen von Zielen und Massnahmen. Wie bei den anderen oben genannten Vorgehen dürfte auch hier gelten: einfach zu erklären, anspruchsvoll in der Umsetzung und lohnend wenn es gelingt.
Ein schöner Spruch den ich vor kurzem mitbekommen habe geht so: "Chaos Engineering ist das was früher Extreme Programming war. Alle ahnen, dass es für die agile Softwareentwicklung einen grossen Sprung nach vorne bedeuten kann, aber weil die meisten Agile Coaches zu wenig Ahnung von Technik haben kann es keiner erklären, und darum macht es fast niemand." Man muss es eingestehen - völlig abwegig ist dieser Spruch nicht, aber gerade deshalb ist das was Emma Garofalo hier macht um so verdienstvoller: sie erklärt das Konzept so, dass auch Nicht-Techniker es verstehen können.
Das Erlernen agiler Arbeitsweisen mit dem Erlernen des Fahrradfahrens zu verbinden ist nicht immer unumstritten, gerade in Bezug auf Scrum gibt es den einen oder anderen
unpassenden Vergleich. Der den Marcus Raitner hier anbringt ist dafür um so passender: genau wie man das Radfahren nicht auf einem Downhill-Track im Gebirge bei aufziehendem Gewitter lernen sollte, sollte man auch das Arbeiten in agilen Frameworks nach Möglichkeiten nicht in Stress- oder Krisenphasen zu erlernen versuchen. Wesentlich zielführender ist es, die ersten Versuche dort zu machen wo Aufwand und Auswirkungen noch überschaubar sind, so dass man ohne grosse Sorgen Experimente wagen kann.
In den Filterblasen der IT-Branche, der
agilen Community und der Medienbranche gibt es in den letzten Monaten die Tendenz zu einer starken Verklärung des Heimarbeit, oft verbunden mit der Aussage, dass diese Art zu arbeiten in nahezu jeder Hinsicht besser wäre als die Präsenzarbeit im Büro. Das Problem dabei - es handelt sich fast ausschliesslich um nicht statistisch validierte Meinungsbilder, bestenfalls angelehnt an
anekdotische Evidenz. Thomas Knüwer hält dem eine ganze Reihe von Studien und Statistiken gegenüber die ein ganz anderes Bild aufzeigen. Das heisst zwar nicht, dass Heimarbeit grundsätzlich schlecht wäre (das wäre nur ein anderes überzogenes Meinungsbild), es zeigt aber, dass man sich durchaus kritischer mit diesem Thema beschäftigen sollte als es häufig der Fall ist.
