Kommentierte Links (XCIX)
Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.
In den letzten Jahren habe ich verschiedene "Corporate Startups", also Startup-artige Ausgründungen grosser Konzerne, bei Gründung und Wachstum begleiten dürfen. Aus dieser Erfahrung heraus kann ich das, was Nathan Furr und Kate O’Keeffe schreiben, bestätigen - derartige Konstellationen haben gegenüber klassischen Startups viele Vorteile. Sie sind von den traditionellen und oft verkrusteten Strukturen ihrer Muttergesellschaften befreit, können aber auf deren Expertise und Kontakte zugreifen und haben eine stabilere Finanzierung als die durch Wagniskapital-Runden. Was ich an dem Artikel besonders mag: er gibt auch Ratschläge was man tun und lassen sollte, um zu verhindern, dass die Schwerfälligkeit des Mutterschiffs sich auf das Tochterunternehmen überträgt.
Dass es zu viele Prozesse gibt, ist eine Beschwerde, die man in nahezu jedem grösseren Unternehmen hören kann. Wesentlich seltener wird gefragt, wo sie herkommen und ob der Grund, wegen dem sie existieren, nicht eigentlich ein sinnvoller ist. Lucas Fernandes da Costa nennt den häufigsten Ursprung: irgendwann ist etwas schiefgelaufen, und um zu verhindern, dass es wieder passiert, wurden Regeln eingeführt. Da die nicht alle Eventualitäten abdecken können, kommt es trotzdem zu neuen Fehlern, die zu neuen Regeln führen, die dann
von Konzern-Trollen missbraucht werden. Etc. Um die so entstandenen Prozesse wieder verschlanken zu können, muss daran gearbeitet werden, dass Root Causes, Auswirkungen und Wahrnehmungen von Fehlern sich ändern. Erst dann werden die Widerstände gegen Verschlankungsvorhaben zurückgehen.
Dass Datengetriebenheit und Reduzierung paralleler Arbeit zu agilem Arbeiten gehören ist (hoffentlich) eine allgemein anerkannte Selbstverständlichkeit. Was in der Realität aber immer wieder passiert, ist, dass diese Praktiken nur auf der Umsetzungs-Ebene angewandt werden. Johanna Rothman zeigt am Beispiel eines ihrer Beratungsprojekte auf, dass auch die Management-Ebene und die Produktportfolio-Planung von ihnen profitieren können. Ein Punkt den sie dabei macht und den auch ich für wichtig halte: um den tatsächlichen Grad der Überplanung zu erkennen sollte der Status eines Projekts oder Arbeitspakets nicht zu granular sein. Alles woran bereits (Vor-)Arbeiten begonnen haben befindet sich in der Umsetzung. Die sich daraus ergebende Menge paralleler Arbeit ist in der Regel deutlich höher als man denkt.
Nein, hier geht es nicht um
agile Bauprojekte. Was Dan North meint sind Tätigkeiten aus der Kategorie "Business as usual", also das was man im Deutschen als Regeltätigkeiten bezeichnen würde. Sie treten vor allem bei Komponententeams auf, also dort wo eine Einheit nicht an allen Aspekten eines Produkts oder Service arbeitet, sondern nur ein einzelnes, allein genommen nicht wertstiftendes System entwickelt oder administriert. Die BAU-Tätigkeiten bestehen in solchen Fällen daraus die immer gleiche Tätigkeit auszuüben, die von aussen angefragt wird, etwa das Konfigurieren von Firewalls oder Datenbanken. Seine Empfehlung (der man sich nur voll anschliessen kann) ist es, möglichst wenige derartige Teams zu haben und stattdessen crossfunktionale Einheiten zu schaffen, die alles für ihre Produktentwicklung Notwendige selbst machen können und dürfen. Nur so lässt es sich verhindern, dass ständig jeder auf jeden wartet und dadurch nichts vorangeht.
Willem-Jan Ageling hat sich schon seit einiger Zeit als fundierter Kenner und Kritiker von SAFe positioniert, mittlerweile sind
über 20 Artikel von ihm zu diesem Thema zusammengekommen. In diesem hier geht es um die neueste Version dieser ständig erweiterten Methode, und obwohl er weiterhin kritisch ist sieht er auch Positives - an einigen Stellen entwickelt sich SAFe in die richtige Richtung, an anderen wird aufgehört etablierte Begriffe falsch zu benutzen. Auch ich habe diesen Eindruck: SAFe ist zwar noch immer nicht das was ich agil nennen würde, es ist aber näher daran als jemals zuvor.
