In dieser Folge der Kolumne „Meditations on Agile“ geht Gerrit Beine dem Problem auf den Grund, dass das organisatorische Wachstum eines Unternehmens nicht automatisch mit einem Wachstum der Intelligenz einher geht, die im Unternehmen zum Tragen kommt.

Die Priorisierung des Backlogs ist eine zentrale Aufgabe für Product Owner. Gleichzeitig ist sie eine der schwierigsten Aufgaben. Viele Methoden konzentrieren sich auf strukturelle und inhaltliche Aspekte. Dieser Artikel möchte eine Methode zeigen, wie ökonomische Aspekte in Kombination mit Simulationen als Grundlage verwendet werden können.

In dieser Folge der Kolumne „Meditations on Agile“ rückt Gerrit Beine einem hartnäckigen Vorurteil aus dem Bereich des Change Management zu Leibe: Wer Veränderungen einführt, muss nicht zwangsläufig in Kauf nehmen, dass sich zunächst eine Verschlechterung der Lage einstellt!

Das erste der zwölf Prinzipien hinter dem agilen Manifest lautet: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen“. Während viele Teams Best Practices durch die frühe und kontinuierliche Auslieferung kennen und auch anwenden, ist die Bestimmung, was wertvolle Software ist, oft nicht so trivial.

Menschen wollen wissen, wo es langgeht. Deshalb basteln wir in Software-Projekten Roadmaps. Auch wenn die gar nichts mit dem Verlauf des Projektes zu tun haben.

Auch wenn verteilte Teams in der agilen Community als Anti-Pattern betrachtet werden, gehören sie doch in vielen Unternehmen zum Projektalltag. Der Autor liefert in diesem Artikel einige Ideen zum Aufbau solcher Teams, die aus seiner persönlichen Erfahrung heraus entstanden sind.

In dieser Folge der Kolumne „Meditations on Agile“ geht Gerrit Beine dem Dilemma nach, dass IT-Projekte mitunter zu einem Festpreis vereinbart werden – was sich mit einem agilen Vorgehen nicht so recht in Einklang bringen lässt.

Was wir von Steve Jobs‘ Gedanken zu Fahrrädern über Agilität lernen können – und warum Scrum kein Übergewicht ansetzt.

Die spektakuläre Pleite von Lehman Brothers ist nun sieben Jahre her. An der Frage, ob die Finanzwelt aus diesem Ereignis etwas gelernt hat, scheiden sich die Geister. Eine andere Frage, die mindestens ebenso spannend ist, wurde aber bislang gar nicht gestellt: Was hat die Softwareentwicklung aus der Pleite von Lehman Brothers gelernt? Eine Frage von zugegebenermaßen nicht geringer Größe, deren Antwort notwendigerweise umfangreich ausfallen muss. Als Informatiker möchte ich mich der Antwort mit einer weit verbreiteten Methode aus der Softwareentwicklung nähern: divide and conquer.

Aus der Perspektive von Agilität haben Unternehmen, die individuelle Software als Projekte realisieren, seit Jahren das falsche Geschäftsmodell. Das Kuriose dabei ist, dass dieses Geschäftsmodell als völlig normal empfunden und so gut wie nie hinterfragt wird. Dieses fehlende Hinterfragen ist ein wesentlicher Grund, warum es oft so schwer ist, in diesen Unternehmen Agilität einzuführen.

In Softwareprojekten kommt es immer wieder zu Ereignissen, die nicht vorhersehbar sind. Manchmal sind deren Auswirkungen so drastisch, dass sie dem Typ Ereignis entsprechen, das seit Nassim Nicholas Taleb als Schwarzer Schwan bezeichnet wird (siehe: Taleb, Nassim N.: „Der Schwarze Schwan“). Um solche Schwarzen Schwäne als Grundlage von Verbesserung zu nutzen, muss ein System eine besondere Eigenschaft haben: Es muss antifragil sein (siehe: Taleb, Nassim N.: „Antifragilität“). Erste Ideen, wie die Bereiche Softwarearchitektur und Projektmanagement von Antifragilität profitieren können, will dieser Artikel zeigen.