Als Coach die gemeinsame Richtung aufzeigen

04.12.2015  /  3 Minuten Lesezeit
Autor:
Christian Warneck

Amadeus Blog: Christian Warneck, Leiter des Bereichs Research & Development (R&D) bei Amadeus Germany, setzt immer stärker auf agile Teams und hat die Vision, Produkte auch über Standorte hinweg in einem synchronisierten Gesamtsystem zu entwickeln.

Das fünfte Interview zu den Rollen in der agilen Software-Entwicklung widmet sich dem Vorgesetzten. Einen übergreifenden Artikel zum Thema inklusive Tipps für die eigene Arbeit finden Sie hier im aktuellen Amadeus Magazin.

Wie viele Entwickler arbeiten bei Amadeus Germany bereits im agilen Modus?

Von den etwa 150 Vollzeitkräften arbeiten heute bereits 48 Prozent im Scrum, insbesondere bei neuen Projekten. Produkte im „Maintenance Mode“ laufen nach Kanban (Vorgehensmodell zur Softwareentwicklung, bei dem die Anzahl paralleler Arbeiten, der Work in Progress (WiP), reduziert und somit schnellere Durchlaufzeiten erreicht und Probleme – insbesondere Engpässe – schnell sichtbar gemacht werden sollen.) Ziel ist, dass das agile Mindset bei R&D alle Mitarbeiter erfasst.

Wie gehst du dieses Ziel an?

Schulung spielt im Moment noch eine zentrale Rolle. Zunächst wird ein Grundverständnis aufgebaut, damit das agile Prozedere verständlich ist und die Vorteile erkennbar sind. Nach der Scrum-Einführung innerhalb eines Projektes startet eine zweite Trainingsphase, in der dann Fragen viel konkreter formuliert und adressiert werden können.

Hast du Tipps zum Aufbau der Teams?

Sehr gut funktioniert das Mischen von Teams: Junge und erfahrene Teammitglieder ergänzen und inspirieren sich gegenseitig.

Welche Kernwerte des agilen Prozesses stehen für dich im Mittelpunkt?

Zum einen wird die Kundensicht (der sogenannte Product Owner übernimmt die Sichtweise der Kunden) einbezogen. Die Kunden können jederzeit Anforderungen neu einbringen und Prioritäten anpassen. Zum anderen wird eine enorme Sichtbarkeit und Transparenz auf das, was gerade passiert, erzeugt und übergreifend führt der geleitete Prozess zur offenen Kommunikation. Das ist eine wichtige Veränderung im Vergleich zur alten Welt, wo Entwickler mitunter im stillen Kämmerlein programmierten. Teamgeist ist ganz wichtig, genauso aber auch die größere Eigenverantwortung. Klar, auch dieses System funktioniert nicht ohne Regeln – nur dass diese wenigen Regeln gerne angenommen werden.

Deine Rolle als Vorgesetzter hat sich gewandelt – du bist heute eher Coach als Chef. Worin siehst du deine zentralen Aufgaben?

Ich muss vor allem motivieren und alle auf diesem Weg mitnehmen. Und ich muss dafür sorgen, dass alle auf dem gleichen Verständnis aufbauen. Dazu haben wir beispielsweise ein Forum gegründet, wo die Manager von agilen Teams ihre Erfahrungen untereinander austauschen. Dort veranschauliche ich beispielsweise, dass eben nicht die Manager die Leader sind, sondern diejenigen, die die Entscheidungen treffen, die Vision verfolgen, die Ziele einbringen. Und das kann jeder einzelne Mitarbeiter in einem Team sein. Meine Aufgabe ist es auch, Dinge, die gut funktionieren, in andere Teams hineinzubringen und die gemeinsame Richtung vorzugeben.

Welche Herausforderungen siehst du noch?

Ich nenne es mal die Skalierung von Agilität. Übergreifende Komponenten sind noch nicht immer synchronisiert mit Projekten, die aber Teil davon werden müssen. Eine App beispielsweise wurde mit anderen Sichtweisen programmiert als eine Buchungsanwendung. Hier brauchen wir eine Vision, wie unsere Produkte zu 100 Prozent zusammenspielen. Auf der Basis können wir dann Schnittstellen definieren. Schwierig wird es auch, wenn Produkte in ganz verschiedenen Teams weiterentwickelt werden. Das heißt, wir brauchen ein Gesamtsystem auch über Standorte hinweg. Und stabile Teams, die zusammenspielen, auch wenn sich Themen ändern. Daran arbeiten wir.

Wenn Kunden Anforderungen im Prozess noch ändern können, wird das nicht schnell ein Fass ohne Boden?

Wir hören den Kunden – externen wie internen – zu und kommunizieren offen, müssen aber auch klären, dass pro definiertem Zeitabschnitt, also pro Sprint, beispielsweise nur zehn Anforderungen umgesetzt werden können. Kommt die elfte, passen Zeitplan bzw. Budget nicht mehr. Entweder sagen wir dann deutlich Nein zur elften Anforderung, oder wir priorisieren um – was im Scrum ganz normal ist. In dem Prozess können Kunden bzw. Product Owner normalerweise mit einem gut begründeten, transparenten Nein gut umgehen.

Alles in allem – liegt dir das agile Vorgehen?

Absolut! Ich möchte meine Zeit nicht nur im Cockpit am PC verbringen, sondern eng mit den Teams arbeiten. Ich bringe gerne meine Ideen ein und fördere die Selbständigkeit der Teams.

 

Weitere Blogartikel dieser Serie:

Als motivierender Steuermann mittendrin
Alle Kraft dem Team
Nach dem Planning Poker möglichst schnell coden
Je früher man einen Fehler findet desto besser

Über den Autor

Christian Warneck, der seine frühe Kindheit in Boston, USA, verbrachte, studierte Mathematik mit Schwerpunkt Informatik in Darmstadt und lebt heute mit seiner Familie in Bad Homburg. Er arbeitet seit 1992…
Mehr über den Autor

Schreiben Sie einen Kommentar