Auf der strategischen Ebene gibt es einen einfachen Ansatz, um das virtuelle Team aus Kunde und Agentur auf gemeinsame Ziele einzuschwören, wie es die Studie empfiehlt. Wir fragen unsere Kunden vor Beginn eines neuen Software-Projekts immer: Warum? Diese Frage hilft uns dabei, zuerst die mit dem Projekt verbundenen Geschäftsziele unseres Kunden zu verstehen, damit wir die richtige Technologie auswählen können, mit der diese Ziele erreicht werden können.

Oftmals teilen uns potentielle Kunden während der Bieterphase genau mit, welche Technologie wir einsetzen sollen, zum Beispiel ein Content Management System (CMS). Hinterfragen wir anschliessend solche technologischen Vorfestlegungen, dann ist das Ergebnis häufig, dass eine andere Technologie viel besser der Umsetzung der Geschäftsziele dient.

Diesbezüglichen Diskussionen darf man als Agentur nicht aus dem Weg gehen, nur um einen Auftrag zu ergattern. Hält ein potentieller Kunde an einer Technologie fest, obwohl sie nicht optimal zu seinem Geschäftsziel beiträgt, dann ist das für uns ein klares Signal, dass von Seiten des Kunden wenig Interesse an einer Kooperation mit regem gegenseitigen Wissensaustausch herrscht. Zwar verschliessen wir uns solchen Projekten nicht in Gänze, allerdings erlaubt uns die Warum-Frage immerhin, den Kunden und das Projektrisiko einzuschätzen, welches sich aus einer niedrigen wahrgenommenen Interdependenz ergibt.

Allgemein verzeichnen wir einen Trend zu IT-Projekten, die zunehmend kooperativ gestaltet werden und in denen ein reger Wissensaustausch stattfindet. Hierzu trägt sicherlich die agile Programmierung bei, die in immer mehr Unternehmen Fuss fasst.

Die agile Programmierung ist die Methode, mit der wir bei YMC wie in der Studie gefordert den gegenseitigen Wissensaustausch in Bezug auf die Aufgaben, das heisst die Umsetzung der Ziele, sicherstellen. Über die Jahre haben wir nicht nur das agile Projektmanagement verfeinert, sondern auch viele wiederkehrende Abläufe automatisiert.

Hierzu arbeiten wir seit vier Jahren innerhalb unserer Agentur und auch im Zusammenspiel mit unseren Kunden auf Basis einer von uns intern entwickelten DevOps-Umgebung. In dieser Umgebung werden alle Prozesse für die Entwicklung (Englisch “development”, also “Dev” in DevOps) und Bereitstellung (Englisch “operations”, also “Ops” in DevOps) von Software nahtlos integriert und automatisiert durchgeführt.

Mit Hilfe unserer DevOps-Umgebung haben wir auch die Kommunikation mit dem Projektmanager des Kunden und weiterer Stakeholder beim Kunden automatisiert, um dort Informationslücken zu schliessen zu Fragen, die immer wieder in Kundenprojekten oder bei einem spezifischen Projekt aufkommen.

Zum Beispiel verwalten wir unsere agilen Programmierzyklen (d.h. Sprints) in JIRA, woraus wir Kunden automatisch über Slack darüber informieren, wann ein Sprint anfängt, welche Aufgaben im Sprint abgearbeitet werden, welche Aufgaben ausserplanmässig extra hinzu kamen, und wann der Sprint endet. Er erfährt auch, falls ein neues Produktivsystem nach einem Sprint bereitgestellt oder ein vorhandenes aktualisiert wurde.

Durch diese Automatisierung per DevOps, sparen wir gut und gerne 30 Minuten Kommunikationsaufwand pro Sprint. Reibungsverluste durch unzureichende mündliche Kommunikation wird vermieden und stattdessen wird sichergestellt, dass alle Stakeholder beim Kunden alle notwendigen Informationen erhalten.

Ein weiteres Beispiel sind automatisierte Reports zu den in der Projektlösung enthaltenen Software-Lizenzen. Hierüber freuen sich die Legal-Abteilungen der Kunden, denn sie müssen im Projektverlauf nicht nachfragen, ob neue Software-Komponenten mit anderen Lizenzen hinzu kamen. Vielmehr bekommen sie diese Information proaktiv zugeschickt.

Auch Changelogs oder Release Notes werden von unserem DevOps-System automatisiert erstellt und dem Kunden zur Verfügung gestellt, damit dieser in Echtzeit über den Projektfortschritt im Bilde bleibt.

Nicht nur die Kommunikation mit unserem Kunden läuft anhand unserer DevOps-Lösung hoch effizient ab, sondern auch die Programmierung selbst, denn darin werden alle wiederkehrenden Entwicklungsaufgaben automatisiert. Zum Beispiel werden Komponenten der Software-Lösung automatisch aktualisiert, unter anderem mit Hilfe des Yarn Package Manager. Dadurch wird verhindert, dass unsere Kunden nach Jahren der Nutzung vor einer veralteten Individuallösung stehen, deren Teile nur mühsam und mit hohem finanziellen Aufwand aktualisiert werden können, zum Beispiel um Sicherheitslöcher zu stopfen.

Insgesamt ermöglicht es unsere DevOps-Umgebung damit, dass Investitionen in Projekte effektiv genutzt werden. Leider nimmt dieser Vorteil umso mehr ab, je mehr uns Kunden aufgrund interner Richtlinien unter anderem Vorgaben bei der Bereitstellung der Software (also im Operations-Bereich von DevOps) machen. Dadurch lässt sich das Ausrollen der Software nicht mehr nahtlos in unseren DevOps-Prozess integrieren, wodurch Brüche entstehen, die die Effizienz herabsetzen, wodurch die Verantwortung diffundiert, weil die Interdependenz hinsichtlich der Aufgaben denkbar gering ist und das Projekt dadurch insgesamt teurer wird.

Damit Kundenprojekte erfolgreich und kosteneffizient ablaufen, sehen wir uns und betätigen wir uns auch sehr stark als Brückenbauer. Wie in der vorgestellten Studie empfohlen, haben wir in unserer Agentur Mitarbeiter, die die Geschäftsprozesse beim Kunden schnell verstehen und für unsere Programmierer, aber falls nötig auch die Inhous-Programmierer beim Kunden, sozusagen übersetzen, damit sie aus technischer Sicht verständlich werden.

Hierbei kommt uns nicht nur unsere langjährige Erfahrung zugute, sondern auch die Tatsache, dass wir mit Hilfe unserer DevOps-Infrastruktur zwischenmenschliche Kommunikationsaufwände entlang der Tool- und Wertschöpfungskette durch Automatisierung, abbauen konnten. Die Zeit, die wir so im Hinblick auf die Umsetzung, also bei den Aufgaben gewinnen, können wir sozusagen als Brückenbauer zur Verfestigung der Interdependenz bezüglich der gemeinsamen Projektziele verwenden.

In gewisser Weise haben wir dadurch die Freiheit gewonnen, in Ansätzen quasi parallele Strukturen zu unseren Kunden aufzubauen, damit diese immer einen passenden Ansprechpartner in den jeweiligen Disziplinen haben, sei es bei den Geschäftszielen, der technologischen Umsetzung, beim Marketing, usw. Dadurch verschwimmen teilweise die Grenzen zwischen unserem Kunden und unserer Agentur und es entsteht ein virtuelles Team, das sich wie ein Software-Startup anfühlt.