Bei der Entwicklung komplexer Leistungen mit sich ständig ändernden Anforderungen wird in der Industrie standardmäßig agil vorgegangen. Auch öffentliche Auftraggeber sind zunehmend an diesem Modell zur Beschaffung von Leistungen interessiert, z.B. zur Beschaffung einer individuell zugeschnittenen Verwaltungssoftware oder aber einer neuen komplexen Homepage. Es fehlen jedoch Vorlagen für Bewerbungsbedingungen, Verträge sowie Eignungs- und Zuschlagskriterien, die eine agile Vorgehensweise berücksichtigen; es fehlen somit sog. „best practices“. Unser Autor Dr. Roderic Ortner, ein ausgewiesener Experte für IT-Beschaffungen, hat sich auf dieses im Vergaberecht neue Terrain begeben und auch schon entsprechende Ausschreibungen begleitet. In seinem Beitrag gibt er am Beispiel der Vergabe eines agilen Softwareentwicklungsvertrages einen Überblick über die Pflöcke, die im Vergabeverfahren einzuschlagen sind, dabei beschränkt er sich auf das Modell Scrum¹.

I.  Die Vorgehensweisen

Bei der Vergabe anspruchsvoller und komplexer Softwareentwicklungsleistungen stehen die öffentlichen Auftraggeber häufig vor dem Problem, dass die Leistungsbeschreibung, an der sie oft Monate lang gearbeitet haben – meist unterstützt durch kostenintensive externe Hilfe – im Zeitpunkt der Vergabe bereits in Teilen überholt ist, entweder, da sich die Technik weiterentwickelt hat (oder nicht mehr „supportet“ wird), oder da die Fachbereiche (Bedarfsträger) beim Auftraggeber zwischenzeitlich dem Einkauf (Vergabestelle) andere oder neue Anforderungen und Wünsche angetragen haben. Häufig wird dann auch erst bei der Auswertung der Angebote festgestellt, dass die Lösungen nicht (mehr) passen. Es kann auch passieren, dass erst nach der Programmierung und Implementierung der Software festgestellt wird, dass die nun abzunehmende Lösung an den Vorstellungen, die man heute hat, vorbeigeht. Änderungen sind dann oft gar nicht oder nur schwer möglich, da sie häufig die Struktur der Softwarelösung als solche betreffen und kostenpflichtige Nachträge nach sich ziehen („change requests“). Alle Nachträge sind bekanntlich wiederum auf den vergaberechtlichen Prüfstand gemäß § 132 GWB zu stellen.

1. Das sog. Wasserfallmodell

Die arbeitsreiche Erstellung einer Leistungsbeschreibung, die dann in den Markt gegeben wird und in toto umzusetzen ist, nennt man auch „Wasserfallmodell“. Im Bereich der Softwareentwicklung handelt es sich dabei um einen Werkvertrag, da die erstellte Software das abzunehmende Werk darstellt. Greift man als öffentlicher Auftraggeber auf einen EVB-IT Vertrag zurück, bietet sich hierzu der EVB-IT Erstellungsvertrag an.

2. Das sog. agile Vorgehensmodell

Die Nachteile, die das Wasserfallmodell mit sich bringen können hat vor über zehn Jahren dazu geführt, dass andere Modelle entwickelt wurden, bei denen der Auftragnehmer die Software für den Kunden nicht en bloc auf Grund einer eindeutig und erschöpfenden Leistungsbeschreibung programmiert und dann das Ergebnis abliefert, sondern in regelmäßigen Treffen mit dem Auftraggeber die im Vorfeld nur funktional beschriebenen Anforderungen nach und nach konkretisiert, einzeln umsetzt und in weiteren Treffen präsentiert; es wird also „agil“ vorgegangen. Das agile Modell hat sich (belegbar) in der Praxis als das erfolgreichere herausgestellt. Die Projektabbruchquote ist deutlich geringer als beim Wasserfallmodell. Ein agiles Vorgehen nach Scrum funktioniert aber nur, wenn es auf Seiten des Auftraggebers (des Kunden) einen verantwortlichen „Kümmerer“ gibt, der sich Vollzeit mit dem Projekt befasst und über die erforderlichen Befugnisse verfügt. Beide Modelle – Wasserfall und agil – haben freilich Vor- und Nachteile, die hier im Einzelnen nicht dargestellt werden können.

Praxistipp: Vor jeder Softwareentwicklung sollte der öffentliche Auftraggeber prüfen, welches Modell im Einzelfall für ihn das bessere ist, und ob das gewählte Modell auch im Hinblick auf die personellen Ressourcen umsetzbar ist.

Hier wird davon ausgegangen, dass der Auftraggeber die Vor- und Nachteile abgewogen hat und sich für das agile Modell entscheidet.

II. Vergaberecht und Scrum

Scrum ist das wohl bekannteste agile Modell. Die agile Vorgehensweise geschieht aber immer erst nach der Beauftragung, d.h. nach der Bezuschlagung. Das Scrum-Modell muss sich also in den Vergabeunterlagen, insbesondere im Softwareentwicklungsvertrag widerspiegeln. Hier beginnen die Schwierigkeiten in der Praxis, da es keine Vorlagen gibt, welche die Besonderheit des Auftraggebers als eine öffentliche staatliche Einrichtung berücksichtigt. Das V-Modell XT Bund Vers. 2.0 lässt eine inkrementelle Entwicklung zwar ausdrücklich zu, schweigt aber zur vergaberechtlichen Herangehensweise. Der EVB-IT Erstellungsvertrag kann zwar theoretisch als Grundlage für einen agilen Vertrag genutzt werden, er ist aber auf das Wasserfallmodell ausgerichtet, so dass man ihn sehr stark durch Änderungen im Text und durch Anlagen verbiegen müsste. Es droht, dass der Vertrag insgesamt intransparent wird und Widersprüchen in den Vergabeunterlagen entstehen. Daher ist ein Individualvertrag zu empfehlen, den die EVB-IT Nutzerhinweise für einen solchen Fall auch zulassen.

Praxistipp: Bei der Vergabe eines agilen Softwareentwicklungsvertrages passt kein EVB-IT Vertrag, so dass ein Individualvertrag zulässig und zu empfehlen ist.

Da im vergaberechtlichen Jargon die Vertragsbedingungen neben der Leistungsbeschreibung Bestandteile der Vertragsunterlagen sind, ist der agile Softwareentwicklungsvertrag vom öffentlichen Auftraggeber bereitzustellen. Der Umstand, einen solchen Vertrag zu vergeben führt außerdem dazu, dass auch an anderen Stellschrauben der Vergabeunterlagen zu drehen ist. Hierauf wird nachfolgend näher eingegangen.

1. Eignungskriterien

Die Eignungskriterien sind vom Gesetz bereits weitestgehend vorgegeben. Im Bereich der VgV bedeutet dies etwa, dass sich der Auftraggeber hinsichtlich möglicher Belege der technischen und beruflichen Leistungsfähigkeit an den abschließenden Katalog des § 46 Abs. 3 halten muss. Hinsichtlich der Nachweisführung durch Referenzen bietet es sich an, neben Referenzen zum Gegenstand der Ausschreibung auch Referenzen abzufragen, die belegen, dass der Bewerber in anderen Projekten bereits Erfahrungen im Bereich Scrum gesammelt hat. Darüber hinaus liegt es nahe, die weiteren bei IT-Vergaben üblichen Kriterien abzufragen, etwa die Beschreibung der Maßnahmen zur Qualitätssicherung im Unternehmen.

2. Zuschlagskriterien

a. Leistungskriterien

Bei Scrum besteht das Scrum Team aus dem Product Owner, dem Entwicklungsteam und dem Scrum Master. Aufgrund seiner Funktion ist der Product Owner in der Regel im Lager des öffentlichen Auftraggebers, während die anderen Teammitglieder vom Auftragnehmer gestellt werden. Als Zuschlagskriterium bietet es sich daher an, gemäß § 58 Abs. 2 Satz 1 Nr. 2 VgV „die Organisation, Qualifikation und Erfahrung“ des einzusetzenden Teams als Zuschlagskriterium festzulegen. Dass das Team „erheblichen Einfluss auf das Niveau der Auftragsausführung“ hat, wie im Gesetz verlangt, dürfte außer Frage stehen.

Als weiteres Zuschlagskriterium könnte man auch ein Umsetzungskonzept o.ä. einfordern, in welchem der Bewerber oder zu einem späteren Zeitpunkt im Vergabeverfahren der Bieter erläutert, wie er mit seinem Team und den vorhandenen Softwaretools, gemessen an den (funktionalen) Anforderungen des Auftraggebers und unter Berücksichtigung von Scrum, die Leistung zu erbringen gedenkt. Nach den Entscheidungen des EuGH vom 14.07.2016, Rs. C-6/15 – Dimarso und BGH vom 04.04.2017, X ZB 3/17 dürfte unbestritten sein, dass der öffentliche Auftraggeber nicht (mehr) verpflichtet ist, den potenziellen Bietern in den Vergabeunterlagen die Bewertungsmethode zur Kenntnis zu bringen, anhand derer er eine konkrete Bewertung der Angebote hinsichtlich der zuvor festgelegten Zuschlagskriterien und ihrer Gewichtung vornimmt und eine Rangfolge für sie erstellt.

b. Angebotspreis

Bzgl. des Preises widerspricht es zunächst einem agilen Vorgehensmodell, dass sich der Auftraggeber für die Gesamtleistung einen Fixpreis anbieten lässt. Dies ist der Unterschied zum Wasserfallmodell, wobei in der Realität auch beim Wasserfallmodell der Auftraggeber häufig mehr zahlt, da die Leistungsbeschreibung im Projektverlauf ständig auf Geheiß des Auftraggebers geändert wird oder weil die Leistungsbeschreibung von Beginn an unvollständig war und damit zahlreiche change requests einhergegangen sind.

Bei der agilen Vorgehensweise zahlt der Auftraggeber für Story Points, wobei ein Story Point einem festen Betrag in EUR entspricht.

Beispiel: In einem Sprint Planning konkretisiert das Scrum Team die Anwendung (User Story) „Personalakte anlegen“, so werden z.B. sämtliche Formularfelder festgelegt, die erforderlichen Schnittstellen, Darstellungsformen, Dateiformate, etc. Es wird festgelegt, dass die Umsetzung der Funktionalität gemessen an Umfang und Komplexität 6 Story Points ausmacht. Angenommen, der Auftragnehmer hat einen Story Point für 1.300 EUR angeboten, entspricht der Preis für die Funktionalität 7.800 EUR.

Praxistipp: Es bietet sich im Vergabeverfahren zum Preisvergleich der Angebote an, bereits mehrere im Detail beschriebene User Stories als Referenzstories zu beschreiben. Die Bieter haben dann Story Points zu vergeben, die wiederum während des Vergabeverfahrens in einem Workshop besprochen und ggf. noch angepasst werden. Im Wettbewerb verglichen wird dann jeweils die Höhe der Story Points, die ein Bieter für sämtliche Referenzstories vergibt multipliziert mit dem angebotenen Einheitspreis je Story Point.

Die Story Points können bei unterschiedlichen Bietern durchaus unterschiedlich ausfallen, da jeder Bieter auch unterschiedliche Entwickler und Softwaretools einsetzt, so dass dem einen Bieter die Umsetzung leichter fallen kann als dem anderen. Auch die Geschwindigkeit (Velocity) kann differieren, so dass sich diese als weiteres Zuschlagskriterium anbietet.

Freilich bleibt auch hier in der Vertragsausübung die Ungewissheit, wie die weiteren User Stories im Hinblick auf Umfang (Story Points) und die dadurch entstehenden Kosten (Story Points x Einheitspreis) eingeordnet werden, so dass dem öffentlichen Auftraggeber zu empfehlen ist, mit einem sog. agilen Festpreis zu arbeiten, d.h. es wird eine Budgetobergrenze festgelegt, wodurch das Scrum Modell in seiner Urform durchbrochen wird.

Als weiteres Zuschlagskriterium beim Preis könnte nun neben dem Angebotspreis pro Story Point die Angabe eines Rabatts gefordert werden, den der Auftragnehmer bei Überschreitung der Budgetobergrenze auf alle bislang bezahlten und zukünftigen Leistungen bezahlt.

Weiterhin wird der Auftragnehmer in der Regel auch die Pflege der Software übernehmen, so dass sich als weiteres Preiskriterium die Angabe des monatlichen Pflegesatzes anbietet; auch eine Orientierung an den Story Points ist denkbar, so dass der Pflegesatz variabel ist.

Es gibt auch noch weitere denkbare Möglichkeiten, den Preis bei agilen Vorgehen im Vergabeverfahren als Zuschlagskriterium festzulegen, jedenfalls ist dies kein Gesichtspunkt, der dem öffentlichen Auftraggeber aus vergabe- oder haushaltsrechtlicher Sicht den Weg in eine agile Vorgehensweise versperrt. Im Gegenteil dürfte bei einem agilen Vorgehen, weil der Auftraggeber stets eingebunden ist, dem Steuerzahler am Ende mehr gedient sein als bei einem abgebrochenen oder durch zahlreiche Nachträge aufgepumpten Wasserfall-Projekt.

3. Verfahrensart und Bewerbungsbedingungen

Ein agiler Softwareentwicklungsvertrag kann sinnvollerweise nur im Verhandlungsverfahren ausgeschrieben werden, wobei gleich mehrere der hierfür erforderlichen Voraussetzungen des § 14 Abs. 3 VgV vorliegen dürften. Ein Vorbehalt des Auftraggebers, auf das Erstangebot bereits den Auftrag zu vergeben, vgl. § 17 Abs. 11 VgV, dürfte in der Regel unzweckmäßig sein, da sich gerade bei der agilen Vorgehensweise ein Workshop wie oben beschrieben anbietet, um ein weiteres Preiskriterium festlegen zu können.

In den Bewerbungsbedingungen ist das phasenweise Vorgehen des Auftraggebers möglichst transparent zu beschreiben, wobei im Hinblick auf die Zuschlagskriterien die Unterkriterien und deren Gewichtung wiederum auch noch im Laufe des Verfahrens konkretisiert werden dürfen. Nur die Zuschlagskriterien selbst (auf oberer Ebene) sowie die Mindestanforderungen müssen unverändert bleiben. Auch hier existieren bislang kaum Blaupausen für öffentliche Auftraggeber, geschweige denn in Bezug auf Scrum.

4. Arbeitnehmerüberlassungsgesetz (AÜG)

Da sich bei Scrum typischerweise Personal des Auftragnehmers regelmäßig beim Auftraggeber aufhält (Sprint Planning, daily oder weekly Scrum, Sprint Review), stellt sich automatisch die Frage der Arbeitnehmerüberlassung. Ob eine solche vorliegt bemisst sich an unterschiedlichen Kriterien und ist stets einzelfallabhängig. Der agile Softwareentwicklungsvertrag ist ein Werkvertrag, dies folgt bereits daraus, dass die einzelnen umzusetzenden User Stories jeweils der Teilabnahme unterfallen und der Auftragnehmer solange an der Umsetzung zu arbeiten hat, bis die festgelegten Abnahmekriterien erfüllt sind (vgl. LG Wiesbaden, Urt. v. 30.11.2016, 11 O 10/15). Dies spricht bereits deutlich gegen eine Arbeitnehmerüberlassung. Um das Risiko einer verdeckten Arbeitnehmerüberlassung zu verringern, sollten neben den üblichen Aspekten der fehlenden Eingliederung in den Betrieb des Auftraggebers (kein eigenes Büro, keine eigene E-Mail, etc.) vor allem Weisungsbefugnisse des Auftraggebers möglichst auf das erforderliche Maß beschränkt werden. Der Scrum Master könnte während der Ausführung insofern auch darauf zu achten haben, dass solche Aspekte berücksichtigt und eingehalten werden.

III. Fazit

Der Weg, Softwareentwicklungen nach Scrum zu vergeben, steht auch öffentlichen Auftraggebern offen. Ob sich dies gegenüber dem Wasserfallmodell anbietet, ist im Einzelfall zu prüfen. Mangels vorhandener Vorlagen bei agilem Vorgehen ist die Zusammenstellung der Vergabeunterlagen sowie die Prüfung der Wirtschaftlichkeit der Angebote derzeit mit einigen Hürden versehen, die aber bei entsprechendem Engagement und Willen zu meistern sind.

¹ Definition z.B. bei: https://de.wikipedia.org/wiki/Scrum oder: http://scrum-master.de/Was_ist_Scrum/Scrum_auf_einer_Seite_erklaert

Über Dr. Roderic Ortner

Roderic Ortner ist Rechtsanwalt, Fachanwalt für Vergaberecht sowie Fachanwalt für IT-Recht. Er ist Partner in der Sozietät BHO Legal in Köln und München. Roderic Ortner ist spezialisiert auf das Vergabe-, IT und Beihilferecht und berät hierin die Auftraggeber- und Bieterseite. Er ist Autor zahlreicher Fachbeiträge zum Vergabe- und IT-Recht und hat bereits eine Vielzahl von Schulungen durchgeführt.

• Profil im DVNW
|
• Alle Beiträge