Kommentierte Links (CII)
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.
Disruption, also die Verdrängung eines etablierten Produkts oder Unternehmens durch neu aufkommende innovative Konkurrenz, wird im Agile- oder Start Up-Kontext immer wieder thematisiert, sei es als Treiber für Veränderungen oder als anzustrebendes Ziel der eigenen Produktentwicklung. W. Chan Kim und Renée Mauborgne weisen allerdings völlig zu Recht darauf hin, dass Innovation nicht zwingend disruptiv sein muss. Anhand zahlreicher Beispiele zeigen sie auf, dass es auch gelingen kann, neue Märkte aus dem Nichts heraus entstehen zu lassen. Ein durchaus erstrebenswertes Ziel.
Technische Schulden sind ein ähnlich häufig zitiertes Buzzword wie Disruption, was darunter verstanden wird kann aber weit voneinander abweichen. Mikael Vesavuori geht mit einem großen Anspruch in seinen Artikel hinein: er will nicht nur das Konzept verständlich machen, er will es auch ausdifferenzieren, Hintergründe aufzeigen, die Entstehung erklären, das Ganze messbar machen und Wege aufzeigen wie man sich wieder daraus befreit - und das Ganze so, dass auch jemand ohne IT-Hintergrund es verstehen kan. Es dürfte wenig überraschend sein, dass sein Text sehr lang geworden ist, er ist aber gleichzeitig auch sehr gut.
Dieser Blogpost von Barry Overeem ist mit einem bisschen Vorsicht zu lesen, denn wie er am Ende schreibt ist es kein wirklicher Erfahrungsbericht, sondern zusammengesetzt aus verschiedenen Erlebnissen, die er mit verschiedenen Teams gemacht hat. Er enthält aber einige Ideen die auch ich bereits in der Realität beobachten konnte, darunter die beiden wichtigsten: die Beauftragung ganzer Scrum Teams auf Basis einzelner Sprints und die Übernahme der Product Owner-Rolle durch den Kunden. Das kann gut funktionieren, ist aber abhängig vom Kontext. Im hier von Overeem beschriebenen (einer Webdesign-Agentur) kann ich es mir sehr gut vorstellen, in grösseren (z.B. einem Konzern-Projekt) wäre es deutlich schwieriger.
Über die Frage, wann eine agile Transformation abgeschlossen ist,
kann man wunderbar philosophieren. Eine klare Antwort gibt es nicht, aber einen guten Ratschlag: man sollte sich im Voraus messbare Ziele überlegen an denen man erkennen kann, dass man voran kommt, und die dann regelmässig überprüfen. Die von Karl Scotland ausgewählten Zielwerte Produktivität, Vorhersagbarkeit, Reaktionsfähigkeit, Qualität, Nachhaltigkeit und Wertschöpfung gehen genau in diese Richtung, da sie tatsächlich quantifizierbar und überprüfbar sind. Ob sie dauerhaft die Richtigen sind wird sich von Fall zu Fall unterscheiden, auf jeden Fall kann man aber gut mit ihnen anfangen.
Die Überschrift von Alexander Ryazanovs Artikel hängt die Messlatte sehr hoch und ist auch sicher als Clickbait gedacht, seine Ideen finde ich aber sehr richtig. Was mir darüber hinaus gefällt sind seine zuerst einfach erscheinenden, gerade deshalb aber gut nachvollziehbaren Visualisierungen. Etwas was ich bei Gelegenheit in meinen Workschops ausprobieren werde.
