Kommentierte Links (XXXIX)
Einer der ursprünglichen Gründe für die Entwicklung agiler Frameworks sind die sich ständig ändernden Wünsche und Bedürfnisse der Kunden, bzw. der Nutzer. Nur um diesen zeitnah gerecht werden zu können wurden Sprints, Daily Standups, User Stories, etc. überhaupt erfunden. Das weitergedacht ist der folgerichtige nächste Schritt ein Service der sich ohne Entwicklungsaufwand selbst an die Kundenbedürfnisse anpassen kann, und das nicht einmal sondern immer wieder. Die in diesem Artikel beschriebenen personalisierten Streaming-Angebote sind ein solches Angebot und dürften damit das sein, was man als "agiles Produkt" bezeichnen könnte.
In der (in weiten Teilen humanistisch-esoterisch angehauchten) Agile-Community ist die Vorstellung weit verbreitet, dass agile Vorgehensweisen immer einen Bezug zur Menschenfreundlichkeit haben, da sie sowohl Nutzern als auch Mitarbeitern das Leben angenehmer machen. Steve Denning weist zurecht darauf hin, dass es sich bei ihnen lediglich um ein Werkzeug handelt, mit dem ungeachtet seiner Geisteshaltung jeder arbeiten kann. Die von ihm angeführte "agile Kampagne" von Donald Trump ist ein sehr greifbares Beispiel, aber bei weitem nicht das Einzige. Vermutlich ist diese Entwicklung der Preis dafür, dass Agilität in den Mainstream wandert.
"The shift in office space could have profound effects on productivity and the quality of work." Das ist das vorweggenommene Fazit
einer aktuellen Studie der britischen Royal Society, aus der die Washington Post zitiert. Zusammengefasst: Grossraumbüros sorgen für eine Fragmentierung, Verlangsamung und Verringerung von Kommunikation in und zwischen Teams, mit den erwartbaren Auswirkungen auf Produktivität und Qualität. Bemerkenswert ist die Studie vor allem wegen ihrer Methodik: in ihr wurden nicht nur die Schwankungen der schriftlichen Kommunikation (Mail, Chat, etc.) überprüft sondern mit Hilfe von Sensoren auch die Gesprächsfrequenz. Sie dürfte dadurch valider sein als viele andere.
Ein eher technisches Thema. Microservices gelten seit einigen Jahren als ein guter Softwarearchitektur-Ansatz für agile Teams oder Unternehmen. Trotz unbestreitbarer Vorteile sind sie aber auch mit Nachteilen verbunden, die Jürgen Lampe hier aufzählt, vom Ressourcenverbrauch über den Testaufwand bis hin zu einer Rückkehr (oder Entstehung) von organisatorischen Silos und Wissensinseln. Wie in vielen anderen Fällen sollte man sich auch bei Microservices fragen, ob die erwarteten Vorteile in einer vertretbaren Relation zu den damit verbundenen Kosten stehen.
Ein Versuch die agilen Transitionen wieder vom Kopf auf die Füsse zu stellen. Statt Rollen, Events und Lieferzeiträume einzuführen "weil das so im Lehrbuch steht" geht Ron Jeffries von der anderen Seite an die Thematik heran. Welche Strukturen sind nötig um in kurzen Abständen neue Funktionen auf Produktion zu bringen, wo sie von den Anwendern genutzt (oder durch Nichtbeachtung abgelehnt) werden können? Im Ergebnis ist es natürlich wieder agil, allerdings mit einem Focus darauf warum das Sinn macht und wo die Schwerpunkte liegen sollten.