So, nochmal herzlich willkommen. Jetzt mit Ton. Ja, ja, bestimmt du kommst. Ich hab schon die Anmoderation gemacht. Ich probier's jetzt nochmal. Ich hoffe der Ton kommt jetzt raus. Also herzlich willkommen zu unserer Diskussionsrunde zum Thema

Wie kommen öffentliche Ausschreibungsverfahren und Agiles Vorgehen zusammen? Es ist ein wichtiges Thema. Es ist ein doppelt wichtiges Thema, denn zum einen wird natürlich das Agiles Softwareentwicklungsparadigma immer wichtiger. Ich denke heutzutage kommt man kaum noch irgendwie an den Begriffen, die wir gerade eben auch im Vortrag von Arnulf gehört haben. Scrum, Safe war mir neu. Viele andere Begriffe vorbei. Auf der anderen

Seite ist es auch so, dass die öffentliche Hand eine deutlich stärkere Position auch in der öffentlichen, also in der Entwicklung von Open Source Software einnimmt und auch einnehmen sollte. Also das Schlagwort ist der Public Money, Public Code. Und andererseits ist es natürlich so, dass Leute, die in der Verwaltung arbeiten,

kennen das natürlich auch die Entwicklungsprozesse, die Vergabeverfahren natürlich etablierte, rechtlich gesicherte Verfahren haben, die zumindest eine Herausforderung stellen, das mit Agilen Softwareparadigma zusammenzuführen. Und genau über diese Herausforderung wollen wir heute sprechen. Ich freue mich, dass wir hier die verschiedenen Diskutanten gewinnen konnten.

Ich würde dir dann auch die Diskutanten bitten, sich kurz vorzustellen. Und ich würde gerne mit unserer, unserem Gast beginnen, die jetzt nicht aus dem unmittelbaren Froskes Umfeld kommt. Umso mehr freut es mich, dass sie heute hier sein kann. Frau Annika Krellmann von der kommunalen Geschäftsstelle für Verwaltungsmanagement.

Ja, hallo. Ich freue mich auch, dass ich hier sein darf. Und so fremd ist mir das gar nicht mehr, weil ich mich jetzt auch schon seit zweieinhalb Jahren für die kommunale Ebene sehr intensiv mit Open Source, insbesondere zur Steigerung der Verstärkung der digitalen Souveränität der kommunalen Verwaltung beschäftige.

Und natürlich ist mit die Froskes so mit als erstes damals mit diversen interessanten YouTube Videos über den Weg gelaufen. Insofern freue ich mich, dass ich jetzt hier sitze. Genau. Und wie schon gesagt, wir gehen unterschiedliche Management-Themen ein, genau mit dem Ziel, Open Source eben mehr in die Verwaltung zu bringen.

Denn Verwaltungen können da mehr tun, gerade im Sinne Public Money, Public Code und sind da auch auf dem Weg. Der ist aber auch nicht immer leicht, aber dazu vielleicht später nochmal mehr. Ja, in der Vorbereitung habe ich auch diesen Bericht gesehen zum Thema öffentliche Verwaltung und Open Source. Da können wir vielleicht gleich nochmal den Link in den Chat posten.

Da würde ich gleich nochmal darum bitten, dass es jemand erledigt. Dann würde ich als Nächsten Thorsten Wiebke bitten, sich vorzustellen. Bitte Thorsten. Ja, hallo, danke. Ja, ich bin Forstwissenschaftler. Ich arbeite als wissenschaftlicher Leiter für Waldinventuren am Landeskompetenzzentrum Forsten übers Walde.

Und ich bin hier, weil es für die effiziente Durchführung von landesweiten Inventuren im Wald Fachkräfte braucht, robuste Hardware und für beides passende Software. Und die gibt es halt nicht von der Stange. Also alle drei Sachen gibt es nicht von der Stange. Und das ist aber, wie ich vorhin schon versucht habe, so ein bisschen zu skizzieren in dem Vortrag zu dem Projekt,

was Gerrit für uns gemacht hatte. Das ist recht schwierig mit dem Beschaffungswesen zu vereinbaren, weil das Beschaffungswesen ist halt darauf spezialisiert, Sachen von der Stange zu kaufen, aus dem Katalog zu kaufen und relativ einfache bzw. Beschaffung zu machen, Aufträge zu vergeben für eindeutige Leistungsbeschreibungen,

wie Fälle alle tiefer mit dem roten Strich und so komplexe Geschichten, wie man für landesweite Inventuren benötigt, sind dort schwierig umzusetzen. Danke. Dann als nächstes Thorsten Friebe, bitte. Ja, hallo Thorsten Friebe. Ich bin Vertreter hier als Entwickler oder eines Dienstleisters.

Wir sind ein kleines Unternehmen aus Bonn, die Firma Latlon. Wir entwickeln schon seit langer, langer Zeit Open Source Software über 20 Jahre, zum Beispiel das Degree Framework. Wir sind also immer wieder täglich damit konfrontiert, diese Software weiterzuentwickeln,

häufig im Auftrag für die öffentliche Verwaltung und bewegen uns da also immer in diesem Spannungsfeld für eine Open Source Software mit den Geldern der öffentlichen Hand eine Weiterentwicklung voranzubringen und uns darum zu kümmern, dass halt die Mittel, die in die Softwareentwicklung einfließen,

dann auch dem Open Source Projekt zugutekommen und das läuft nicht immer perfekt. Darüber wollen wir heute reden. Ja, danke. Marco, bitte. Ja, hallo. Also manche kennen mich ja vielleicht schon vom Keynote-Vortrag vom Beginn der VOSCIS-Konferenz oder von früheren VOSCIS-Konferenzen,

weil ich seit Jahren versucht habe, das Thema agile Entwicklung, Open Source Strategien auch in der Behörde hier in die Community zu tragen. Ich bin heute dabei, weil wir seit sechs, sieben Jahren etwa das Notfallschutzsystem des Bundesamtes für Strahlenschutz, also die Softwarekomponenten, die uns jetzt auch helfen,

die Lage in der Ukraine einzuschätzen beispielsweise, auf Open Source Basis neu entwickelt haben. Vorher waren wir in einem klassischen Länderlog, eine sehr spezifische Software, die nur fürs BFS entwickelt wurde. Und jetzt haben wir eben ein Konstrukt, das einerseits auf Open Source aufsetzt,

aber in dem Rahmen auch Open Source weiterentwickelt wurde, aber Komponenten auch komplett neu geschaffen wurden, die auch unter Open Source veröffentlicht wurden. Und in dem Zusammenhang mussten wir uns natürlich auch, und darum soll es ja heute gehen, mit den entsprechenden Ausschreibungsverfahren dazu beschäftigen,

denn die Manpower hat eine Bundesbehörde, zumindest eine, die fachlich arbeitet. Normalerweise ja nicht so eine Entwicklung komplett in Haus vollziehen zu können. Da hatten wir Dienstleister, Ausschreibungen und was das genau bedeutet. Da können wir dann gerne jetzt dann noch vertiefend darüber sprechen. Ja, sehr gerne. Dann würde ich noch Arnulf bitten, die Forschungsrunde abzuschließen.

Ja, mein Name ist Arnulf Kristl und ich bin hier so ein bisschen ein Dinosaurier, scheint mir, zusammen vielleicht mit dem Thorsten und dem Marco. Wir machen das schon eine ganze Weile. Ich habe angefangen mit Open Standards und alle haben gesagt, ja, das ist sehr doof.

Dann habe ich Open Source gemacht, dann haben alle gesagt, das ist doof. Dann habe ich Open Data gemacht und dann haben alle gesagt, das geht ja gar nicht. Was ziemlich cool ist, ist, dass jetzt alles zusammenkommt und das tatsächlich geht. Und jetzt haben wir auch noch aus der Softwareentwicklung kommt ja eigentlich dieses agile Vorgehen, dass man eben sagt, es geht nicht nach einem Plan, sondern wir müssen da agiler werden.

Das ist sozusagen das Letzte, was wir noch brauchen, um da eine runde Sache draus zu machen. Und es freut mich sehr zu sehen, wie gut das funktioniert. Wir haben jetzt zum Beispiel ein Bundesamt für Strahlenschutz oder auch einen kleineren Faustbewerber. Das ist super. Also ich glaube, wir sind auf dem richtigen Weg. Vielleicht fangen wir nochmal ganz kurz mit den Grundlagen an.

Arnulf, ich würde bei dir kurz bleiben. Vielleicht kannst du nochmal in zwei, drei Sätzen einfach nochmal agile Softwareentwicklung zusammenfassen, damit wir da die gemeinsame Grundlage haben. Die agile Softwareentwicklung beinhaltet vor allen Dingen Entwicklungsmethoden, bei denen nicht nach einem starren Schema etwas abgearbeitet wird,

sondern ein minimal viable product, eine minimale Lösung zusammengebaut und die dann vom Endanwender gleich schon getestet wird und verwendet wird, der daraufhin zurückmeldet, was denn da noch verbessert werden muss. Das Ganze läuft in einem Rahmen. Das wäre noch nicht genug, wo ein Mensch, der den Übersicht hat,

eine Liste hat von Funktionen und Features, die er gerne haben möchte und die in einer Prioritätenliste sortiert, sodass also die wichtigen Sachen zuerst gemacht werden und nach und nach wächst dieses Produkt. Das ist eigentlich, glaube ich, zusammengefasst ganz gut, das Vorgehen.

Und wichtig ist, dass eben diese Iterationen nicht zu lang sind, dass man also relativ kurz und schnell Antwort bekommt auf das, was da schon entwickelt worden ist. Das ist sozusagen dann vor allem auch die agile Komponente, die da drin steckt. Jetzt reden wir natürlich nicht nur über agile Entwicklungen, wir reden auch über öffentliche Ausschreibungen.

Vielleicht eine Frage an unseren Gast, Frau Krellmann. Was kann man irgendwie sagen? Was ist denn das Spezifische, was eine öffentliche Ausschreibung ausmacht? Gibt es da Spezifika, dieses Unterscheiden? Öffentliche Ausschreibungen sind einfach extrem, ich sage es mal ganz ehrlich, anstrengend und kompliziert, ich glaube, für beide Seiten.

Also sowohl für die Auftragnehmer bzw. die Bietenden als auch für die Verwaltung selbst. Und es hängt immer davon ab, so im Groben haben wir einmal diesen sogenannten Überschwellenbereich, also wo wir EU-weit ausschreiben müssen. Da ist es noch wichtiger, immer wichtiger als noch wichtiger, dass wirklich alles genau passt, dass man niemanden ausschließt und so weiter,

damit man eben nicht vor der Vergabekammer auch landet. Und im unterschwelligen Bereich ist es auch schon nicht einfach. Und jetzt muss man sagen, eigentlich haben wir in dieser Runde gleich zwei Herausforderungen gleichzeitig, meines Erachtens, denn einmal ist es für viele Verwaltungen auf Novum, agile Softwareentwicklungen mit dem Vergaberecht zusammenzubringen.

Und zum anderen, und das stelle ich eben auch in meinem Projekt nochmal fest, also nochmal ganz kurz, das hatte ich vorhin gar nicht gesagt, wir sind ein Fachverband. Also wir sind tatsächlich auch als eine Art Verein organisiert und arbeiten ganz eng mit den Kommunen zusammen. Dann ist auch die Vergabe von Open Source noch mit vielen Besonderheiten verknüpft.

Die klassischen Vergabearten beziehungsweise EVBIT und Co. kommen ja noch zu auch nur so bedingt Abbilden aktuell. Da ist man dran, da muss aber meines Erachtens noch viel passieren, auch in den Vorschriften, damit uns das gut und rechtssicher gelingt.

Weil natürlich sind Kommunen immer die Ängste gleich recht groß, wenn man eventuell hier und da sozusagen Gefahr läuft, gegen Geld recht zu verstoßen, logischerweise. Und es kommt noch dazu, dass einige Vergabearten, wie beispielsweise die Innovationspartnerschaft,

die sich hier und da auch mal gut eignen kann, nicht so häufig sind. Das sind eher häufig so klassische Ausschreibungen. Das heißt, da sind Verwaltungen dann auch nicht so geübt in der Regel. Das im Haus viel abzustimmen mit der Revision und so weiter. Also es ist tatsächlich immer ein großes Vorhaben, sobald das Vergaberecht im Spiel ist.

Da will ich mal spontan nachfragen. Innovationspartnerschaft sagt mir persönlich jetzt gar nichts als Begriff. Können Sie das ganz kurz nochmal erläutern? Es ist auch noch nicht so, es ist tatsächlich noch nicht so oft genutzt. Das eignet sich immer dann besonders gut, wenn man sozusagen noch keine fertigen Lösungen, die man, sage ich mal, am Markt hat. Dann kann man darauf ganz gut zurückgreifen, weil man ja ähnlich, sage ich mal,

wie im wettbewerblichen Dialog immer wieder mit Firmen sprechen kann, verhandeln kann in unterschiedlichen Stufen und so dann auch Produkte entstehen können. Und das wiederum passt ja ganz gut zu dem Agilen, wo man vielleicht eine Vision hat,

also schon ganz gut beschreiben kann, wohin man möchte. Aber der Weg sozusagen noch nicht fertiggemalt ist. So wie wir das ja in der Vergangenheit, ich sage mal bei proprietärer Software auch, ist es ja ganz häufig so, dann kauft man halt ein Produkt. Und bei Open Source ist das eben häufig nicht so. Deshalb ist es sicherlich spannend, da nochmal einen Blick drauf zu werfen.

Ja, spannend, ja. Also ich kann die Erfahrung, das jetzt in Ausschreibung zu gestalten, nicht unbedingt vergnügungssteuerpflichtig ist, nur aus persönlicher Erfahrung bestätigen. Aber ich denke, das ist wirklich eine wichtige und hilfreiche Diskussion, die wir führen, die vielleicht vielen Leuten auch nochmal Anregungen geben kann, wie man das besser auch organisieren kann.

Ja, vielleicht mal eine Frage in die Runde. Ich würde tatsächlich bei der Innovationspartnerschaft gerne noch eine Frage stellen, weil bei uns stellt sich immer so ein bisschen die Frage, wer hat denn die Verantwortung fürs Produkt? Und das ist ja häufig so, dass der Bedarfsträger eigentlich jede Verantwortung von sich weisen will.

Er will formulieren, was er denn braucht und dass das dann auch definitiv eins zu eins so kommt, das hat die Firma gefälligst zu gewährleisten. Innovationspartnerschaft bringt jetzt für mich schon nach so einem etwas offeneren Verfahren, wo der Ausgang so ein bisschen offener ist und das wegen der Bedarfsträger auch selbst

mit in der Pflicht ist, sich um das Erreichen des Zieles aktiv auch während des Prozesses zu kümmern. Und das war bei uns auch, auch wenn wir mit einer klassischen Ausschreibung gearbeitet haben, als Rahmenabrufvertrag, wo wir Entwicklungsdienstleistungen letztendlich eingekauft haben, auch ein wichtiger Punkt, wo man die Leute auch erstmal braucht,

wo man sagt, die Verantwortung für das Projekten gelingen, die haben wir selbst übernommen. Da haben wir als Behörde gesagt, wir sind Product Owner. Wir sorgen dafür, dass es durchläuft und dass am Ende das Richtige rauskommt. Wir brauchen nur die Unterstützung, hauptsächlich in Dienstleistungen. Aber das ist natürlich auch nicht überall da.

Ja, das ist ein sehr guter Punkt. Frau Keilmann, wollten Sie direkt darauf antworten oder? Deshalb finde ich das auch so interessant. Jetzt muss ich ganz ehrlich sagen, ich bin jetzt keine Expertin für Innovationspartnerschaften. Da gibt es sicherlich andere, die sich darauf noch besser spezialisiert haben. Aber ich denke, es lässt sich gut zusammenbringen.

Und dieses Parten drückt ja auch schon das andere Verständnis aus. Ich glaube, da müssen wir ganz, ganz dringend hin. Und auch im agilen Arbeiten haben wir das. Ja, wir kommen ja vielleicht im weiteren Verlauf der Diskussion nochmal zu der Rollenverteilung, die vorhin ja auch schon nochmal vorgestellt worden ist.

Und ja, Verwaltung müssen immer schon. Also auch Testing von proprietären Produkten ist ein Riesenthema, was häufig zu kurz kommt. Aber erst recht, wenn Software agil entwickelt wird, muss man in die Sprint sein. Man muss nach jedem Sprint gescheit natürlich schauen, passt das alles, fehlt noch was und und und.

Wenn man da nicht im Dialog ist, ist das natürlich auch Sache des Auftraggebers, wenn es am Ende nicht läuft. Das sehe ich ganz klar so. Da hat man eine unbedingte Verantwortung, auch als Verwaltung. Ja, unbedingt. Das ist auf jeden Fall ein absoluter Paradigmenwechsel, der da tatsächlich stattfindet. Man kauft eben kein Produkt. Man ist sozusagen selbst eben, wie heißt das so schön?

Product Owner. Habe ich das richtig im Kopf? Nein, der agilen Sprechweise. Vielleicht bevor wir da, wir sind schon dabei tief einzusteigen. Das ist total klasse. Vielleicht nochmal. Wir sind hier hier auf der Foskis. Nochmal die allgemeine Fragen die Runde. Warum ist es denn so wichtig, das auf Open Source Basis zu machen?

Freiwillige vor? Also ganz früher, als ich angefangen habe mit dem Open Source, da hieß es immer You scratch an itch. Wenn Open Source entsteht, weil du ein Problem hast und das möchtest du gern lösen.

Und diese Probleme, die sind halt überall und die müssen gelöst werden. Und ich kann aber nur das Problem lösen, wenn derjenige mir sagt Ja, ich suche nicht mehr. Ohne Kommunikation läuft das halt nicht. Und das ist der ganze Kern von Open Source. Es gibt meiner Meinung nach kein gutes, funktionierendes, stabiles Open Source

Projekt, das nicht echt sinnvoll wäre. Und bei proprietary Software würde ich das jetzt nicht so uneingeschränkt sagen. Und ich glaube, deswegen ist dieses Ich handel mich an dem Problem entlang und löse es iterativ, bis die Lösung so ist, wie sie am besten funktioniert. Und deswegen passt das gerade so gut zusammen.

Frau Kelmer, Sie hatten vor kurz von den rechtlichen Herausforderungen gesprochen, die spezifisch bei Open Source für Kommunen bestehen. Können Sie da vielleicht irgendwie das nochmal kurz an einem Beispiel erläutern oder nicht an einem konkreten Beispiel, aber einfach nochmal kurz ausführen? Ja, also es fängt schon damit an, dass man zum Beispiel bei den

EVB IT Verträgen ja gerne herangezogen werden. Ganz genau schauen muss und auch bei einzelnen Formulierungen schauen muss, dass man gerade die Anbieter, die Open Source basierte Software anbieten, nicht durch irgendeine Formulierung ausschließt, vergaberechtlich. Also solche Dinge ist es zum Beispiel, deshalb finde ich es auch gut.

Es gibt gerade auch Arbeitsgruppen, die sich damit auseinandersetzen, wie man das mehr zusammenbringt, wie man auch für Open Source sozusagen Beschaffungsrichtlinien hat, die den Verwaltungen, egal auf welcher Ebene, also sprechen wir nicht nur in meinem Fall von Kommunalverwaltungen, aber auch von Bund und Ländern, die da unterstützen.

Also dementsprechend ist da noch einiges zu tun. Das kann man gar nicht so kurz alles zusammenfassen. Aber ich kann vielleicht direkt dann anfügen. Der Grund ist definitiv natürlich auch die Stärkung der digitalen Souveränität und dieses Prinzip Public Money, Public Code. Deshalb wir auch als Fachverband meinen, dass es gerade die Verwaltungen sind,

die da nach vorne gehen sollten. Und aktuell, das ist vielleicht jetzt gerade im GES-Kontext nicht unbedingt allen so geläufig, ist das Online-Zugangsgesetz ein ganz großes Thema, dass wir Ende des Jahres alle Leistungen online haben müssen. Und da gibt es auch so ein sogenanntes Einer-für-alle-Prinzip.

Das ist ganz komplex auch im föderalen System. Aber wenn wir schon hören, Einer für alle, dann ist Open Source ja wie gemacht dafür. Und deshalb müssen wir mehr dahin. Und diese Abhängigkeiten haben wir in Verwaltungen ganz extrem,

natürlich von bekannten Hyperscalern, aber auch von Nischen-Software-Anbietern. Das ist immer ein Risiko für Verwaltungen, wenn da irgendwann irgendwo was nicht mehr läuft. Ja, das ist wirklich ein bekanntes Problem. Das trifft man häufig. Also ich persönlich komme aus der Geschichtsecke und da gibt es in jedem Archiv

eine eigene Software-Lösung, die irgendwie manchmal proprietär ist, manchmal katastrophal. Also das ist wirklich ein ganz interessantes Beispiel auch für so eine Nischen-Software, wo sich wirklich ein ganz kurioser Markt etabliert hat, wo man sich denken würde,

eine Software-Open Source-Lösung würde reichen, um das alles zu bedienen, weil die Anforderungen sind die gleichen. Ja, vielleicht können wir kurz, wir würden gleich nochmal in so eine Art Praxisbeispiel reingehen. Vor, würde ich vielleicht eine Frage an Marco Lechner nochmal vorziehen. Vielleicht einfach kurz mal nochmal die Praxis am BFS kurz zu skizzieren.

Also ich kann das ja kurz mal in zwei Sätzen, drei Sätzen zusammenfassen, was eigentlich unser Ausgangspunkt war. Also zunächst war ein klassischer Wenderlock, sprich eine Abhängigkeit vorhanden. Und dann kam eine neue Gesetzgebung, die klar gemacht hat, mit dem jetzigen Produkt

und den Dienstleistungsverträgen, die es mit einem proprietären Partner gab, lässt sich das bestehende System einfach nicht weiter entwickeln und dann die neuen Anforderungen anpassen. Da waren einfach die Änderungen zu groß und letztendlich auch die Wartungsverträge dann verhältnismäßig zu teuer bzw. die Technik auch überhaupt nicht mehr zeitgemäß

über die mehreren Jahre betrieb. Und dann war es klar, was macht man neu? Anpassung geht nicht, also mache ich eine Neuentwicklung. Und dann war es, ich glaube das ist auch so ein bisschen Stichwort Voraussetzungen, war es im Endeffekt eine Initiative innerhalb des Amtes von Einzelpersonen.

Da war ich auch noch gar nicht am BFS, die gesagt haben, Mensch, in sowas wollen wir nicht nochmal reingeraten. Wir versuchen das jetzt anders aufzuziehen. Und deswegen wurden so ein paar Kriterien festgelegt. Wir wollen, dass es Open Source entwickelt wird. Wir wollen vorhandene Komponenten nutzen und nicht immer alles selbst entwickeln,

nur dort, wo es es gar nicht gibt. Und wir wollen dort, wo Kommunikation notwendig ist, nicht eigene Schnittstellen schaffen, sondern Standards soweit vorhanden ist einsetzen. Das waren so die Vorgaben, die genutzt wurden. Und dann hat man sich so Stück für Stück einfach daran gewagt.

Auch die Ausschreibungen haben sich dann so ein bisschen gewandelt. Die ersten Ausschreibungen waren drei Jahre gültig. Dann sind die Verträge ausgelaufen, kam eine Folge Ausschreibung. Dann hat unsere Ausschreibungsstelle gesagt, Moment, so wie das damals war. Das geht aber gar nicht. Das war ja vergaberechtlich gar nicht in Ordnung.

Oder das Vergaberecht hat sich geändert in der Zwischenzeit. Und so sind wir in so einen Prozess gekommen. Wir haben aber immer versucht, mit unserer Beschaffungsstelle, die ja das letztendlich mittragen müssen, im Dialog zu sein. Klar, wir sind die fachlichen Bedarfsträger.

Und dann geht es immer so ein bisschen darum, denen auch deutlich zu machen, dass unsere fachlichen Anforderungen tatsächlich sind, diese Unabhängigkeit definitiv nicht mehr zu haben. Und damit wird auch das Bewertungsschema,

das man in die Ausschreibungen reinpacken kann, ein anderes. Das heißt, da wird Open Source dann selbstverständlich. Und das ist jetzt gerade durch einen Koalitionsvertrag nochmal gepusht, wo die digitale Souveränität recht hochgehalten wird. Wir hoffen, dass das auch in der Legislatur entsprechend umgesetzt wird.

Also diese Souveränität, das war eins der Hauptanliegen, die dann letztendlich eins nach dem anderen brachte. Aber es ist wichtig, eine Einzelperson oder ein kleines Team zu haben, das auch erstmal sagt, hey, wir wollen, wir stehen dahinter. Da ist erstmal Idealismus und man kämpft in der Behörde natürlich auch erstmal da kämpfe, um das zu erreichen.

Ja, das ist ja wirklich ein Kulturwandel, das wir sehen oder beschreibst, der über mehrere Jahre läuft. Das ist ein ganz guter Übergang zu dem nächsten Segment, wo ich mal die beiden Torstens einbeziehen möchte. Thorsten Wiebke, du hast ja vor schon beschrieben, du kommst jetzt eher sozusagen aus einer kleineren Verwaltungsumgebung.

Gestern, als der Vortrag von Marco Lechner war, hatten wir leider keine Gelegenheit, die Fragen zu beantworten. Aber die eine Frage, die wirklich alle umgedrungen hatte, ich glaube, das war im zweistelligen Bereich gewartet, war, ja, das ist alles super, aber wie kann man das denn umsetzen, sozusagen in einer Verwaltung, wo diese ganzen Begriffe eben nicht so präsent sind, also wo dieser Kulturwandel noch nicht stattgefunden hat.

Und da würde ich jetzt einfach mal dich, Thorsten, kurz bitten, vielleicht mal so ein Beispiel aus der Praxis einfach mal zu bringen, das man mal durchspielen könnte. Thorsten Ja, gerne. Ich würde noch zu ein paar anderen Sachen was sagen. Du hast jetzt mehrfach gesagt, kleinere Verwaltung, ne?

Also ich arbeite beim Landesforst. Thorsten Ja, wir sind wieder zurück, hoffentlich gleich im Stream hier auf meinem anderen Bildschirm zu sehen.

Tut uns leid für die kurze Unterbrechung. Das ist natürlich nur, um Spannung aufzubauen. Und ja, also wir haben gerade eben von Thorsten Wiebke gehört, was seine spezifischen Anforderungen sind. Also es ist keine große Softwarelösung, aber es ist doch eine sehr spezifische Softwarelösung, für die man halt nichts von der Stange kaufen kann. Und da wäre jetzt meine Frage an Thorsten Friebe.

Wie würdest du denn da jetzt aus Entwicklersicht mit umgehen? Vielleicht kannst du dazu was sagen. Thorsten Ja, also ich glaube erst mal unabhängig, ob die Dinge klein oder groß sind. Wir können als Entwickler selten in den Kopf des Anwenders reingucken. Wir wissen gar nicht, was sie wirklich wollen. Und manchmal stellt man auch fest, dass erst über die Zeit,

über die Projektlaufzeit die Anforderungen so gereift sind, dass beide Seiten wissen, was soll wirklich umgesetzt werden. Deswegen, ich kann mir eigentlich gar nicht mehr eine Softwareentwicklung ohne Agilität vorstellen. Denn ein Lastenheft oder ein Pflichtenheft,

was wirklich fehlerfrei war, wo man sagen kann, auch alle Anforderungen, die dort aufgeschrieben wurden, wurden zum Ende auch wirklich gebraucht. Das heißt, sie wurden auch später in Produktionen genutzt. Das habe ich schon sehr lange nicht mehr gesehen. Also das war vielleicht in den Anfängen der IT noch normal.

Aber ich glaube, wir haben mittlerweile das Problem, dass wir oft mit sehr hohen Erwartungen reingehen, während des Projektes auch lernen, dass sich die Dinge verändern, dass auch der Bedarf sich verändert. Und wir wollen unbedingt vermeiden, bei der agierenden Softwareentwicklung, dass wir auch Dinge entwickeln, die später gar nicht gebraucht werden.

Die hat zwar jemand mal aufgeschrieben am Anfang des Projektes, weil er dachte, ach, das wäre ganz schick. Aber zum Ende des Projektes hat man festgestellt, das braucht man nicht. Das heißt, wie gehen wir im Idealfall bei solchen Anforderungen ran? Wir wollen erstmal wirklich mit den Anwendern ins Gespräch kommen

und gemeinsam möglichst schnell Prototypen entwickeln, die dem Kunden dann vorgestellt werden, der Gruppe, der Anwender und dort direktes Feedback einsammeln. Und über mehrere Iterationen kann man dann genau eben auch das herausarbeiten, was sind die nutzbringenden Funktionen, worauf muss man sich fokussieren

und welche Funktionen kann man auch wirklich weglassen. Da gibt es die agile Softwareentwicklung, hat ja da auch verschiedene schöne Begriffe etabliert. Aber den Waste vermeiden, also zu vermeiden, dass man Software entwickelt, die nicht gebraucht wird.

Da gibt es Studien zum Beispiel von der Standish Group, die immer wieder fragen, wie viel Code ungenutzt im Software vorhanden ist. Der ist enorm. Und wenn man sich dann wiederum anguckt, wie viele Softwareprojekte erfolgreich oder eben leider nicht erfolgreich sind,

spricht das alles dafür, sich wirklich auf das Wesentliche zu konzentrieren. Das heißt, ausserwarten der wichtigen Sachen und darauf fokussieren. Ja, finde ich sehr überzeugend. Jetzt vielleicht zurück an anderen Thorsten nochmal gefragt. Wenn du das auch überzeugend findest und damit an die entsprechenden Stellen herantrittst,

mit denen du dich da abstimmen musst, glaubst du, das ist etwas, wo du auf große Begeisterung stößt oder wie wäre da deine Einschätzung? Bei mir persönlich ja auf alle Fälle. Also der Thorsten läuft da bei mir auf eine Tür. Nein, finde ich ganz super.

Auch die Herangehensweise finde ich total super. Das Problem ist nur, ich muss ja, wenn ich irgendwie in die Beschaffung geben will, muss ich selber halt irgendwie einen Plan haben, was ich eigentlich will. Das muss ich intern begründen. Da muss ich erstmal klarstellen, dass das ganz doll notwendig ist. Und dann wird von mir verlangt, dass ich sehr deutlich und sehr detailliert darstelle, was die Leistung ist.

Weil einfach auch in einer Haushaltsordnung drin steht, dass jegliche Beschaffung über die Vergabemarktplatz erfolgen muss und dass dabei diskriminierungsfrei die Leistung ausführlich und detailliert beschrieben werden muss. Und da stehe ich dann halt mit sowas, wie ich vorhin gesagt habe.

Ich möchte jetzt hier gerne, dass mehrere Fachleute GPS-Positionen im Wald einmal frei erfassen können, auf einer Datenbank synchronisieren können, kollaborativ miteinander abgreifen können und das möglichst auf Open Source. Das reicht denen nicht aus. Da kommen sie dann und verlangen von mir, dass ich jetzt aber nochmal bitte die Firma detailliert eingrenze,

irgendwelche Ausbildungen vorschreibe, irgendwelche Zertifizierungen vorschreibe. Was auch gern verlangt wird, ist, dass man eine gewisse Umsatzsumme vorschreibt, wo ich dann immer sage, nein, das macht doch überhaupt nichts an der Qualifikation. Und dann laufe ich halt schon mal monatelang mit den Kollegen im Kreis.

Frau Krämer, können Sie das irgendwie so bestätigen? Ist das was, was häufiger vorkommt? Also sozusagen diese motivierten Mitarbeiter, die uns Marco Lechner vor auch präsentiert hat, für diesen Kulturwandel im BFS, die dann auf entsprechende Vergabestellen stoßen? Ich wage jetzt mal zu sagen, dass das mit Sicherheit

dass viele diese Erfahrung machen an Verwaltung. Und deshalb gehört dazu ja auch mehr als jetzt beispielsweise irgendwie die Regelungen nochmal klarer zu fassen, sondern tatsächlich auch die Qualifizierung der Mitarbeitenden und ein Stück weit sogar auch die Kultur. Also ich habe selber, ich habe auch ein Verwaltungs-Background.

Ich habe selber auch schon mal in einem Agilien-Projekt gearbeitet, allerdings jetzt erst in der KGST. Und da lernt man ganz viel bei, aber man lernt eben auch, dass ganz anders gearbeitet wird in diesem Agilien-Projektmanagement. Also für mich selbst war das auch einfach eine gute Erfahrung. Ich war da sozusagen Product Owner.

Und ich glaube, deshalb ist es noch ein längerer Weg, weil man das vielleicht auch erst lernt, wenn es mal gemacht würde. Und dafür müssen aber wiederum die Hemmschwellen ein bisschen senken, gesenkt werden. Und wir müssen ran und die Leute fit machen sozusagen. Da sind wir als Fachverband natürlich auch mitgefragt, ganz klar.

Genau, das ist vielleicht ein super Einstieg für diese Frage, dieser Product Owner. Das scheint ja wirklich nochmal zentral zu sein. Vielleicht mag nochmal jemand, vielleicht Arnold, von dir haben wir ja auch länger nichts mehr gehört. Vielleicht magst du kurz nochmal beschreiben, was der Product Owner ist und dann vielleicht nochmal von Marco und von Frau Krellmann vielleicht nochmal, wo kann das denn in der öffentlichen Verwaltung angesiedelt sein? Also wer macht das dann tatsächlich?

Wer wird zum Product Owner? Ja, die Product Ownerin ist diejenige, die versteht, was die Fachseite braucht und es so niederschreiben kann, dass ein Entwickler es zum Beispiel anfängt zu verstehen. Ich sage noch nicht, dass es wirklich verstanden hat, aber dass er anfängt, das zu verstehen.

Das ist immer ein großes Problem, dass der Endanwender sein Fach Chinesisch spricht und der Softwareentwickler sein Softwareentwickler Chinesisch. Und dazwischen muss ein Übersetzer geben. Und das ist die Product Ownerin. Und die hat richtig viel zu tun. Ich sage immer, für ein normal formatiges Projekt, für ein Team mit fünf bis sieben Entwicklern,

braucht man eine Vollzeitstelle Product Owner. Macht nichts anderes, außer in Besprechungen rumzuhängen und den Leuten zu erklären, was sie tun sollen und den anderen zuzuhören, um zu verstehen, was sie brauchen. Das ist eine ganz zentrale Aufgabe und ganz wichtig. Und das ist der, der früher im kleinen Kämmerchen ein Leistungsheft zusammengezimmert hat.

Und der ist jetzt plötzlich ganz zentral in diesen Prozess mit drin und übersetzt zwischen den Anforderungen und den Entwicklern, die das dann umsetzen. Das ist die Aufgabe der Product Owner. Ja, vielen Dank. Dann vielleicht erstmal nochmal an Marco die Frage. Habt ihr da spezielle Product Owner? Ist das projektspezifisch? Wie sieht das in der Praxis aus? Ja, ich hatte ja vorhin mal kurz skizziert,

dass das Notfallschutzsystem, das wir da entwickelt haben und die Weiterentwicklung ist auch ähnlich strukturiert in Teilprojekten, in Komponenten organisiert ist. Und das heißt dann auch, dass letztendlich bei uns das sind das Referenten, Fachreferenten, weil da kommt ja auch die Fachanforderung her. Die zählen bei uns als Teilprojektleitungen.

Und das sind de facto dann die Product Owner, die dann mit dem Dienstleister zusammen auch die Workshops organisieren. Wir haben jetzt kein statisches Scrum 14-Tage-Verfahren, sondern das hängt auch ein bisschen natürlich mit den Ressourcen der Dienstleistenden ab, wie man sich da abstimmt. Aber im Endeffekt ist das genau der Punkt.

Die Teilprojektleitung ist dafür zuständig, dass das Projekt vorangeht, macht die Kommunikation mit dem Dienstleister, mit dem Team letztendlich auf beiden Seiten, organisiert die Workshops um die Anforderungen immer wieder rückzukoppeln und schreibt Tickets, Tickets, Tickets und schiebt die in nächste Releases und so weiter. Ja, das ist ja eigentlich eine Fortbildungsfrage,

oder Frau Krellmann? Also letztendlich, also ich glaube, man kann die Leute natürlich ins kalte Wasser schmeißen. Das funktioniert wahrscheinlich auch. Aber so eine gewisse Grundvorbereitung wäre sicherlich ganz hilfreich. Ja, definitiv. Also generell agiert das Projektmanagement und auch Scrum mit den ganz unterschiedlichen Rollen, die daran hängen, ist aktuell auch extrem gefragt,

auch in Kommunen. Also sie machen sich da schon auf den Weg. Und womit wir sehr gute Erfahrungen gemacht haben, ist tatsächlich, wir haben noch so eine Art Proxy Product Owner installiert, der sozusagen die Schnittstelle dann zwischen dem eigentlichen Product Owner, also beispielsweise den Prozessverantwortlichen oder Prozesseignern in der Verwaltung, die wirklich Bescheid wissen,

was gebraucht wird, wie die Produktvision aussieht und so weiter und den Entwicklern. Weil ich glaube, das ist ein gutes Vorgehen, weil man damit zwar klar definierte Rollen hat, aber der Realität auch ein bisschen gerecht wird, dass die Product Owner in der Verwaltung seltenst.

Das muss man einfach so sagen, auch bei der Personalsituation in Verwaltung. Die werden ja nicht entbunden von ihren anderen Aufgaben in der Regel. Und deshalb finde ich so ein Vorgehen ganz gut. Das heißt, dann bräuchte man aber bei dem IT-Dienstleister auch nochmal jemanden, der als Proxy-PEO sozusagen, dem es gelingt, sich auch in die Prozesse

so ein bisschen mit reinzudenken und diese Schnittstelle mit abzubilden. Aber den sehen Sie dann quasi beim IT-Dienstleister und jetzt nicht auf Seiten der Verwaltung? Genau, das ist ein Proxy, ja. Also ich finde, die Verwaltung sollte eigentlich Product Owner sein, ist ja nun mal so. Ihr gehört ja sozusagen auf das Produkt, Sie muss da eine Vision haben. Und ja, genau, den Proxy würde ich dann

beim IT-Dienstleister sehen. Also wir haben es selbst so gemacht. Das hat super geklappt. In dem Fall, ich hatte ja vorhin gesagt, dass ich die Product Ownerin war, mich auch entlastet, was Tagesgeschäft angeht oder so. Und gleichzeitig auch nochmal war das ein bisschen mehr sozusagen Learning on the Job, was die Methode angeht. Ja, vielleicht Thorsten Liebke nochmal kurz.

Achso, Thorsten Friebe, bitte. Ja, ich würde da gerne nochmal auch auf die verschiedenen Fähigkeiten darauf eingehen, die von einem Product Owner oder einer Product Ownerin da eigentlich abgefragt werden. Kommunikation war ja gerade eben da und Sprache. War es vorher derjenige oder diejenige, die im stillen Kämmerlein, die Arnulf es sagte,

die Leistungsbeschreibung geschrieben hat, ist es jetzt vor allem ein kommunikativer eine Rolle, die also viel durch direkte Kommunikation mit allen Beteiligten die Interessenlagen sondiert, vor allem auch moderieren kann. Und da geht es gar nicht um die fachliche Expertise

oder auch die technische Expertise, sondern eher um kommunikative Fähigkeiten und vor allem die Fähigkeit, auch Entscheidungen zu treffen, dafür zu sorgen, auch möglichst alle mitzunehmen und diese dann auch zu vertreten. Gerade wenn der Product Owner auf Seiten des Auftraggebers sitzt,

diese dann gegenüber seinen sogenannten Stakeholdern auch zu vertreten und dabei zu bleiben, das ist ganz wichtig, hat ganz viel mit Kommunikation zu tun. Ja, zeigt auch nochmal, wie unterschiedlich tatsächlich diese agilen Ausschreibungsverfahren nochmal zu klassischen Ausschreibungsverfahren sind, wo ich mir ein Produkt kaufe und fertig

und ja doch nochmal viel mehr Verantwortung drinsteckt. Vielleicht Thorsten Liebke nochmal kurz ein, zwei Sätze zu deiner persönlichen Erfahrung, wie du zum Product Owner geworden bist. Nebenbei. Ich habe die auch nebenbei ausgeführt, die Rolle als Product Owner eigentlich regelmäßig.

Aber das beantwortet ja die Frage eigentlich nicht. Also grundsätzlich bin ich zum Product Owner geworden, weil ich bin die Beschaffungsstelle. Ich weiß, was ich da will. Ich habe die Ahnung, was am Ende bei rumkommen soll und es ist einfach und das hatte die Frau Kellmann ja recht deutlich gesagt, es ist schlicht und ergreifend kein anderer da.

Also das Tagesgeschäft ist noch zu erledigen und nebenbei ist die Entwicklung von der Software irgendwie mitzubegleiten, so gut es geht. Und es ist einfach niemand anderes da, der das fachlich, inhaltlich und auch zeitlich übernehmen könnte. Und daher, weil ich das haben will, bin ich da jetzt Product Owner.

Ja, genau, vielleicht kommen wir, bitte Marco. Ja, ich glaube, dieses Verhältnis, das war gerade so ein bisschen skizziert. Naja, es gibt letztendlich beim Bedarfsträger jemanden, der so eine Art Projekt Lead macht, aber der kann das auch nicht allein, weil er vielleicht auch die Entwicklungsexpertise hat und bei einer eingekauften Dienstleistung dazu hat man so einen Gegenpol, also sprich auch eine Projektleitung,

was man auch in der Ausschreibung ja an Qualifikation auch abfragen kann, dass da auch jemand Adäquates ist. Das scheint ja so ein bisschen ein Standardmodell hier zu sein, das wir gerade rausarbeiten. Ich frage mich aber an der Stelle auch immer, und das haben wir beim Foskes auch schon in den Workshops diskutiert, wie stark das in die eine oder andere Richtung verschoben werden kann.

Bei uns ist es jetzt relativ stark, dass eine fachliche Expertise da ist und dass es uns dann auch wichtig war, das Wissen mitzutransferieren in dem Prozess, dass wir auch prinzipiell, nicht mit der ganzen Entwicklungsleistung, aber ohne den Dienstleister das Projekt weiterentwickeln könnten, dass zumindest das Know-how mit aufgebaut wird.

Auf der anderen Seite kann man natürlich auch sagen, bei einer Behörde oder einer Institution, wo das gar nicht vorhanden ist, weil einfach andere Aufgaben, kann sowas dann noch deutlich stärker vielleicht bis komplett zum Dienstleister verlagert werden, dass man sagt, hier Product Owner wird komplett und das Management wird komplett auch dahin verlagert und der Aufwand für die Behörde bleibt wieder relativ klein.

Es läuft letztendlich an der Stelle, egal mit welcher Konstellation, immer darauf hinaus, dass ich ein gesundes Vertrauensverhältnis zwischen den Vertragspartnern brauche und dass man sich dieses Vertrauen auch entgegenbringen muss. Das hat bei uns sehr gut funktioniert.

Ich weiß nicht, ob das immer so ist. Ich hoffe es. Zumindest bei allen Firmen, die ich hier im Foskes Umfeld kenne, kann ich mir das eigentlich sehr gut vorstellen. Ja, Frau Kremer, bitte. Und vielleicht noch mal so ein bisschen, auch weil es gerade im Chat auch noch mal diskutiert wurde, weil ich diesen Proxy-PO vorhin ja angesprochen hatte. Damit meinte ich nicht, dass das irgendwie total nebenbei läuft,

auf gar keinen Fall. Also jetzt in meinem Beispiel, ich glaube, ich hatte so 50 % immerhin für das Projekt und wir haben deshalb Vertrauen trifft, dass wir super transparent gearbeitet haben. Es waren insgesamt sogar drei Organisationen beteiligt, bis hin dazu, dass wir uns unsere Kalender sozusagen geteilt haben,

zumindest was die Weblog-Zeiten angeht. Wir haben unterschiedliche Tools gehabt, mit Jira, Confluence und Co. gearbeitet, alle miteinander. Und das hat gut geklappt. Aber da ist dieses Vertrauen eben, im Prinzip waren wir wie Kollegen, sage ich mal, obwohl wir aus unterschiedlichen Organisationen kommen. Und ich glaube auch, dass das so eine gewisse Voraussetzung ist,

damit es dann wirklich gut klappen kann. Und dass das gerade für viele in der Verwaltung auch ein interessantes, neues Arbeiten ist, das kann ich mir schon gut verstehen. Da frage ich mich natürlich, wie man sozusagen Vertrauen in einen Dienstleistungsvertrag reinbekommt. Also man weiß ja vielleicht nicht unbedingt sozusagen, wer letztendlich den Zuschlag bekommt.

Also es hängt da wahrscheinlich davon aus, wie das Vergabeverfahren dann strukturiert ist. Aber ich denke, Vertrauen ist tatsächlich eine sehr wichtige Grundlage. Vielleicht auch einfach mit der Haltung, dass man einfach als Verbreitung der Haltung vorangeht, erstmal auch den Dienstleister, den Partner, den man ja dann hat, einen Vertrauensvorschuss zu geben. Also ich glaube, das kann man nicht alles vertraglich am Ende

nur vereinbaren sozusagen. Genau, in jedem Fall. Ja, vielleicht können wir nochmal kurz ein bisschen so in die rechtlichen Sachen nochmal reinkommen. Also es ist ja wohl so, dass der EVB-IT-Vertrag so die Grundlage ist. Marco, wie sieht das bei euch aus,

wenn ihr Ausschreibungen macht? Ist das auch auf EVB-IT-Basis oder? Ja, das müssen wir ja im Großen und Ganzen. Und wir haben in den letzten Jahren praktisch zwei Varianten gefahren. Ich hatte vorhin noch, während Arnoldes Vortrag war das, auch den Link ins Foskes Wiki reingestellt. Da sind auch zwei unserer Ausschreibungsunterlagen nochmal rein,

weil die aus den öffentlichen Portalen nach Zuschlag ja irgendwann wieder verschwinden. Die habe ich da einfach reingestellt, habe auch das Okay von unserer Beschaffungsstelle dafür bekommen. Also ist kein Problem. Und das sind genau zwei solche Beispiele, wie wir das gemacht haben. Einerseits ist es ein Erstellungsvertrag, weil das ein recht abgeschlossenes Projekt war.

Das war unser Open-Street-Maps-Stack, den mein Kollege Sven Burbek heute Mittag irgendwann vorgestellt hat. Da war vorher schon relativ klar, was man im Großen und Ganzen will und die Laufzeit. Und dann ging es nur darum, wer hat überhaupt die Expertise, die von uns gewünschten Techniken auch miteinander verknüpfen zu können. Das ist jetzt bei Open-Street-Map auch relativ gut,

an ein paar Fingern abzuzählen. Das ließ sich also dann relativ gut auch skalieren. Und das andere, was wir üblicherweise für die längeren Entwicklungen machen, sind Rahmenabrufverträge. Das heißt, wie schon mal gesagt, wir sind verantwortlich fürs Projekt. Wir kaufen uns eigentlich nur Entwicklungs- und ein bisschen Projektleitungs- Dienstleistungen mit ein.

Und das ist auch so ein bisschen die Vertrauensgeschichte. Wir formulieren ja in der Ausschreibung bereits, dass unser Ziel ist, als freie Software das zu entwickeln und zu veröffentlichen. Wir da nur Unterstützung brauchen. Eigentlich machen wir die Arbeit ja selbst, nicht als Manpower, aber von der Verantwortung her.

Und das ist natürlich auch eine Möglichkeit für die Firmen, die da dann auch den Zuschlag bekommen, dass die auch wissen, Moment, wenn wir dann im Geo-Server eine Zusatzfunktionalität reinbringen, weil das BFS das möchte, dann wissen wir auch, das BFS kann und will da auch gar nichts dagegen machen. Dass es auch vernünftig ins Projekt zurückfließt. Das fördert die Vertrauensbasis.

Und andererseits wieder für die Beschaffung, also für die Beschaffungsstelle bei uns. Die Rahmenabrufverträge, die haben keine Mindestabnahmen. Das heißt, wenn es tatsächlich überhaupt nicht geht, dann kann man diesen Vertrag letztendlich ungenutzt auslaufen lassen. Hätte vielleicht ein Problem, die exakte Leistung nochmal auszuschreiben.

Da weiß ich nicht genau, was man da machen müsste, um sich dann einen anderen Dienstleister zu suchen, der aber eigentlich das gleiche formal tun soll. Aber zumindest kommt man an der Stelle dann raus und ist nicht gezwungen, irgendwie mehrere Hunderttausend sozusagen einem Dienstleister zu geben für eine Leistung, mit der man letztendlich nicht zufrieden ist.

Ja, Torsten Friede vielleicht nochmal kurz ein, zwei Sätze zum EVBIT aus Entwicklersicht. Ich denke, das wird dir wahrscheinlich häufiger begegnen, wenn du sozusagen öffentliche Ausschreibung auch studierst. Studieren, das ist das richtige Wort. Das ist manchmal schon eine Herausforderung.

Natürlich für uns, wenn wir in der Rolle als Entwickler, als Dienstleister tätig werden, ist eine Dienstleistung, also ein EVBIT Dienstleistungsvertrag hat viele Vorteile. Wir können für die Tätigkeiten, die wir mit dem Auftraggeber abstimmen, die Zeiten, die wir für die Softwareentwicklung dann investieren,

direkt dann eben abrechnen. Das heißt, zum Beispiel in Form eines Sprints innerhalb eines vorgegebenen Zeitraums werden Aufgaben klar benannt. Die sind so fein granular beschrieben. Anus hatte das ja erwähnt über das Product Backlog,

eine User Story, sodass am Ende der Nutzen, der entwickelt werden soll, klar ist. Und wenn man innerhalb des vorgegebenen Zeitraums den dann umsetzt, dann freut man sich natürlich auch, wenn man dafür dann bezahlt wird. Und zwar für den tatsächlich geleisteten Aufwand. Nicht die Schätzungen, die man vorher abgegeben hat.

Im Rahmen des Planings werden ja auch Schätzungen erstellt. Die können ungefähr ein Indikator dafür sein, wo man dann vielleicht zeitlich bei rauskommt. Aber sie geben nicht exakt den Aufwand in Stunden oder Tagen an, sondern nur so einen groben Rahmen. Und dadurch kann eben der Auftraggeber wiederum steuern, oh, die Story ist mir zu groß vom Aufwand her,

damit auch das Risiko, dass wir nicht in der Zeit das schaffen. Er hat also die Möglichkeiten zu steuern. Das heißt, nochmal auf die Frage zurückzukommen, der EVB-Dienstleistungsvertrag passt da sehr gut für uns. Die anderen Verträge sind oft zu starr

und man muss sehr viel daran umbauen, um die wiederum für die agile Softwareentwicklung passend zu machen. Vielen Dank. Arnof, möchtest du vielleicht noch aus Projekt-Management-Sicht irgendwas zum EVB-T beitragen? Super Sache, wenn es ein Dienstleistungsauftrag ist.

Und was ich hier so sehe in dem Chat und auch meine sonstige Erfahrung, denke ich, wir sind da auf einem sehr guten Weg. Und ich bin mir absolut sicher, dass ich mir demnächst wieder was Neues suchen muss, weil Agile ist dann auch normal. Und da war eigentlich alles in der Tüte. Also, sehr schöne Runde. Hier hat mir sehr gefallen.

Und ich glaube, wenn es noch offene Fragen gibt, der Link ging auch schon rum. Im Forstgeswiki gibt es eine eigene Seite, wo wir jetzt schon seit einem halben Jahr Sachen zusammentragen und versuchen, das ein bisschen transparenter und klarer zu machen. Und ich fände es super, wenn wir diese Energie hier mitnehmen könnten aus dieser Runde und dort auch Leute eintreffen würden,

die sich noch nicht sicher sind und vielleicht Fragen haben. Und dass wir das dort weiterführen können. Genau. Ja, super, dass du darauf hinweist. Also, es ist eben diese Arbeitsgruppe. Nein, das ist nicht das Schlusswort. Und wir sind auch noch nicht ganz am Schluss. Wir haben tatsächlich noch fünf Minuten für unsere Abschlussstatements von allen noch mal.

Das nächste Treffen von eurer Arbeitsgruppe zumindest ist das. Mein letzter Stand ist am 21.2. um 20 Uhr. Das kann sich vielleicht schon mal jeder notieren, der gerade hier am Bildschirm zuschaut. Ich denke, es wäre wirklich klasse, wenn wir da die Energie dieser Diskussion hier mitnehmen könnten. Und genau, es ist ja auch dann eben alles im Wiki.

Und ich denke, es gibt viele Ansatzpunkte. Und ich glaube, das wird tatsächlich ein Thema sein, das in den nächsten Jahren an Bedeutung nur zunimmt. Ich möchte jetzt abschließend nochmal in die Runde fragen an jeden, was wären denn so Gelingensfaktoren, die jeder Einzelne nochmal sieht, um eben öffentliche Ausschreibung

und akiles Softwareentwicklung zusammenzubringen. Gerne auf Meldungen. Ich habe jetzt da keine Reihenfolge vorbereitet. Freiwillige vor. Ja, fange ich mal an. Stimme aus dem Off. Hier ist nochmal der Adolf. Ich fände es wichtig, dass wir den Product Owner,

die Product Ownerin tatsächlich freistellen, dass das nicht so eine Nebenbei-Arbeit ist, sondern die das wirklich hauptamtlich machen dürfen und dass sie mit denen kollaborieren dürfen. Kollaborieren ist ein böses Wort in Deutschland, dass sie zusammenarbeiten dürfen mit den Entwicklern oder einem Product Proxy auf der anderen Seite.

Da kann man ganz interessante Konstellationen zusammen bekommen. Je enger die Zusammenarbeit, da ist meine Erfahrung nach, umso besser wird das Ergebnis. Ja, Frau Krellmann, Ihre Einschätzung, was wären so Faktoren, die zu beachten wären? Ich schaue jetzt mal einfach in die Verwaltung hinein. Ich würde mir wünschen,

dass wir sowohl zum Thema agile Beschaffung, agiles Projektmanagement, Entwicklungen beziehungsweise Open Source auch innerhalb der Verwaltung mehr multidisziplinär arbeiten. Das stelle ich gerade ganz häufig fest. Gerade kam das ja schon mal. Dann gibt es die Innovativen, die Lust haben,

und dann brenzt Beschaffung und Vergabe. Oder wir haben die Rechnungsprüfung mit drin. Wir haben die Organisation mit drin. Und es sind ganz viele Akteure beteiligt. Und da müssen wir das Verständnis sowohl für die Relevanz von agiler Softwareentwicklung, aber auch von Open Source in dieser ganzen Personengruppe sozusagen stärken.

Es bringt halt nichts, wenn es nur punktuell ist. Sondern es muss wirklich vom Management auf top Ebene, würde ich sagen, mit aufgegriffen werden und an unterschiedlichsten Bereichen der Verwaltung gespiegelt werden. Das würde ich mir wünschen, dass uns das gelingt in den nächsten, ich sage jetzt mal zwei Jahren. Ich glaube, ein bisschen Zeit braucht es um hier.

Ja, da muss ich mit der Wunschliste. Also vielen Dank, Drossel-Friebe. Deine persönliche Wunschliste für agiles Software und öffentliche Ausschreibung. Ja, natürlich ganz viel Vertrauen. Auf beiden Seiten Vertrauen in die Entwicklungsfähigkeit aller Mitarbeitenden. Sich auch weiter entwickeln und weiter bilden zu können.

Das Vertrauen darin, dass Open Source Software die richtige Art der Investition ist. Auch in die Zukunft. Gerade für die öffentliche Hand. Und dann noch das Thema Transparenz. Also klar machen, wofür wird das Geld verwendet. Und nicht, dass es irgendwo verschwindet

in dunklen Kanälen, sondern wirklich transparent auch darlegen. Wenn mal eine Aufgabe länger gedauert hat, erklären, warum hat sie länger gedauert? Warum hat man Probleme gehabt? Diese Transparenz auch dem Auftraggeber gegenüber zu haben, finde ich ganz wichtig. Und hoffe, trägt dazu bei, dass die Projekte gelingen und alle dann auch ein gutes Gefühl dabei haben.

Das wäre schön. Nochmal ins aufgegebenen Thorsten Liebke. Gelegenheitsfaktoren. Ja, Gelegenheitsfaktoren. Kompetenz vor allen Dingen. Schön ist, wenn in der Verwaltung eine eigene Entwicklungsabteilung vorhanden ist. Wenn die nicht da ist,

dann wäre es schön, wenn wenigstens jemand da ist, der die theoretische Kompetenz hat. Das theoretische Wissen mitbringt. Und wie es jetzt auch schon benannt wurde, in der Lage ist, beide Sprachen irgendwie so ein bisschen zu können. Ich glaube, da ist relativ viel dran. Es sind wirklich komplett unterschiedliche Sprachen. Ich weiß nicht, ob euch das hier gerade aufgefallen ist.

Aber mit all den Vokabeln, die jetzt gerade in der letzten Viertelstunde gekommen sind, brauche ich bei mir eine IT-Abteilung oder eine Beschaffungsstelle nicht kommen. Die wissen nicht, wovon wir reden. Und ziehen sich dann auf ihr eigenes, sicheres Feld zurück. Und deshalb glaube ich, ein großer Gelegenheitsfaktor ist

dieses Passwort-Bingo aufzubrechen und ein gewisses Sprachverständnis zu schaffen. Und von daher finde ich die Arbeitsgemeinschaft, so wie sie jetzt hier ist, auch ganz wichtig. Und wir sind ja dabei, eine Handreichung zu erstellen für beide Seiten, dass sie eine gemeinsame Sprache miteinander finden. Aber grundsätzlich ist jetzt auch schon mehrfach genannt worden,

man kommt nicht umhin, die Kompetenz in die Verwaltung zu bringen. Und da muss die Führungsebene dann eben doch mal den einen oder anderen noch mal irgendwie einstellen. Ja, in jedem Fall. Vielen Dank. Dann gebe ich noch an Marco Lechner, der hier in unserer Runde quasi das letzte Statement abgeben darf.

Bitte Marco. Danke. Ich werde natürlich dann nochmal dir das Wort übergeben. Oder du wirst es dir hoffentlich nochmal nehmen. Ich wünsche mir an der Stelle, dass das Thema digitale Souveränität kein Passwort wird, sondern tatsächlich ein Impuls ist

von allen Behörden auf allen Ebenen, dass dann auch die IT- und Beschaffungsstrukturen da auch einen Veränderungsprozess vollziehen können. Dass es natürlich die Personen von unten braucht, auch von den Fachanforderungen her, die das wollen und das auch dann vielleicht initiieren. Dass aber, wie es ja vorhin auch schon gesagt wurde,

über das Thema digitale Souveränität auch erkannt wird, dass solche Ausschreibungsverfahren eben eigentlich genau der Weg sind, digitale Souveränität zu erreichen. Und dass das dann eben auch von den Behördenleitungen mitgetragen und gewollt wird. Denn nur wenn es gewollt wird, wird es dann auch vernünftig funktionieren.

Das hoffe ich mir. Und ja, da hoffe ich auch, dass der Vosges einen Beitrag dazu leisten kann, indem er an dem Thema dran bleibt. Danke. Ja, klasse. Genau, vielen Dank. Ich denke auch, die Diskussion fand ich persönlich sehr, sehr anregend. Es macht Lust auf mehr.

Gute Nachricht ist, es kann mehr geben. Die Arbeitsgruppe trifft sich regelmäßig, was wir auch geplant hatten. Und ich hoffe, dass einige der Diskussionsteilnehmer auch mitkommen, ist, dass wir jetzt gleich in einen der BOF-Räume wechseln, und zwar in den BOF-Raum 1. Wer Lust hat, da noch rüberzukommen und vielleicht ein bisschen Q&A zu machen.

Ich würde mich freuen. Ich gehe auf jeden Fall gleich rüber. Wir sehen uns dann in einigen Minuten drüber. Drüben im BOF 1. Die Arbeitsgruppe, Thorsten Wiebke, du hast das gerade eben hier im Chat gepostet. Das nächste AG-Treffen ist der 24. oder 25.3. Also war das vorher falsch von mir mit dem 21.2., oder?

Da läuft ja noch ein Dudel, aber ja. Gut, aber der Link auf die Arbeitsgruppe steht. Ich denke, man kann euch auch nochmal dann anschreiben, denke ich mal, wenn man interessiert ist, hier in der Arbeitsgruppe teilzunehmen. Ich denke, es ist ein wahnsinnig wichtiges Thema. Ich finde, die Diskussion hat sehr viel Mut gemacht, auch für diese Leute, die jetzt hier im Publikum sitzen,

die ja diesen Kulturwandel in der Behörden auch durchsetzen müssen, so wie das Marco vor auch beschrieben hat. Und ja, ich würde mich freuen, wenn da unsere Diskussion einen kleinen Impuls für leisten konnte. Und würde mich freuen, wenn wir einige der Zuschauer dann auch gleich nochmal im BoF-Raum sehen. Ich danke allen Diskutanten ganz herzlich. Ich danke insbesondere Ihnen, Frau Krellmann,

dass Sie sich die Zeit genommen haben, uns hier beim FOSKIS zu besuchen. Und ja, vielleicht ergibt sich ja irgendwann die Gelegenheit, dass Sie auch nochmal einen Vortrag hier auf der Konferenz halten. Ich denke, Sie können da wirklich sehr interessante Impulse gerade aus Ihrer Praxis auch setzen. Und vielen Dank auch allen anderen. Und ich wünsche auch dem Publikum noch einen schönen Abend. Vielen Dank. Tschüss.