Collaboration Hacks for Distributed Teams

Last month I have been invited to join an event for the PMA young crew organization in Austria, an organization that has the aim to foster project management knowledge for young professionals. The organizer asked if I do have experiences with distributed teams and if I can share them with interested young professionals from all over Europe. Therefore, I prepared a workshop to elaborate on success factors for distributed teams, no matter if they are distributed around the world or in the same city sitting in different offices. Although I’m primarily working with agile teams, the experiences shared could be used for any work setting. This is also the reason I named the workshop “Agile flavored Collaboration Hacks for Distributed Teams”.
In my opinion, there are two major categories of enablers for high performing distributed teams:

From my perspective the most important success factor is that the project leader can decide autonomously on how to structure the process of collaborating and which tools are used. If everything is predefined and there is no freedom in adapting to challenges, chances are pretty low that the team will fully unleash its potential. Therefore, be self-confident and define your space of autonomy with your sponsors so that you can decide on important adaptions improving your team performance!
You can find more experiences in my slide deck:
Agile Flavoured Collaboration Hacks for Distributed Teams

Foto: CC0 Creative Commons, pixabay -Free-Photos

"Ja, aber …" oder woran ich erkenne, dass ich agil bin

Wie bei jeder Reise, die wir unternehmen, wollen wir auch in Veränderungsprozessen wissen, ob wir Fortschritte machen. Wenn wir wissen, wie weit wir schon gekommen sind, können wir eine Prognose darüber anstellen, wie viel mehr Energie wir einsetzen müssen, bis wir unser Ziel erreicht, unsere Vision erfüllt haben. Gehen wir daran, agile Arbeitsmethoden, wie zum Beispiel Scrum, zu implementieren, ist die Einhaltung des Rahmenwerks ein konkreter Indikator dafür, wie vollständig, wie gut ich schon agil „mache“:

In der Praxis hat sich allerdings gezeigt, dass man nur vollständig agil „machen“ kann, wenn man auch agil ist, d.h. wenn das dahinterliegende Mindset, die Kultur im Unternehmen etabliert ist. Es gibt eine Wechselwirkung zwischen machen und sein. Nun lässt sich das agile Machen – wie oben beschrieben – recht einfach messen: Ich zähle einfach die Häkchen, die ich hinter die verschiedenen Elemente des Rahmenwerks machen kann. Falls ich nicht auf die volle Zahl Häkchen komme, lässt sich interessanterweise mutmaßen, dass es beim Mindset hapert. Anders ausgedrückt: Tatsächlich sind die Hard Facts ein Indikator dafür, ob es bei der Etablierung eines agilen Mindsets in eurem Unternehmen noch Verbesserungspotenzial gibt. Und wie beschrieben, lassen sich die Hard Facts recht leicht messen. Wer sich mit Objectives und Key Results auseinandergesetzt hat, weiß wahrscheinlich, dass Ergebnisziele und Fortschrittsziele zwei verschiedene Dinge sind. Auf unser Anliegen übertragen heißt das: Ich messe den Erfolg der Einführung agiler Methoden anhand der „Treue“ zum Scrum-Framework.

Ja, aber wie messe ich nun die Soft Facts?

Nur wie lässt sich messen, wie weit meine Bemühungen zur Etablierung des Mindsets gediehen sind? Wie messe ich meine Fortschritte auf dem Weg zum Ziel? Wie messe ich Kultur? Für den Start reicht es einmal genau zuzuhören. Zählt einmal, wie oft ihr „Ja, aber …“ in eurem Team und Unternehmen hört – und wie oft ihr selbst „Ja, aber …“ sagt. „Ja, aber“ heißt in Klardeutsch „Nein“. Alles, was hinter dem Aber kommt, negiert die erste Satzhälfte. lehnt damit die Position des anderen ab. Erst wenn ein Team in der Lage ist, verschiedene Standpunkte nebeneinander in der Schwebe zu halten, können dem Spannungsfeld der verschiedenen Sichtweisen neue und kreative Lösungen entspringen. Dann hat das Team dialogische Kompetenz entwickelt – eine wichtige Kulturtechnik für ein agiles Unternehmen. Im praktizierten Pluralismus liegt die Chance zur Schaffung eines neues Ganzen, das größer ist als die Summe seiner Teile.

Was könnt ihr für die Entwicklung dieser Kompetenzen tun? Was sind eure Fortschrittsziele?

In multifunktionalen Teams treffen häufiger Menschen mit unterschiedlichen Persönlichkeitstypen aufeinander als in Silo-Teams, deren Teammitglieder meist denselben Beruf gewählt haben. Analysen von Persönlichkeitstypen, wie beispielsweise disc oder der Myers-Briggs-Typenindikator helfen den Teammitgliedern zu verstehen, wie ihre Kollegen ticken. Das erhöht auch die Bereitschaft, Andersartigkeit zu tolerieren und den genannten Pluralismus zunehmend wertzuschätzen. Der ScrumMaster spielt in der Förderung dieser Entwicklung eine wichtige Rolle. Er erklärt den Teammitgliedern die Bedeutung von „ja, aber …“ und spiegelt ihnen, wie sich Kommunikation gestaltet, wenn es verwendet wird oder wenn es ausbleibt.

Video: Digital Avengers – So stellen Sie Ihr schlagkräftiges Superhelden-Team zusammen

Im Call for Papers der „Agile Digital Transformation“ inspirierte mich die Frage nach dem geeigneten Team, mit dem man die Herausforderungen der Digitalisierung meistern kann. Ich machte mich auf die Suche nach einem passenden Hollywood-Teams als Metapher und stieß schließlich auf die Superhelden-Truppe der Avengers. Nicht nur konnte ich sofort einige Parallelen zu performenden Teams entdecken, die Verknüpfung passte auch zum Start des neuen Avengers-Streifen im Kino. Also, Welt aus, Film an und beide Teile der Avengers-Streifen geguckt, um nach den Parallelen und Mustern zwischen den Superhelden und Hochleistungsteams zu suchen. Herausgekommen ist ein unterhaltsamer Vortrag, der sich einerseits damit beschäftigt,

Die Slides zu diesem Vortrag findet ihr unter diesem Link
Viel Spaß beim Nachschauen!

Scrum and multi-disciplinary teams

In this edition of my video series, I explain the need to use multidisciplinary teams in Scrum, rather than cross-functional. Teams should consist of members from all business areas to develop a fully functional solution.  
Join me in my video to find out why using multi-disciplinary teams is critical. 

Manager, entscheidet euch oder entscheidet euch!

Das häufigste Impediment, das uns in Großunternehmen am Weiterkommen hindert, ist die nicht getroffene Entscheidung. Teams stoßen regelmäßig an den Rand ihrer Entscheidungsfähigkeit, da es geschriebene und ungeschriebene Regeln im Unternehmen gibt: Bestimmte Entscheidungen sind vom Vorstand oder zumindest einer bestimmten Hierarchieebene zu treffen.
Eine nicht getroffene Entscheidung hat zwei Effekte:

Nichtentscheiden kostet Geld

Das Arbeiten mit Hypothesen führt zu einem hohen Grad an Unsicherheit und demotiviert die Mitarbeiter: Sie müssen nämlich befürchten, dass ihre Arbeit bei einer gegensätzlichen Entscheidung überflüssig wird. Hierbei ist noch nicht der finanzielle Schaden bedacht, der einem Unternehmen durch verzögerte Entscheidungen und dem daraus resultierenden Hantieren mit Hypothesen entstehen kann.
Ein Beispiel: Ein Team besteht aus neun Mitgliedern, jedes davon verdient im Schnitt 80.000 €/Jahr. Das Team wartet auf eine Entscheidung und beginnt, vorläufig mit einer Hypothese zu arbeiten. Nach sechs Wochen fällt der Vorstand eine gegensätzliche Entscheidung. Durch die verzögerte Entscheidung entstehen also folgende Kosten: 9 Mitarbeiter * 80.000 €/Jahr: 52 Wochen * 6 Wochen = 83.077 €. Innerhalb von sechs Wochen wurde somit das Jahresgehalt eines Mitarbeiters verbrannt und ein motiviertes Team erfolgreich in die Demotivation geführt.
Dieser finanzielle Schaden für das Unternehmen wird in Kauf genommen, weil im Hintergrund das Machtdenken dominiert. Entscheidungsgewalt abzugeben, führt beim Management zunächst zum Gefühl einer gewissen Ohnmacht, da Entscheidungsgewalt doch immer mit Macht gleichgesetzt wird.
Tatsächlich führt das Abgeben von Entscheidungsbefugnissen aber zu motivierten Teams und besseren Performances. Eine Win-Win-Situation: Der Manager darf sich schnellerer und performanterer Teams rühmen, während die Teams die Lust und Motivation am Arbeiten zurückgewinnen. Zudem kann sich der Manager als Führungskraft wieder auf seine eigentliche Aufgabe konzentrieren: auf das Führen!
Möchte man also demotivierte Teams vermeiden, Selbstorganisation fördern und Ressourcen nicht verbrennen, folgen daraus zwei logische Konsequenzen: Entweder trifft der Manager (besser daher der Entscheider) schnelle Entscheidungen, oder er entscheidet sich dazu, Entscheidungsgewalt ab- und dafür in die Teams zu geben. Einfacher lässt sich Motivation nicht erzeugen und Kostenverschwendung vermeiden! Also Manager, entscheidet euch, euch zu entscheiden!

Foto; CC0 Creative Commons – congerdesign, pixabay

Pair und Mob Programming – der kleine, aber feine Unterschied

Wissenstransfer, die Ideen und Kompetenzen von vielen nutzen, Einarbeiten neuer Kollegen – Mob und Pair Programming sind wirklich sinnvolle Arten der Zusammenarbeit. Aber wann eignet sich welche der beiden Arbeitsmethoden am besten?

Vier Augen sehen mehr

Beim Pair Programming sitzen zwei Entwickler gleichzeitig vor einem Bildschirm und bilden somit ein „Pair”. Einer der beiden programmiert, der Zweite liest die Codezeilen mit. Nach dem Motto “vier Augen sind besser als zwei” wird so der Code von beiden Entwicklern gleichzeitig geschrieben. Besonderen Charme hat dieses Vorgehen deshalb, weil die beiden Entwickler einerseits besseren und sauberen Code schreiben und sich andererseits gegenseitig zu innovativem Denken motivieren. Der Austausch zwischen den Entwicklern zum geschriebenen Code führt dazu, dass sie voneinander lernen und ihr Wissen erweitern.
Tipp: Nach einer zuvor vereinbarten Zeit sollten Coder und Mitleser sich abwechseln, um Ermüdungserscheinungen (nachlassende Konzentrationsfähigkeit) vorzubeugen.

Komplexe Themen im Team bearbeiten

Beim Mob Programming sitzt das gesamte Team vor einem großen Bildschirm und nur einer aus dem Team programmiert. Die Besonderheit ist hierbei, dass das programmierende Teammitglied nicht seine eigenen Gedanken in Code verwandelt, sondern das restliche Team über den nächsten Codeabschnitt diskutiert. Der Entwickler an der Tastatur muss aus der Diskussion heraushören, wie die nächsten Codezeilen aussehen werden bzw. lässt er sich diese teilweise sogar diktieren (je nach Erfahrungsgrad). Durch die Diskussion wächst nicht nur bei jedem Teammitglied die Erfahrung im Umgang mit komplexen Problemstellungen, sondern gleichzeitig auch das Wissen über den Code. Jeder im Team ist in der Lage, den Code zu verstehen, weiß worum es geht und kann schnell Code Refactoring betreiben.
Tipp: Diese Art des Programmierens ist für denjenigen, der gerade tippt, sehr anstrengend. Daher sollte der codende Entwickler nach ca. 10-15 Minuten von einem anderen Teammitglied abgelöst werden. Bei einer Teammitgliederanzahl von mehr als vier ist es besser, mit einem Beamer zu arbeiten, statt auf einen Bildschirm zu starren. So kann jeder einfach folgen und niemand versperrt einem anderen Teamkollegen die Sicht.

Best Practice

Meine persönliche Erfahrung mit beiden Methoden hat gezeigt, dass es bei neuen Thematiken sinnvoller ist, erstmal gemeinsam zu starten, um eine gemeinsame Laufrichtung zu finden. Im nächsten Schritt sollte man das Team in kleine Pairs aufbrechen, um sich die geschnittenen Themen zu erarbeiten. Nach einiger Zeit trifft man sich wieder als Team im Mob, fügt die Codefragmente zu einem gemeinsamen Code zusammen, testet gemeinsam und bleibt für die weitere Entwicklung im Mob. Oder: Das Team einigt sich auf die nächsten Einzelthemen, die wieder im Pair erarbeitet werden. So entsteht ein angenehmer Arbeitsflow, bei dem das Wissen aller Teammitglieder stark wächst und das Produkt dadurch schnell, effizient, effektiv und erfolgreich geliefert werden kann.

Foto: (c) rawpixel

Die User Story als Einladung zu einer Diskussion

Viele meiner Kunden fragen, wie viele Anforderungen eine User Story beinhalten sollte und wo denn die „anderen“ Anforderungen abgespeichert werden sollen.
Diese Frage ist meiner Meinung nach ein Widerspruch in sich. Denn eine User Story besteht ja nicht nur aus dem berühmten Satz „Als <Rolle> möchte ich <Funktion>, um <Nutzen> zu haben“, sondern enthält einiges mehr an Informationen.
Zunächst mal: Was braucht man, um ein Produkt zu entwickeln? Natürlich das Wissen darüber, wie dieses Produkt am Ende aussehen soll. Was *braucht* der User? Was *will* der User? Was sind die Rahmenbedingungen (Budget/Ressourcen, Gesetze etc.)?
Um all diese Fragen zu beantworten, sollte also eine User Story diese Informationen beinhalten:

Wie umfassend soll diese „Dokumentation“ sein? Ich beobachte, wie lange mein Team beim Refinement darüber geredet hat – das ist mein Richtwert. Denn das ist genau das, was in diesem Meeting passieren soll: darüber reden. So lange bis jeder weiß, was diese Funktionalität können muss.
Jetzt werden viele sagen: „Wir arbeiten ja nur mit Kärtchen, da passt das alles nicht drauf.“ Das ist schon richtig. Es spricht allerdings nichts dagegen, zusätzlich zum Kärtchen auch andere Medien zu verwenden, die separat geführt werden. Ein Flipchart reicht oft völlig aus.
Wie sieht bei Ihnen eine User Story aus?

Scrum – eigentlich so einfach wie kochen

Einzelne Teams, inzwischen aber auch ganze Unternehmen stellen sich die Frage: Wie können wir uns angesichts sich ständig verändernder Marktbedingungen so aufstellen, dass wir unsere Anpassungsfähigkeit erhöhen und gleichzeitig schneller in der Umsetzung werden? Sicher: Auf diese Frage gibt es viele mögliche Antworten und ganz sicher gibt es nicht das eine Rezept. Eine Antwort ist, die Haltung und Methoden von Scrum für sich zu entdecken und anzuwenden.
Oft erleben wir viele Hemmungen, wenn Menschen zum ersten Mal von Scrum hören und es für sich und ihren Kontext anwenden sollen. Deshalb wollen wir das Thema einmal aus einer anderen Perspektive betrachten und es mit dem Kochen vergleichen. Stellt euch vor, ein Familienmitglied hat Geburtstag. Ihr wollt diesen Geburtstag bei euch Zuhause feiern und ein Festmahl zubereiten. So ähnlich ist es, wenn man den Scrum Flow für sich entdeckt und seinen Projekt-/Arbeitsalltag mit Leben füllt.

Mit Offenheit kocht es sich leichter

Eine wichtige Voraussetzung ist aus unserer Sicht die Haltung, beispielsweise die Offenheit für Experimente. Bezogen auf unser Menü bedeutet das, nicht zu lange zu überlegen, sondern bereit zu sein, einfach loszulegen. Sich darauf einzulassen, dass das Menü während des Kochens weiter Form annimmt. Natürlich kann man beliebig viel Zeit investieren, ein besonders kreatives Menü zusammenzustellen, doch lasst uns einfach mal damit beginnen!
Auf den Kontext der Organisation übertragen, bedeutet das eine neue Haltung in der Führung: sich beispielsweise gemeinsam mit den Mitköchen zu überlegen, was traue ich mir und meinen Mitköchen zu, die Aufgaben aufzuteilen und dann loszulassen. Es bedeutet, in die Selbstorganisationsfähigkeit des Teams zu vertrauen, in die Kollaboration über horizontale und vertikale Grenzen hinweg, damit das Essen gemeinsam gelingt. Welche Zutaten tragen wesentlich zum Gelingen bei?

Die Vision: Pasta oder Schweinshaxe?

Um den Geburtstag gebührend zu feiern, wollen wir unsere liebe Familie und die Freunde bekochen. Natürlich soll es etwas Besonderes geben. Wir haben es geradezu vor Augen: Das größte Festmahl aller Zeiten soll es werden! Ein rauschendes Fest, wie es die Welt noch nicht gesehen hat. Mit einem Leuchten in den Augen erzählen wir bei der Einladung von unserem Plan und sehen, wie geradezu der Funke überspringt. Alle freuen sich auf das anstehende Fest und bieten ihre Unterstützung an. Im Scrum-Kontext ist es der Product Owner, der diese Vision in ein Produkt verwandelt und emotional kommuniziert und dadurch das Team motiviert, voller Energie an der Umsetzung mitzuwirken.

Die Constraints: der Blick in den Kühlschrank

Wir stehen also in der Küche und haben die Vision eines opulenten Festmahls vor Augen. Ein Blick in den Kühlschrank holt uns zurück auf den Boden der Tatsachen. Er ist ziemlich leer. Es ist Monatsende und das Konto zeigt überdeutlich, dass ein Großeinkauf heute nicht mehr drin ist. Es gibt aber noch ein paar Dosen geschälte Tomaten und in der Vorratskammer findet sich eine Packung Nudeln. Etwas Knoblauch ist auch noch da, frische Chili-Schoten und Olivenöl. Leider ist der Backofen seit Wochen defekt, aber immerhin funktionieren die Herdplatten, im Schrank finden sich ein Topf und eine Pfanne. Mit diesen Rahmenbedingungen lässt sich zwar kein 10-Gänge-Menü zaubern, für eine große Portion Penne Arrabbiata dürfte es aber reichen. Zusammen mit der letzten Flasche von dem guten Rotwein ergibt es das bestmöglichste Gericht.
So ambitioniert eine Vision auch sein mag, kein Produkt und kein noch so leckeres Gericht ist frei von Einschränkungen und Rahmenbedingungen, eben den sogenannten „Constraints“. Im Kontext einer Produktentwicklung geben diese Rahmenbedingungen vor, wie die Vision umgesetzt werden kann. Wie groß ist das Budget? Wie viele Mitarbeiter können an einem Projekt arbeiten? Welche gesetzlichen Vorschriften müssen eingehalten werden? Was ist technisch überhaupt machbar?

Die Rollen: Verantwortung teilen – kochen im Team

Wie auch im Scrum Flow gibt es beim gemeinsamen Kochen zugewiesene Rollen. Diese Rollen sind klar voneinander abgegrenzt: Jeder der mitkocht, übernimmt eine bestimmte Arbeit. Im Scrum Flow gibt es die drei Kernrollen Scrum Master, Product Owner und Entwicklungsteam. In drei weiteren Rollen kommen noch Kunde, User und Management ins Spiel. Auch hier sind die Rollen klar voneinander abgegrenzt: Der Product Owner weiß genau, was er oder sie am Schluss vor sich stehen haben möchte. Er organisiert das Menü und ist dafür verantwortlich, dass jeder Koch im Team die benötigten Fähigkeiten hat, um das beste Menü auf den Tisch zu zaubern. Seine „Vision“ gibt er an die Mitköche weiter, die das Entwicklungsteam bilden. Sie kochen das Menü „tatsächlich“ und bringen es in eine Form. Ohne sie würde der Product Owner das Gericht nicht rechtzeitig zur Feier fertigbekommen.
Die Rolle des Scrum Masters kann in der Küche mit jemandem verglichen werden, der sich darum kümmert, dass jeder die Zutaten hat, um seine Arbeit schnellstmöglich auszuführen. Der Scrum Master sorgt auch dafür, dass das Team ohne Probleme und Einschränkungen kochen kann, indem zum Beispiel Geschirr abgewaschen oder Abfälle entsorgt werden. Um den Scrum Flow zu vollenden, benötigen wir noch Kunde, User und Management. Im unserem Fall ist das Geburtstagskind Kunde und User. Es gibt im Vorfeld an, welche Wünsche es hat (oder das Kochteam weiß das aus vergangenen Beobachtungen), und genießt das Mahl im Anschluss an die Zubereitung. Der Manager finanziert das Geburtstagsessen, er hat nichts mit der Küche und dem Kochen zu tun. In unserem Fall könnte das der Vater des Geburtstagskindes sein.

Kochen und abschmecken: Selbstreflexion und Feedback-Loops

Lasst uns nun kochen. Um das Rezept bestmöglich umzusetzen, bietet sich ein gewisses Vorgehen an. Die taktische Ebene des Scrum Flow umfasst alle Meetings und ist mit den Anleitungen in einem Rezept vergleichbar. In diesen Anleitungen steht genau beschrieben, welche Schritte und welche Zutaten wann eingesetzt werden.
Starten wir mit dem Sprint Planning 1: In diesem Meeting überlegen wir uns, was das Festmahl beinhalten soll. Eventuell möchten wir mehrere Gänge zubereiten und entscheiden uns dafür, dass Kartoffelsuppe das Beste für den ersten Gang sei. Nachdem alle zugestimmt haben, überlegen wir uns, wie wir unseren ersten Gang umsetzen werden – vergleichbar mit dem Sprint Planning 2. Jeder Koch hat seine Aufgabe zugeteilt bekommen: Der eine wäscht die Kartoffeln, der andere schält die Kartoffeln, der Dritte schneidet sie klein und so weiter.
Nun ist das Vorgehen klar und alle Köche kommen ins Tun. Während der Zubereitung kann es Rücksprachen geben – im Scrum Flow spiegelt sich das in den Dailys wider. In diesem täglichen, rund 15 Minuten dauernden Standup-Meeting halten alle Köche kurze Rücksprachen zu den einzelnen Aufgaben. Ist die Suppe fertig, wird der Product Owner in die Küche gerufen, um zu probieren. Gefällt ihm die Kartoffelsuppe, wird sie an den Tisch gebracht und kann vom Geburtstagskind und den Gästen probiert und bewertet werden. Sind die Gäste und vor allem das Geburtstagskind zufrieden, hat die Kartoffelsuppe bestanden. Sollte es jemandem nicht schmecken, wird zum Beispiel mit weiteren Gewürzen nachgebessert – das geschieht im Rahmen des Scrum Flow mit Produkten nach dem Review. Nachdem die Kartoffelsuppe von den Genießern „abgenommen“ wurde, trifft sich das Team in der Küche und reflektiert die Zusammenarbeit, wie in einer Retrospektive.
Die Prinzipien und Vorgehensweisen von Scrum sind also eigentlich nichts Neues – sie werden in anderen Kontexten täglich praktiziert. Was vielleicht ungewohnt ist, ist die Anwendung dieser Prinzipien auf die Wissensarbeit. Fangen Sie doch einfach genau so an, wie wir es hier beschrieben haben: Legen Sie einfach los, machen Sie sich den Spaß und bereiten Sie mit Freunden ein Essen nach dem Ablauf des Scrum Flow zu. Guten Appetit!

Diesen Artikel haben Mara Ambs, Michael Gissler und Miruna Sachse im Mob-Writing gemeinsam verfasst.

Agiles Arbeiten: Fokus entsteht durch Vertrauen

Bei einem Product Owner Training haben mich drei Teilnehmer auf das Thema Fokus gebracht. Nicht zuletzt ist “Fokus” einer der fünf Werte von Scrum. Doch wozu brauchen wir ihn, wie wirkt er und überhaupt: Wie entsteht Fokus? In einer angeleiteten Freewriting Session hatte ich dann die Chance, dieses Thema von Grund auf für mich zu beschreiben. Und naja, was soll ich sagen: Dabei fiel mir zunächst einmal Basketball ein. Ich habe selbst früher Basketball gespielt und wirklich geliebt. Man kämpft gemeinsam als Team und spielt alle nötigen Spielzüge aus, um einen Korb gegen seinen Gegner zu werfen.
Der Moment aber, in dem ich absolute Fokussierung wirklich spüren konnte, war während einer Freiwurfsituation. Sie ist hart erkämpft, und sichtlich aus der Puste steht man an der Freiwurflinie und soll zum angezeigten Zeitpunkt den Ball im Korb versenken. Alles andere als eine leichte Übung, wenn man das in einer realen Wettkampfsituation machen muss.
Fürs Gelingen braucht es Fokus und eine einstudierte Routine, durch die man im Moment der höchsten Anspannung die Umwelt vollkommen ausblenden kann. Der Fokus beschränkt sich nur noch auf den Ball, den Korb und den eigenen Herzschlag. Noch einmal tief durchatmen: und Wurf!

Wodurch entsteht Fokus?

Wie kann ich mich dazu bringen, die Umwelt für eine gewisse Zeit auszublenden, um im übergreifenden Sinne auch in der Unternehmenswelt zu „punkten“? Man könnte meinen, Meditation wäre ein möglicher Weg, um in einer Stresssituation cool bleiben zu können. Ja, sicher. Ich denke aber, dass der eigene Fokus nur ein Teil der gesamten Lösung ist. Denn was es in einer Freiwurfsituation braucht, ist nicht nur die eigene Ruhe, sondern die Ruhe des gesamten Teams, in dem man spielt.
Der Kern liegt also im Vertrauen zu seinem Umfeld.
Ich muss mich auf meine Leute verlassen können, egal was passiert. Selbst wenn ich den Ball nicht versenke, braucht es das Team, um den Ball wieder einzufangen, um im Spielverlauf durch weitere Versuche Punkte zu machen. Nur wenn ich es schaffe, dem Team vollkommen zu vertrauen, kann ich mich selbst auf das Wesentliche konzentrieren.

pixabay.com, Skitterphoto, CC0 Creative Commons

Wie funktioniert Fokus in der Unternehmenswelt?

In der freien Marktwirtschaft sind wir einer viel höheren Dynamik und Komplexität ausgesetzt. Wir haben oft mehrere Bälle im Spiel und jonglieren diese viel schneller als wir es eigentlich möchten. Doch der Fokus auf das Wesentliche macht ein Unternehmen wirtschaftlich. Würde ein Unternehmen auf jeden Reiz reagieren, würde es nicht mehr wertschöpfend sein.
Folglich scheint der wertschöpfende Fokus essentiell für den Erfolg in unserer Marktwirtschaft zu sein. Durch Vertrauen sowie eine passende Rollen- und Aufgabenverteilung behält ein Team die umliegenden Geschehnisse im Blick und reagiert nur auf die wichtigen Ereignisse. Denn wer den eigenen Fokus auf die wenigen, wirklich wichtigen Dinge legt, hat eine gute Chance, sein Vorhaben zu meistern. Durch den Fokus kann man sich jede beliebige Situation zu eigen machen, das Beste aus ihr herausholen und sie zu einem guten Abschluss bringen! Wohl wissend, dass das Team hinter mir steht und bei Problemen meinen Rücken stärken wird.

Wider die unsinnige Teamisierung von Leistung

Teamisierung? Gibt es nicht. Ein Kunstbegriff. Für mich beschreibt er ein Phänomen, das seit längerem in Zusammenhang mit der Einführung von agilen Methoden in Unternehmen beobachtbar ist. Ich meine hier nicht die „Sozialisierung“ – darunter versteht man das Vergemeinschaften und Teilen etwa von Belastungen, Gewinnen oder Lernerfahrungen unter den an einer Gesellschaft Beteiligten. Mit „Teamisierung“ meine ich eine leichtfertige Pauschalisierung und Verallgemeinerung von Individuen, die an einem Objekt oder in einer Leistung zusammenwirken. Sie passiert meist unmerklich zunächst auf der sprachlichen Ebene und wirkt sich in weiterer Folge auf die Struktur aus.
Plötzlich gibt es nur noch „das Team“ in seiner äußeren Hülle und Pauschalität – ähnlich indifferent wie „die Gesellschaft“, „die Wirtschaft“ oder „die Wissenschaft“ in politischen oder religiösen Polemiken. Als Hinweis auf eine innere Differenziertheit bleibt maximal das Attribut übrig, dass „das Team“ möglichst „crossfunktional“ besetzt sein soll. Dem Team stehen spezifische Rollen gegenüber: der ScrumMaster, der Product Owner, der Manager, der User, der Kunde. Das Team aber – jedenfalls in der ihm entgegenschlagenden Erwartungshaltung – als amorphe Masse angesprochen und sprachlich behandelt, trägt und erfüllt den hehren Anspruch, im Sinne aller beteiligten Anspruchsgruppen zu handeln, alle Bedürfnisse in sich zu absorbieren und zu verarbeiten. Mit intrinsischer Motivation und methodischer Kompetenz werden alle diese Bedürfnisse in Produktinkrementen iterativ aufgelöst und erfolgreich integriert. „Ask the team“ ist zur Weltformel geworden.
Einst war es eine Aufforderung, die Entscheidungen dorthin zu legen, wo die Information ist. Heute ist es mitunter eine Plattitüde, die einem ungelenken Management in ohnmächtiger Laissez-faire-Manier eine zeitgeistig erscheinende Beschreibung des eigenen – jetzt agilen – Mindsets und Führungsstils ermöglicht. Früher lästerte man vielleicht: „TEAM – toll, ein anderer macht’s.“ Das war wenigstens noch auf die dysfunktionalen internen Teamdynamiken gemünzt und mit einem Augenzwinkern eine freundliche Anmahnung für Zusammenspiel und Teamplay. Ganz nach der Idee des Mannschaftssports.

Leistung ist ein Zusammenspiel von Einzelnen

Aufgaben werden heute teamisiert – in ein Team geworfen – und dort durch das wundersame, unerklärliche Wirken des Teams auf höchstem Niveau bearbeitet und gelöst. Entsprechend wird auch Leistung teamisiert: Also keiner war’s – nicht nur im Negativen (wir erinnern uns an den ahnungslosen Blick kleiner Kinder, die mit dem Fußball eine Scheibe eingeschossen haben. Da war’s auch keiner). Schlimmer noch: Auch im Erfolgsfall war´s keiner. Weil es eben nur das Team gibt. Leistung aber, kommt im Zusammenspiel einzelner Teamplayer zustande. Wir sind kein Schwarm (was für ein grausamer Begriff im Kontext von Agilität), der instinktiv einen Formationsflug oder das Formationsschwimmen meistert. In der Regel sind wir doch höchst spezielle und spezialisierte Wesen mit einem hohen Maße an Differenzierungsmöglichkeiten und Bedürfnissen, die diese Diversität in den Dienst eines gemeinsamen Objekts (vielleicht des Teamworks) stellen. Für den Erfolg ist es noch nicht einmal notwendig, dass wir denselben Benefit aus diesem Zusammenwirken erhalten. Was uns eint, ist der Moment des Erfolgs, in dem wir uns in unseren Anstrengungen, Entbehrungen und Wirken bestätigt sehen.

Agiles Management führt Individuen

Lange Zeit hatte ich nicht verstanden, warum einige (vor allem Software-) Entwicklungsteams sich Namen wie „Defenders“ (entlehnt von Marvel-Figuren) gaben. Heute verstehe ich das als einen Hinweis auf die Unterschiedlichkeit im Team, als Hinweis darauf, die spezifischen Einzelleistungen und -beiträge im Team zu sehen, sichtbar zu machen und anzuerkennen, statt eine amorphe Masse namens „Team“ zu kreieren. Das ist ein wichtiger Schritt agilen Managements und somit einer agilen Führung und Steuerung: Es geht uns im Team um eine handverlesene Truppe von Charakteren und Profilen – ausgerichtet auf eine Sache. Eine Sache, die in ihrer Art und Natur ein komplexes und hochgradig soziales System der Bearbeitung, Beantwortung und Veränderung erfordert. Als agile Manager sind wir dafür verantwortlich, dieses komplexe, hochgradig soziale System zu etablieren und in eine Kultur der Selbsterhaltung und Selbstorganisation zu führen, um eben jener Sache (Aufgabe) gerecht zu werden.

Team ist Beziehung

Allzu schnell lösen wir den Einzelnen wie eine Brausetablette im Teamwasser auf (was nicht anzuraten ist). Jeder im Team bleibt aber wegen seiner menschlichen Natur immer nur er/sie selbst und wird nicht zu Team. Vielmehr vernetzt er sich in wiederholender, erweiternder und laufender Kommunikation mit anderen, die sie selbst bleiben. Erst diese Kommunikation lässt die Idee des Teams entstehen. Und diese Idee nährt sich aus den Beziehungsleistungen einzelner, die sich selbst in Bezug zueinander und zum ko-konstruierten Ganzen – dem Team – setzen. Entweder positiv inspirierend – dann nehmen wir die anderen Teammitglieder und das Teamkonstrukt positiv erweiternd zu unserem individuellen Wirkraum wahr – als Möglichkeit, über uns hinauszuwachsen. Oder wir erleben es eben als Gegenteil: Als Begrenztsein innerhalb der uns ohnehin schon schmerzlich bewussten Limitationen aus unserem Alleinsein. Durch das Teamkonstrukt erlebe ich mich also noch ohnmächtiger, als ich mich durch meine menschlichen Grenzen ohnehin schon erlebe. Sozialisierung der Limitationen statt Erweiterung der Möglichkeitsräume.

Team ist ein Konstruktionsprozess

Das bedeutet: Team ist immer ein Konstruktionsprozess, ein Work in Progress, der sich im Einzelnen positiv oder negativ nährt. Er wirkt selbstverstärkend dort, wo Konsens in der Beurteilung erlebt wird; energetisierend, wenn die Selbsterhöhung durch andere bestätigt wird; zerstörerisch dort, wo diese Konstruktion als behindernd, verhindernd oder gar lebensbedrohlich empfunden wirkt. Team ist also immer auch eine Einzelleistung, so verrückt das klingen mag. Auch wenn diese Einzelleistung zuallererst in der Konstruktionsbereitschaft des Wirklichkeitskonstrukts Team bestehen mag.Das bedeutet aber, sich nach dem Setup auch der Bedeutung der Einzelnen im Gesamtsystem Team bewusst zu bleiben. Damit kann sich die Schlagkraft, Bearbeitungs-, Beantwortungs- und Veränderungskompetenz und -fähigkeit weiterentwickeln und damit das System Team am Leben erhalten werden.
Konkret heißt das: 

Ich wäre nicht Berater, hätte ich nicht einen Begriff, der einem Executive Summary gleichkäme: Coopetition. Die Verbindung aus Cooperation und Competition. Das „sowohl als auch und und“ – auf Unternehmens-, Bereichs- und eben auch Teamebene. Weil wir eben sind, was wir sind: Individuen, die durch Sozialisierung überlebensfähig werden.