Einführung von Scrum bei XING – ein Erfahrungbericht #2: Die Schwierigkeiten

Willkommen zum zweiten Teil der Einführung von Scrum bei XING. Nachdem es im letzten Beitrag um die Gründe für die Scrum-Einführung ging, beschreiben wir heute die Hürden, die es zu überspringen galt.

Die Herausforderungen

Die erste Herausforderung war es, Scrum innerhalb des ganzen Unternehmens zu verstehen. Wenn Scrum als Projektmanagement-Methode oder als Vorgehensmodell wie etwa das Spiralmodell missinterpretiert wird, bleiben die meisten Vorteile ungenutzt. Vorboten solcher ungünstigen Voraussetzung ist das Beibehalten klassischer Projektstrukturen und Planungsmethoden. Die Herausforderungen liegen daher nicht in komplexen Prozessen, methodischen Ansätzen oder Tools. Es stellt sich eher als Hürde dar, die agilen Werte – wie im Agilen Manifest beschrieben – und die neuen Prinzipien (adieu Projektmanagement-Dreieck!) zu verstehen und die neuen Rollen und Verantwortlichkeiten umzusetzen. Diese Prämissen verändern Teile des Produktentwicklungsprozesses grundlegend.

Das für die neuen Rollen benötigte Wissen und die entsprechenden Erfahrungen zeigen sich anfangs oft mit den vorherrschenden Jobbeschreibungen im Unternehmen unvereinbar. Sowohl die Umstellung vom zentralen Projektmanager zum Scrum Master, (die organisatorische Kompetenz des Teams und der Prozesse), als auch die entrepreneurhafte Rolle des Product Owners (verantwortlich für die Ziel-, Budget- und Prioritätenvergabe) müssen erst mal akzeptiert und verinnerlicht werden. Der Wille von Management und Mitarbeitern, diese Veränderungen voranzutreiben und auch mehr Verantwortung in die Teams zu geben und zu übernehmen, ist absolut notwendig. Damit dies funktioniert, bedarf es einer Unternehmenskultur, die grundsätzlich dem agilen Manifest folgen kann.

Auch technisch war eine Optimierung erforderlich, obwohl XING schon vor der Scrum-Einführung jede Woche Produkte oder Features veröffentlicht hatte. Unsere Infrastruktur und die Routinen innerhalb der Projektteams waren nicht darauf zugeschnitten, alle ein bis drei Wochen fertigen Code innerhalb eines Projektes ohne Produktivitätsverlust zu veröffentlichen. Hier mussten wir einige Anpassungen vornehmen und unsere Arbeitsweisen ändern, zum Beispiel hinsichtlich unserer Qualitätssicherung oder des Releasemanagements.

Im nächsten und letzten Teil geht es um unser Vorgehen bei der Einführung von Scrum und unser bisheriges Fazit.