Das agile.agreement - ein enzyklopädischer Eintrag

Das agile.agreement ist ein Framework zur Beschaffung komplexer Vorhaben im öffentliche Auftrag gem. Vergaberecht (insbesondere von agilen Softwareentwicklungsprojekten) und deren vertraglichen Regelung. Es wurde ursprünglich in der agilen Softwareentwicklung angewendet, ist aber davon unabhängig.

Komplexe Vorhaben gehören nach dem Cynefin-Framework in die Domäne «Complex», sprich Vorhaben bei denen zu Beginn noch nicht bekannt ist, wie die Lösung aussehen wird (zum Cynefin-Blog).

Für solche Vorhaben ist die Lösung emergent und kann nur inkrementell geplant werden [1]. Daher ist die Anwendung einer agilen Vorgehensweise wie bspw. Extreme Programming oder Scrum zur Umsetzung solcher Vorhaben von grossem Vorteil.

Die Beschaffung und vertragliche Regelung solcher agilen Vorhaben im Rahmen öffentlicher Aufträge stellt jedoch viele Organisation die dem öffentlichen Vergaberecht unterstehen vor eine Herausforderung. Insbesondere die geltende Gesetzgebung wird als hinderlich betrachtet.

Das agile.agreement bietet einen Lösungsansatz für die Beschaffung und vertragliche Regelung solcher agilen Vorgehen, im Rahmen der heutigen gesetzlichen Rahmenbedingungen und dass ohne die Werte und Vorteile der Agilität zu verlieren.

Das agile.agreement unterstützt den gesamten Beschaffungsprozess und sichert die Vertragsabwicklung in der Umsetzungsphase ab.

• Erarbeitung einer klaren Vision
• Analyse und Definition der Bedürfnisse für den Beschaffungsgegenstand als auch für die künftige gewünschte Partnerschaft mit dem Vertragspartner (Lieferanten).
• Testen, Verstehen und ggf. Anpassung der Vision und Bedürfnisse am Marktangebot, mögliche Vertragspartner mittels Marktanalyse bspw. Mittels einem Request for Information (RFI) identifizieren.
• Erstellung der Ausschreibungsunterlagen für die Beschaffung resp. den Request for Proposal (RFP)

• Gemäss dem Prinzip des agile.agreements «Kooperation vor Spezifikation» sucht man nicht die beste Lösung (bspw. Produkt), sondern den zu einem am besten passenden Vertragspartner (Lieferanten) mit den notwendigen Fähigkeiten. Entsprechend werden die Bewertungskriterien für die Evaluation danach ausgerichtet. Beim agile.agreement wird die Partnerschaft im Gegensatz zum vorgeschlagenen Lösungsansatz und dem Preis überdurchschnittlich gewichtet. Dem Kriterium Preis sollte gegenüber den anderen Zuschlagskriterien weniger Gewicht eingeräumt werden, je komplexer und anspruchsvoller die ausgeschriebene Leistung ist. Nach dem Bundesgericht gibt es eine unterste Grenze für die Mindestgewichtung des Preises von 20 Prozent [16].
• Die Evaluation resp. Beurteilung der potentiellen Vertragspartner erfolgt insbesondere mittels Workshops, Assessment-Centers und Proof of Concepts (POC) statt über die Beurteilung schriftlich eingereichter Unterlagen.
• Das agile.agreement unterstützt und regelt auch den Dialog zur Erarbeitung der Vertragsunterlagen für die künftige agile Zusammenarbeit.

• Nach dem Vertragsabschluss folgt die Umsetzungsphase, die gemäss den bestimmten Methoden und Prinzipien iterativ und interaktiv erfolgt.
• Das agile.agreement unterstützt das Vorhaben und sichert die vereinbarte agile Vertragsabwicklung.

Der Ursprung des agile.agreements liegt in der Umsetzung diverser Softwareprojekte. Bei der Einführung agiler Vorgehensweisen in diesen Projekten stiess man mit den klassischen Verträgen an Grenzen. Für agile IT-Projekte ist es nötig, einen Vertragsrahmen zu finden, der den Spagat zwischen festem Kostenrahmen (Maximalpreisrahmen) und agiler Entwicklung – zum Beispiel im Rahmen von Scrum - unterstützt [2].

Aus der Überzeugung, dass klassische Verträge die klassischen Ansätze der «Agilität» nicht unterstützen, entwickelte sich die erste Version des agilie.agreements [3].

Das ganze Framework des agile.agreements basiert auf dem Gedankengut der agilen Softwareentwicklung. 

Das Framework hat zur Vereinheitlichung verschiedene Begrifflichkeiten vom agilen Festpreis übernommen.

Das agile.agreement zeichnet sich durch zwei Kernprinzipien aus:

In der Ausschreibung einer Beschaffung mit dem agile.agremeent geht es darum, den zu einem am besten passenden Vertragspartner mit den notwendigen Fähigkeiten für das Vorhaben zu finden, und nicht die beste Lösung (bspw. Produkt). Schon allein der Begriff Partner signalisiert, dass hier mehr vorhanden ist, als nur die reine Betrachtung als Auftragnehmer und Auftraggeber [4].

Die wichtigsten Einflussfaktoren auf den Erfolg sind nicht technische Faktoren, sondern Offenheit, Vertrauen, Zusammenarbeit, Kommunikation, Entscheidungsfindung und Leadership [5]. Die Merkmale der Menschen sind ein Erfolgstreiber erster Ordnung, kein Treiber zweiter Ordnung [6]. Besonders agile Methoden fokussieren auf die face-to-face Zusammenarbeit zwischen Kunde und Entwickler um die Ziele zu erreichen [7]. 

Das agile.agreement stellt damit die Beschaffung der Kooperation in den Mittelpunkt (zum Blog). In agilen Projekten ist die Zusammenarbeit im Team (Kunde und Lieferant zusammen) von grösster Bedeutung [8][9][10]. Mit einem Partner, der dieselben Werte und Prinzipien hat, lässt es sich einfacher Vertrauen und Verlässlichkeit aufbauen.

Im Rahmen des Projekts wird die passende Lösung gemeinsam mit dem Lieferanten entwickelt. Die notwendige Abkehr von einer auf den Lieferantenwert fokussierten, zu einer beziehungsorientierten Beschaffungsstrategie lässt sich mit dem folgenden Statement zusammenfassen: «Not always the best supplier is also the best partner for every firm» [11].

Eine gute Zusammenarbeit im Team erhöht die Agilität des Teams - es kann schneller auf Veränderungen reagiert werden und es muss weniger im Voraus definiert werden [12].

Das agile.agreement folgt dem Grundsatz «Enough Design Upfront (EDUF)» (zum EDUF-Blog). Es lassen sich kaum je alle Anforderungen im Voraus definieren [15]. Deshalb muss akzeptiert werden, dass ein komplexer Beschaffungsgegenstand nicht vollumfänglich beschrieben und dann genau gemäss Beschrieb beschafft werden kann. Der künftige Lieferant muss zwingend am Prozess der Beschreibung beteiligt sein. Daher sollte im Voraus (vor der Beschaffung) nur eine «genügende» Beschreibung (Enough Design Upfront) des Beschaffungsgegenstandes vorliegen. In der Regel ist dies eine klare Vision, die Beschreibung der essentiellen Bedürfnisse und der unumstösslichen nichtfunktionale Anforderungen.

Die Herausforderung besteht darin, dass der Beschaffer nicht versucht ist alles im Voraus bis ins kleinste Detail zu beschreiben um sich vermeintlich ggü. dem Lieferanten abzusichern. Um die Agilität zu erhöhen, wird der Aufwand im Voraus reduziert, sodass alle Parteien gemeinsam früher in die Entwicklung einbezogen werden und Feedback geben können [12]. Die Beschreibungen und darauf folgenden Spezifikationen werden erst im Verlauf des Vorhabens entwickelt und präzisiert. Das komplette Gegenteil ist Big Design Upfront (BDUF).

Ein agiles Vorhaben wird im Optimalfall mit einem Vertrag geregelt der die Agilität fördert und fordert. Ein sogenannter agiler Vertrag kann fixe Kosten und einen fixen Termin haben, aber nie einen fixierten Umfang [5]. Ein agiler Vertrag ermöglicht es dem Kunden und dem Lieferanten zusammen effektiv zu arbeiten und das gewünschte Resultat für den Endnutzer zu schaffen [5].

Das agile.agreement unterstützt mit einem adäquaten Vertragswerk ein agiles Vorhaben, sodass die agilen Werte auch gelebt werden können und damit von den Vorteilen der Agilität vollumfänglich profitiert werden kann.

Damit diese Zusammenarbeit funktionieren kann, werden die gemeinsame Kooperation, das Vorgehen und die Rollen, der Umgang mit Komplexität und Ungewissem, sowie die kommerziellen Risiken abgesichert. Wie beim Agilen Festpreisvertrag ist das Projekt nicht durch einen vorgängigen Plan getrieben, sondern durch das Bestreben, das zu entwickeln, was Wert für den Auftraggeber darstellt oder im Sinne der Vision ist [2].

Das agile.agreement setzt dies mit dem Rules of Games Canvas von Thomas Molitor [13] vertraglich um. Das Rules of Games Canvas ist ein gutes Instrument um zu Beginn die wichtigsten Punkte gemeinsam mit dem Partner zu klären [14]. Durch das gemeinsame Besprechen und Festlegen der einzelnen Bestandteile; Kooperation, Vorgehen, Umgang mit Ungewissem, Komplexität und Absicherung der gegenseitigen kommerziellen Risiken entsteht Sicherheit und Vertrauen zwischen Lieferanten und Auftraggeber.

Der Vertrag bildet einen Kostenrahmen mit dem das Problem (resp. Beschaffungsgegenstand) gelöst werden kann. Dieser Rahmen muss mit den Kostenvorstellungen und Risikobereitschaft des Auftraggebers und des Lieferanten abgestimmt sein. Basis dieses Kostenrahmens bildet eine vom Lieferanten garantierte und über einen Risikofaktor (risk.share) abgesicherte Initialschätzung der Kosten für ein sogenannte Minimal Viable Product (MVP). Diese Schätzung wir als Kostendach oder Festpreis festgelegt und mittels dem scope.governance Prozess des agile.agreements sichergestellt.

Zusammen mit dem MVP werden gleichzeitig auch sogenannte Referenz-User Stories festgelegt und als verbindliche Referenz-Preise für künftige User Stories festgehalten. Damit erhalten auch künftige User Stories im weiteren Verlauf des Vorhabens einen verbindlichen Preis.

Der grosse Vorteil ist, dass das agile.agreement mit den öffentliche Auftrag gem. Vergaberecht umgehen kann. Insbesondere der wettbewerbliche Dialog (auch "Dialog" oder "Dialogverfahren") stellt sich als ideale gegenseitige Ergänzung heraus. Mit dem Dialog wird es für Organisationen die dem öffentlichen Vergaberecht unterstehen möglich, gesetzeskonform agile Vorhaben zu beschaffen und durchzuführen. Das Framework eignet sich aber auch für die Beschaffung und Vertragsabwicklung agile Vorhaben im privaten Sektor, sowohl auf Auftraggeber- wie Auftragnehmer-Seite.

Das agile.agreement setzt voraus, dass die involvierten Parteien ein agiles Vorgehen wünschen und beherrschen. Gegenseitiges Vertrauen wird vorausgesetzt. Auch der beste agile Vertrag kann dies nicht ersetzen.

Das agile.agreement eignet sich insbesondere für die Beschaffung und vertragliche Abwicklung komplexer Vorhaben, in der ein agiles Vorgehen angewendet werden soll. Für andere Vorhaben eignen sich andere Modell sicherlich besser.

Im Weiter ist das Framework für die werkvertragliche Abwicklung ausgerichtet, wo der Lieferant stark involviert wird und Verantwortung übernehmen kann.

Über EDUF: EDUF braucht Erfahrung. Eine zu starke Reduzierung des Vorabdesigns kann zu einer zufälligen Architektur führen, die die Fähigkeit des Teams zur Entwicklung von Funktionen nicht unterstützt und die Anforderungen nicht erfüllt [12].

1.  Jan Breitschuh, Albert Albers, Patrick Seyb, Sophie Hohler, Jonathan Benz, Nicolas Reiß and Nikola Bursac: Scaling agile practices on different time scopes for complex problem-solving. Hrsg.: NordDesign 2018. ISBN 978-91-7685-185-2, S. 3.
2. Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr: Der agile Festpreis - Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. Hrsg.: Carl Hanser Verlag München. Carl Hanser Verlag, München 2012, ISBN 978-3-446-43393-9, S. 43.
3. Thomas Molitor: Eine erfolgreiche Vereinbarung für agile Projekte – das agile.agreement. In: https://www.agileagreement.com. 5. August 2019, abgerufen am 23. September 2021 (deutsch).
4. Golinsky Falk: Konferenz Agile Verwaltung am 27. Februar 2020 in Ettlingen – Nachlese. In: https://agile-verwaltung.org. März 2020, abgerufen am 23. September 2021 (deutsch).
5. Peter B. Stevens: Ten Agile Contracts - A Practitioner's Guide to Creating the Right Contract. Hrsg.: Peter B. Stevens. First printing Auflage. Saat Network GmbH, November 2019
6. Dr. Alistair Cockburn: Characterizing people as non-linear 1st order components in software development (cockburn.us). In: https://ameyakarve.wordpress.com. 22. Juli 2012, abgerufen am 23. September 2021 (englisch).
7. F. Paetsch, A. Eberlein, F. Maurer: Requirements engineering and agile software development. In: WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003. IEEE Comput. Soc, Linz, Austria 2003, ISBN 978-0-7695-1963-0, S. 308–313, doi:10.1109/ENABL.2003.1231428 (ieee.org [abgerufen am 23. September 2021]).
8. A. Cockburn, J. Highsmith: Agile software development, the people factor. In: Computer. Band 34, Nr. 11, November 2001, S. 131–133, doi:10.1109/2.963450(ieee.org [abgerufen am 23. September 2021]).
9. B. Boehm, R. Turner: Using risk to balance agile and plan- driven methods. In: Computer. Band 36, Nr. 6, Juni 2003, ISSN 0018-9162, S. 57–66, doi:10.1109/MC.2003.1204376 (ieee.org [abgerufen am 23. September 2021]).
10. Elizabeth Whitworth, Robert Biddle: The Social Nature of Agile Teams. In: Agile 2007 (AGILE 2007). August 2007, S. 26–36, doi:10.1109/AGILE.2007.60(ieee.org [abgerufen am 23. September 2021]).
11. Holger Schiele, Jasper Veldman, Lisa Hüttinger: Supplier innovativeness and supplier pricing: the role of preferred customer status. In: International Journal of Innovation Management. Band 15, Nr. 01, 1. Februar 2011, ISSN 1363-9196, S. 1–27, doi:10.1142/S1363919611003064 (worldscientific.com [abgerufen am 23. September 2021]).
12. Michael Waterman, James Noble, George Allan: How Much Up-Front? A Grounded theory of Agile Architecture. In: 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering. IEEE, Florence, Italy 2015, ISBN 978-1-4799-1934-5, S. 347–357, doi:10.1109/ICSE.2015.54 (ieee.org [abgerufen am 23. September 2021]).
13. Thomas Molitor: agile.agreement Rules of Games Canvas. Februar 2020, abgerufen am 23. September 2021.
14. Marc Fischer: Agile Beschaffungsverträge. https://savient.ch, Juni 2019, abgerufen am 23. September 2021 (deutsch).
15. Wolfgang Straub, 2015, ‘Verträge für agil geführte Projekte’, Jusletter [Preprint]. 
16. Claudia Schneider Heusi: Vergaberecht - Die Revision. In: PBG aktuell 4/2021