Kommentierte Links (XLI)
Bild: Pixabay / Bru-nO - Lizenz |
Marcus Raitner: Die modernen Hofnarren
Einerseits ist das was Markus Raitner hier schreibt absolut richtig - dadurch dass ein Scrum Master (bis zu einem gewissen Grad) von den Konventionen und sozialen Barrieren eines Unternehmens entbunden ist kann er Dinge ansprechen die von anderen nicht angesprochen werden können. Andererseits ist eine Konstellation in der das zutrifft hochgradig dysfunktional, bedeutet es doch, dass "normale Angestellte" eben nicht die Erlaubnis haben Kritik zu üben. Der Scrum Master-Hofnarr kann demnach zwar in einer Übergangsphase seine Berechtigung haben, als ständige Institution wäre er aber ein Anzeichen dafür, dass die agile Transition gescheitert ist.
Trish Khoo: Make a technical debt payment plan
Eine grossartige Idee! Wenn die finanziellen Schulden eine passende Inspiration für die Metapher der technischen Schulden sind, dann kann auch der Abbau technischer Schulden mit einem Begriff aus dem finanziellen Umfeld beschrieben werden. Ein Rückzahlungsplan wie man ihn für die Befreiung aus erdrückenden Verbindlichkeiten benötigt macht in der IT genau so viel Sinn wie bei der Haushaltsplanung: welche Schulden sind die drängendsten und dringensten, mit welchen Schritten kann ihr Abbau angegangen werden und wer wird sich dieser Schritte annehmen? Peter Zwegat wäre begeistert.
Krishna Kandala: Business agility for speed to market - Applying design & agile thinking to drive consumer value
Der beste Weg in Richtung Zukunft ist die beständige Lieferung kleiner, funktionsfähiger, Mehrwert stiftender Neuerungen und Erweiterungen. Der Versuch in wenigen, grossen, seltenen Schritten riesige Fortschritte zu erzielen macht schwerfällig und vervielfacht das mit Fehlentscheidungen einhergende Risiko. Was in der IT Common Sense ist versucht Krishna Kandala auf die Business-Welt zu übertragen. Ein zentraler Punkt seiner Überlegungen: grosse Unternehmen haben in der Regel kein Problem mit der Entwicklung neuer Ideen, sie tun sich aber sehr schwer damit, daraus vermarktbare Produkte zu machen - und zwar weil sie ihre grossen Visionen nicht in kleine Incremente herunterbrechen können.
Mike Cohn: What Does It Mean to Be Potentially Releasable?
Einer der wichtigsten Sätze im Scrum Guide ist: "The increment must be in useable condition regardless of whether the Product Owner decides to release it." Was für diesen Zustand nötig ist und was nicht ist Gegenstand umfassender und beständig wiederkehrender Debatten. Die Gedanken die sich Mike Cohn hier macht umfassen vieles davon und gehen an einer wichtigen Stelle noch einen Schritt weiter - was sollte man tun wenn man merkt, dass ein Increment nicht "potentially releasable" sein wird? Sein Ratschlag: die Arbeit daran unterbrechen, bzw. beenden. Interessant ist auch was er nicht empfiehlt: den Sprint-Abbruch.
Ron Jeffries: XP revisited
Einmal mehr ein typischer Ron Jeffries-Text. Sehr lang, sehr gehaltvoll, sehr zu empfehlen. Im Mittelpunkt die Frage: wenn Extreme Programming heute neu erfunden, bzw. neu eingeführt werden würde - was wären seine Kernelemente?