Agile Antipatterns – Teil 1: Projektbudgetierung

Die gewünschten Vorteile der agilen Entwicklung sind vielfältig:

• Die Kunden sind zufriedener und damit kaufbereiter.
• Die Zeit von der Idee bis zur Lieferung an die Kunden ist kürzer.
• Die Mitarbeiter sind motivierter und leisten mehr.

Hört sich doch gut an, oder? In der Praxis stehen bestimmte Verhaltensweisen den genannten Vorteilen im Weg. Weil ich als Scrum Master und agiler Coach dieselben Muster in vielen Firmen immer wieder sehe, schreibe ich in dieser Artikelserie darüber.

Ich mache einen Vorschlag, wie Sie das Blatt dann doch zum Positiven wenden können. Probieren Sie’s mal aus und reflektieren über das Ergebnis im Team, um die Dinge an die Bedürfnisse Ihrer Organisation anzupassen.

Heute geht es um Projektbudgetierung und Verträge.

AAP1: Der Lieferumfang muss vorab festgelegt sein, damit es das Budget / den Auftrag gibt.

In vielen Firmen muss zuerst geklärt werden, was der Lieferumfang ist. Anschließend wird der Aufwand geschätzt und das nötige Budget berechnet. Dann gibt es eine Go- oder No-Go-Entscheidung.

Bei vielen Kunden-/Lieferantenbeziehungen ist es ähnlich. Erst muss ein Vertrag aufgesetzt werden, der beschreibt, was geliefert wird. Sonst gibt es keinen Auftrag.

Wie sollte es auch anders sein? Wie kann man als Kunde denn sonst sicher sein, was am Ende rauskommt?

Als Agilist antworte ich: Als Kunde kann man sowieso nicht vorab genau wissen, was am Ende herauskommt. Softwareentwicklung ist voller Überraschungen. Die Anforderungen von heute sind morgen schon Schnee von gestern.

Es ist wichtig, sich das Spannungsfeld von Vorhersagbarkeit und Änderbarkeit zu vergegenwärtigen. Man kann leider nicht beides haben: genaue Vorhersagbarkeit des Endergebnisses am Anfang, und maximale Berücksichtigung von Änderungswünschen später.

Das ist zum Scheitern verurteilt, getreu dem Motto: Wasch mir den Pelz, aber mach mich nicht nass.

So können Sie damit umgehen:

Der Vertragsinhalt

Im Idealfall wird in Verträgen bzw. in der Projektbudgetierung nur grob der Rahmen abgesteckt. Es wird eine Produktvision vereinbart, und vielleicht noch eine grobe Roadmap.

Was aber, wenn das in Ihrer Firma nicht möglich ist? Wenn die Stakeholder die Vorabklärung der Anforderungen nicht aufgeben wollen?

Dem ist entgegenzuhalten, dass es Zeitverschwendung ist, viel Zeit in die Detaillierung von Anforderungen zu stecken, die sich später sowieso ändern.

Was also tun?

Die Anforderungen sollten nicht bis ins letzte Detail vorab geklärt werden. Das lohnt sich einfach nicht, und schränkt den Implementierungsspielraum zu sehr ein.

Eine sinnvolle Vorabklärung kann zum Beispiel auf User-Story-Ebene stattfinden, aber ohne die Akzeptanzkriterien vorwegzunehmen. Man verschiebt die Klärung der Details also in die Entwicklung, kurz vor die Umsetzung. Der Vorteil ist, dass die bisherigen Erkenntnisse aus der Entwicklung dann einfließen können.

Change Management richtig gemacht

Schon zu Beginn des Projekts bzw. während der Vertragsverhandlung sollte der Modus der Zusammenarbeit und der Umgang mit Änderungen vereinbart werden.

Dabei ist es wichtig, einige Prinzipien zu beachten.

Wenn es Änderungen gibt, reicht ein Change-Management-Prozess, der jede Änderung einzeln bewertet, NICHT. Stattdessen sollten die Änderungen in Relation zu anderen Änderungen gestellt werden.

Es gilt die Regel: für jede Änderung, die tatsächlich umgesetzt wird, muss entweder

• eine andere Anforderung/Änderung aus dem Lieferumfang genommen werden, oder
• die Laufzeit des Projekts muss erhöht werden.

Während der Entwicklung können somit einzelne Elemente durch vom Aufwand gleichwertige Elemente ersetzt werden. Scrum bietet dafür mit dem Product Backlog eine gute Möglichkeit: durch das vorrangige Umsetzen eines Backlogelements bekommen die anderen Elemente automatisch eine geringere Dringlichkeit.

Wenn Sie mehr über das Thema und insbesondere agile Vertragsgestaltung wissen wollen, empfehle ich Ihnen, sich z.B. mit der agilen Vertragsart Money for Nothing and Your Change for Free auseinanderzusetzen.