Der Vertrag über agile Produktentwicklung
Zu den frustrierenden Erlebnissen die man im Rahmen agiler Projekte haben kann gehört die Vertragskeule. Das wäre ja alles schön und richtig mit Inspect, Adapt, Incremental und Iterativ heisst es häufig, der Vertrag wäre da aber leider sehr restriktiv. Was hierbei zu bedenken ist: derartige Situationen werden in der Regel nicht bewusst herbeigeführt sondern beruhen auf Unkenntnis der für agile Vorgehensweisen nötigen Vereinbarungen. Die in meiner Sicht wichtigsten Punkte für solche Vereinbarungen möchte ich im Folgenden zusammenfassen, basierend auf eigenen Erfahrungen und einigen Impulsen von Philipp Kühn (Verfasser des "agilen Teils" des Handbuchs der IT-Verträge).
Rollen
Vor allem dort wo es noch verbreitet klassische Aufbau- und Ablaufstrukturen gibt von zentraler Bedeutung. Dass der Scrum Master nicht der Projektleiter ist und man für eine gute Software-Architektur keinen Software-Architekten haben muss mag für den überzeugten Agilisten selbstverständlich sein, für den Vertragspartner ist es das ggf nicht. Das klar festzulegen kann verhindern, dass Konflikte und falsche Erwartungen überhaupt entstehen und unnötig Energie binden.
Abnahmen
Auch klare Vereinbarungen zur Art wie Abnahmen in einem agilen Arbeitsmodus ablaufen müssen können Missverständnisse vermeiden. Zum einen dürfen diese nicht mehr ganz am Ende erfolgen sondern kurzfristig, im gleichen Takt wie die Inbetriebnahmen (dazu gleich mehr), zum anderen muss klar werden, dass es sich bei ihnen nicht um den Abgleich mit Detailspezifikationen handelt sondern um Überprüfungen auf welche Weise ein abstrakt beschriebener Anwender-Mehrwert verwirklicht wurde.
Liefer- und Inbetriebnahme-Rhythmus
Ebenfalls ein klarer Bruch zu den klassischen Vorgehensweisen, auf den man sich klar festlegen sollte. Egal ob in Scrum und XP mindestens ein Release pro Iteration stattfindet oder ob ein Kanban-Team möglichst im Single Piece-Flow arbeitet und jedes neue Feature direkt auf Produktion bringt - allen Beteiligten muss von Anfang an klar sein, dass kurze Rhythmen zwingend nötiger Bestandteil von Agilität sind.
Mitwirkung
Passend zum letzten Punkt sollte auch geregelt werden in welchem Umfang und zu welchen Zeitpunkten wer verfügbar sein muss. Das betrifft zum einen die Mitglieder des Umsetzungsteams, die nach Möglichkeit in Vollzeit und dauerhaft verfügbar sein sollten, es betrifft aber auch die Vertreter von Kunden und Auftraggebern, die für die oben genannten Inbetriebnahmen, als Onsite Customer, als Berater oder für Abnahmen verfügbar sein müssen, und zwar regelmässig.
Vergütung
Nicht nur im Umfeld der Agilität ein zentrales Thema, hier aber besonders kompliziert, da sich der Arbeits- und Funktionsumfang nach Erkenntnisgewinnen ändern kann und soll. Im Agentur-Umfeld finden sich oft Festpreise für Sprintziele, in Festpreis-Grossprojekten kann man den Austausch von alten Arbeitspaketen gegen gleichgrosse neue ermöglichen. Möglichkeiten Time & Material-Verträge flexibler zu gestalten wären Preisschwellen für Mindestabnahmemengen oder Mengenrabatte.
Anpassung
Ein weiterer Bruch zu den üblichen Vorgehen. Vertragsänderungen sollten in einem agil arbeitenden Umfeld immer möglich sein. Der dafür passende Anlass wird sich zwar nicht im voraus regeln lassen, wohl aber, dass es grundsätzlich möglich ist, dass es jederzeit zur Diskussion gestellt werden kann und dass diese Diskussion dann auch geführt werden muss. Auch eine kurzfristige Verfügbarkeit der beteiligten Stellen (Recht, Einkauf, etc) kann vereinbart werden.
Mit diesen (und ggf. anderen) Punkten lassen sich Verträge so gestalten, dass sie besser zu den agilen Vorgehensmodellen passen als es bei klassisch gestalteten Unterlagen meistens der Fall ist. Was aber auch klar sein muss - in einem solchen Umfeld wird sich nie alles festlegen lassen, ab einem gewissen Punkt muss zwischen den Vertragsparteien ein Grundvertrauen bestehen. Das ist zwar nicht überall gegeben, andererseits ist dort wo es fehlt die Agilität auch nicht das Thema das als erstes angegangen werden sollte.