Ja, hallo und herzlich willkommen zur 132. Ausgabe des eGovernment Podcasts. Ich bin Thorsten Frenzel und ich habe heute wieder Gäste in meinem virtuellen Studio. Diesmal endlich mal weibliche Gäste. Wunderbar, ich freue mich total. Und zwar die Christina und die Stefanie. Hallo ihr beiden.

Hallo Thorsten.

Dann fangen wir doch ganz einfach mal an mit der Christina. Wer bist du denn?

Ich bin die Geschäftsführerin des Digitalservice und vom Hintergrund Juristin. Ich habe die Organisation auch 2019 mitgegründet, aber ich glaube, da gehen wir ja gleich nochmal vielleicht auch ein bisschen intensiver drauf ein. Deshalb würde ich jetzt gar nicht so viel mehr sagen.

Ja, vielen Dank. Und Stefanie, wer bist du denn?

Dann sage ich das noch genau. Ich bin Stefanie, Chief Product Officer beim Digitalservice und ja, ich bringe so 19 Jahre Berufserfahrung in der Produktentwicklung mit und der dazugehörigen Teams und Organisationen und habe das in unterschiedlichen Bereichen schon gemacht und bin jetzt schließlich bei der Verwaltungsdigitalisierung gelandet. Wie mir scheint, die Königsdisziplin.

Ja und eines der spannendsten Felder, die es momentan gibt, also meiner Meinung nach.

Ja, auf jeden Fall. Also ich habe tatsächlich im Entertainment angefangen und habe auch mal eine ganze Weile Spiele entwickelt und da sehr viel gelernt über nutzerzentrierte Softwareentwicklung. Bin dann in den Gesundheitsbereich gegangen und da war ich dann schon im hochregulierten Bereich. Da war die Verwaltungsdigitalisierung nicht mehr weit.

Naja, Entertainment gibt es in der Verwaltungsdigitalisierung auch genügend.

Das kann man so sagen, ja.

Genau, aber dann fangen wir doch einfach mal an. Ihr habt jetzt gerade sowas gesagt wie Digitalservice oder Digitalservicebund. Und was ist denn das?

Genau, wir sind eine interne Digitalisierungseinheit auf der Bundesebene und ich glaube, was uns im Kern auszeichnet, ist, dass wir eigene Softwareentwicklungsteams aufbauen innerhalb der Bundesverwaltung, die dann wirklich Ende-zu-Ende-Produkte entwickeln und betreiben können. Und wir machen das seit ein bisschen mehr als zwei Jahren mittlerweile. Wir sind 2020 vom Kanzleramt aufgekauft worden. Wir haben ein Jahr vorher gestartet als eine Non-Profit-Organisation, die Fellowship-Programme organisiert hat. Tech for Germany und Work for Germany. Und das war so ein bisschen der Nukleus dafür, dass das Kanzleramt dann mit uns in Gespräche gegangen ist. Sie hatten damals schon die Schirmherrschaft für das Fellowship und wir uns gemeinsam mit Frage beschäftigt haben, wie kann man diese Menschen, die sich für so ein Fellowship bewerben und dann auch für drei Monate begeistert und total motiviert mit der Verwaltung zusammenarbeiten, wie kann man die eigentlich auch dauerhaft für die öffentliche Verwaltung gewinnen? Weil wir in den ersten zwei Jahrgängen bei Tech for Germany gesehen haben, dass viele von diesen Profilen sich danach nicht in der Verwaltung direkt oder auch in den bestehenden behördlichen Strukturen bewerben. Und das war der Geburtsgedanke für den Digital Service.

Und du hast gerade gesagt, ihr habt eigene Entwicklerteams. Was ist denn eure Aufgabe? Seid ihr quasi das Entwicklungsunternehmen des Bundes oder habt ihr andere Aufgaben?

Das ist eine große Frage. Also das Interesse an des Bundes daran, diese Softwareentwicklungskompetenzen auch innerhalb der eigenen Verwaltungsstrukturen aufzubauen, ist erstmal kein ganz Neues gewesen. Aber wir haben 2020 gesehen, dass in der damaligen Legislaturperiode, es gab ja auch Gespräche darüber, eine E-Government-Agentur zu gründen und es gibt andere Akteure, es gab die OZG-Labore, es immer relativ schwer war, diese Talente in die öffentliche Verwaltung zu bekommen. Und das war etwas, was wir mit dem Fellowship-Programm überraschend gut hinbekommen haben. Also wir haben damals noch zum großen Teil Berufseinsteiger dafür begeistern können, sich für dreimonatige Programme, Projekte mit der Verwaltung zu bewerben. Und das hatte ich ja eben schon gesagt, die sind aber danach nicht in der Verwaltung geblieben. Und dafür wollten wir eine Lösung finden. Und wir haben deshalb auch in dieser Bundes-GmbH-Logik gesagt, wir brauchen etwas, was ein bisschen einen geschützten Organisationsrahmen bietet, weil wir eine andere Arbeitskultur anbieten wollen, die sich schon in bestimmten Bereichen von der Art und Weise, wie Softwareentwicklung in der Verwaltung heute gedacht und dann auch umgesetzt wird, unterscheidet. Aber gleichzeitig wollen wir auch nicht ein klassischer externer Dienstleister sein, der mit einem konkreten Scope oder schlimmstenfalls einem Lastenheft beauftragt wird und das dann drei bis fünf Jahre entwickelt und zurückkommt und ein Ergebnis vor die Tür stellt. Sondern wir wollen ein interner Umsetzungspartner sein, der mit den Fachbereichen in den Ressorts auf Augenhöhe zusammen und zwar schon im Problemraum gemeinsam, nutzendenzentriert arbeitend Softwareprodukte konzipiert, entwickelt, umsetzt und betreiben kann.

Und du hast gerade gesagt, ihr kommt ursprünglich aus dem Bereich mit Fellowships. Wie ist denn da die Nachhaltigkeit? Wie viele Leute bei euch kommen aus den Fellowships oder wie viele Leute könnt ihr nachhaltig halten bei euch?

Tatsächlich haben wir aus den Fellowship-Programmen immer aus jedem Jahrgang so knapp ein Drittel übernommen. Wir haben nochmal dann einen separaten Auswahlprozess nach dem Fellowship-Programm. Was wir jetzt aber gerade in den letzten anderthalb Jahren gesehen haben, ist, dass sich zunehmend auch sehr erfahrene Leute, ich meine, Steffi ist ein gutes Beispiel dafür, aber wir haben auch gerade im letzten Jahr viele andere Leute für die Arbeit im Digitalservice gewinnen können, die 15, 20 Jahre Industrieerfahrung mitbringen und jetzt sagen, ich könnte jetzt die siebte App entwickeln in irgendeiner Industrie, aber ich möchte mal das, was ich alles schon an Erfahrungswissen, an an Kompetenzen mitbringen, in einem Bereich anwenden, der wirklich sinnhaft ist, wo man wirklich was verändern kann. Und genau, den Leuten bieten wir eine Heimat. Und die können wir auch ganz gut halten.

Okay. Und wahrscheinlich trotzdem mit externen, oder? Kriegt die Teams noch nicht komplett gestafft mit euren eigenen Leuten?

Tatsächlich, das ist schon grundsätzlich ein bisschen ein Unterschied auch zu anderen IT-Dienstleistern und wie die sich strategisch aufstellen. Wir haben den Anspruch, dass wir komplett eigene interne agile Teams aufbauen. Wir arbeiten vereinzelt mit Freelancern zusammen, aber wir sind jetzt nicht, also zum Beispiel das ITZ Bund gibt ja auch sehr viel dann wieder über Projektbeauftragungen raus an externe Dienstleister. Das ist nicht unser Geschäftsmodell.

Du hattest gesagt, ihr kommt von dem Fellowship-Gedanken. Wie hat sich die Rolle denn so verändert in letzter Zeit? Also ihr habt wahrscheinlich jetzt einen ganz, ganz anderen Auftrag.

Ja, wir machen nach wie vor die Fellowship-Programme, weil die uns eine gute Basis dafür geben, in die Breite zu wirken. Und das, was wir in unserer eigenen Produktentwicklung lernen, was wir da an Veränderungen vorantreiben können, auch anderen wieder zugänglich zu machen. Aber mittlerweile arbeiten 70 Prozent unserer Organisation in den eigenen Softwareentwicklungsprojekten. Wir sind mittlerweile über 120 Leute. Und davon organisieren zehn Personen die Fellowship-Programme. Und der Rest arbeitet in der Produkteinheit.

Jetzt hast du gerade schon gesagt, Programme und Produkte. Was habt ihr denn für Projekte?

Ich glaube, das kann unsere Chief Product Officer sehr gut erzählen.

Genau, also von den Fellowships mal abstrahiert, haben wir Projekte in verschiedenen, sag ich mal, größeren Bereichen. Also zum Beispiel Steuer und rund um Steuererklärung Steuererklärung haben wir zunächst mal eine vereinfachte Steuererklärung für RentnerInnen entwickelt. Dann haben wir die Grundsteuererfassung entwickelt, also eine Grundsteuererklärung für Privateigentum, die auch immer noch online ist, wenn gleich natürlich die Erfassungsperiode eigentlich zu Ende ist. Aber es immer noch Menschen gibt, die ihre Grundsteuererklärung abgeben. Wir arbeiten im Bereich digitale Identitäten an einer App, die es NutzerInnen erlaubt, ihren Ausweis zu nutzen, um sich online zu identifizieren. Und dann arbeiten wir noch im Bereich Open Data an einem Projekt. Da geht es um die Veröffentlichung von Rechtsinformationen. Da arbeiten wir vor allen Dingen mit den Bundesgerichtshöfen zusammen, mit denen wir gemeinsam iterativ die Software entwickeln, die sie nutzen, um ihre Urteile zu erfassen. Und dann an der Datenhaltung und an einer API, damit diese Daten auch für alle verfügbar gemacht werden können. Und, und das finde ich besonders spannend, und da können wir auch noch mal detaillierter darauf eingehen, wir arbeiten an einem Projekt, das nennt sich DigitalCheck, in dem wir tatsächlich keine Software entwickeln, weil wir aber im letzten Jahr gemerkt haben, dass es wahrscheinlich nicht ausreicht, in Anführungszeichen, nur digitale Produkte zu bauen, um zu einem digitalen Staat zu kommen, der das Leben der Bürger vereinfacht, sondern dass es da ganz stark auch um Prozesse und vor allen Dingen um die zugrunde liegende Gesetzgebung geht, arbeiten wir an einem Projekt namens Digitalcheck. Da kann ich auch gerne noch mehr zu erzählen.

Ja, da bitte ich darum, weil zum Thema Digitalcheck suche ich immer noch Leute, die mir was erzählen dazu. Aber vielleicht können wir das auch nochmal auslagern in eine Extrasendung. Vielleicht kannst du nochmal ganz grob umreißen, was Digitalcheck ist. Untertitel im Auftrag des ZDF für funk, 2017.

Ja, total gerne. Da habe ich auch tatsächlich so ein bisschen mein Herz dran verloren. Also ich muss ja sagen, ich komme ja, wie gesagt, aus der Softwareentwicklung. Das ist, was ich die letzten 20 Jahre gemacht habe. Und jetzt haben wir, wenn wir mal das Beispiel Grundsteuererklärung nehmen, da haben wir eine Software entwickelt, die eine vereinfachte Abgabe der Grundsteuererklärung ermöglicht. Und das haben auch sehr viele BürgerInnen genutzt. Da haben fast eine Million Menschen ihre Grundsteuererklärung abgegeben. Wir haben sehr viel positives Feedback bekommen. Und trotzdem ist es so, dass ich denke, wenn wir in sieben Jahren, da ist die nächste Erfassungsperiode, nochmal eine Software für die Grundsteuererklärung bauen, dann sind wir nicht so weit gekommen in Deutschland und auch nicht mit unserer Mission beim Digitalservice. Warum ist das so? Weil wir damit immer nur das Interface, also die Software mehr oder minder, entwickeln, die der Bürger oder die Bürgerin sieht. Aber eigentlich, wo wir doch eigentlich hinwollen, ist die Verringerung des Aufwands an dieser Schnittstelle zwischen BürgerInnen und Staat. Und da ist doch eigentlich die beste digitale Lösung am Ende des Tages die, die ich als BürgerInnen gar nicht mehr anfassen muss, weil alle Daten vorhanden sind. Und dazu muss man sich aber die dahinterliegenden Prozesse und vor allen Dingen die dahinterliegende Gesetzgebung anschauen. Und das Ziel des Digitalchecks ist es eigentlich, ich sage mal, so einen Methodenkasten zu entwickeln, der es Legisten und Legistinnen, das sind die, die die Gesetze schreiben, ermöglicht Digitaltauglichkeit auch schon während der Entwicklung des Gesetzes mitzudenken, dass am Ende Gesetze entstehen, die einer digitalen Umsetzung nicht im Weg stehen. Ich glaube, ohne das werden wir nie in der Lage sein, in Deutschland gute digitale Lösungen zu bauen.

Genau, da haben wir… Ja, gebt ihr da vielleicht den Legisten auch Werkzeuge an die Hand, dass man zum Beispiel gemeinsam an Texten arbeitet, also à la GitHub.

Ja, also das ist auf jeden Fall eine Ausbaustufe, die man sich total vorstellen kann. Da träume ich auch noch so ein bisschen von. GitHub für Gesetzgebungsverfahren. Wir haben jetzt erstmal, also wir arbeiten in dem Projekt gemeinsam mit dem BMI, das da federführend verantwortlich ist und haben im letzten Jahr eine, ich sage mal, Beta-Version für den Digital-Check entwickelt. Das sind zunächst mal, sind das fünf Prinzipien, die, wie sie auch in Dänemark entwickelt worden sind, die, ich sag mal, wie so eine Guideline sind und auch für alle verständlich. Und dann haben wir, ich sag mal, Methoden entwickelt für den Prozess, der sich vor allen Dingen bezieht auf den frühen Erarbeitungsprozess eines Regelungsvorhabens. Also praktisch bevor ich ein Gesetz schreibe, stelle ich mir bestimmte Fragen, um Digitalisierungstauglichkeit mitzudenken. Und da geht es natürlich auch sehr stark darum, darum, welche Fachlichkeit muss ich eigentlich einbeziehen, um meine Fragen diesbezüglich zu beantworten? Weil am Ende, ich weiß auch nicht, wie ein Gesetz geschrieben wird, und die Legistin oder der Legist muss auch nicht wissen, wo kommen jetzt die Daten her, wenn ich zum Beispiel ein automatisiertes Verfahren ermöglichen möchte.

Und ich glaube, vielleicht da ganz kurz ergänzend, das ist eine so der Kernherausforderung bei digitaltauglicher Gesetzgebung, weil wenn man an DigitalCheck denkt, das hattest du, Das hast du, glaub ich, auch eben angeschnitten, Thorsten. Das klingt ja erst mal so wie ein Prozessschritt, den man eben ganz am Ende auch noch abhakt. Aber was wir eigentlich erreichen wollen, ist, dass Menschen ihre Kernarbeitsweise, nämlich Legiste und Registen, die Art und Weise, wie sie an so ein Gesetzesentwicklungsprozess rangehen, anders angehen und schon von Anfang an Digitaltauglichkeitsfaktoren mit berücksichtigen. Und deshalb ist das kein reines Wir entwickeln jetzt noch eine zusätzliche Checkliste, Sondern wir müssen ran an das Mindset und die Haltung der Menschen, die bisher eben Gesetze entwickelt haben, bei denen Digitaltauglichkeit gar keine Rolle gespielt hat. Und dafür gilt es, Methoden zu entwickeln. Und die müssen wir dann auch nutzend zentriert, nämlich mit den Legistinnen und Legisten ausprobieren. Was verstehen die, was nicht, was hilft ihnen tatsächlich im Alltag. Damit das am Ende die Wirkung entfaltet, die wir brauchen.

Ich sehe schon, ich glaube, das Thema müssen wir vertiefen. Also das müssen wir nochmal auslagern in einer Extrasendung. Vielleicht laden wir uns da noch ein paar andere Leute mit ein, zum Beispiel vom Normenkontrollrat, um hier noch ein bisschen tiefer reinzugehen. Machen wir einfach mal weiter mit dem Digitalen, auch wenn jetzt die Hörerinnen und Hörer vielleicht traurig sind, dass wir hier nicht weiter eingehen. Aber da kommt was. Ich habe jetzt gerade Normenkontrollrat gesagt und da kommt mir sofort das Wimmelbild in den Kopf. Und im Wimmelbild ist auch ein Logo von euch und diese komplexe Ökosystem, diese komplexe Landschaft der Verwaltungsdigitalisierung. Welche Rolle spielt ihr denn da? Mit wem seid ihr da vernetzt? Welche Aufgaben habt ihr ganz konkret? Arbeitet ihr nur auf Bundesebene oder geht es auch über andere Ebenen hinweg?

Wir arbeiten nur auf Bundesebene, als eine Bundes GmbH können wir auch nur von der Bundesverwaltung direkt beauftragt werden. Wir sind vernetzt, beziehungsweise tauschen uns aus mit ganz schön vielen Akteuren auf dem Wimmelbild. Ich weiß gar nicht, ob das Sinn macht, die jetzt alle aufzuzählen, aber wir sind bei Next engagiert, wir tauschen uns mit der FITKO aus, wir sprechen mit der Digitalakademie. Wir haben auch gemeinsame Büroräumlichkeiten mit Next und der Digitalakademie, aber auch GavTech Campus, Zendes, also verschiedene, sovereign tech fund, verschiedene Akteure, die auch teilweise schon länger oder kürzer existieren als wir, sind wir im Gespräch. Das ITZ Bund war auch gerade bei der Gründung des Digitalsoft relativ eng mit einbezogen. Ich glaube, so wie wir unsere Rolle verstehen, ist, in erster Linie entwickeln wir strategisch relevante Softwareprodukte für die Bundesverwaltung selbst. Für diese Projekte werden wir beauftragt von der Bundesebene, aus den IT-Budgets der verschiedenen Ressorts. Und wir haben einen Auswahlprozess, mit dem wir sicherstellen wollen, dass die Lösungen, zu denen wir uns am Ende auch verpflichten, für die wir Verantwortung übernehmen, dass das Produkte sind, die einen gewissen strategischen Mehrwert auch bieten, also die viele Menschen erreichen, die eine relevante Veränderung für Bürgerinnen und Bürger bedeutet und die gleichzeitig vom Scope her zum einen so lösungsoffen sind, dass wir wirklich nutzendenzentriert arbeiten können, das nicht eigentlich am Anfang schon fest steht, was genau am Ende gebaut werden soll und die auch nicht so komplex sind, dass wir die mit unserem noch relativ kleinen Team in den ersten zwei Jahren auch verantworten können. Und was wir sehen ist, also der initiale Gedanke war ja, dass die Lösungen, die auch im OZG-Kontext entwickelt worden sind, oder die Art und Weise, wie man über OZG nachgedacht hat, dass es am Ende, dass die Nutzendenzentrierung häufig nicht im Mittelpunkt stand. Und das war so ein bisschen die Kernfragestellung, mit der wir auch gestartet sind und mit der wir uns immer wieder auseinandersetzen. Was sind so strukturelle Hürden in der Art und Weise, wie die öffentliche Verwaltung und gerade dann die Bundesebene, aber die dahinterliegenden Prozesse und Regularien sind ja eigentlich für Länder und Kommunen ähnlich. Wo muss sich strukturell was verändern, damit wir zu wirklich nutzender, quasi nutzendezentrierter Softwareentwicklung kommen? Dass wir iterativ, datengetrieben arbeiten können. Und das probieren wir in einzelnen, konkreten Projekten aus. Aber wir versuchen auch, weil wir eine interne Einheit sind, die eng mit der Verwaltung zusammenarbeitet, wir versuchen auch, das, was wir lernen, irgendwie für andere aufzubereiten und nachnutzbar zu machen und dann wieder eben über so Organisationen wie Next oder, dass wir viele Open Sourcen, dass wir auch Konzepte zur Verfügung stellen, dass wir uns mit anderen Akteuren austauschen, die Erkenntnisse wieder anderen zur Verfügung zu stellen.

Jetzt haben sich ganz viele Fragen bei mir. Jetzt muss ich mal sehen, ob ich die in die richtige Reihenfolge kriege. Du hast gesagt, ihr übernehmt Projekte, wo noch nicht am Ende, noch nicht am Anfang feststeht, wie es am Ende ausschauen wird. Du hast iterativ gesagt, du hast, ich habe extra hingehört, du hast das Wort agil vermieden. Kommt die Bundesverwaltung damit zurecht, dass sie etwas beauftragen, wonach nicht feststeht, wie es in drei Wochen ausschaut oder Ende des Jahres ausschaut und wo ein Datum dransteht, wann das jetzt fertig ist und ausgerollt wird?

Ich glaube, das ist genau die Übersetzungsarbeit, die wir hier leisten müssen. Und dass das natürlich schwierig abzubilden ist, ist klar. Aber, ähm, also... Dadurch, dass wir aus privatwirtschaftlichen Kontexten auch viel kommen, verfolgen wir eben dieses nutzerzentrierte, iterative, zahlengetriebene, weil das unsere feste Überzeugung ist, dass das der einzige Weg ist zu guten digitalen Lösungen. Und unsere Aufgabe ist es jetzt, das eben in die Rahmenbedingungen, auf die wir treffen, die Rahmenbedingungen dafür zu schaffen, mit den Ministerien gemeinsam, und das übrigens mit einer sehr großen Offenheit, dass wir also nicht kommen und sagen, wir wissen genau, wie es geht, sondern dass wir das gemeinsam erarbeiten mit den Ministerien und in ihren Rahmenbedingungen, in denen sie das tun. Das ist also, wie gesagt, eine sehr große Übersetzungsleistung und wir verstehen das als eine Partnerschaftlichkeit auch, also dass wir in einer Partnerschaftlichkeit zusammenarbeiten. Und am Ende des Tages wird das ja in einem Vertrag abgebildet. Und das ist auch was, was wir iterativ weiterentwickeln, wo wir einfach merken, Verträge sind ja normalerweise, in denen steht drin, was wird geliefert, in welchem Zeitraum und wie viel kostet das. Und unsere Verträge, das kann man auch online nachschauen, da haben wir einige unserer Verträge veröffentlicht, versuchen eben genau diese Art und Weise, wie wir arbeiten müssen, um die Qualität unserer Produkte sicherzustellen, die Verträge bilden genau das ab. Und ich würde nicht sagen, dass wir da schon am Ende sind, sondern dass wir das auch weiter iterativ entwickeln werden. Aber wie, denke ich, alles in unserer Organisation.

Und vielleicht, das wird ja wahrscheinlich auch den meisten Hörerinnen und Hörern was sagen, es gibt einfach oder es gab, ich glaube, es gibt immer noch keine, es gibt keine EVB-IT-Verträge, die speziell ausgerichtet sind auf agile Softwareentwicklung. Und deshalb haben wir in dem Bereich dann mit den Ministerien, mit denen wir zusammenarbeiten, aber wie gesagt, die Vertragskonstrukte, die veröffentlichen wir auch, einen Weg entwickelt, aufbauend auf EVB-IT, Also auf diesen Standard-Vertragsbedingungen, mit denen die öffentliche Hand Softwareprodukte beauftragt, einkauft, selbst entwickelt. Wie man da agil vorgehen kann. Und wie Stefanie gerade schon sagte, da wird eben weniger eine Lösung beauftragt und mehr ein bestimmtes Vorgehen.

Das klingt interessant. Weil ich mache ja auch hier und da mal Projekte. Und am Anfang sind sich immer alle einig, wir machen das agil und Schritt für Schritt, iterativ. Und dann kommt trotzdem nach ungefähr der Hälfte die Frage, wann ist es jetzt endlich fertig? Versprochen zu einem bestimmten Datum.

Ja, und Thorsten, das ist ja auch total nachvollziehbar, wenn man sich in die andere Seite reinversetzt, halte ich das für, also das ist verständlich. Da treffen allerdings Welten aufeinander. Du weißt es ja selber, wir können eben, wenn wir nutzerzentriert und wir vermeiden übrigens das Wort agil. Nur manchmal deshalb, weil es in so vielen Kontexten auch falsch verwendet wird und sagen, deshalb lieber iterativ und Daten und Erkenntnis getrieben, dass man in so einem Prozess eben einfach genau nicht sagen kann, bis wann eine Lösung fertig, das Wort fertig würde ich übrigens in diesem Kontext auch nicht verwenden, sondern sagen wir mal, ein erste Minimalversion eines Produktes live ist, das auch schon Mehrwert bietet und dass man dann eben kontinuierlich weiterentwickeln kann. Also so diese ganze Frage von Betrieb. Betrieb bedeutet für uns auch kontinuierliche Weiterentwicklung. Das ist, glaube ich, noch mal ein sehr wichtiger Punkt.

Also das Konzept des MVP ist angekommen und wird akzeptiert?

Ja, also wir haben das jetzt in verschiedenen Projekten schon im letzten Jahr erlebt, dass wir, also ich muss vielleicht noch mal einen Schritt zurückgehen, wir unterteilen unsere Projekte in Projektphasen und es beginnt mal mit einer Anbahnung. Und in dieser Anwarnung geht es ganz stark darum, dass wir mit den ProjektpartnerInnen in den Ministerien darüber sprechen oder gemeinsam definieren, was ist eigentlich das Problem, was wir hier gemeinsam lösen wollen. Und mal aus dem Lösungsraum, in dem man immer schnell ist, aus dem Lösungsraum weggehen und nochmal zurückgehen und sagen, okay, was ist wirklich das Problem, was wir versuchen zu lösen. Und dass wir anhand dieses Beispiels dann auch unsere iterativen Arbeitsweisen erklären und uns so in unseren Arbeitsweisen eigentlich aneinander annähern. Das Ergebnis davon ist dann ein Vertragswerk. Idealerweise ist das auch übrigens dann keine Vertragsverhandlung mehr, sondern nur noch ein Gespräch, weil man sich darüber schon ausgetauscht hat. Dann haben wir eine sogenannte Discovery-Phase, in der wir dann schauen, ist das Problem, was wir hier definiert haben, ist das eigentlich wirklich ein Problem? Das tun wir, indem wir ganz viel NutzerInnen und StakeholderInnen involvieren und eben versuchen zu verstehen, welches Problem ist das ein Problem, das wir hier versuchen zu lösen. Und erst dann, wenn wir das haben, und das involviert auch schon ganz viel Entwicklung von Prototypen, Prototypen, damit meine ich, das kann auch total No-Code sein, also ohne irgendwelchen Code geschrieben zu haben, können wir es doch aber schaffen, eine Version von einer Lösung zu entwickeln, die wir schon Leuten in die Hand geben können. Dann können wir diese Personen einladen und dann gucken wir denen über die Schulter und versuchen so rauszufinden, ist das, löst dieser Prototyp, den wir da gerade entwickelt haben, eigentlich schon das Problem. Und erst dann kommen wir zu einem, sagen wir mal, Konzept eines MVPs. Und das haben wir jetzt gerade im letzten Jahr im BMJ, Justizministerium, genau zweimal eigentlich durchexerziert. Und in beiden Projekten arbeiten wir jetzt an einem MVP. Das freut mich sehr. Und es war auch sehr viel, wie gesagt, Übersetzungs- und Transferleistung. Das habe ich ja vorhin schon gesagt. Das ist, glaube ich, unsere ganz große Aufgabe.

Und vielleicht ist ein ganz gutes anderes Beispiel die Steuerprojekte, weil da jeweils ganz klar feststand, bis zu welchem Zeitpunkt muss eigentlich eine erste zur Verfügung stehen, weil es Abgabeperioden gibt. Das war bei der Steuererklärung für Rentnerinnen und Rentner klar, dass die Anfang Mai live gehen muss, weil die Abgabeperiode Ende Juli endet. Für die Grundsteuererklärung war das vergleichbar. Es war Anfang Juli und initial sollte die Abgabefrist Ende Oktober enden. Die wurde ja dann einmal verlängert. Und wir können ja auch getimeboxed arbeiten. Wir können, wenn wir den Projekt-Scope einigermaßen, also den Umfang der Lösung, die angeboten werden soll, einigermaßen verstanden haben über so eine Discovery-Phase, dann können wir auch sagen, ja, wir übernehmen die Verantwortung, dass bis zu dem Zeitpunkt etwas live geht, was ein bestimmtes erstes Problem löst. Aber wir behalten uns dann auch in der Art und Weise, wie wir entwickeln, offen, welchen Funktionsumfang dieses Produkt schon genau hat. Und gerade bei Grundsteuererklärung konnten wir mit dem Finanzministerium dann auch sehr schön über diese vier, beziehungsweise am Ende waren es dann sieben, wenn ich mich jetzt grad nicht verrechne, Monate, datengetrieben weiterentwickeln. Also wir haben durch das Feedback der Nutzenden gesehen, was sind denn jetzt eigentlich konkrete Features, die man noch ergänzen müsste? Gibt es mehr Menschen, die das nutzen wollen, die eine Garage haben oder deren Hausdenkmal geschützt ist? In der Phase, in der das Produkt schon live war, die Lösung so erweitern, dass wir für möglichst viele Menschen ein Angebot schaffen können.

Das klingt so, als ob ihr so arbeitet, wie das moderne, hippe Startups gerne machen würden.

Wir arbeiten so, wie wir sicherstellen können, dass wir Produkte bauen, die auch ein Problem lösen und die möglichst einfach zu nutzen sind und vielleicht sogar in der Nutzung ein bisschen Spaß machen.

Ja, für mich klingt das sehr interessant, also auch dieser Ansatz so zu arbeiten. Gut ab.

Vielleicht noch ergänzend zu dem, was Christina gerade gesagt hat. Ich glaube, was dem zugrunde liegt, ist, dass wir sagen, es gibt eigentlich, es gibt nicht zwei fixe Aspekte. Man kann nicht sagen, die Timeline ist fix und der Funktionsumfang ist fix. Das funktioniert nicht in der modernen Softwareentwicklung. Und gerade bei Grundsteuer hat das aber sehr gut funktioniert. Und ich glaube, mir ist nochmal wichtig zu sagen, dass wir auch, dass uns extrem wichtig ist, den Funktionsumfang unserer ersten Produkte so klein wie möglich zu halten, aber natürlich schon benutzbar, damit wir möglichst schnell die Produkte, die wir entwickeln, mit der Realität konfrontieren. Weil erst dann können wir tatsächliche Daten erheben zur Nutzung. Und natürlich datensparsam, aber nur so – da spricht auch wieder das Produktmanagerinnen-Herz – nur Nur so können wir ja unsere Hypothesen validieren, nur so können wir rausfinden, ob das jetzt leicht zu nutzen ist oder nicht, oder wo brechen die Leute ab. Und nur so können wir dann auch iterativ ein Produkt wirklich weiterentwickeln. Und deswegen ist uns dieses frühe, aber auch stille Veröffentlichen übrigens sehr, sehr wichtig.

Dieses stille Veröffentlichen, spielt das in diesen Transparenzgrundsatz mit rein, den ihr verfolgt?

Ja, ich glaube, was wir damit meinen, ist nicht so sehr, dass wir das verstecken, sondern dass es nicht ein großes Live-Event gibt, mit dem eine Ministerin oder ein Minister auf den roten Knopf drückt. Und es gibt eine begleitende Medienkampagne. Sondern wir entwickeln die meisten unserer Produkte ja auch offen. Also wir stellen nicht nur im Nachgang... Den Code zur Verfügung, sondern man kann, wenn man das möchte, über GitHub verfolgen, woran wir gerade arbeiten und entwickeln halt offen. Aber wir, ich mein, Steffi, das kannst du wahrscheinlich besser erklären, aber wir nehmen uns eben auch nach der Veröffentlichung ein bisschen Zeit, ohne große Medienaufmerksamkeit, auf die Produkte zu lenken, um so initiale Bugs zu fixen, zu testen. Auch im Live-Betrieb funktioniert das wirklich alles so, wie wir das geplant haben. Ich mein, da gibt's ja auch in der jüngeren Vergangenheit Wenn man das nicht so macht, das ist jetzt ID-Wallet, dass dann einfach die schnelle Skalierung und quasi die Aufmerksamkeit dazu führt, dass die Produkte nicht die Erwartungen erfüllen. Wenn ich da noch ...

Entschuldige, Christina. Wenn ich da noch ergänzen darf, jetzt wieder aus dieser privatwirtschaftlichen Brille gedacht, man würde ja auch im privatwirtschaftlichen Kontext ein Produkt zunächst mal so entwickeln, dass es auch wirklich funktioniert. Also, keine Ahnung, sagen wir bei dem Online-Ausweisen, dass die Ersteinrichtung funktioniert, dass man nicht im Laufe der Ersteinrichtung unfassbar viele NutzerInnen verliert und erst dann würde man Marketingmaßnahmen starten. Und deswegen sagen wir stille Veröffentlichung, weil wir eben nicht die unglaublichen Massen haben wollen, sondern wir brauchen dann eben so viele NutzerInnen, um das Produkt in einen Zustand zu bringen, in dem es wirklich Probleme löst und nicht zu viele Leute abbrechen. Erst dann kümmern wir uns um den Wachstumsteil.

Ja, ich verstehe das schon. Bundesprojekte, die skalieren oftmals sehr schnell sehr hoch, bei potenziell 83 Millionen Nutzern. Wir haben ja hier ein gemeinsames Pad, wo wir uns vorbereitet haben. Und da habt ihr eine Phrase reingeschrieben, Working in the open. Und ihr sagt, dass ihr euch voll der Transparenz verschrieben habt. Wie muss ich mir das vorstellen, außer dass ihr auf GitHub entwickelt? Da habe ich auch noch eine Frage dazu, aber machen wir erst mal das.

Also im Prinzip vertreten wir die Grundüberzeugung, dass dadurch, dass unsere Projekte durch öffentliche Gelder finanziert sind, wir auch alles, was wir an Erkenntnis gewinnen und an Mehrwert leisten, wir wieder der Öffentlichkeit zur Verfügung stellen sollen und wollen. Das ist, das tun wir zum einen darüber, dass wir bloggen, dass wir Code auf GitHub veröffentlichen, aber auch, dass wir uns in Community-Arbeit hauptsächlich verwaltungsintern einbringen. Und wir sind da durchaus noch nicht am Ende. Also ich weiß, dass es gerade aus der Zivilgesellschaft auch immer wieder Forderungen gibt, dass wir uns noch mehr dort einbringen, was wir heute so noch nicht tun, weil das auch mit Ressourcen verbunden ist, die wir so noch nicht aufgebaut haben. Es ist aber so, das, was wir jetzt hier gerade beschreiben, dass wir alle unsere Projekte komplett offen entwickeln. Das ist für die Projektpartner, mit denen wir zusammenarbeiten, ein riesen Paradigmenwechsel. Wir stoßen da heute auch immer noch in den Anbahnungsphasen, wenn wir sagen, das sind die Parameter, die für uns quasi nicht verhandelbar sind. Wir wollen unter offenen Lizenzen entwickeln und wir wollen auch Working in the Open betreiben. Wir sprechen da auch gerade mit unserem Kommunikationsteam im Vorfeld immer relativ viel mit den Projektpartnern. Das brauchen wir auch für Abstimmungskanäle zwischen der Öffentlichkeitsarbeit in Ministerien und der Art und Weise, wie wir auch nicht nur über Erfolge kommunizieren, sondern auch, wenn wir mal irgendwo gescheitert sind oder was wir gelernt haben über Dinge, die nicht so gut funktioniert haben, dass wir da eine andere Art von Transparenz und Einblick in unsere Arbeit geben wollen, als das häufig ja in der öffentlichen Verwaltung der Fall ist. Und da müssen wir auch noch relativ viel Überzeugungsarbeit leisten bei unseren Projektpartnern. Zum Beispiel auch offenes entwickeln, dass das nicht mit Sicherheitsrisiken verbunden ist, dass das auch ihnen keine Nachteile bringt, wenn andere auch auf den Code zugreifen können und den nachnutzen können. Und wir sind da sicher noch nicht am Ende dessen, was wir tun könnten, aber ich glaube, wir sind da in zwei Jahren schon ein gutes Stück weit gekommen.

Das sprecht ihr mir aus einem tiefen Herzen. Ich als großer Open-Source-Befürworter bin ja ein großer Fan davon. Vielleicht noch eine Frage, ihr veröffentlicht auf GitHub. Warum seid ihr nicht auf Open Code? Das ist ja auch so eine Plattform für die öffentliche Verwaltung. Da ist zum Beispiel das Projekt E-Gesetzgebung ist drauf, der Bundesmessenger ist mit drauf. Also wird tatsächlich auch von der Bundesverwaltung genutzt.

Wir waren als Stakeholder involviert bei der Entwicklung von Open Code. Wir haben so ein, zwei Interviews gemacht mit den Verantwortlichen und wir waren auch im Gespräch als frühe Nutzergruppe. Ich hab das gesehen, dass du die Frage in das Pad geschrieben hast, und hab gedacht, ich weiß gar nicht, wo wir heute in den verschiedenen Projekten stehen. Wir haben natürlich, wir haben schon angefangen quasi GitHub zu nutzen, bevor es Open Code gab. Und was jetzt die konkreten Gründe dafür sind, dass wir mit unseren Projekten noch nicht umgezogen oder das zumindest auch dort veröffentlichen, das kann ich dir ja Stand heute gar nicht sagen.

Okay, das wäre ein konsequenter Schritt. GitHub ist ja Microsoft und Open Code gehört schon mal der öffentlichen Verwaltung. Also es wäre ein konsequenter Schritt Richtung Open Code.

Hast du darauf schon mal gearbeitet? Wie ist denn deine Erfahrung mit der Plattform?

Ja, das ist ein GitLab, was dahinter steckt. Und das kann man ganz normal an seine Systeme anbinden, wie man auch GitHub anbindet oder ein eigenes GitLab anbindet. Also es funktioniert alles wunderbar. Meine Firma, die AKDB, wir haben da auch Code drauf. Da bin ich der Administrator. Deswegen kann ich hier so ein klein wenig aus der Tiefe plaudern. Aber das funktioniert. Hat noch nicht alle Funktionen wie so ein normales GitLab, aber das wird nach und nach aufgebaut, aber man kann schon gut drauf arbeiten.

Vielleicht kommen dazu im Nachgang wir nochmal auf dich zu.

Sehr, sehr gern. So, jetzt muss ich gleich nochmal unser Pad anschauen, bevor wir uns hier ins Open Source Thema verquatschen. Habt ihr, wenn wir gerade beim Open Source Thema sind, habt ihr irgendeine Strategie, um euren Auftraggebern das Thema näher zu bringen, dass das halt keine Gefahr ist, den Code zu veröffentlichen?

Ich glaube, Strategie wäre ein bisschen hochtrabend. Wir haben in der Anbahnungsphase, sprechen wir offen über die Ängste und Sorgen, die sie vielleicht einer offenen Entwicklung entgegenbringen. Wir haben das auch in unseren Vertragsbedingungen abgebildet. Aber ehrlich gesagt, wir nutzen auch öffentlich zugängliche Ressourcen, so Public Money, Public Code, veröffentlicht ja auch Argumentationshilfen. Und wir stimmen uns mit unserem Projektpartner, auch gerade mit dem BMI ab, was so geeignete Lizenzen sind. Wird das jetzt nicht als eine quasi ausgereifte Strategie bezeichnen.

Ja, ich freue mich auf die neuen EVB-IT-Vorlagen. Da ist Open Source auch explizit möglich, also konkrete Open Source-Verträge abzuschließen. Ich bin gespannt, wann die endlich veröffentlicht werden.

Spannend, ja.

Genau, das wird sehr, sehr spannend. Generell, wie beauftragt euch denn so eine Behörde?

Das hatte Steffi ja eben schon mal skizziert. Also Stand heute sind wir primär mit den IT-Verantwortlichen in den verschiedenen Ministerien im Austausch. Die kennen mittlerweile das Produktangebot des Digital Services. Ich glaube, insbesondere über den Aspekt nutzenden, zentrierte Services für die Öffentlichkeit, also nicht verwaltungsinterne Lösungen, sondern Produkte, Services, die am Ende Menschen, Unternehmen, die Gesellschaft erreichen sollen, können wir beauftragt werden. Und wenn die entsprechende Bedarfe haben, kommen die auf uns zu. Und in ersten Gesprächen versuchen wir dann erst mal zu klären, ist das was, wofür sich eine neue, quasi eigene Softwareentwicklung, wofür das notwendig ist? Gibt es da nicht eigentlich einen Markt für etablierte Lösungen? Und dann bei unseren begrenzten Ressourcen schauen wir dann auch immer noch mal drauf, ist das was, was gut in unser Produktportfolio passt, wofür wir Verantwortung übernehmen wollen und können?

Und ihr betreut die Projekte dann auch dauerhaft oder gebt ihr den irgendwann ab?

Das ist tatsächlich was, was sich über die letzten zwei Jahre ein bisschen entwickelt hat. Die initiale Hypothese und da auch wir in unserer Organisationsentwicklung und wo wir als Digital Service eigentlich strategisch hinwollen, hinterfragen regelmäßig, was können wir mit dem, was wir an Kompetenzprofilen aufbauen und dem, was wir leisten, wo können wir eigentlich den größten Mehrwert stiften. Und wir haben bei der Übernahme, gab's noch die Hypothese, dass wir maximale MVPs entwickeln und dass wir quasi kurz nach dem Live-Gang dann das Produkt an andere IT-Dienstleister, an einen ITZ-Bund oder aber auch an einen Landes-IT-Dienstleister übergeben können. Die dahinterliegenden Rechtskonstrukte sind nochmal eine andere Frage, wie das möglich gemacht werden kann. Aber wir haben gesehen, auch aus einer Produktperspektive entspricht das nicht der Art und Weise, wie wir der Überzeugung sind, wie man wirklich nachhaltig gute Produkte entwickelt, an den Markt bringt und dann auch weiterentwickelt, weil mit dem MVP eigentlich ja nur die erste Realitätskontronisation statt gefunden hat. Und man hat dann gerade ein eingeschwungenes Team, was auch, oft sich dann sehr mit den Zielgruppen identifiziert und eine hohe Motivation mitbringt, eine Begeisterung für das Produkt, für die Lösung, für die Rahmenbedingungen. Also da arbeiten wir auch ganz anders als vielleicht traditionelle Beratungsunternehmen oder Agenturmodelle, die halt ein Produkt nach dem Nächsten abliefern. Wir sind dazu übergegangen, dass wir dauerhafte Teams aufbauen, die dann auch für die Weiterentwicklung verantwortlich sind und nicht nur für kurzfristige Projekte.

Das klingt sehr interessant, weil die Erfahrung zeigt ja auch, dass, wenn ich einen MVP entwickle und das dann weitergebe an irgendein anderes Softwarehaus, dann wird das mit nicht so viel Herzblut weiterentwickelt, weil man hat es ja irgendwie über den Zaun geworfen gekriegt.

Und das ist genau diese, du hast genau das richtige Bild genutzt Thorsten, das ist ein Zaun und an dem prallt es eigentlich ab, aber so aus Produktmanager-Perspektive ist das der Moment, in dem es eigentlich erst richtig spannend wird, weil dann eben erst die Daten tatsächlich kommen und man erst dann ja auch tatsächlich iterativ weiterentwickeln kann.

Ja, wir hatten heute schon das Thema Transparenz und Iterationen und ich nenne es jetzt trotzdem agile Entwicklung angesprochen. Zu einer agilen Entwicklung gehört auch eine Art Retrospektive, wo ich mir anschaue, was ist gut gelaufen, was ist nicht so gut gelaufen, was können wir besser machen? Geht ihr damit auch? Öffentlich oder transparent um, dass man sehen kann, welche Fehler gemacht wurden und dass man vielleicht andere diese Fehler direkt von Anfang an vermeiden könnten?

Genau, dazu gehört eine Retrospektive. Und Christina hat es vorhin schon gesagt, wir arbeiten ja nicht nur iterativ in unseren Softwareentwicklungsprojekten, sondern auch in der Art und Weise, wie wir im Team zusammenarbeiten oder in der Organisation. Und das Format der Retrospektive nutzen wir da an allen Ecken und Enden, will ich mal sagen. Und, wie Christina eigentlich vorhin auch schon, glaube ich, du hast es schon gesagt, wir veröffentlichen ja im Rahmen des Working in the Open auch sehr viel auf unserem Blog. Und da schreiben wir auch über die Dinge, die nicht gut funktioniert haben, um in so eine Lernkultur zu kommen. Und das können wir natürlich auch nur, indem wir das vorleben. Und ich wollte, glaube ich, gerne zu diesem Working in the Open Aspekt noch einen Punkt sagen. Ich habe da letztens den schönen Satz gehört, there are more experts out there than in here. Und das ist schon auch etwas, was wir proaktiv tun, dass wir in unseren Projekten jeweils die Stakeholder da draußen identifizieren und proaktiv ansprechen, um einfach deren Wissen und deren Feedback auch proaktiv einzusammeln.

Und da wollte ich noch einen Punkt, den bringe ich vielleicht jetzt, den wollte ich eigentlich eben erwähnen, als du über unsere Discovery-Phasen gesprochen hast. Wir sind ja in Deutschland in ganz wenigen Bereichen noch in der privilegierten Situation, dass man auf der grünen Wiese was ganz Neues entwickeln kann. Das heißt, für uns ist ein total wichtiger Aspekt, in so einer Discovery-Phase auszuschauen, was gibt es eigentlich schon für Produkte, für Lösungen, für Akteure, mit denen man kooperieren kann oder Dinge, auf die man aufsetzen kann. Wir hinterfragen dann natürlich auch, funktioniert das, ist das noch zukunftsfähig, wie kann das sinnvoll miteinander interagieren? Es ist jetzt nicht so, dass wir für die Projekte, für die wir beauftragt werden, quasi auf Grünen, Wiese... Ganz ganz neu anfangen, sondern wir glauben schon, dass wir dort, wo es schon sinnvolle Vorarbeiten gibt, dass man da auch kooperieren und darauf aufsetzen sollte.

Wie kann ich mir die Arbeit bei euch vorstellen? Also wie kann ich mir vorstellen, wie arbeite ich bei euch in den Teams? Wie findet das statt? Arbeit ihr dezentral? Seid ihr zusammen in einem Büro? Wie ist so eine Tagesstruktur aus oder so eine Wochenstruktur?

Also, wir arbeiten erstmal in interdisziplinären Teams. Das heißt, jedes Team hat dediziert das, was es braucht, um an seinem Produkt oder an seiner digitalen Lösung zu arbeiten. Und das, ich würde sagen, sehr hybrid. Es gibt dann manchmal so Teamtage, die sich aber die Teams, je nachdem, wie sie das brauchen, ja, selber einrichten, wo sich dann die Menschen auch mal im Büro begegnen, aber in der Regel funktioniert sehr, sehr viel hybrid. Und dann ist es total abhängig davon, in welchem Projekt wir gerade sind, aber in vielen Projekten gibt es eine wöchentliche Planung. Es gibt all das, was man eigentlich kennt, Daily Stand-Ups, es gibt Retrospektiven. Es ist eine, ja, ich würde sagen, sehr offene gemeinsame Zusammenarbeit. Und ich weiß nicht, Christina, ob du dazu noch was ergänzen möchtest, Aber ich glaube, das, was uns alle eint, und das ist mir auch so wahnsinnig wichtig, dass wir das als Kultur beibehalten, ist unsere Offenheit in der Art und Weise, wie wir mit den Ministerien in unseren Projektpartnerschaften zusammenarbeiten. Also es ist nicht wir gegen den Rest der Welt, was ja einfach wäre, sich dahinter zu versammeln. Aber genau so ist es eben nicht, sondern ich bin schon der festen Überzeugung, dass nur gute Lösungen entwickelt werden, wenn wir das gemeinsam schaffen. Und das geht nur, wenn wir konstruktiv und offen bleiben. Und das glaube ich. Und eine Sache noch. Ich bin wirklich sehr beeindruckt, wie beim Digitalservice eine so große Gruppe so sehr an der Sache interessiert sein kann und einfach für die Sache tatsächlich arbeitet. Das ist schon was sehr Besonderes bei uns.

Ich möchte dazu tatsächlich auch noch gern was sagen, weil... Ich möchte eine Lanze für die Mitarbeitenden aus der öffentlichen Verwaltung brechen. Die Menschen, mit denen wir da zusammenarbeiten dürfen, sind auch in hohen Teilen sehr kompetent, unheimlich motiviert und können in den Strukturen und Rahmenbedingungen, die ja ungleich schwieriger sind als das, was viele aus unseren Teams aus der Privatwirtschaft kennen, Berge versetzen, damit wir gemeinsam mit ihnen auf diese andere Art Softwareprodukte entwickeln können. Wir könnten das auch nicht ohne die. Und das ist auch ein wichtiger Punkt. Wir versuchen in unseren interdisziplinären Teams, auch die Verwaltungsmitarbeitenden eng einzubeziehen. Das ist häufig eine Herausforderung, weil einzelne ReferentInnen in der Verwaltung ja häufig für mehrere Projekte verantwortlich sind und dann nicht ein vollwertiger Teil unseres Teams sein können, weil sie parallel noch vier andere Projekte betreuen müssen und dann weniger Kapazität für uns mitbringen, als wir das manchmal gerne hätten. Da sieht man auch, dass die Verwaltung noch anders über Softwareentwicklung nachdenkt. Da geht es darum, ich beauftrage was und ich prüfe die Leistungsnachweise und Erfolgskontrolle. Aber nicht so sehr, ich bringe mich fachlich ein mit meiner Steuer, mit meiner juristischen Expertise in den Entwicklungsprozess. Dadurch, dass wir aber so eng und vertrauensvoll auch mit der Verwaltung zusammenarbeiten und dass wir auch Retrospektiven und Review-Prozesse mit der Verwaltung machen, sehen wir, Die Transparenz ist nicht zu 100 Prozent alles veröffentlichend für uns, weil wir brauchen auch teilweise den vertrauensvollen Raum, um ehrlich über Fehler zu reflektieren. Das ist was, was für Verwaltungsmitarbeiter häufig noch ein sehr ungewohnter Prozess ist. Uns hat mal jemand gesagt, ihr fragt immer als Erstes irgendwie nach meinem Motto des Tages oder wie ich heute aufgestanden bin. Ich bin es gar nicht gewohnt, auf diese Art mit KollegInnen zu interagieren. Das ist mir viel zu persönlich. erst mal auf diese ganzheitlichere Art, sich als Mensch und als Team zu verstehen, einlassen. Ich glaube, das ist mit der Grund, warum viele aus der Verwaltung auch gern mit uns zusammenarbeiten, weil sie sagen, Mensch, das macht richtig Spaß, so wenn ich mit euch arbeiten kann, ich komme da mit Motivation zur Arbeit. Ich sehe auch schnell Erfolge, weil wir iterativ kleine Pakete schnüren, die irgendwie nach einer überschaubaren Zeit auch zu einem Mehrwert führen, zu konkreten Verbesserungen. Aber ich glaube, es ist schon auch das Wie unserer Zusammenarbeit.

Und darf ich da noch was ergänzen, Thorsten?

Natürlich.

Ich glaube, mir ist gerade in diesem, weil jetzt du vorhin auch schon nach Fehlern und wenn mal was nicht so gut gelaufen ist und weil Christina jetzt auch von Fehlern gesprochen hat, ist mir nochmal wichtig zu sagen, dass wir ja in der Softwareentwicklung wahnsinnig viele Hypothesen aufstellen und eine widerlegte Hypothese ist eigentlich nicht etwas, was nicht gut gelaufen ist, sondern das ist besonders gut gelaufen, weil wir rausgefunden haben, dass wir sie widerlegt haben. Und ich glaube, das zu verstehen und da zu verstehen, dass es sich dabei nicht um einen Fehler handelt. Ein Fehler ist, wenn jemand einen Server löscht an irgendeiner Stelle. Das ist wirklich ein Fehler. Aber wenn wir eine Hypothese aufstellen, dass eine Lösung x, y, z Feature oder Funktionsumfang enthalten muss, damit sie ein Problem löst und wir hinterher herausfinden, dass das nicht die richtige Funktionalität war oder wir sie nicht richtig nutzerfreundlich gebaut haben, dann ist das erstmal eine widerlegte Hypothese und eigentlich was sehr, sehr Gutes.

Das ist eine sehr schöne Sichtweise auf Softwareentwicklung. Jetzt haben wir sehr viel über den Digitalservice Bund gesprochen und wo findet denn jemand, der sich für tiefere Informationen interessiert, wo findet er euch denn am besten?

Der findet uns wahrscheinlich zuallererst mal auf digitalservice.bund.de, also unsere Webseite, da kann man sich, wie gesagt, über den Blog informieren, über die Projekte, an denen wir arbeiten, auch über die Learnings aus dem ersten, aus dem zweiten Jahr unserer Arbeit, verfassen wir immer mal wieder Blogbeiträge. Da beschreiben wir natürlich auch, wie wir arbeiten, wie wir unsere Organisation aufbauen, auch wie die Fellowship-Programme funktionieren, an welchen Projekten wir da gearbeitet haben. Wenn man bei uns einsteigen will, findet man da auch die Job-Postings und darüber hinaus, klar, wir twittern auch, wir sind auf LinkedIn unterwegs, also ein bisschen die gängigen Social-Media-Plattformen. Und zunehmend bringen wir uns auch ein auf den großen Konferenzen, also Creative Bürokratie Festival. Glaube ich, einen Vortrag halten oder etwas tun, hoffentlich, wenn es gevotet wird, zum Digitalcheck, auf dem digitalen Staat etc. Also auf den ganzen Konferenzen sind wir auch vertreten und kann man uns gerne ansprechen.

Sehr gut. Also ich spreche euch auf jeden Fall an, wenn wir uns das nächste Mal sehen. Also ich bin auch auf den ganzen Konferenzen meistens vertreten. Haben wir noch Dinge, die ihr unbedingt ansprechen wollt. Weil ich habe mir gerade die Karriereseite angeschaut. Also ich kann nur sagen, wer einen Job sucht in der öffentlichen Verwaltung und aus den üblichen IT-Bereichen kommt, findet auf jeden Fall auf der Karriereseite mindestens ein Angebot. Also ich denke, das lohnt sich auf jeden Fall, da mal reinzuschauen.

Und auch jenseits der Angebote, die auf der Karriereseite sind, freuen wir uns über jede Initiativbewerbung in einer anderen Rolle. Das auf jeden Fall.

Okay, jetzt nochmal, haben wir noch irgendwas vergessen? Müssen wir noch irgendwas ansprechen, was ganz konkret wir jetzt nicht geschafft haben? Also ich glaube unsere Liste haben wir abgearbeitet, aber vielleicht ist noch irgendeine Idee gekommen.

Ich glaube nicht und wenn nicht ist das Grund für eine Wiedereinladung zu einem späteren Zeitpunkt.

Genau, ich nehme euch auf jeden Fall nochmal mit auf die Liste für den Digitalcheck und dann bedanke ich mich ganz herzlich bei euch. Und für euch liebe Hörerinnen und Hörer, danke, dass ihr zugehört habt und bis zum nächsten Mal.