Schlagwort: Teamentwicklung

Welches Team für welchen Zweck?

Welches Team für welchen Zweck?

Nahezu jede Form der Zusammenarbeit von Menschen wird heute mit dem Begriff Team belegt. Aber nicht überall wo Team drauf steht, ist auch das Gleiche drin. Eine Unterscheidung der Charakteristika der Zusammenarbeit ist wichtig. Nicht jedes „Team“ ist für jede Aufgabe geeignet. Zudem unterscheiden sich die Ansätze von Leitung und Führung zum Teil erheblich.

Highheels und Badelatschen

Highheels und Badelatschen

So lautete der Titel, der Session, die ich auf dem #pmcamp12 angeboten hatte. Aufhänger für den Titel der Session war eine Postkarte auf der die Beine und Schuhe unterschiedlicher Menschen zu sehen sind. Business-Schuhe eines Herrn im Anzug, Schuhe mit hohen Absätzen einer Dame in feiner Kleidung und die Schlappen eines Herrn in Jeans. Die Beine und Schuhe auf dem Bild stehen scheinbar unmotiviert zusammen. Das ist ein durchaus gängiges Problem mit dem man in Projekten konfrontiert ist: Eine Gruppe unterschiedlicher Menschen zu einem funktionierenden Team werden zu lassen … Inhalt und Ablauf der Session sind auf openPM dokumentiert. Ich möchte an dieser Stelle noch auf einen Aspekt hinweisen. Die Beschäftigung mit Gruppendynamik in Projekten ist keine Spielerei sondern die Arbeit an einem relevanten Erfolgsfaktor. Verschiedene Untersuchungen haben inzwischen gezeigt, dass ein konstruktiver Verlauf der Gruppendynamik außerordentlich positiv mit dem Projekterfolg korreliert. Zum Nachlesen sein ein Artikel empfohlen, den ich zusammen mit Sven Lindenhahn geschrieben habe: Eberhard Huber, Sven Lindenhahn: TEAMWORK: Warum Projektteams erfolgreicher sind als Projektgruppen Objektspektrum Ausgabe 02 / 2010 Das PDF kann direkt beim Verlag heruntergeladen und weiter gegeben werden, ich habe eine entsprechende Vereinbarung mit dem Verlag getroffen.  
Trupp oder Team

Trupp oder Team

Der Spruch “T E A M = Toll Ein Anderer Macht es” ist oft zu hören. Angesichts des inflationären Gebrauchs des Begriffes “Team” ist das kein Wunder. Nahezu jede Form der Zusammenarbeit von Menschen wird heute mit dem Begriff Team belegt. Die sprachliche englisch-deutsch Durchmischung führt zu noch mehr Unschärfe. Dass nicht jede Form der Zusammenarbeit den Begriff Team rechtfertigt lässt die Unzufriedenheit wachsen, die unter Anderem in sarkastischen Sprüchen wie dem genannten mündet. Eine Unterscheidung der verschiedenen Team-Arten ist jedoch wichtig: Nicht jedes “Team” ist für jede Aufgabe geeignet. Zudem unterscheiden sich die Ansätze von Leitung und Führung doch erheblich. Im Folgenden möchte ich zwischen Teams (im engeren Sinne), Mannschaften (Crews) und Trupps unterscheiden. Die Begriffe sind nicht zufällig gewählt, sie verkörpern einerseits extreme Beispiele andererseits werden damit gelegentlich verwendete Metaphern aus Sport oder Militär deutlicher. Ich möchte die Unterschiede an der Form der Aufgabenteilung, dem Führungsprinzip sowie der möglichen Aufgabenstellung beleuchten. Der extreme Fall des Trupps ist z.B. im Militär oder in Organisationen wie Feuerwehr und Katstrophenschutz zu finden. Die Aufgabenteilung ist sehr strikt und wird gezielt eingeübt. Es ist im Einsatzfall bereits vorher entschieden und allen klar, wer welche Aufgabe übernimmt. Die Entscheidung wer die Drehleiter bedient, wer die Schläuche verlegt und wer die Leiter hoch klettert muss (!) im Vorfeld getroffen werden. Im Ernstfall ist es dafür zu spät. Diese Vorab-Entscheidung ist deshalb möglich weil ein Trupp konkrete Handlungsszenarien und definierte Abläufe hat, die eingeübt werden. Der Begriff der “Ãœbung” ist jetzt schon zweimal gefallen. Zu Recht – er ist ein wesentliches Merkmal. Ein Trupp kann und muss üben. Die Ãœbung findet unter Anleitung eines Führers1 statt. Mit dem explizit benannten Führer gehen auch eine klare, stabile Hierarchie und eine Kommandostruktur einher. Am anderen Ende der Skala steht ein “echtes Team” wie es z.B. in (agilen) Projekten zum Einsatz kommt. Die Einsatz-Szenarien sind weitgehend unbekannt. Die Aufgabenteilung ergibt sich dynamisch aus den Anforderungen des Projektes. Die innere Hierarchie verändert sich in engem Zusammenspiel mit der konkreten Aufgaben- und Rollenteilung. Eine hierarchische Kommandostruktur und Vorab-Ãœbungen nützen wenig bzw. sind sogar kontraproduktiv. Die (Fußball) – Mannschaft stellt gewissermaßen die Ãœbergangsform dar. Ãœbungen machen Sinn. Es gibt explizite Hierarchie-Positionen wie z.B. den Trainer oder den Mannschafts-Kapitän2 Die Aufgabenteilung ist vorab festgelegt kann aber in gewissem Umfang wechseln – schließlich kann und darf auch ein Verteidiger Tore schießen. In anderen Sportarten wie z.B. dem American Football ist der Abstand zum “Trupp” geringer, hier wechseln je nach Spielsituation sogar die Spieler das Feld. Aus diesen Merkmalen ergeben sich noch andere Unterschiede. In einem Trupp ist die Spezialisierung viel größer, dies ermöglicht in den eingeübten Situationen eine sehr hohe Effizienz. Anderseits ermöglicht die Flexibilität des “echten Teams” den besseren Umgang mit unbekannten Situationen. Jede dieser Gruppen hat ihre Berechtigung sollte aber auch passend eingesetzt werden. Für die Projektarbeit, die oft eine Aneinanderreihung von unbekannten Situationen ist, würde ich eine Gruppe empfehlen, die so weit wie möglich einem echten Team entspricht.
  1. Auch wenn der Begriff eventuelle negative Assoziationen auslösen mag, so trifft er doch den Punkt. []
  2. Interessanterweise ist der altmodische Begriff für den Kapitän der Spielführer. []
Warum Selbstorganisation in Projekten?<br />Die erste von 2 kurzen Antworten

Warum Selbstorganisation in Projekten?
Die erste von 2 kurzen Antworten

Lohnt sich Selbstorganisation? Ich hatte schon einmal einen Beitrag mit diesem Titel geschrieben. Ich schreibe heute ein Update weil mir diese Frage in regelmäßigen Abständen wenn auch in etwas anderen Formulierung immer wieder aus Neue gestellt wird: “Was habe ich von guten Teams oder Selbstorganisation – was bringt mir das?”. Ich gebe zwei Antworten auf diese Frage:
  1. Erfolgreichere Projekte!
  2. Zufriedenere Menschen!
Erfolgreichere Projekte Der Grad der Selbstorganisation1 in einem Team lässt sich mit Kontrollfragen2 grob ermitteln. Salopp formuliert lässt sich über die Auswertung der Fragen grob differenzieren ob es sich um ein (selbstorganisiertes) Team oder eine ggf. teilweise zerstrittene Arbeitsgruppe handelt. Für nebenstehende Grafik haben wir erstmals die Untersuchungsergebnisse der letzten 5 Jahre zusammengetragen und für 478 Projekte die Erfolgsquoten der Projekte in Abhängigkeit des Teamzustands ermittelt. Das Ergebnis spricht eine mehr als deutliche Sprache. Von den 478 Projekten hatten 199 gute Teams, von denen wiederum 132 erfolgreich waren. Dies entspricht einer Erfolgsquote von ca. 66%. Bei den Projekten mit schlechten Teams sieht es hingegen düster aus. Nur 6 von 40 Projekten waren erfolgreich (15%). Anders herum formuliert: Wer sich schlechte Teams leistet überzieht in mindestens 8 von 10 Projekten das Budget und/oder den Termin. Die Alternative ist es sich um die Teams zu kümmern, die Selbstorganisation zuzulassen um dann nur noch jedes dritte Projekt zu überziehen. Jede(r) hat die freie Wahl. Die zweite Antwort “Zufriedene Menschen” steht hier.
  1. Selbstorganisation zielgerichteter Arbeit entsteht als Ergebnis eines gruppendynamischen Prozesses den das Projektteam durchlebt. Hierbei wird eine innere Rollenklärung durchgeführt. Weniger diplomatisch formuliert: Es gibt Machtkämpfe. Am Ende entsteht ein Gerüst aus teilweise unausgesprochenen Normen, Regeln und Verhaltensmustern. Dieses Gerüst stellt die selbst geschaffene Organisation dar. []
  2. Die erwähnten Kontrollfragen und die Ermittlung des Teamzustandes werden hier am Beispiel einer kleineren Stichprobe beschrieben Weiche Faktoren sind wichtig. []
Die agile Essenz

Die agile Essenz

Projekte, die agile Vorgehensweisen einsetzen, sind erfolgreicher. Anderseits gibt es einen noch ausgeprägteren Zusammenhang zwischen Teamqualität und Projekterfolg. Meine These lautet: Es kommt darauf an, dass sich während des Projektes ein echtes Team bildet. Wenn agile Methoden eingesetzt werden, gelingt dies ein wenig leichter. Diese These möchte ich im Folgenden erläutern. Wie sieht der gemeinsame Kern agiler Vorgehensweisen aus?
  • Es wird akzeptiert, dass zu Beginn nur ein Teil der Anforderungen definiert ist.
  • Es besteht permanenter und enger Kontakt zu denen, die das Arbeitsergebnis geliefert bekommen.
  • Es wird in wiederkehrenden Intervallen gearbeitet.
  • Am Ende jeden Intervalls wird ein verwendbares Zwischenergebnis fertig gestellt.
  • Jedes Arbeitsintervall wird ausgewertet. Es werden Konsequenzen für das nächste formuliert und auch gezogen.
  • Die produktive Arbeit wird von einem Team geleistet, das selbstorganisiert arbeiten darf.
Aus der Formulierung der Merkmale wird schon deutlich, dass diese Arbeitsweise nicht nur für Software-Entwicklung sondern für viele verschiedene Projektarten möglich sein wird. Wie die Merkmale in der Praxis konkret umgesetzt werden (z.B. mittels Scrum) ist letztendlich egal. Genauer betrachtet lässt sich diese Arbeitsweise auch mit “klassischem Projektmanagement” zuzüglich ordentlichem Changemanagement, kooperativer Führung und transparenter Kommunikation verwirklichen. Agilität ist ohnehin eher als Geisteshaltung denn als Prozessbeschreibung zu verstehen.1 Nehmen wir an, dass in einem Projekt wie oben beschrieben gearbeitet wird. Das Team arbeitet und liefert nach einer gewissen Zeit ein (hoffentlich) verwertbares Zwischenergebnis ab. Sollte im ersten Intervall nichts Brauchbares fertig werden, muss eben nach den Gründen gesucht werden um dann im zweiten Anlauf erfolgreicher zu sein. Egal ob im ersten oder zweiten Anlauf, das Team hat sehr früh ein Erfolgserlebnis. Konkrete (Erfolgs)-Erlebnisse und Erfahrungen beschleunigen die teaminternen Klärungsprozesse wie Rollenklärung oder die üblichen Machtkämpfe erheblich. Ein simples Beispiel: Ein Kollege bezeichnet sich selbst als Spezialist für ein bestimmtes Thema. Stimmt das? Können sich Team und Projekt wirklich darauf verlassen? Nach der Lieferung des ersten Zwischenergebnisses hat sich das bestätigt (oder eben nicht). Die Bestätigung der Fähigkeiten, der Verlässlichkeit, das Erproben der Zusammenarbeit, das Wachsen des aufkeimenden Vertrauen – all dies erfolgt schneller wenn mit greifbaren Zwischenschritten gearbeitet wird.2 Im negativen Fall wird ebenfalls schneller klar, dass der Kollege vielleicht nur eine große Klappe hatte und er mit einer anderen Aufgabenstellung mehr für das Projekt tun kann. Wichtige Grundvoraussetzungen für eine erfolgreiche Teamentwicklung wie die Klärung der Fragen “Wer gehört dazu?” bzw. “Wie sieht die gemeinsame Aufgabe aus?” werden bei einer solchen Vorgehensweise quasi im Vorbeigehen erledigt. Wer agil arbeitet, stellt gewissermaßen ganz nebenbei gute Rahmenbedingungen für eine konstruktive Teamentwicklung bereit. Eine konstruktive Teamentwicklung innerhalb des Projektes ist m.E. DER Erfolgsfaktor für Projekte. Scrum stellt hierfür bessere Rahmenbedingungen als das Wasserfallmodell bereit. Dennoch gibt es keinen Königsweg. Auch in Wasserfall-Projekten lässt sich ein Teil des agilen Gedankenguts (siehe obige Merkmale) leben. Ein gutes Team schafft fast alles, eine zerstrittene Projektgruppe kann jedes Projekt scheitern lassen.
  1. Insofern kann ich Stimmen, die Scrum als alten Wein in neuen Schläuchen bezeichnen durchaus verstehen. []
  2. Ein Meilenstein in einem Projektplan ist nicht zwingend ein greifbarer Zwischenschritt. Die Softwareentwicklung hat es hier relativ leicht. Hier entspricht dies einem lauffähigen Release. In anderen Projekten muss die Definition der Meilensteine genau bedacht werden. []
© pentaeder 2019 / 2020