Interview mit Software-Entwickler Klaus

Klaus Hartl ist Senior Software Engineer beim DigitalService. Zuvor war er unter anderem als Software-Entwickler bei der internationalen Technologieberatung und Agile Pionier ThoughtWorks tätig, half maßgeblich bei der Entwicklung eines Ride-Pooling-Algorithmus beim Mobility-as-a-Service Start-up door2door und gründete ein eigenes Start-up. Seine zwei Katzen heissen Coffee und Tea.

Klaus, Du hast über 20 Jahre Erfahrung in der Software-Entwicklung mit Stationen u.a. bei Nokia, door2door und ThoughtWorks? Was sind Deine bisher wichtigsten Lektionen?

Das wichtigste Learning, mit Gerald Weinbergs Worten: „No matter what the problem is, it's always a people problem.“ Technisch ist das Meiste lösbar. Aber alle Leute unter einen Hut zu bringen, gemeinsames Verständnis zu schaffen, Kollaboration, dass das Team zusammen funktioniert und letztlich alle glücklich sind, das ist die eigentliche Herausforderung.

Nach Nokia und vor door2door hast Du auch mal Dein eigenes Start-up gegründet? Was war Dein Ansatz?

Die Idee war es, Fernsehfilme und Serien zu empfehlen basierend auf Facebook Likes. Das war zwischen 2010 und 2013. Zu der Zeit war Facebook noch nicht so verpönt wie heute. Zusätzlich haben wir die Nutzer:innen informiert, wo sie ihren Lieblingscontent anschauen können: iTunes, Netflix etc. Es gab dann später auch Notifications, wenn interessante, also empfohlene Filme im (linearen) TV gezeigt wurden.

Seit Mai 2021 bist Du jetzt beim DigitalService. Was ist Deine Motivation für Dein Engagement?

Purpose, das war definitiv meine Hauptmotivation. Vorher habe ich als Berater bei ThoughtWorks gearbeitet. Das war in meiner Karriere die bisher wichtigste Zeit. Doch zu meinen letzten Projekten dort gehörte die Software-Entwicklung für einen großen deutschen Automobilkonzern. Ich wollte aber 2020 nicht einen Beitrag dazu leisten, dass mehr Autos verkauft werden, sondern meine Fähigkeiten verstärkt gemeinwohlorientiert einsetzen. Da habe ich mich dann nach etwas Neuem umgesehen unter der Prämisse: Jetzt will ich was machen, wo ich wirklich einen Sinn drin sehe. Dann kam noch die Erfahrung der Pandemie mit dazu. Es wurde öffentlich viel kritisiert, dass die Gesundheitsämter teilweise noch mittels Fax kommunizieren... Das Problem der mangelnden Digitalisierung wurde in dem Bereich ganz gut exponiert.

Eure Mission in Deinen Worten?

Wir wollen einen Kulturwandel anstoßen, was die Methodik der Software-Entwicklung in der Verwaltung angeht. Kulturwandel in dem Sinne, dass man schneller zu Ergebnissen kommt mit besseren Resultaten für die Nutzer:innen.

Wieso liegen Euch eigentlich die Bürger:innen so am Herzen? Welche Chancen siehst Du in Eurem gemeinwohlorientierten Ansatz?

Wir wollen eine größere Zufriedenheit bei den Bürger:innen herstellen, was Angebote aus der Verwaltung angeht. Vielleicht können wir sogar einen kleinen Beitrag zum demokratischen Zusammenhalt leisten.

Was macht für Dich eine gute Unternehmenskultur aus?

Empathie. Aufrichtigkeit. Spaß. Die Reihenfolge ist nicht gewichtet.

Wie erlebst Du den Spirit beim DigitalService?

Was uns auszeichnet, ist eine starke Empathie, das habe ich schon während des Bewerbungsverfahrens bemerkt. Und gleichzeitig ein gesunder Pragmatismus. Jede:r ist aus einem guten Grund da und will etwas zum Besseren bewegen. Es gibt das gemeinsame Ziehen an einem Strang für eine gute Sache.

Wie sollte die Verwaltung aus Deiner Sicht langfristig Software entwickeln?

Stärker in Kollaboration mit den tatsächlichen Nutzer:innen. Die Erkenntnisse der letzten 20 Jahre Software-Entwicklung haben gezeigt, dass es wenig zielführend ist, alle Anforderungen an ein neues Software-Produkt im Vorhinein zu sammeln und an Dienstleister:innen weiterzugeben. Da gibt es immer Wissensverluste und falsche Annahmen. Agile Software-Entwicklung ermöglicht es, unter starker Einbindung der Nutzer:innen kollaborativ Software zu entwickeln, mit möglichst kurzen Feedbackschleifen. So kann man früher und schneller reagieren, falls tatsächlich mal eine Anforderung missverstanden wurde oder wenn die Nutzer:innen etwas anderes brauchen als im Vorfeld gedacht.

Ist das auch Eure Engineering Strategy beim DigitalService?

Ja, ganz eindeutig. Wir wollen bewusst diese agile Methodik der Software-Entwicklung einsetzen und dafür stehen wir auch ein. Wir setzen nicht ein großes Dokument mit Anforderungen im stillen Kämmerlein um, sondern entwickeln unter ständiger Einbindung der Nutzer:innen die Software kollaborativ. Während der Entwicklung beobachten wir sehr genau, welche Bedürfnisse und Anforderungen an unser Software-Produkt sich im Prozess herauskristallisieren. Wir machen User Testing so früh es geht. Schon mit dem Scribble – einer Art Ideenskizze – eines Prototypen auf Papier lassen sich wertvolle Dinge in Erfahrung bringen.

Was sind Deine Ambitionen bei der Software-Entwicklung?

Technische Exzellenz. Qualität. Wartbarkeit – also sicherzustellen, dass eine Software lange Bestand hat und weiterentwickelt werden kann. Und: Ich möchte Software so entwickeln, dass meine Mitentwickler:innen auch Freude daran haben. Kent Beck, einer der Unterzeichner des agilen Manifests, hat mal gesagt: „Programming at its best is an act of empathy“. Das hat mich, beziehungsweise meine Arbeit, sehr beeinflusst. Empathie bei der Software-Entwicklung bedeutet, die Nutzer:innen ebenso im Blick zu haben wie die Mitentwickler:innen. Das heißt: Ist Dein Code lesbar? Kann er auch von anderen gut gewartet werden? Die Empathie spielt in beide Richtungen: nach innen und nach außen.

Was ist Deine Rolle beim DigitalService?

Bei meinem ersten Projekt war ich mehr Software-Architekt: eine Systemarchitektur konzipieren, Technologien auswählen, Architekturrichtlinien beachten... Wir waren da noch in der Discovery Phase. So eine intensive Discovery von Grund auf habe ich in dieser Form bislang noch nicht gemacht. Es ging darum, möglichst genau zu verstehen, was wir entwickeln müssen. Das in der Verwaltung gängige Lastenheft versucht, so prädiktiv wie möglich zu sein. Das steht im Gegensatz zu unserem Ansatz. Bei der agilen Software-Entwicklung wollen wir adaptiv sein und dadurch ein Stück weit unnötige Komplexität vermeiden. Bei meinem momentanen Projekt liegt der Fokus wieder auf tatsächlicher Entwicklung von Software.

Was hast Du als Entwickler in der bisherigen Zusammenarbeit mit der Verwaltung Neues gelernt?

Definitiv eine große Genauigkeit. Bei der agilen Methodik schieben wir Dinge gerne auch mal auf den sogenannten „last responsible moment“. Das funktioniert in der Verwaltung aufgrund von Plänen, internen Prozessen, Ressourcen etc. nicht immer. Wir finden aktuell mit der Verwaltung einen guten Kompromiss zwischen prädiktiv und adaptiv. Denn die ideale agile Welt gibt es natürlich auch nicht.

Wie schafft Ihr es, schnell zu iterieren?

Indem wir uns auf unsere eigene Expertise besinnen und versuchen, uns nicht zu sehr von anderen Denkweisen irritieren zu lassen. Selbstbewusstsein haben und unsere Expertise nach außen tragen. Und zum anderen, indem wir Menschen immer wieder aktiv einbinden und durch unsere Resultate überzeugen. Sobald es ein gutes Resultat gibt, schafft das Vertrauen und dadurch erlangt man Autonomie, um schneller zu iterieren. Anders gesagt: versuchen Nebenschauplätze klein zu halten und mit guten Ergebnissen überzeugen. Show, don’t tell.

Was ist Eure Tool Chain?

Am Ende zählt, ob die Software für den oder die Nutzer:in einen Nutzen bringt oder nicht. Technologien sind Mittel zum Zweck. Ich denke da eher in Prozessen. Ich versuche, bei der Software-Entwicklung für und mit der Verwaltung eine DevOps-Kultur zu etablieren. DevOps bringt Development und IT Operations zusammen und ist im Grunde der agile Gedanke konsequent und übergreifender weitergedacht.

Erzähl hier gerne ein bisschen mehr. Was heißt das?

DevOps liefert die methodische Basis für das Zusammenspiel von Betrieb und Entwicklung. Das heißt auch, Entwickler:innen in die Lage zu versetzen, Software selber zu betreiben: You build it, you run it. Früher wurde die Software nach der Entwicklung bildlich gesprochen über den Zaun geworfen und jemand anderes musste schauen, dass das alles irgendwie läuft. Wenn dann Fehler auftauchten, dauerte es natürlich lange, diese zu fixen. Die DevOps-Kultur zielt darauf ab, ganz kurze Release-Zyklen für die Software zu haben: Continuous delivery. Sprich: Die Software wird zu jedem Zeitpunkt in einem auslieferbaren Zustand gehalten. Änderungen werden mehrmals täglich ausgespielt. Die Software wird so kontinuierlich ausgespielt, dass es keinen klassischen Release mehr gibt. Dafür braucht es unter anderem eine gute Teststrategie. Je mehr Tests Du automatisiert durchführen kannst, desto sicherer und effizienter funktioniert das. Das gibt wiederum Vertrauen, dass Du die Software beliebig häufig ausspielen kannst.

Da geht es dann natürlich wesentlich schneller, im Prozess auftauchende Fehler zu fixen oder veränderte Bedürfnisse zu berücksichtigen.

Genau das ist der Punkt.

Stichwort: Out in the open... Was sind Vorteile von Open Source?

Wiederverwendbarkeit. Open Source wird von vielen genutzt. Das heißt, diese Komponenten sind erprobt und haben unter Umständen weniger Bugs. Software that matters: Erst in den Händen echter Nutzer:innen wird Software relevant, weil erst hier treten Fehler auf. Je mehr Leute eine Software nutzen, desto mehr Fehler kannst Du finden.

Wie würdest Du Deine Arbeit einem 5-jährigen Kind erklären?

Ich sage Computern, was sie zu tun haben.

Was ist für Dich eine gute Führungskultur?

Es gibt das schöne Stichwort Servant Leadership. Kein Command und Control, sondern empathisch schauen, wie ich die Leute unterstützen kann, das bestmögliche Ergebnis zu liefern. Wir wollen Leute empowern, ihr bestmögliches zu geben und sich in der Organisation weiterzuentwickeln. Bescheidenheit ist mir wichtig. Das beschränkt sich nicht nur auf Führungskultur. Das betrifft auch unsere Organisationskultur beim DigitalService.

Was zeichnet eine lernende Organisation für Dich aus?

Stete Neugier bei den Leuten innerhalb der Organisation. Neugier auch im Sinne von: Es gibt kein Silodenken. Das mag ich an unserer Start-up-Kultur: Die Offenheit. Die Flexibilität. Das Unvorhergesehene. Und eine gute Feedbackkultur. Wissen und Learnings schnell weitertragen – auch ganz wichtig, um laufend dazuzulernen.

Was hättest Du gerne früher gewusst?

No matter what the problem is… siehe oben!

Was würdest Du Entwickler:innen mitgeben, die sich beim DigitalService bewerben?

Von Frontend über Backend bis Infrastruktur: Sie sollten Generalist:innen sein und ein breites Spektrum mitbringen, beziehungsweise die nötige Neugier. Kommt zum DigitalService, wenn Euch der Nutzen und Nutzer:innen einer Software ein wenig wichtiger sind als die reine, zugrundeliegende Technologie.

Wie lebt Ihr Verschiedenheit?

Mit viel Empathie. Unser Grundverständnis ist es, jede:n so sein zu lassen, wie er oder sie ist. Wir versuchen, zu verstehen, warum jemand wie handelt. Dafür braucht es individuelles wie kollektives Fein- und Taktgefühl. Ein wichtiger Aspekt ist, dass wir ganz bewusst Kompetenzen und Sichtweisen suchen, die uns als Team ergänzen. Verschiedenheit fängt beim Recruiting an.

Wenn der DigitalService ein Tier wäre, welches wäre es und warum?

Vielleicht ein Kuckuck. Wir legen der Verwaltung Eier ins Nest. Was Gutes. Was Fliegendes. Was neue Gedanken einpflanzt.