Technical Agile Coach
Patrick Baumgartner arbeitet als Technical Agile Coach im Code und mit dem Team. Der Fokus liegt auf Entwicklungskompetenzen, nicht auf Zeremonien oder Zertifikaten.
Entwickler-Coaching für Java- und Spring-Teams
Ihr Team kennt die Praktiken, wendet sie unter Lieferdruck aber nicht konsequent an. Technisches Coaching stellt die Arbeit in ihren echten Kontext: Ein Technical Agile Coach arbeitet im Pairing in Ihrem Repository und an aktuellen Tickets und hilft dem Team, tragfähige Arbeitsgewohnheiten zu entwickeln.
Typischerweise ein bis zwei Tage pro Woche, mindestens drei Monate.
Anonymisierte Ergebnisse: Ein Produktteam eines Grossunternehmens steigerte den Durchsatz in der Auslieferung um 25 Prozent; ein Team im Finanzdienstleistungsbereich wechselte von quartalsweisen Releases zu täglichen Produktions-Deployments. Ergebnisse hängen von Ausgangslage und Rahmenbedingungen ab.
Womit Teams typischerweise zu uns kommen
Ihr Team kennt die Theorie. Der Lieferdruck zeigt den Abstand zwischen Wissen und Handeln.
-
Wissen wird im Alltag nicht angewendet
Das Team kennt die Konzepte. Unter Termindruck greift es trotzdem auf die bisherigen Arbeitsweisen zurück, weil Übung und Feedback im echten Projekt fehlen.
-
Reviews stauen sich bei wenigen Personen
Schwierige Reviews und Entscheidungen warten auf wenige erfahrene Engineers. Das bremst die Lieferung und verteilt Wissen zu langsam im Team.
-
Den Tests kann man nicht trauen
Die Testsuite ist langsam, flaky oder beides. Entwickler umgehen sie, weil das Feedback zu spät kommt, um das Design zu steuern.
-
KI erhöht Tempo und Prüfbedarf
KI-Coding-Assistenten können die Menge vorgeschlagener Änderungen erhöhen. Ohne klare Review-, Test- und Verantwortungsstandards kann das Team Code übernehmen, den es später nicht verlässlich erklären oder warten kann.
Das ist technisches Coaching, kein Scrum- oder Prozess-Coaching. Wenn Sie breitere Unterstützung in der Softwareentwicklung brauchen, sehen Sie unsere Leistungen.
Was das Coaching abdeckt
Kein Kurs im Seminarraum. Wir üben diese Fähigkeiten in Ihrem Code, an Ihrem Backlog und dort, wo die Abwägungen real sind.
-
Testing und Feedback unter Lieferdruck
Test-Driven Development, schnelles Feedback und eine Teststrategie, die nützliche Belege liefert, ohne jede Änderung zu verlangsamen.
-
Legacy-Refactoring mit geringerem Risiko
Characterization Tests, Seams, kleine Schritte und Designverbesserungen, die Risiko senken, während das Produkt weiter ausgeliefert werden muss.
-
Pairing und Mob Programming
Wissen sichtbar machen. Schwierige Tickets gemeinsam bearbeiten, damit Expertise sich verteilt und nicht bei einem Senior Developer bleibt.
-
Reviews, die lehren
Code Review wird zu einer Lernschleife statt zu einem Tor. Wir verbessern Review-Gewohnheiten, Feedbackqualität und gemeinsame technische Standards.
-
Disziplin bei Continuous Integration
Der Main-Branch bleibt auslieferbar: kleine Änderungen, zuverlässige Pipelines, schnelles Feedback und Verantwortung für kaputte Builds.
-
Architektur, die sich entwickeln kann
Inkrementelle Architekturverbesserung in Ihrem bestehenden Code. Für einen fokussierten Architektureingriff sehen Sie unser Architektur-Review.
-
Verantwortungsvolle KI-gestützte Entwicklung
KI-Coding-Assistenten nutzen, ohne Review-Standards zu schwächen: generierten Code verstehen, testen und begrenzen. Das Team übernimmt nur Änderungen, die es erklären und verantworten kann. Für vertiefte KI-Entwicklung siehe Agentic AI Engineering.
So läuft der Auftrag ab
Der Auftrag hat eine ausdrückliche Übergabe und einen definierten Endpunkt. Während Ihr Team mehr Verantwortung übernimmt, reduzieren wir unsere Mitarbeit.
-
Ausgangslage
Wir beobachten, wie das Team wirklich arbeitet: einen Sprint, den Code, die Pipeline, die Review-Kultur und die Punkte, an denen Arbeit stecken bleibt.
-
Ziele vereinbaren
Wir vereinbaren wenige technische Ziele mit dem Team, nicht nur mit dem Manager. Die Ziele verbinden technische Arbeitsweisen mit messbaren Lieferergebnissen.
-
Coaching im Arbeitsalltag
An regelmässigen Tagen pairen und reviewen wir und arbeiten gemeinsam an aktuellen Tickets. Wir zeigen Praktiken im konkreten Kontext und helfen dem Team, sie selbst weiterzuführen.
-
Schrittweiser Rückzug
Wir reduzieren unsere Präsenz bewusst und verfolgen, ob die vereinbarten Praktiken weiter genutzt werden. Der Zeitpunkt richtet sich nach den beobachteten Ergebnissen.
Was Sie erhalten
Arbeitsweisen und technische Verbesserungen, die Ihr Team selbst weiterführt.
- Eine Ausgangslage Ihrer aktuellen Entwicklungsgewohnheiten, Lieferabläufe und technischen Einschränkungen
- Vereinbarte Ziele, die das Team versteht und beeinflussen kann
- Arbeitsbeispiele in Ihrem Repository: Tests, Refactorings, Reviews und Pipeline-Verbesserungen
- Eine zuverlässigere Testsuite und schnelleres Feedback, wenn dort der Engpass liegt
- Review- und Pairing-Praktiken, die Wissen über wenige erfahrene Personen hinaus verteilen
- Praktische Leitplanken für KI-gestützte Entwicklung, die Verständnis und Verantwortung erhalten
- Metriken, die zeigen, ob die Gewohnheiten nach unserem Rückzug halten
- Eine geplante Übergabe und ein vereinbartes Ende des Auftrags
Für wen ist das gedacht?
-
CTOs und Engineering Manager mit Java-Landschaft
Sie verantworten Java und Spring in Produktion und sehen einen konkreten Abstand zwischen den benötigten und den im Alltag angewendeten Entwicklungskompetenzen.
-
Teams nach einer fachlichen Schulung
Das Team kennt die Begriffe und Methoden, braucht aber Unterstützung dabei, sie unter realen Lieferbedingungen anzuwenden.
-
Organisationen mit wachsender Lieferung
Onboarding dauert Monate, Senior Engineers sind überlastet und Sie brauchen technische Gewohnheiten, die ohne eine weitere Prozessebene skalieren.
Warum wir
Wir verbinden technische Tiefe und Lehrerfahrung mit der nötigen Praxis, um Ihr Team auch an den schwierigen Stellen eines produktiven Systems wirksam zu coachen.
Lehre und Praxis
Patrick ist seit 2013 ZHAW-Dozent, Java Champion, Oracle ACE, Microsoft MVP, Spring Certified Professional und VMware Certified Spring Instructor.
Erkenntnisse aus früheren Aufträgen
In zwei anonymisierten Aufträgen wechselte ein Team im Finanzdienstleistungsbereich von quartalsweisen Releases zu täglichen Produktions-Deployments; ein Produktteam eines Grossunternehmens steigerte nach technischem Coaching den Durchsatz in der Auslieferung um 25 %. Ergebnisse hängen von Ausgangslage und Rahmenbedingungen ab.
Klein und erfahren
Patrick leitet das Coaching. Wo der Auftrag ergänzende Erfahrung in Lieferung oder Lehre erfordert, unterstützt ihn das Kernteam. Der belegte Erfahrungshintergrund umfasst mehr als 20 Jahre Enterprise Java, über 70 Konferenzvorträge und über 200 Workshops.
Lernen Sie die Menschen hinter der Arbeit auf unserer Unternehmensseite kennen. Entdecken Sie unsere weiteren Leistungen, wenn Coaching Teil einer grösseren technischen Veränderung ist.
Häufige Fragen
Wie unterscheidet sich das von einem Training?
Ein Training vermittelt Wissen und bietet Raum zum Üben. Coaching begleitet die Anwendung im Arbeitsalltag. Wir arbeiten in Ihrem Repository, an Ihrem Backlog und mit Ihren realen Rahmenbedingungen. Wenn Ihr Team zuerst eine fachliche Grundlage braucht, finden Sie unsere Trainings.
Wie viel Zeit Ihres Teams beansprucht das?
Das Coaching findet während der normalen Arbeit statt, nicht zusätzlich dazu. Wir pairen, führen Code-Reviews und arbeiten an Aufgaben aus dem laufenden Entwicklungsprozess, typischerweise ein bis zwei Tage pro Woche.
Findet das Coaching remote oder vor Ort statt?
Beides ist möglich. Termine vor Ort können in den ersten Wochen hilfreich sein, weil Beobachtung, Pairing und Teamgespräche leichter fallen. Danach nutzen wir den Mix, der zu Ihrer Organisation passt.
Wie messen Sie, ob es funktioniert hat?
Wir vereinbaren mit dem Team Ausgangswerte und verfolgen passende Signale aus Lieferung und Entwicklung: etwa Lead Time und Deployment-Frequenz als zwei der DORA-Metriken, den Ablauf von Code-Reviews, das Vertrauen in die Testsuite, die Onboarding-Zeit und die Fähigkeit des Teams, Probleme ohne uns zu lösen.
Was, wenn das Team Vorbehalte hat?
Vorbehalte sind eine wichtige Information und kein Grund, dem Team eine Methode aufzuzwingen. Wir beobachten zuerst die tatsächliche Arbeit, vereinbaren Ziele mit dem Team statt nur mit dem Management und erproben Verbesserungen an aktuellen Aufgaben. Das Coaching soll Verantwortung übertragen, nicht Abhängigkeit schaffen.
Wie arbeiten Sie mit mehreren Teams?
Wir starten mit einem Pilotteam, üblicherweise dort, wo der Lieferengpass am deutlichsten ist. Gemeinsame Reviews und Pairing beziehen benachbarte Teams ein; gleichzeitig entwickeln wir interne Coaches, die die Praktiken weiterführen können. Bei mehreren Teams staffeln wir den Start: Zuerst etablieren wir den Ansatz mit einem Team, dann kommt das nächste hinzu.
Was kostet das?
Typischerweise ein bis zwei Tage pro Woche, mindestens drei Monate. In einem 30-minütigen Gespräch klären wir Umfang, Ziel und passenden Startpunkt.
Etablieren Sie Praktiken, die im Arbeitsalltag Bestand haben
Buchen Sie ein kurzes Gespräch mit Patrick, 30 Minuten genügen. Bringen Sie den konkreten Engpass und ein Beispiel aus der Arbeit Ihres Teams mit. Gemeinsam klären wir, ob Coaching im Arbeitsalltag passt und wo wir beginnen sollten.