Kommentierte Links (CXXIII)
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.
Eine der klassischen Herausforderungen, an denen (nicht nur agile) Entwicklungsteams scheitern, ist die Erklärung von Refactoring für Menschen ohne IT-Hintergrund. Wer mal wieder in dieser Situation ist, kann sich an diesen Artikel von David Pereira halten. In ihm wird nicht nur das Konzept erklärt, sondern auch warum es wichtig ist, wie mayn es falsch machen kann, wie man es richtig machen kann, wann man es machen sollte und was typische Formen von Refactoring sind.
Auf die Gefahr hin, versehentlich in die Falle von Maslows Hammer zu laufen - man kann Objectives und Key Results (OKRs) eigentlich für so gut wie alles benutzen. Jeff Gothelf zeigt hier ein eher selten verwandtes Einsatzgebiet auf: die Verwendung von OKRs für agile Transitionen (oder wie er es nennt, organisatorische Agilität). Im Wesentlichen geht es dabei darum, Reaktions- und Durchlaufzeiten messbar zu verkürzen. Schlicht, aber wirkungsvoll.
Neben dem Durchfluss von zu erledigenden Aufgaben durch ein Verarbeitungssystem hat der Begriff Flow im Arbeitskontext eine zweite Bedeutung: den idealen Zustand, in dem eine Person oder ein Team werder überfordert noch unterfordert ist, und daher hochmotiviert und leistungsbereit. Erik de Bos differenziert das mit Hilfe des so genannten Flow Channel aus, in dem ein Team versuchen kann, dauerhaft zu bleiben, um optimale Ergebnisse erbringen zu können.
Dieser Blogpost hier ist durchaus erstaunlich, da sein Verfasser, Produktmanagement-Thought Leader Marty Cagan, über lange Zeit dafür bekannt war, öffentlich schlecht über agile Rollen und Frameworks zu sprechen. Irgendetwas scheint seine Meinung geändert zu haben, denn auf einmal findet er es nicht nur grundsätzlich ok wenn agil gearbeitet wird, er erkennt sogar an, dass Agile Coaches dazu einen wertvollen Beitrag leisten können - was er allerdings vor allem im Delivery-Bereich sieht.
Zugegeben, Sebastian Sigls Überschrift klingt auf den ersten Blick so, als würde als nächstes eine Plattitüden-Sammlung folgen. Tatsächlich ist seine Übersicht aber durchaus sinnvoll, denn er zählt nicht nur die vier Bereiche auf (Anpassungsfähigkeit, Zielsetzung, Psychologische Sicherheit und Feedback), sondern er zeigt auch Fehler auf die man vermeiden sollte, wenn man hier besser werden möchte - darunter auch einige unerwartete, wie z.B. ein zu grosses Vertrauen in Expertenwissen.
