Kommentierte Links (XXVIII)
Direkt zu Beginn dieses Textes wird die Tragik des Untergangs von Kodak auf den Punkt gebracht: die Firma ging nicht nur unter weil ihre Erzeugnisse durch den technischen Wandel obsolet wurden, sie hatte diesen Wandel selbst begonnen, wollte dann aber doch nicht auf ihre traditionellen Erfolgsprodukte verzichten. Tendayi Viki geht davon aus, dass ein solches Management-Verhalten seinen Ursprung in einer falschen Ausbildung der Manager an den Universitäten und in den Firmen hat, wo vermittelt wird, dass eine Fokussierung auf ein einziges Geschäftsfeld sinnvoll ist. Sein Gegenvorschlag besteht darin bis zu 30 % der Ressourcen auf neue und disruptive Geschäftsmodelle mit noch unklaren Erfolgschancen zu verwenden und diese möglichst früh validierbar zu machen. Klingt gut, es bleibt aber die Frage wie das mit kurzfristigen Shareholder-Interessen in Einklang zu bringen sein wird.
Ob Business Agility und agiles Projektmanagement wirklich neue Trends sind und ob sie grundsätzlich das Risiko in sich tragen die eigentliche Agilität mit zu viel Prozessen einzuengen würde ich hinterfragen. Ron Jeffries hat aber Recht damit, dass es eine spürbare Tendenz gibt agile Transformationen als rein organisatorische Vorhaben zu sehen und die technischen Implikationen auszublenden. Bei vielen Managern gibt es den Irrglauben, dass eine zweitägige Zertifizierung oder eine zweiwöchige Begleitung durch einen Coach ausreichen um ein Team "agil zu machen". In meiner Erfahrung sind eher
mehrere Monate nötig, aber das muss erstmal jemand bezahlen wollen. Wobei klar ist - wer eine billige Transition will zahlt meistens drauf.
Da Jurgen Appelo zur Zeit an einem Framework-unabhängigen Methodenbaukasten arbeitet sind seine in letzter Zeit zunehmenden Äusserungen über die Starrheit und Unflexibilität dieser Frameworks mit Vorsicht zu betrachten. Einen zutreffenden Kern haben sie aber, hier werden Freiheiten und Optionen bewusst durch Leitplanken eingegrenzt. Ich bin auch bereit zu hinterfragen ob agile Teams diese Leitplanken wirklich brauchen, erfahrungsgemäß ist das oft nicht der Fall. Wenn aber auf der anderen Seite unerfahrene Teams versuchen die Methoden anzupassen endet das sehr oft in Verschlimmbesserungen.
Harikiri, wie ich es nenne. Frameworks haben ihren Sinn, man muss ihn sich nur bewusst machen statt ihnen kritiklos zu folgen.
Einer der klassischen Fehler die man bei User Stories machen kann ist, dass bereits Lösungen beschrieben werden statt der Bedürfnisse des Benutzers oder des Kunden. Übertroffen wird das gelegentlich noch durch die Beschreibung von Bearbeitungsschritten ("Als Sachbearbeiter möchte ich auf einen Knopf drücken ..."). Der Lösungsansatz von Urs Enzler ist der Richtige, da er das Erarbeiten der Lösung beim Team lässt. Die Voraussetzung dafür ist allerdings, dass in dem auch wirkliche Software-Entwickler sitzen und nicht nur Coding Monkeys. (siehe auch:
"As a User" needs to stop).
Mit ihrer Aussage "It's all about Business Agility" gibt Debbie Wren scheinbar eine Gegenthese zu Ron Jeffries (weiter oben) ab. Wo sie wieder mit ihm zusammenkommt: um das zu erreichen ist (unter anderem) "technische Agilität" notwendig. Erst das, in Kombination mit Autonomie und Empowerment, macht Business Agility möglich.
