Lange habe ich mich gegen Deadlines in der agilen Softwareentwicklung ausgesprochen, da sie meiner Meinung nach unnötigen Druck und Stress in den Teams verursachen. Von einigen Ausnahmen, wie z.B. einer gesetzlichen Vorgabe mit festem Zeitpunkt, abgesehen, erscheinen die meisten Deadlines als künstlich und willkürlich festgelegt. Warum also sollte sich ein Team unter Umständen ausbrennen und bis zur Erschöpfung arbeiten, nur um ein imaginäres Ziel zu erreichen?

In der agilen Softwareentwicklung geht es unter anderem darum in einer kontinuierlichen, haltbaren Geschwindigkeit Mehrwert zu liefern, also sich explizit nicht so zu verausgaben (z.B. durch Überstunden oder technische Schulden), dass ein Team Probleme hat, in Zukunft zu liefern oder lange braucht um sich wieder zu erholen. Das waren bisher meine Gedanken zum Thema Deadlines.

In den letzten Jahren hat sich meine Perspektive geändert: Deadlines können einem Team helfen.

Die große Gefahr, wenn keine Deadline und keine klare Erwartungshaltung von außen existiert, ist, dass kritische Fragen nicht gestellt und harte Entscheidungen immer weiter hinausgeschoben werden. Die dringend notwendige Priorisierung und das Abschneiden unnötiger Sonderlocken passiert nicht. Es gibt keinen Grund zur Fokussierung, da der Rahmen beliebig groß ist oder zumindest als solcher wahrgenommen wird.

Deadlines zwingen Teams kritische Fragen zu stellen und harte Entscheidungen zu treffen.

Das Prinzip “Fixed Time, Flexible Scope” zielt genau darauf ab. Projekte werden innerhalb eines festgelegten Zeitrahmens abgeschlossen, während der Funktionsumfang (Scope) flexibel bleibt. Das Team ist dafür verantwortlich, die Priorisierung und die tatsächlichen Funktionen und Features kontinuierlich anzupassen, um den maximalen Wert innerhalb des vorgegebenen Zeitfensters zu liefern.

Indem man die Zeit konstant hält und den Umfang anpasst, kann das Team sich auf die wichtigsten Funktionen konzentrieren und so besseren Mehrwert für den Kunden bieten, während das Risiko sich zu verkünsteln drastisch reduziert wird.

Soweit die Theorie. Das funktioniert natürlich nur, wenn das Team den entsprechenden Freiraum hat, diese Entscheidungen zu treffen und in der Lage ist sich selbst zu managen und harte Grenzen zu ziehen. Wenn das Team diesen Freiraum und diese Fähigkeiten nicht mitbringt, besteht tatsächlich das Risiko auszubrennen. Viele Teams haben an dieser Stelle viel Arbeit vor sich, um zum einen die notwendigen Fähigkeiten im Team zu entwickeln und zum anderen das Vertrauen der Stakeholder aufzubauen (mehr dazu gibt es in einem der nächsten Artikel).

Gibt es andersherum diesen festen Rahmen nicht, gilt Parkinsons Gesetz: „Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.“

Live Webinar: Softwareentwicklung skalieren, ohne sich im Wachstumsprozess aufzureiben

„Im Webinar wurden genau die Pain Points angesprochen, die in unserem Wachstum gerade auftreten. Bei stetig steigender Zahl an Mitarbeitern im Dev & Product Team mussten wir selbst feststellen, wie schwierig es ist, eine sinnvolle Struktur aufzubauen, die bei jedem das Maximum an Effizienz und Leistung hervorbringt und gleichzeitig zu einer gesunden Arbeitsatmosphäre führt.”
Pascal von Briel, Co-Founder & CPO @ exporto GmbH