Agilität, New Work, Neue Wirtschaft, … – Arbeit ganzheitlich vom Menschen her gedacht – radikal!

Es sind sehr erfreuliche Veränderungen, die man in letzter Zeit immer wieder lesen darf. Arbeit soll wieder menschlicher werden. Um es vorwegzunehmen: Natürlich erhoffen sich Unternehmen von revolutionären Ansätzen wie New Work entsprechende wirtschaftliche Vorteile. Das ist nicht nur völlig ok, sondern vielmehr Bedingung, damit New Work überhaupt eine Chance hat. So gesehen ist die Digitalisierung als Treiber für diese Veränderungen sehr zu begrüßen.

Viel mehr möchte ich dazu an dieser Stelle gar nicht sagen, sondern eher darauf eingehen, was für mich die oben genannte Radikalität bedeutet. Sie bedeutet für mich in allererste Linie zunächst jeden Menschen so anzunehmen, wie er sich bei seiner täglichen Arbeit gibt. Und zwar nicht nur mit seinen individuellen Fähigkeiten, Meinungen, usw., sondern auch mit seiner jeweiligen zu diesem Zeitpunkt persönlichen Lebenserfahrung und Reife. Wir alle sind auf einer Reise, die uns, je nachdem, was wir erfahren haben, zu dem gemacht haben, was wir heute sind.

Wenn ich mit Menschen, mit denen ich in Projekten, zu denen ich hinzugezogen werde, neu zusammen arbeite, dann tue ich als Erstes immer das: Nichts! Ich lasse einfach alle mal machen, wie sie es schon immer getan haben und wie sie es gerade für richtig halten. Ich habe das tiefe Vertrauen, dass jeder Mensch – wenn man ihn einfach lässt – versucht, das Beste zu geben, was er kann. Connection before Action nenne ich das. Ich möchte erst die Menschen kennenlernen, mit denen ich zusammen arbeite, zunächst eine emotionale Verbindung aufbauen. Verstehen, wer mein Gegenüber ist. Ich tue das, weil ich regelmäßig erfahre, dass erst dann Gespräche über die aktuelle Arbeitsweise und/oder alternative Herangehensweisen in der täglichen Arbeit möglich sind. Eine emotionale Verbindung schafft Vertrauen und Offenheit, die als Basis für gute fachliche Gespräche dient und damit die Grundlage liefert, auf der Veränderung (insbesondere aus eigener Motivation heraus) überhaupt erst möglich ist.

Das ist natürlich keine Garantie, dass dies auch immer so klappt. Muss es auch gar nicht. Welcher Coach wäre ich, wenn ich meine Ideen und Meinungen einer Organisation, einem Team und letztlich den Menschen aufzwingen wollte? Mir ist vielmehr wichtig, dass wir zu gemeinsamer Reflektion kommen. Dass wir wieder lernen, den Mut zu haben, NEIN zu sagen. Oder Mut, ein Experiment einzugehen. Mut haben, uns selbst wieder etwas zuzutrauen, wohlwissend, dass wir dafür vielleicht Kritik ernten. Gleiches gilt, unserem Gegenüber wieder etwas zuzutrauen, anstatt (gerade aus einer Führungsposition heraus) zu versuchen, das Verhalten des Mitarbeiters direkt zu ändern. Nur weil wir der Meinung sind, das wäre besser für ihn, das Projekt oder das Unternehmen. Welche Anmaßung wäre das!

Und dann passiert meistens etwas Erstaunliches und Wunderbares: Menschen beginnen, mir freiwillig zu folgen und sich meinen Ideen und eigenen Erfahrungen zu öffnen. Aus eigenem Wunsch heraus, weil sie wissen, dass ich ihnen meine Ideen und Meinungen nicht aufzwinge. Sie wissen, wenn sie NEIN sagen zu meinen Ideen, dass dies absolut in Ordnung ist und sie für ihren Mut ‚Nein zu sagen‘ gerade deswegen um so mehr Anerkennung und Respekt erfahren. Das ist die Basis meiner Arbeit und eine wichtige Prämisse für mich.

Und andersherum: Wenn Menschen oder ein Team mir nicht mehr freiwillig folgen, dann bin ich als Coach und Berater ‚raus‘. Dann werde ich kaum mehr weitere Erfolge erzielen und ich bin mein Honorar nicht mehr wert. Für mich ist klar: In erster Linie liegt es in meiner Verantwortung, sollte diese Freiwilligkeit nicht mehr gegeben sein. Dann beginne ich, über mich selbst zu reflektieren, was ich hätte besser machen können. Das ist manchmal sehr herausfordernd und nagt am Selbstbewusstsein. Und gleichzeitig – sobald man da durch ist – lässt mich das gestärkt und mit zusätzlichen Erfahrungen auf’s Neue an die Herausforderungen herangehen.

Damit ich nicht missverstanden werde: Diese Freiwilligkeit mir zu folgen bedeutet für die Menschen, die mit mir zusammenarbeiten, dass sie weder meine Ideen und Überzeugungen annehmen, noch dass sie sich gegen mich stellen. Vielmehr bedeutet es, auf Augenhöhe mit mir diverse Meinungen und Ideen zu diskutieren und sich am Ende zu einer gemeinsamen Lösung zu ‚committen‘. Mir zu folgen bedeutet in diesem Zusammenhang, sich einzulassen auf (durchaus knifflige) Diskussionen, sich dabei gegenseitig zu respektieren und gemeinsam Veränderungen anzugehen. Mir zu folgen, bedeutet Stillstand als Option auszuschließen. Diese Veränderungen bringen uns als Menschen, Teams und letztlich das Unternehmen nach Vorne. Für Letzteres werde ich heute üblicherweise bezahlt. Eine veränderte Kultur – die für mich als Basis des Erfolgs unabdingbar ist – bekommt man umsonst dazu. Schön wäre es, eines Tages dafür beauftragt zu werden, primär eine veränderte Kultur als Ziel zu haben.

Daily Scrum = Daily Eskalation

Es ist schwer dem Team zu vermitteln, was der Mehrwert des Daily Scrum ist, wenn sie unreflektiert nur die 3 Fragen beantworten. Viele Teams sagen: „Wir reden doch sowieso den ganzen Tag miteinander, warum muss ich das jetzt auf ein Meeting konzentrieren, in dem noch nicht einmal ausführliche Diskussionen stattfinden sollen?“ Das ist nachvollziehbar.

Aus klassischen Projekten, wo es am Ende plötzlich eng wurde, kenne ich in Eskalationssituationen, dass plötzlich priorisiert wird, plötzlich eng miteinander kommuniziert wird, plötzlich fokussiert wird, um am Ende des Tages zumindest etwas Funktionierendes liefern zu können. Der Auslöser dafür war meistens ein Eskalationsmeeting, kein Statusmeeting oder Projekt-JourFixe, sondern ‚Die Kacke ist am dampfen‘-Meeting.

Analog gesehen kann man das Daily Scrum als Eskalationsmeeting für den aktuellen Tag verstehen. Probiert mal Folgendes aus: Jeden Tag im Daily Scrum so tun, als ob morgen der Sprint zu Ende wäre und was wäre anzugehen, damit zumindest 1 Story heute geliefert werden kann. Plötzlich erscheint die tägliche Abstimmung in einem ganz anderen Licht und das Daily Scrum gewinnt wieder an Mehrwert. Für alle Beteiligten!

Achtsamkeit

Neulich ist es passiert. Ein Projektkickoff, der beflügelt war von der beeindruckenden Eingangsrede des CIO. Ich hatte eine kurze Einführung zu Agilität beizusteuern und voller Euphorie über das eben Gehörte und auch etwas Aufgeregtheit vor so vielen Projektbeteiligten habe ich mich von meinen Emotionen verleiten lassen. Was zur Folge hatte, dass ich meinen Vortrag spontan um Worte passend zu denen des CIO ergänzt hatte, samt dazugehöriger Körpersprache und … den roten Faden verlor! Meine Folien waren eigentlich klar und abgesprochen und ich hätte mich einfach an ihnen entlanghangeln können und alles wäre gut gewesen. So aber blieb ein konfuser Eindruck meines Auftretens zurück.

Ich hatte mir direktes Feedback dazu geholt und viel darüber reflektiert, was eigentlich passiert war. Das Ergebnis steht oben. Mein Learning daraus: Bleib achtsam in Bezug auf Deine Emotionen, wenn Du vor Leuten sprichst! Sie werfen Dich schneller aus der Bahn, als Du denkst. Hätte ich das getan, hätte ich mich rechtzeitig wieder an meinen Folien orientieren können, die mich sicher durch den Vortrag geleitet hätten.

Das nächste Mal klappt es besser 🙂

Prinzipien über Regeln

Als Scrummaster ist man ja ständig damit beschäftigt, Veränderungen zu bewirken. Eine klare Vision und ein Ziel sind dazu sehr förderlich. Bleibt die Frage, wie bringt man sein Team auf den Weg dahin. Changemanagement gehört seit jeher zu den herausfordernsten Aufgaben und Menschen sind sehr unterschiedlich in Bezug auf Veränderungen. Den Einen geht’s nicht schnell genug (die Early Adopters) und die Anderen sind nicht wirklich zu überzeugen (die Laggards).

Was nun, wenn es um Veränderungen geht, hinter denen das gesamte Team stehen soll? Reicht es da, selbst im Konsent gemeinsam erarbeitete Regeln zu verabschieden? Meine Erfahrung mit schwierigen Veränderungen ist, dass Regeln von den Early Adopters gerne erwünscht, aber von den Laggards mit großen Bedenken begegnet wird und sie empfinden die neuen Regeln eher als Zwang. Ist Zwang zielführend? Ich meine NEIN! Wann immer ein zwanghaftes Gefühl im Spiel ist, gibt es keine oder kaum eine intrinsische Motivation für die Veränderung. Was möglicherweise schon eher funktioniert, sind Prinzipien. Sie geben dem individuellen Menschen einen Freiraum, in dem er sich nicht zwanghaft eingesperrt fühlt.

Ein Beispiel: Ein Team beschließt, dass sie Pair Programming anwenden wollen. Pair Programming ist aber nicht jedermans Liebling. Anstatt nun eine Regel aufzustellen, die besagt, Code sei im Pair Programming zu entwickeln, lässt sich das auch als Prinzip ausdrücken, etwa so: „Wann immer wir knifflige Aufgaben zu lösen haben, sind wir bestrebt, diese im 4-Augen Prinzip durchzuführen.“

Das genannte Prinip ist kein ‚Gesetz‘ wie die Regel. Es spricht von Bestreben, nicht von müssen. Es lässt Freiraum, ist nicht so konsequent und kann daher gerade von den Nachzüglern leichter angenommen werden. Zugegebenermaßen hat ein Prinzip nicht die Hebelwirkung wie eine Regel. Langfristig gesehen passiert aber die Veränderung durch das Prinzip nachhaltiger, weil es intrinsischer motiviert ist. Auch in der Anwendung lässt es sich empathischer damit argumentieren. „Wir hatten uns in der Retrospektive auf die Regel ‚xyz‘ geeinigt…“ klingt zwanghaft. „Wir hatten in der Retrospektive festgehalten, dass wir bestrebt sind ‚xyz‘. Wollen wir mal probieren…?“ lässt sich viel leichter hören.

Ich weiß nicht mehr von wem ich das mal gehört habe, aber angeblich hatten sich die 21 Verfasser des Agilen Manifests ‚bis auf’s Blut‘ gestritten, was denn nun die Beste Art und Weise sei, Software zu entwickeln und sind diesbezüglich zu keiner Einigung gekommen. Jedoch die 4 Wertepaare und die 12 erarbeiteten Prinzipien konnte jeder zu 100% unterschreiben.

Mach mal wieder ein Foto…

Neulich während der Moderation eines zweitägigen Workshops: Die Zeit war fortgeschritten, die Themen anstrengend, auch die Pausen wirkten nicht mehr so erfrischend. Was tun, um die Energie wieder zum Fließen zu bringen? Und da kam mir die Idee: „Wisst ihr was? Wir machen jetzt erst mal ein Gruppenfoto. Am Besten vor den Flipcharts.“

Und schon wurde wieder deutlich mehr gelacht 🙂

In diesem Sinne: Mach mal wieder ein Foto!

Achte auf Deine Gedanken!

Ein chinesisches Sprichwort sagt: Achte auf Deine Gedanken, denn sie werden zu Worten. Achte auf Deine Worte, denn sie werden zu Handlungen. Achte auf Deine Handlungen, denn sie werden zu Gewohnheiten. Achte auf Deine Gewohnheiten, denn sie werden Dein Charakter. Achte auf Deinen Charakter, denn er wird Dein Schicksal.

Wer jetzt den direkten Bezug zu Agilität sucht, dem mag das fast schon esoterisch vorkommen. Und doch ist er da. Denn es hat sehr viel mit den agilen Grundwerten zu tun, allen voran mit Respekt und Wertschätzung. Agile Methoden setzen bewusst auf (divers besetzte) Teamarbeit, auf offenen Umgang mit Fehlern; Scrum kennt drei Rollen, deren Verantwortungsbereiche gewollt in einer Grundspannung zueinander stehen; allumfassende Transparenz ist gewünscht. Das daraus entstehende Konfliktpotential birgt Chancen zu Reflektion, zu Verbesserung, zu Innovation und vielen weiteren positiven Dingen, WENN man konstruktiv damit umgeht.

Und jetzt mal ehrlich: Wer hat sich noch nicht dabei ertappt, wenn es hier und da zu Spannungen, zu Problemen kam, dass man sich gedanklich schnell in Beurteilungen wiederfindet. Und gar nicht so selten endet das in einer überschnellen Verurteilung. Ich sage, das ist absolut menschlich und liegt in unserer Natur. Gleichzeitig haben wir Menschen die Fähigkeit zu reflektieren und somit negative Gefühle und Gedanken umzuwandeln in positive Erkenntnisse und positives Verhalten. Ein Beispiel: Wenn ein Diskussionspartner übermäßig kritisch mit einem guten Vorschlag umgeht, dann ist man leicht geneigt, sein Gegenüber z.B. als Widerständler abzuurteilen. Bin ich mir bewusst, dass ich gerade menschlichen Schwächen erliege, dann bin ich auch in der Lage, das Positive darin zu erkennen: Dass sich mein Gegenüber mit dem Thema auseinandersetzt, darüber nachdenkt, sein Gehirn einschaltet und seine Erfahrungen beisteuert. Und plötzlich verfliegen die negativen Gefühle und Respekt und Wertschätzung treten an ihre Stelle und ermöglichen so eine konstruktive Lösungsfindung.

Hier kommt das obige Sprichwort ins Spiel. Alles beginnt mit der Wahrnehmung seiner eigenen Gedanken und Gefühle. Nicht selten sind wir so in die Sache vertieft, dass wir unsere Emotionen nicht bewusst wahrnehmen. Dann erliegen wir ihnen, haben unsere Gedanken nicht unter Kontrolle und damit auch nicht unsere Worte, unsere Handlungen, unsere Gewohnheiten ….

Ich habe es mir zur Gewohnheit gemacht vor herausfordernden Situationen – z.B. eine Retrospektive, in der ich ein schwieriges Thema erwarte – mir einige Minuten Zeit zu nehmen und zunächst innerlich ‚leer‘ zu werden. Damit ich mir meines Befindens und meiner Emotionen zu dem Thema ganz bewusst werde. Erst das versetzt mich in die Lage, wirklich neutral zu bleiben, ganz bewusst die Stimmungen der Teilnehmer zu erspüren und damit respektvoll und wertschätzend mit jeglicher Meinung umzugehen.

Esther Derby nennt in ihrer bekannten Vorlage zu Retrospektiven den ersten Schritt ‚Setting the stage‘. Wer sich gefragt hat, wo der Mehrwert dieses Schrittes ist? Das ist er! Die Teilnehmer ganz bewusst aus ihren jetzigen Gedanken, Emotionen und Gefühlen rausbringen auf eine neutrale, gemeinsame Ebene. Ich verwende dazu gerne spannende Themen aus den aktuellen Nachrichten, die ich rezitiere. Oft entsteht daraus eine kleine Diskussion, der ich timeboxed fünf Minuten ihren Lauf lasse, bevor ich in die eigentliche Retrospektive überleite. Der Effekt dieses kleinen Zwischenspiels auf die Effektivität und Effizienz des Meetings ist deutlich zu spüren.

Wertschätzung und Respekt sind Dinge, die ganz zentral beim eigenen Ich beginnen. Wenn man sich in einer Diskussion über ein schwieriges Thema wiederfindet, dann ist es von entscheidender Bedeutung, auf welcher Ebene man sein Gegenüber sieht. Es ist nur menschlich, z.B. wenn man völlig konträrer Meinung ist, dass man schnell dazu neigt zu meinen, man wisse etwas besser als der andere. Wenn einem das passiert – und es passiert oft unbewusst – stellt man sein Gegenüber unweigerlich auf eine niedrigere Stufe als die eigene. Meine Erfahrung ist, dass dann keine konstruktive Diskussion mehr gelingt. Mir hat es stets geholfen, vorab mir bildlich vorzustellen, wo ich mein Gegenüber tatsächlich sehe und welche Emotionen ich in mir spüre. Und wenn ich feststelle, dass wir nicht auf derselben Ebene sind, korrigiere ich zuerst dieses Bild. Erst dann kann die gute Diskussion beginnen.

Selbstorganisation und das Emailverteiler-Syndrom

Wer kennt das nicht: Man schreibt eine Email an einen Mitarbeiter und bittet ihn etwas zu tun. Der Mitarbeiter fühlt sich verantwortlich und kümmert sich um die Erledigung der Aufgabe. Man schreibt eine Email an mehrere Mitarbeiter und bittet sie, dass sich jemand um eine Aufgabe kümmert. Und? Nichts passiert! (Zumindest oft)

Bei vielen agilen Vorgehensweisen – am bekanntesten Scrum – ist die Selbstorganisation des Entwicklungsteams ein zentraler Bestandteil. Mit dem Entwicklungsteam als Rolle ist einhergehend die Verantwortung dieser Rolle als Teamverantwortung. Ich erlebe immer wieder, wenn Teams mit dieser Verantwortung konfrontiert werden, dass sich plötzlich niemand mehr verantwortlich fühlt. Dies ist umso mehr der Fall, wenn in der bisherigen Arbeitsweise Einzelnen die Verantwortung für den Fortschritt eines Themas anvertraut wurde. Da wurde bisher von Einzelnen ausgehend sämtliche Skills in der Organisation zusammengerufen, um das persönliche Ziel zu verfolgen. Dabei entsteht spontan recht gute Teamarbeit, die vom Einzelnen vorangetrieben wird. Nachteilig dabei sind Reibungsverluste durch Taskswitching, weil sich viele Mitarbeiter in vielen virtuellen Teams befinden, schlechte Skalierbarkeit und oft mangelnde Transparenz.

Mit der Einführung von ’stabilen‘ Teams – z.B. in einem Scrum-Umfeld – geht nun die Einzelverantwortung verloren. Eine Verantwortlichkeit für einzelne Teammitglieder sieht Scrum in den 3 Hauptrollen zunächst nicht vor. Hat z.B. früher ein Projektleiter Einzelnen jeweils Aufgaben übertragen, überträgt nun der Product Owner dem Team die Verantwortung für die Umsetzung der einzelnen Anforderungen. Doch plötzlich geschieht Unvorhergesehenes: Niemand aus dem Team fühlt sich direkt verantwortlich, weil die Verantwortung ja gesamthaft beim Team liegt. Wer kennt nicht die Team-Metapher: „Toll Ein Anderer Macht’s“.

Ich bin der Überzeugung, dass dieser Wechsel im Mindset des Einzelnen – weg von der Einzelverantwortung, hin zur Teamverantwortung – einer der größten Hürden bei der Einführung von agilen Methoden, z.B. bei Scrum darstellt. Hier ist ein starker Scrummaster gefordert, der sehr präsent sein muss und das Team ständig an die Teamverantwortung erinnert und dem Team dabei in seiner Selbstorganisation unterstützt. War es in der bisherigen Arbeitsweise für den jeweils Einzelverantwortlichen einfach, Schuld für ein Nichtvorankommen leicht von sich zu schieben, weil z.B. liefernde Abteilungen nicht geliefert haben, so ist es in einem crossfunktionalen Team nun nicht mehr möglich, sich darauf zurückzuziehen. Dennoch ist beobachtbar, dass einzelne Teammitglieder versuchen, sich selbst ins gute Licht zu rücken und Verantwortung von sich zu weisen, weil ja andere Teammitglieder ihren Anteil nicht geliefert hätten. Vielmehr müsste aber ein neues Denken einsetzen, indem die einzelnen Teammitglieder beginnen, sich gegenseitig anzuspornen, weil man ja gemeinsam im selben Boot sitzt. Alternativ gibt es auch die Möglichkeit, dass sich jemand aus dem Team als sogenannter Story Owner verantwortlich zeigt, eine Story bis zur Erfüllung der Definition of Done voranzutreiben, stellt aber auch nur einen Workaround dar und packt das Übel nicht bei der Wurzel.

Letztlich findet sich dieses beobachtbare Verhalten in den 4 Teamphasen nach Tuckman wieder, die jedes Team durchlaufen muss, bevor es richtig performen kann. Auch hier ist wieder der Scrummaster gefordert, das Team durch die 4 Phasen zu begleiten. Wichtig dabei ist auch ein unterstützendes Verhalten der Managementebene. Die 4 Phasen zu durchlaufen benötigt Monate bis sogar Jahre und allzu schnell wird das neue Verfahren, z.B. Scrum schuldig dafür gemacht, dass jetzt alles noch schlechter als bisher läuft und die Implementierung des Frameworks wird vorzeitig abgebrochen. Nicht umsonst heißt es, Scrum is easy, Scrum to master is hard.

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.