Aktuelles.

Aspekte der agilen Arbeitsweise bei FORTIS – Teil 2: Kundennähe als Prinzip

Agiles Arbeiten erfordert dem Agilen Manifest zufolge grundsätzlich eine enge Kommunikation zwischen allen Beteiligten. Die FORTIS IT-Services GmbH hat sich daher früh dazu entschlossen, dass ihre Software-Entwicklungsteams in Abstimmung mit den Kunden eng mit ihnen zusammen arbeiten. Dadurch stehen sie als Dienstleistende von FORTIS in permanenter, direkter Abstimmung mit den Auftraggebenden. Zweiter Teil einer Serie zu Aspekten der agilen Arbeitweise bei FORTIS, Teil 1 im Februar 2018 behandelte die Sinnhaftigkeit.

Im Agilen Manifest von 2001 betont der erste Grundsatz:

„Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“.

Dieser wird durch den dritten und vierten Grundsatz ergänzt, die dabei ebenfalls von entscheidender Bedeutung sind:

„Zusammenarbeit mit dem Kunden ist wichtiger als eine Vertragsverhandlung.“

Sowie: „Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.“

Die agilen Grundsätze sowie auch die zwölf Prinzipien hinter dem Agilen Manifest sind im Internet nachzulesen. Als wichtiger Hinweis zu den Grundsätzen wird dort ergänzt, dass auch die Werte am Ende der Sätze wichtig sind, diejenigen zu Beginn der Sätze aber höher eingeschätzt werden. Inwiefern beziehen sich die zitierten drei Grundsätze nun auf die Entscheidung von FORTIS, seine Entwicklungsteams nahe beim Kunden einzusetzen?

Direkter Kontakt ist unersetzlich

Der Vorrang von Individuen und ihren Interaktion gegenüber festgelegten Prozessabläufen bedeutet, dass der direkte Kontakt zwischen den Auftraggebenden und –ausführenden unersetzlich ist. Dies formulieren auch Prinzipien der Softwareentwicklung: „Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.“ sowie „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Erntwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“

Ähnliches betont das zweite Zitat (der dritte Grundsatz): Die Ausgestaltung der täglichen Zusammenarbeit ist wichtiger als das, was auf einem Vertragspapier steht. Dies ergänzt eines der Prinzipien der Softwareentwicklung: „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“ Mit anderen Worten: Agile Arbeitsweise kann nur funktionieren, wenn die Teams Eigenverantwortung und Entscheidungsbefugnis besitzen.

Diese Eigenschaften können jedoch nicht durch Zuweisung erteilt werden, sondern die Beteiligten müssen sich diese selbst erwerben. Damit einher geht die Bereitschaft sinnvolle Entscheidungen zu treffen, unternehmerisch zu denken und im Sinne der Verantwortung auch dafür einzustehen.

Teaminterne Veränderungsfähigkeit

Schließlich: Die Möglichkeit auf Veränderungen schnell zu reagieren ist nur dann gegeben, wenn die Entscheidungsbefugnis und -bereitschaft dazu bestehen. Andernfalls würden sich die Teams in einer Illusion der Planbarkeit wägen und müssten zudem bei Abweichungen vom Plan zuerst in der zentralen Business Unit nach möglichen Lösungen fragen oder nach der Erlaubnis eine neue Lösung umzusetzen. Dies ist insbesondere bei Software-Entwicklung (wie in vielen anderen Bereichen des Lebens auch) nicht zielführend. Vor allem wäre ein solches Vorgehen behäbig, zeitraubend und – angesichts sich immer schneller verändernder Märkte – auch nicht zeitgemäß.

Reagieren auf Veränderung muss teamintern geschehen. Dies soll zweifellos im Einklang mit den unternehmerischen Grundsätzen beider beteiligten Unternehmen stehen (Auftraggebende und -ausführende), dies bedeutet aber auch, dass die Teams selbstorganisiert und dabei in der Lage sein sollten, ihre interne Organisation auch anzupassen. Beides ist in weiteren Prinzipen der Softwareentwicklung festgehalten: „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.“ und „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“, „inspect“ und „adapt“ genannt. Alexander Boehnke von FORTIS IT-Services erklärt:

„Inspect und adapt im Team umsetzen macht man nicht einfach so über Nacht mit ein paar Retrospektiven. Es erfordert ein über Jahre gewachsenes Vertrauen, um tatsächlich kritisch mit sich und dem Team umgehen zu können und das dann auch mit den Kolleginnen und Kollegen zu teilen.“

Dass Entwicklungsteams eng mit Kunden arbeiten, ist also keine Erfindung von FORTIS, sondern lediglich eine sinnvolle Umsetzung der als relevant erkannten Grundsätze des Agilen Manifests, um in enger Koproduktion bestmögliche Ergebnisse bei der Software-Entwicklung zu erzielen. Gleichzeitig – um eine gelegentlich geäußerte Kritik zu entkräften – bedeutet dieser Umstand keineswegs, dass die Teams „Dienende zweier Herren“ wären.  Vielmehr agieren sie wie oben geschildert in größerer Eigenverantwortung und Autonomie als andere Dienstleister.

Die Einbindung von Entwicklungsteams bei den Kunden betrifft bei FORTIS bereits Neueinsteigende im sogenannten K.N.U.T.-Programm („Kontinuierliche Nachwuchsentwicklung ungeschliffener Talente“), die von Anfang an ihren Einsatzort ebenfalls in den jeweiligen Business Teams haben und damit auch unmittelbar den Kundenkontakt als zentrales Element der Arbeitsweise bei FORTIS kennenlernen.

Dieses Modell steht zugleich für flache Hierarchien, wobei das Software-Unternehmen in seinem Aufbau nicht mehr wie eine Pyramide darzustellen ist, sondern vielmehr wie ein Kreis voller Kreise. Die einzelnen kleineren Kreise stellen die Teams dar, die sich an der Peripherie, das heißt im direkten Kundenkontakt bewegen. Dazu haben sich die Teams vor Ort mit dem Ohr am Kunden bestens bewährt. Wie die autonomen Teams bei FORTIS in ihren alltäglichen Abläufen ticken und welche Instrumente sie zur regelmäßigen Reflektion und Anpassung haben, behandelt der dritte Teil der Serie im Juni 2018.