Kommentierte Links (V)
Ein etwas in die Irre führender Titel. Tatsächlich geht es in diesem Text darum, dass die Rollen des Product Owners und der Teammitglieder verschwimmen (können). Der Product Owner, der in dieser Konstellation zu einer neuen Rolle namens Product Champion wird, gibt nur noch die grobe Richtung vor (ich als Kunde möchte meine Daten verwalten können). Alles weitere erarbeitet und entscheidet das Team selbst, wodurch es sich das Produkt "selbst aneignet" - daher auch kein Product Owner mehr. Das klingt für mich zwar durchaus so wie Scrum im Idealfall sein sollte, zumindest in Großunternehmen oder Großprojekten bin ich aber nicht sicher ob das so einfach machbar sein wird. Zum einen besteht hier die Gefahr, dass das Team zu sehr in politische Strukturen hineingezogen wird, zum anderen würde dem Management die "Telefonnummer" fehlen, bei der es schnelle Informationen bekommen kann.
Ritika Puri macht sich hier sehr gute Gedanken darüber, wie agile Großvorhaben organisiert werden können. Entweder durch das Aufsetzen einer übergeordneten Hierarchie oberhalb der Entwicklungsteams - das passt besser in bestehende (Konzern)Strukturen und erleichtert es dem Management (scheinbar) die Übersicht zu behalten, ist aber schwerfällig und verlangsamt alles. Oder man versucht auch das agil zu machen, wobei aber einige Voraussetzungen nötig sind: Professionelle Tools, Clean Code, horizontale Kommunikation zwischen den Teams und schnelles Feedback, das von den Kunden direkt zu den Teams durchgeht. Dass der zweite Ansatz der bessere ist klingt erstmal nachvollziehbar, wohl aber in erster Linie für Menschen wie mich. Einige der Manager die ich kenne, sehen das durchaus anders. Sie zu überzeugen ist dann ein wesentlicher Teil meines Jobs.
Ausgangspunkt dieses Beitrags ist ein grundlegendes Problem vieler IT-Projekte: Änderungen am Code werden "nebenbei" durchgeführt. Nicht auf Grundlage einer Story und auch nicht auf Grundlage eines Bug- oder Defect-Tickets sondern weil ein oder mehrere Entwickler einen Teil ihrer Zeit nutzen um bestehende Features zu "optimieren". Um diesen Aufwand nicht vorher vom PO oder dem Projektleiter genehmigen oder nachher vor ihm rechtfertigen zu müssen werden diese gar nicht erst benachrichtigt. Da es das beabsichtigte Ergebnis ist, dass sich die Anwendung nachher genau so verhält wie vorher und lediglich schneller oder besser wartbar ist, kommt man mit diesem Verhalten häufig unbemerkt durch. Eine Analysemethode wie die hier von Elmar Jürgens vorgestellte würde helfen derartige heimliche Änderungen aufzudecken und dadurch wichtige Informationen in gleich zwei Dimensionen liefern: man entdeckt geänderten aber ungetesteten Code und man entdeckt welchen Entwickler man zukünftig um mehr Transparenz seiner Ergebnisse bitten muss.
Ein Text von Manas Fuloria mit schönen Beispielen und Begründungen dafür, warum Unternehmen als ganze (und nicht bloß ihre IT) heute agil sein sollten. Bereits das erste Fallbeispiel, die unterschiedliche Entwicklung der Mode-Ketten GAP und Zara macht das deutlich: während GAP versuchte durch langfristige Planungen die Trends der nächsten Saison vorauszusagen und die Produktion frühzeitig darauf einzustellen, perfektionierte Zara eine möglichst schnelle Reaktion auf neue Trends, die so in kürzester Zeit in das eigene Sortiment integriert werden konnten. So konnte das ursprünglich kleinere Unternehmen den größeren Konkurrenten GAP überholen.
Volker Zastrow: Deutschland schafft sich ab [Edit: Link ist mittlerweile tot]
Der erste Reflex: Wenn die FAZ schon in der Überschrift schreibt, dass Deutschland sich abschafft, dann ist der Artikel vermutlich voller weinerlichem Kulturpessimmismus. Weit gefehlt - was Volker Zastrow hier beschreibt ist eher die
kreative Zerstörung auf gesellschaftlicher Ebene. Und er lehnt sie nicht etwa ab, sondern er empfiehlt sich ihr durch ein agiles Vorgehen anzupassen - durch Inspect and Adapt, oder wie er es nennt
"Versuch und Irrtum, Versuch und Erfolg". Das man derartiges mal in dieser Zeitung lesen würde ...
