Push-Kulturen sind hartnäckig

Obwohl alle mit Hochdruck arbeiteten, klappte das Projektmanagement nicht so wirklich. Das Projekt kam schleppend voran, man war frustriert und demotiviert. Alle waren sich einig, dass es so nicht weitergehen sollte. Agile und Scrum schienen passende Problemlöser zu sein. Also los! Erste Workshops zum Scrum Vorgehen, erste Vorbereitungen, der erste Sprint, die erste Retrospektive:

„Dieser Meeting-Marathon, ich komm nicht zum arbeiten!“, „Es reicht, wenn wir nur jeden zweiten Tag ein Daily machen“, „Für die Konzeption haben wir doch Architekten“, …

Also gut, braucht es die Scrum-Meetings wirklich so exzessiv? Die Hälfte fühlt sich besser an. Nächster Versuch, nächster Sprint, nächste Retrospektive:

„Die User Stories waren noch nicht wirklich ‚Ready‘ .“, „Ich wurde nicht gefragt bei diesem Konzept!“, „Die Abstimmung bzgl. gangbarer technischer Umsetzungen war nicht gut.“, …

Also gut, wir brauchen so was wie ein Backlog-Grooming, damit die User Stories besser abgestimmt sind.  „Was! Noch ein Meeting!?!“

Ich bin überzeugt, dass viele Unternehmen ähnliche Erfahrungen gemacht haben. Als Scrum-Master könnte man daran verzweifeln. Eigentlich liegt die Lösung doch auf der Hand? Scrum funktioniert, wenn man es richtig anwendet! Warum nimmt das Team nicht die wenigen Regeln des Frameworks an und setzt die Scrum-Meetings nicht konsequent zu ihrem Nutzen ein?

Ganz einfach: Weil man Scrum nicht ohne Weiteres auf eine bestehende Kultur draufsetzen kann. Damit sich das Scrum-Framework voll entfalten kann, braucht es zunächst den notwendigen Freiraum. Die Teammitglieder müssen sich tatsächlich so fühlen, als dass sie nichts Besseres zu tun hätten. Nur dann werden sie sich anfangs bereitwillig auch für noch nicht effizient laufende Scrum-Meetings die Zeit nehmen. Aber eben das will gelernt sein! Wenn man bisher selbstverantwortlich und unter ständigem Hochdruck gewohnt war zu arbeiten, fällt es manchem schwer, bewusst anfängliche Ineffizienz in Kauf zu nehmen. Die neu geschaffenen Freiräume werden nicht genutzt, um an neuen Arbeitsweisen zu reifen. Wer kennt nicht die dazu passende Metapher: „Ich hab keine Zeit die Axt zu schärfen, weil ich sonst noch weniger Bäume fälle!“

Jetzt könnte man meinen: Nichts einfacher als das in einem Scrum-Umfeld. Mit einem guten Product Owner auf der Anforderungsseite könnte dieser doch in den ersten Sprints bewusst weniger Stories für die Sprints vorsehen. Und trotzdem: Der Drang, dort keine Zeit zu verlieren, wo man nicht wirklich dabei sein muss, ist nach wie vor tief im Unterbewusstsein verankert. So kommt es, dass sich manche Teammitglieder schlichtweg vom Scrum-Framework gegängelt fühlen und keinen Sinn darin sehen.

Leider gibt es keine Blaupause, wie man mit solchen Situationen umgeht. Für die einen Scrum-Teams funktioniert es, wenn es klare Vorgaben bzgl. des Scrum-Frameworks gibt und sie erkennen mit der Zeit, dass es gut so war. Bei anderen Scrum-Teams sitzt die Blockade gegenüber Scrum und seiner vermeintlichen Ineffizienz so tief, dass man nur mit kleinen Schritten und sehr vorsichtiger Unterstützung von außen vorankommt.

Teamdynamik und Freelancer

Es gibt immer wieder Gründe, warum man ein Scrum-Team gerne um ein oder zwei weitere Teammitglieder erweitern möchte, z.B. um eine höhere Entwicklungsgeschwindigkeit zu erreichen. Es ist allgemein bekannt, dass dadurch die Geschwindigkeit zunächst sinkt, um sich dann später auf einem höheren Niveau einzupendeln. Dazu gibt es genügend Literatur und Erfahrungsberichte und soll hier nicht das Thema sein.

Interessanter finde ich die Auswirkungen auf die Teamdynamik, wenn man ein Scrum-Team das bisher ausschließlich aus fest angestellten Mitarbeitern besteht, mit freiberuflichen Entwicklern ergänzt. Folgende Erfahrungen habe ich dabei gemacht:

Zunächst muss das neue Teammitglied von den bestehenden fest angestellten Teammitgliedern eingearbeitet werden. Unabhängig davon ob der neue Mitarbeiter fest angestellt wurde oder als Freiberufler seine Dienste erbringt, ist diese Aufgabe eine zusätzliche Belastung. Im Falle von freiberuflichen Mitarbeitern stellen sich diese Anstrengungen aber als Verschwendung dar, da das aufgebaute Wissen ja nicht in das permanente Wissenskapital des Unternehmens einfließt. Schließlich ist das Dienstleistungsverhältnis nur von temporärer Dauer.  Nicht selten hat allein diese Tatsache demotivierende und frustrierende Auswirkungen bei den Mitarbeitern, die diese zusätzliche Belastung tragen.

Aus Sicht der fest angestellten Teammitglieder wird der freiberufliche Mitarbeiter immer als ein Externer gesehen. Auch wenn das Team gut eingespielt ist, kommt immer wieder durch, dass mit dem freiberuflichen Mitarbeiter ein Dienstleistungsverhältnis besteht. ‚Der ist ja nur eine Zeit lang da und wird in ein paar Monaten wieder verschwunden sein‘ sind typische Aussagen. Dies kann z.B. dazu führen, dass bei strategischen Besprechungen oder Entscheidungen die externen Teammitglieder nicht mit einbezogen werden und somit das Teampotential nicht vollständig genutzt wird.

Frei von historischem oder operativem ‚Ballast‘ kann der freiberufliche Mitarbeiter in der Regel ungestörter an seinen Aufgaben arbeiten als die festangestellten Mitarbeiter. Damit verbunden ist ein höherer Output. Schnell mutiert der Freelancer dadurch zum ‚Arbeitstier‘ und er erhält vom Team seine Aufgaben zugewiesen anstatt sich beim Daily Scrum Tasks auf freiwilliger Basis zu nehmen. Es bildet sich damit innerhalb des Teams eine Hierarchie aus, die eher dem klassischen Projektmanagement entspricht. Die Identifikation und das Commitment für das Sprintziel gehen für den freiberuflichen Mitarbeiter verloren oder werden zumindest aufgeweicht.