Ich habe als Unternehmensberater in vielen spannenden Projekten gearbeitet, in denen ich unzähliges über verschiedene Unternehmen, Projekte, Technologien und Methoden lernen konnte. Irgendwann kam für mich jedoch der Moment, wo ich für meine persönliche Entwicklung eine neue Herausforderung wollte. Aus diesem Grund habe ich mich an Weihnachten 2020 entschieden, mein Dasein als Unternehmensberater (vorerst) zu beenden. Ich habe zum Glück mit der Techem ein Unternehmen gefunden, das mir genau diese neue Herausforderungen geboten hat.
Techem: Eine neue Herausforderung
Unternehmensberater zu sein ist definitiv ein spannender und herausfordernder Job. Ich habe in einigen Projekten tolle Dinge bewegen und so einiges lernen können:
- verschiedene Branchen wie die Finanzprodukte oder die Energiebranche
- verschiedene Positionen und Rollen wie Business Analyst, Cloud Architekt oder Projektleiter
- verschiedene Technologiefelder von Monolithen bis zu Cloud-native Apps und
- verschiedenste Tätigkeitsspektren aller Colour.
Eines konnte ich in all diesen Projekten jedoch nie: etwas einmal zu Ende bringen. Als externer Berater kommt man meistens in einer spezifischen Rolle in eine Projektphase und darf sich durchaus in dieser ganzheitlich einbringen. Aber alles, was ein Anfang hat, hat auch ein Ende. So habe ich in meiner Karriere als Unternehmensberater einige Dinge in Bewegung versetzen und Veränderungen lostreten können. Meistens aber nur als Konzept und was aus diesen geworden ist habe ich nie selbst miterleben dürfen. Genau das ist es aber, was ich suchte und unbedingt wieder für mich haben wollte: eine Mission von Anfang bis zum Ende bringen.
Führung eines eigenen Teams
Darüber hinaus hat es mir gefehlt, wieder mit einem eigenen Team zusammenarbeiten zu dürfen. In meiner Zeit als Unternehmensgründer und Geschäftsführer war ich für alle 22 Mitarbeiter disziplinarisch verantwortlich. Ich habe ich die Aufbauorganisation genauso wie die Zusammenarbeit durch die Prozesse gesteuert. Auf menschlicher Ebene ist es für mich immer wieder spannend, die alltäglichen Aufgaben als Führungskraft zu meisten. Ich mag es die individuellen Probleme und Sichten mit dem Team zu diskutieren. Genauso fasziniert es mich aber, jeden einzelnen Mitarbeiter auf seiner persönlichen Reise und Entwicklung begleiten sowie voranbringen zu dürfen. Ich setze mich gern mit allen Personen individuell zusammen und versuche mit ihnen Fragen wie die folgenden zu beantworten:
- Wie kann ich jeden Einzelnen bei der Erreichung der persönlichen Ziele unterstützen?
- Wie können wir die individuellen Ziele und Interessen jedes Einzelnen mit den übergeordneten Zielen des Teams in Einklang bringen?
Dies hat mir als zweite Sache als Unternehmensberater gefehlt. Ich habe mich zwar sehr oft in der fachlichen Führungsrolle gesehen und diese auch sehr gern entsprechend ausgefüllt. Ich konnte aber in dieser Rolle als externer Berater nicht die Verantwortung für einen Bereich übernehmen und über den Weg zur Zielerreichung entscheiden. Mich dabei einzubringen, womöglich ein Team dafür zu formen und zu entwickeln sowie über die Zusammenarbeit organisatorisch zu entscheiden, war für mich leider nicht möglich.
Die Techem im Umbruch
Aus diesen Gründen habe ich mich Ende des Jahres 2020 dazu entschieden, mich nach einer neuen Herausforderung umzuschauen. Ich wollte unbedingt wieder ein eigenes Team führen und ganzheitlich Verantwortung übernehmen, sodass ich eine Sache von Anfang bis zum Ende treiben kann.
Nach kurzer Zeit sah ich mich in Gesprächen mit einigen interessanten Unternehmen und habe dabei tolle Gespräche führen dürfen. Die Bandbreite reichte von der Teamleitung für Cloud-Architektur oder Buiness Intelligence bis hin zur Leitung eines Competence Center für eine größere IT-Beratung in Raum Frankfurt.
Am Ende habe ich mich jedoch für die Techem entschieden, die mir eine für mich ideale Doppelrolle geboten hat. Einerseits wurde ich Head of Software Architecture für die gesamte IT der Techem. Da die Techem sich im Sinne der Spotify Engineering Culture erst jüngst zuvor neuorganisiert hatte, übernahm ich damit die Leitung des Chapters Software Architecture . In dieser Rolle trug ich die Verantwortung, den Themenkomplex Softwarearchitektur in der Techem aufzubauen.
Zusätzlich bekam ich die Rolle des Squad Leads für das Kernprodukt der Techem, Abrechnung Online, übertragen. Damit übernahm ich die Verantwortung über das IT-Produkt, mit dem die Techem ihr Privatkundengeschäft betreibt und damit rund ein Drittel ihres Konzernumsatzes erwirtschaftet. Damit wurde ich ebenfalls disziplinarische Führungskraft für das Entwicklungsteam hinter dieser selbstentwickeltem Portalapplikation.
Ich entschied mich vor allem für die Techem, da sich das Unternehmen selbst in einem digitalen Wandel sieht und hier massive Anstrengungen auffährt, um diesen Wandel für sich erfolgreich beschreiten zu können. In den aktuellen Zeiten schreitet überall der digitale Wandel schneller und schneller voran – davon ist auch der Markt der Immobilienbesitzer nicht verschont geblieben. Auch die Kunden der Techem wünschen sich einfache Produkte, die ihre Probleme lösen und die einfach gut für sie funktionieren.
Aufbau eines High Performance Teams
Die ersten Monate über ging der größte Teil meiner Schaffenskraft in den Aufbau eines Entwicklungsteam, welches vollumfänglich die Verantwortung für das Kernprodukt Abrechnung Online übernehmen kann. Bereits vor meiner Zeit bei der Techem wurde die Initiative für Abrechnung Direct gestartet. Das Ziel dahinter ist schnell erklärt: Abrechnungen für die Endkunden in Echtzeit anbieten. Bisher war der Abrechnungsmarkt auf jährliche Abrechnungen ausgelegt.
Im Zeitalter von „always on“ und „alles in Echtzeit im Internet verfügbar“ reicht dies jedoch nicht mehr aus. Also haben wir uns ans Werk gemacht, um unseren Kunden ebenfalls Abrechnungen in Echtzeit anbieten zu können. Mittels Abrechnung Direct sind die Kunden nun in der Lage, ihre Abrechnungen in Echtzeit zu erhalten. Das ist nicht nur revolutionär aus Sicht des Abrechnungsmarkts, sondern eine erhebliche Steigerung der User Experience.
Was aus Kunden- und Marketingsicht sinnvoll und nutzenstiftend ist, macht die technische Umsetzung nicht einfach. Aus Sicht der Verarbeitungsprozesse war dies eine radikale Veränderung. Vorher wurden die Abrechnungen als Batch-Prozesse asynchron einmal im Jahr angestoßen. Nun kann ein Kunde den Prozess direkt und synchron aus dem Kundenportal heraus aufrufen.
Meine Aufgabe war es, eben jenes High Performance Team für die architekturellen Umbauten an Abrechnung Online aufzubauen. Ich heuerte als Erstes externe Entwickler als Freelancer und über Personalvermittler an, welche mich sofort in die Lage versetzten, an meinem Produkt aktiv weiterarbeiten zu können. Das Business wartet nicht darauf, bis neue Mitarbeiter in Festanstellung ausgewählt und eingestellt sind.
Aber auch mit meiner bestehenden Mannschaft setzte ich mich zusammen. Wo möchten sie sich individuell hin entwickeln? Welche Rollen sehen sie in einem agilen Softwareentwicklungsteam für sich? Wie gehen wir den weiteren Aufbau von Skills und Expertise mittels Weiterbildungen an? Die neuen Kollegen in Festanstellung sowie die externen Kollegen für die Zwischenzeit integrierte ich mit meinem Kernteam und formte mit ihnen zusammen eine schlagkräftige Truppe.
Agiles Reguirements Engineering in der Techem
Meine erste große Aufgabe lag dann in dem Aufbau eines geeigneten Anforderungsmanagements – in enger Zusammenarbeit mit meiner Fachabteilung. Vor meinem Einstieg in der Techem umfasste das Entwicklungsteam zwei Entwicklerinnen, was die Abstimmung über Anforderungen noch recht einfach machte. Spätestens aber, als wir ein zehn-köpfiges Entwicklungsteam hatten, brauchte es nachhaltige Strukturen und Prozesse für das Requirements Enginnering. Es reichte schlicht nicht mehr aus, in einem direkten Gespräch die Details unter Vieraugen zu besprechen. Mit der Zeit wurden dann auch mehr und mehr Stakeholder in der Organisation zu Sponsoren von neuen Anforderungen. Deshalb mussten wir das Anforderungsmanagement zusammenführen und gemeinsamen Prozessen unterwerfen. Nur so wussten alle Beteiligten (inklusive mir), was noch zu tun ist und wo wir in der Umsetzung stehen.
Ich begann die Arbeit mit dem Entwicklungsteam, eine agile Organisation nach Scrum aufzubauen. Es bat sich in diesem Setup an, ein gemeinsames Backlog für das Produkt aufzubauen. So konnten wir schnell Transparenz für das Management und für die jeweiligen Stakeholder zu schaffen. Mittels diesem Backlog konnte ich dann auch die Priorisierung für das Team vornehmen lassen. Auch wir hatten schlicht viel mehr zu tun, als wir ad-hoc umsetzen konnten. Zusätzlich wandelt sich auch der Immobilienmarkt für die Techem und geht immer mehr in der neuen VUCA-Welt auf. Diesem Wandel mussten wir uns auch als Entwicklungsteam unterwerfen. Zwei-wöchige Sprints schufen Produktinkremente und damit regelmäßigen Fortschritt für alle Stakeholder. Zusätzlich konnten wir in dieser Zeit unserem Sprintziel nachgehen und den zugesagten Umfang an Stories erbringen.
Ein cross-funktionales Team
Die gemeinsame Arbeit und unsere Vernetzung mit dem Fachbereich waren jedoch genauso wichtig wie unsere interne Organisation als Entwicklungsteam. Die Techem hat ihre Fachabteilungen noch traditionell neben der mit der Umsetzung betreuten IT gestellt. Für das Produkt waren damit in Summe das Fachteam und unser Entwicklungsteam in zwei organisatorisch getrennten Abteilungen verantwortlich. Mein Ziel war es dennoch eine möglichst enge Zusammenarbeit zu erreichen, um „cross-funktional“ als ein Team agieren zu können. Auch hierfür bedienten wir uns im Scrum und übernahmen Refinements und Groomings als Zeremonien. Damit konnten wir gemeinsam Anforderungen besprechen und ein gemeinsames Verständnis im ganzen Team für diese erreichen. Nur wenn wir das gleiche Wissen über Anforderungen und Lösungsdesigns miteinander teilen, trifft die technische Umsetzung im Nachgang auch die Erwartungshaltung des Product Owners sowie der Stakeholder.
Die Brücke hin zu einer agilen Aufwandsschätzung im nächsten Schritt wurde jedoch deutlich länger. Als Unternehmen mit langer Historie kommt die Techem noch aus einer Welt, in der Projekte im Vorfeld geplant und terminiert werden. An neue Anforderungen aus dem Business gesellte sich sogleich die Frage nach dem Fertigstellungstermin und welcher Entwickler diese Aufgabe genau umsetzen wird. Da wir als gesamtes Team die Verantwortung bzw. die „Ownership“ für das Produkt übernahmen, konnte ich noch recht schnell kommunizieren. Für das Verständnis einer agilen Aufwandsschätzung in Teilen der Organisation zu werben war schon herausfordernder für mich. Schließlich bestimmten wir nicht mehr die PTs für eine Anforderungen, sondern schätzen ihre Komplexität für unsere Sprintplanung im Team. Etwas anderes konnten wir auch schlicht nicht „vorhersagen“.
Softwareentwicklung von Scratch
Im Team hatten wir jedoch noch viele weitere Herausforderungen zu meistern, damit wir gleichermaßen effizient und effektiv arbeiten konnten. Eine Zusammenarbeit und Zusammenführung von Code in Git kann für zwei Entwickler noch recht einfach gehalten werden. Bei sieben Entwicklern im Team funktioniert dies jedoch nicht mehr. So nutzen wir für uns das bekannte Gitflow als Modell für unsere Codeverwaltung. Nach ein wenig Übung und Anpassung an das übergeordnete Release-Management der Techem klappte dies schnell recht gut.
Die Softwareentwicklung dreht und entwickelt sich ebenfalls kontinuierlich weiter. Als mittlerweile größeres Entwicklungsteam brauchten wir auch ein einheitliches Verständnis von Codequalität. Anderenfalls verderben bekanntlich viele Köche den Brei. Zu diesem Zweck stellten wir für uns Coding Conventions auf und richteten uns an der restlichen Compliance der IT aus. Bestandteil unser Team-internen Coding Conventions waren u.a. Namenskonventionen, unterstütze Browser und Auflösungen sowie Akzeptanzkriterien für SonarQube.
Die aus dem Scrum bekannten Definition of Done sowie Definition of Ready waren ebenfalls ein Thema für uns. Bereits im Anforderungsmanagement haben wir uns intensiv mit der Frage beschäftigt, wann eine Anforderung so weit spezifiziert ist, dass sie in die Umsetzung genommen werden kann. Aber auch die simple Frage „Wann sind wir mit der Umsetzung fertig?“ ist nicht zu verachten. Hier spielen nicht nur die fachlichen Abnahmen oder das erfolgreiche Bestehen aller Testfälle eine entscheidende Rolle. Auch Aspekte wie die technische Dokumentation, Code Reviews oder Security dürfen nicht vernachlässigt werden.
Techems Abrechnungen aus der Azure Cloud
Für uns als Entwicklungsteam kristallisierte sich schnell heraus, dass die bestehenden Auslieferungs- und Installationsprozesse hinter unserem Produkt der größte Pain Point war. Es war noch nicht allzu lange her, dass in der Techem der Betrieb von der Entwicklung in der IT getrennt war. Dies führte dazu, dass auch die Prozesse für diese „Übergabe“ zwischen den Abteilungen entsprechend gestaltet waren. Viel Papierkram und zeitaufwendige Abstimmungen – wenig bis keine Automatisierung. Dies führte dazu, dass das Team für jedes Auslieferung einer neuen Produktversion gut einen Tag beschäftigt war. Wertschöpfend war diese Zeit sicherlich nicht investiert. Darüber hinaus waren wir mit diesen langwierigen Prozessen als agiles Entwicklungsteam schlicht nicht in der Lage, schnell Updates oder Inkremente zu liefern. Tödlich, wenn Agilität kurze Entwicklungszyklen und Lean schnelles Experimentieren erfordern.
Ich setze es mir deshalb als persönliches Ziel, unsere Deployment-Prozesse auf ein zeitgemäßes Level zu heben. Zum Glück musste ich hier nicht gänzlich Pionierarbeit leisten und konnte mich auf die generelle Cloud-Strategie der Techem berufen. Hier ist die Techem aktiv dabei, den Weg in die Azure Cloud sukzessiv zu gehen. Die Elastizität und Skalierbarkeit der Cloud bietet auch hier große Vorteile gegenüber selbst entwickelten Lösungen on-premise. Die Datenmengen werden auch in der Wohnwirtschaft immer größer und KI-basierte Lösungen zur Datenauswerten auf diesen Daten werden immer wichtiger.
Vollautomatisierte Deployments in die Cloud
Ich machte mich also mit dem Team ans Werk und konzeptionierte für unser monolithisches Produkt einen „Lift und Shift„-Weg in die Cloud. Auch wenn unser betreutes Produkt nicht cloud-native entwickelt wurde, können wir dennoch von vollautomatisierten Deployment-Prozessen profitieren. Darüber hinaus bietet Kubernetes als Betriebsplattform viele „Goodies“ im Betrieb, angefangen über echtes Loadbalancing out-of-the-box genauso wie erhöhte Ausfallsicherheit.
Wir verprobten daher die Containerisierung des Produkts, die Anbindungen an alle Drittsysteme aus der Cloud heraus (dank ExpressRoute) und betrieben als Team einen massiven Technologie-Invest. Leiden hatten viele aus dem Team noch nicht produktiv mit der Azure Cloud oder Kubernetes Cluster entwickelt, sodass wir hier einiges an Wissen initial aufbauen mussten. Wir bauten eine vollautomatisierte CI/CD-Pipeline in Gitlab CI auf, welche unser Produkt kompiliert, automatisiert testet und in den Kubernetes Cluster über Helm Charts ausliefert. Wir integrierten in diese Pipeline SonarQube für eine statistische Codeanalyse genauso wie einen automatisierten CVE-Scan hinzu.
Nach zwei bis drei Monaten Arbeit (neben dem eigentlichen Business) haben wir als Team unsere neue Pipeline in Betrieb genommen und schrittweise das Produkt über die einzelnen Stages in die Cloud migriert. Von vormals mehr als einem ganzen Entwicklertag an Arbeit für eine Auslieferung lief die neue Pipeline nun in ca. zehn Minuten vollautomatisiert durch.
Das Chapter Softwarearchitektur
Neben meiner Rolle als Squad Lead hatte ich ebenfalls die Aufgabe bekommen, das Chapter Softwarearchitektur aufzubauen. Durch die erst kürzlich erfolgte Neuorganisation in der IT in eine Matrixstruktur gab es nun nicht nur Tribes und Squads in der vertikalen Organisation. Es fehlte noch die horizontalen Querschnittsfunktionen als Bindeglied: die Chapter. Die Techem hat die Chapters und Gilden nicht 1:1 adaptiert, sondern die eigentlichen Gilden schlicht Chapters genannt. Ich übernahm das Chapter Softwarearchitektur, welches sich im Themenschwerpunkt um den Softwareentwicklungsprozess mit einem Fokus auf Architektur widmet.
Im Gegensatz zu meinem Squad gab es das Chapter vorher in der Organisation noch nicht. Ich startete also komplett auf der grünen Wiese (was ich durchaus sehr mag) und stellte mir die Sinnfrage: was soll das Chapter eigentlich konkret machen? Ich begab mich also initial auf die Suche nach meinen Stakeholdern und befragte sie nach ihren Vorstellungen, Wünschen und Anforderungen. Mit den daraus gewonnenen Erkenntnissen hatte ich schon einmal ein konkretes Zielbild vor Augen. Es kristallisierte sich heraus, dass der Schwerpunkt unserer Arbeit auf der Vernetzung und der Kollaboration der unterschiedlichen Unternehmensbereiche liegen wird. Es gab weniger Forderungen der Architekten und der Entwicklungsteam nach Knowhow und architektureller Expertise. Vielmehr wurde der Wunsch nach einem Squad- und Tribe-übergreifendem Austausch sowie einer Synchronisation Einstimmung geäußert. Es fand bis dato zu wenig Abstimmung zwischen den Teams statt und die gegenseitigen Erfahrungen wurden nicht miteinander geteilt.
Kommunikation als Schlüssel zum Erfolg
Damit baute ich das Chapter mit dem Ziel auf, eine Austauschplattform für die Entwicklungsteams zu sein. Ich rekrutierte aus jedem Team den Architekten oder Lead-Entwickler als Repräsentanten für das Chapter. Wir organisierten uns auch hier agil nach Scrum und arbeiteten mit einem vier-wöchigen Sprint. Ich legte den Fokus auf die Zielorientierung in unserer Arbeit. Dafür führte ich ein Backlog ein und lies Backlog kontinuierlich priorisieren, sodass wir uns für den nächsten Sprint konkrete Umsetzungsziele steckten. Ich wollte konkrete Deliverables „hands-on“ für die Entwicklungsteams produzieren, um die Akzeptanz für unser Chapter zu bekommen. Nur so konnte ich verhindern, dass wir Lösungen in unserem architekturellen Elfenbeinturm bauen, die am Ende niemanden unserer „Kunden“ weiterhelfen.
Ferner war es mir sehr wichtig, dass wir einen regelmäßigen Austausch führen. Unsere Arbeitsergebnisse in Form Dokumentationen, Code Snippets oder Blue Prints sollten ihren Weg in die einzelnen Teams finden. Unser Credo war dafür ein „Entwickler Self-Service-Portal“ aufzubauen, an dem sich die einzelnen Entwicklungsteam ausrichten können. Hierfür haben wir in unserer Arbeit im Chapter Guidelines und Best Practices erstellt. Da wir nach Anforderung aus dem Management keine Deliverable-Verantwortung und damit operative Themen zu betreuen hatten, konnten wir uns gänzlich auf unsere Rolle als „Inhouse Consultants“ fokussieren.
Viele Wege führen die Techem nach Rom
All diese und weitere Veränderungen haben ihre Früchte getragen. Nach Ansicht des aktiven Vorstands der Techem wurden wir innerhalb von einem Jahr zum erfolgreichsten Produktteam der Techem. Viel bessere Lorbeeren kann ich mir für unsere Arbeit als Team nicht vorstellen. Es hat mich sehr gefreut zu sehen, dass all diese Entwicklungen funktioniert haben. Unser Fokus auf eine klare strukturierte und durch bewährte Methoden inspizierte Softwareentwicklungsprozesse haben uns hier zum Erfolg geführt.
Genauso wichtig ist es jedoch, auf den Menschen, die vorhandenen Mindsets und die gelebten Werte zu schauen. Peter Druckers legendäres Managementzitat „Culture eats strategy for breakfast” trifft meiner Erfahrung nach den Nagel auf den Kopf. Die schönsten Pläne und Konzepte helfen nichts, wenn sie nicht von den Menschen in der Organisation getragen werden. Am Ende macht der Mensch den Unterschied. In unserem Team hat dies bedeutet, dass wir uns alle zusammen auf Augenhöhe bewegt haben, eine offene Fehlerkultur gelebt haben und ich mich dem Leitbild des Servant Leaderships unterworfen habe. Dies hat uns – neben vielen weiteren Aspekten – zu einem High Performance Teams gemacht, auch wenn wir hier noch viel Potenzial in uns gesehen haben.
Auf der anderen Seite macht der Mensch jedoch auch den Unterschied, ob unsere Teamkultur zur restlichen Unternehmenskultur passt. Wir sind als Team nur ein Teil der großen Organisation und würden unseren eigenem Auftrag nicht gerecht werden, wenn wir hier gegen Windmühlen ankämpfen würden. Aus diesem Grund sehe ich mich nach einer zu kurzen, aber dennoch für mich persönlich sehr erfolgreichen Zeit bei der Techem wieder auf der Suche nach einer neuen Herausforderung. Ich habe für mich in einer großen Organisation die agile Transformation eines Teams erfolgreich bestreiten können und habe für mich daraus sehr viele positive Erkenntnisse gewinnen können.
Ich habe für mich gelernt, dass mein Weg an die Führung eines erfolgreichen Softwareentwicklungsteam heranzugehen erfolgreich ist. Auf Prinzipien und Leitbilder wie Agilität, Scrum, Servant Leadership, Lean Development und DevOps zu setzen funktioniert für mich auch in der Praxis bei vormals traditionell geführten Großunternehmen – wenn man es will. Ich weiß, dass ich diesen Weg weitergehen möchte.