Kommentierte Links (LXII)

Bild: Unsplash / Dayne Topkin - Lizenz

• Cal Newport: Why Remote Work Is So Hard - and How It Can Be Fixed

Ein Longread aus dem New Yorker für den man sich Zeit nehmen sollte. Basierend auf zahlreichen Quellen und verwoben mit Exkursen in die Technologie- und Wirtschaftsgeschichte breitet Cal Newport ein differenziertes Bild der Heimarbeit aus. Was ihre Vorläufer waren, wie sie entstanden ist, wie sie zurückgedrängt wurde und wie sie durch die Corona-Pandemie einen erneuten Schub erhalten hat wird hier nacherzählt, es geht aber auch um das grosse Dilemma das diese Arbeitsform schon immer umgibt: sie gibt den Angestellten (unter gewissen Voraussetzungen) eine bessere Work Life-Balance, führt aber auch zu einem spürbaren Rückgang von Effektivität, Effizienz und sozialem Zusammenhalt. Interessant ist dabei vor allem eine These: Newport ist der Überzeugung, dass der agil arbeitende Teil der Software-Industrie der einzige Sektor der Wirtschaft ist, der es geschafft hat die negativen Aspekte der Heimarbeit spürbar abzuschwächen. Dass trotzdem auch andere Branchen darüber nachdenken ihre Mitarbeiter dauerhaft zu Hause arbeiten zu lassen hat einen Grund der im New Yorker zu kurz etwas kommt, dafür aber von der New York Times und Vanity Fair aufgegriffen wird: viele Büros sind heute arbeitsfeindliche Umgebungen. Nochmal eine Geschichte für sich.

• Matt Philip: NoEstimates, Applied

  Es kann natürlich täuschen und der individuellen Filterblase geschuldet sein, gefühlt ist es aber in den letzten Jahren um das Thema NoEstimates ruhiger geworden (vielleicht wegen des aus Marketing-Gesichtspunkten eher unglücklich gewählten Namens?). Dass die dahinterstehende Bewegung noch immer da ist zeigt dieser Beitrag von Matt Phillip, in dem er erklärt wie er sich mit diesem Ansatz an einer grösseren Ausschreibung beteiligen würde. Wer sich mit dem Thema bereits näher beschäftigt hat wird seinen Ausführungen nur zustimmen können, wer grosse Organisationen kennt wird aber auch wissen, dass er es sehr schwer haben dürfte mit diesem Vorgehen erfolgreich zu sein. Es wäre sicher hochgradig spannend einen solchen "Sales Pitch" einmal mitzuerleben.

• Roman Pichler: Six Types of “Product” Owners

  Wer die Arbeit von Roman Pichler verfolgt wird wissen, dass er schon seit längerem versucht die Rollen im Produktmanagement auszudifferenzieren. In der Vergangenheit führte das unter anderem zur Gegenüberstellung von Product Manager und Product Owner und zur Entwicklung des Balanced Product Leaders, mit diesem Artikel kommt die Aufschlüsselung des Product Owners auf die sechs Typen Scrum Product Owner, Feature Owner, Component Owner, Platform Owner, SAFe Product Owner und Portfolio Owner dazu. Für jeden der eine PO-Rolle innehat sollte es interessant sein sein Stellenprofil mit diesen Typen abzugleichen. Was ebenfalls kurz angesprochen wird ist die Auswirkung des Scrum-Schismas auf die Product Owner-Rolle, hier besonders durch die stark voneinander abweichende Ausgestaltung im klassischen Scrum und in SAFe.
  

• Willem-Jan Ageling: SAFe Scrum Master vs ‘Scrum’ Scrum Master

  Apropos Scrum-Schisma zwischen klassischen Scrum und SAFe - auch Willem-Jan Ageling nimmt sich dieses Themas an, allerdings mit Focus auf der anderen herausragenden Rolle, dem Scrum Master. Ähnlich wie Pichler arbeitet auch er heraus, dass die beiden Ausprägungen sich zwar auf den ersten Blick ähneln mögen, sich bei genauerer Betrachtung aber deutlich unterscheiden. Was den grossen Unterschied zur PO-Rolle ausmacht ist, dass der Scrum Master in viel intensiverer Weise in der namensgebenden Methodik verankert ist. Da diese aber in SAFe je nach Sichtweise abgeschwächt oder optional ist kann es zur paradoxen Situation kommen, dass ein nicht nach Scrum arbeitendes Team einen Scrum Master hat. Dass das sogar eine offiziell mögliche Variante ist zeigt, wie weitreichend die Veränderungen sind die hier vorgenommen wurden. [Nachtrag 02.06.: Es gibt eine Erwiderung von Paddy Corry]
  

• Todd Lankford: If Your Scrum Is Not Fun, You Are Doing It Wrong

  Eine Wahrheit die man gar nicht oft genug aussprechen kann. (Richtig umgesetztes) Scrum liefert Entwicklungsteams Vieles was sie sich schon immer gewünscht haben: die Möglichkeit unrealistische Arbeitslasten abzuwehren, einen unmittelbaren Wertschöpfungsbeitrag, Kontakt und Austausch mit dem Anwender, die Erlaubnis systemische Dysfuntionen der Organisation anzusprechen und zu beheben, und das auch noch in einer ansprechenden Verpackung. Fast immer führt das dazu, dass die Freude an der Arbeit spürbar steigt. Der Zusammenhang ist sogar so offensichtlich, dass man Todd Lankfords Aussage wörtlich nehmen kann - wenn die Arbeit mit Scrum keinen Spass macht ist das Framework mit zimlicher Sicherheit falsch implementiert worden.