Diplomarbeit Ausgew¨ ahlte Team Patterns anhand der Theorie und Praxis der Softwareentwicklung sowie eine Analyse deren Beru ¨ cksichtigung in Extreme Programming durchgef¨ uhrt am Institut f¨ ur Rechnergest¨ utzte Automation Arbeitsgruppe Industrial Software Technische Universit¨at Wien unter der Leitung von Univ. Prof. DI Dr. Thomas Grechenig und Univ. Lektor DI Dr. Wolfgang Zuser durch Martin Kahr Trazerberggasse 6/2C/7, 1130 Wien Matr.Nr. 9226439

Wien, 16. J¨anner 2005

Zusammenfassung Die goldenen Jahre der IT Industrie scheinen vorbei zu sein. Effizient und kosteng¨ unstig muss Software heute entwickelt werden. Auf unterschiedlicher Art und Weise versuchen Unternehmen auf diese ge¨anderten Rahmenbedingungen zu reagieren. Effizienz und die erfolgreiche Abwicklung von Projekten sind von vielen Faktoren abh¨angig. Einer dieser Faktoren ist der Mensch sowie die Zusammenarbeit mit Kollegen und Kunden. Diese Arbeit besch¨aftigt sich mit dem Faktor Mensch und der Arbeit im Team. Erfolgreiche Teams k¨onnen die t¨aglichen H¨ urden der Projekte besser meistern als Arbeitsgruppen, in welchen jeder einzelne unterschiedliche Ziele verfolgt. Unternehmen profitieren durch solche Teams. All zu oft bieten aber Unternehmen nicht die notwendigen Rahmenbedingungen, um solche Teams schaffen zu k¨onnen. Auf Basis umfangreicher Praxiserfahrung werden im Hauptteil dieser Arbeit Punkte identifiziert, welche beim Teambuilding unterst¨ utzend wirken k¨onnen, oder die Schaffung von Teams behindern bzw. unm¨oglich machen. Kommunikation, der Arbeitsplatz, die unterschiedlichen Rollen in Teams, die Firmenstruktur und vieles mehr haben Einfluss auf Teams und deren Entstehung. Ein erfolgreiches Team aufzubauen ben¨otigt Zeit und Geld. All zu oft wird diese Investition unachtsam vergeudet und ein erfolgreiches Team zerst¨ort. Software Prozesse versprechen ebenfalls eine Steigerung der Effizienz in Unternehmen. Vor allem in den letzten Jahren entwickelten sich eine Reihe so genannter agiler Software Prozesse. Als Sperrspitze dieser Bewegung“ gilt der Software Prozess Extreme Programming. ” Prozesse definieren Regeln und Aktivit¨aten der Zusammenarbeit in einem Projekt. Dementsprechend beeinflussen Prozesse die Wahrscheinlichkeit, ein erfolgreiches Team bilden zu k¨onnen. Am Beispiel von Extreme Programming wird untersucht, wie ein Prozess das Teambuilding unterst¨ utzen bzw. hemmen kann. Extreme Programming kann zu Recht Teamprozess genannt werden.

i

INHALTSVERZEICHNIS

Inhaltsverzeichnis 1 Softwareentwicklung nach Euro und Jahr 2000 1.1 Konsolidierung oder Faster, Faster, Faster . . . 1.2 gescheiterte Projekte . . . . . . . . . . . . . . . 1.3 Management . . . . . . . . . . . . . . . . . . . . 1.4 Prozesse als Heilmittel . . . . . . . . . . . . . . 2 Teams 2.1 Teamgr¨osse . . . . . . . . . . . . . . 2.2 Arten von Teams . . . . . . . . . . . 2.2.1 Das Skiteam . . . . . . . . . . 2.2.2 Das Chirurgenteam . . . . . . 2.2.3 Symphonieorchester . . . . . . 2.2.4 Fußballmannschaft . . . . . . 2.2.5 Rennteam . . . . . . . . . . . 2.2.6 Tennis-Doppel . . . . . . . . . 2.2.7 Softwareteam . . . . . . . . . 2.2.8 Teams in Teams . . . . . . . . 2.3 Eingenschaften erfolgreicher Teams . 2.3.1 Jelled – eingeschworene Teams 2.3.2 Ziel . . . . . . . . . . . . . . . 2.3.3 Motivation . . . . . . . . . . . 2.3.4 Vertrauen . . . . . . . . . . . 2.3.5 Niedrige Fluktuationsrate . . 2.3.6 Teamidentit¨at . . . . . . . . . 2.3.7 Fehler . . . . . . . . . . . . . 2.3.8 Kommunikation . . . . . . . . 2.3.9 R¨aumlichkeiten . . . . . . . . 2.3.10 Negative Seiten von Teams . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1 1 2 3 4

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

7 9 9 9 10 10 11 11 12 12 14 15 15 15 16 16 17 17 17 17 18 18

3 Teams in der Softwareentwicklung 3.1 Das Team im Arbeitsmarkt . . . . . . . 3.2 Erfolgreiche Teamprojekte . . . . . . . . 3.3 Open Source Projekte und deren Teams 3.4 Prozesse und Teams . . . . . . . . . . . 3.4.1 Definition . . . . . . . . . . . . . 3.4.2 Prozessmedaillen . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

19 19 20 21 23 24 25

ii

. . . . . . . . . . . . . . . . . . . . .

INHALTSVERZEICHNIS

3.5

3.4.3 Prozesse und Kulturen . . . 3.4.4 Prozessfrust . . . . . . . . . 3.4.5 Prozess-Layers . . . . . . . Wie erh¨alt man erfolgreiche Teams

. . . .

. . . .

. . . .

4 Team Patterns 4.1 Zeit . . . . . . . . . . . . . . . . . . . . 4.1.1 Forming/Orientierung . . . . . . 4.1.2 Storming/Redefinition . . . . . . 4.1.3 Norming/Zusammenfinden . . . . 4.1.4 Performing/Leistungsst¨arke . . . 4.1.5 Adjourning/Zerfall . . . . . . . . 4.2 Firmenstruktur . . . . . . . . . . . . . . 4.2.1 Großes Softwarehaus . . . . . . . 4.2.2 Mittlerer Produkthersteller . . . . 4.2.3 Kleiner Projektabwickler . . . . . 4.2.4 Bodyleaser . . . . . . . . . . . . . 4.3 Arbeitsplatz . . . . . . . . . . . . . . . . 4.3.1 Kreative M¨obel . . . . . . . . . . 4.3.2 Kommunikative M¨obel . . . . . . 4.3.3 State-of-the-art Ausstattung . . . 4.4 Projektmanagement . . . . . . . . . . . 4.4.1 Vertrauen . . . . . . . . . . . . . 4.4.2 Fehler . . . . . . . . . . . . . . . 4.4.3 Umgang mit Erfolg . . . . . . . . 4.4.4 Schuster bleib bei deinen Leisten 4.5 Teamzusammensetzung . . . . . . . . . . 4.5.1 Rollen . . . . . . . . . . . . . . . 4.5.2 Mischung . . . . . . . . . . . . . 4.5.3 Der Kunde und das Team . . . . 4.5.4 Das Interview . . . . . . . . . . . 4.6 Kommunikation . . . . . . . . . . . . . . 4.6.1 Kontext . . . . . . . . . . . . . . 4.6.2 Medium . . . . . . . . . . . . . . 4.6.3 K¨ unstliche Teamhierarchien . . . 4.6.4 Morning Coffee . . . . . . . . . . 4.6.5 Verteilte Teams . . . . . . . . . . 4.7 Ziele . . . . . . . . . . . . . . . . . . . . iii

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

25 27 28 29

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 30 31 32 32 33 33 34 34 34 35 35 36 36 37 39 41 41 41 42 43 44 44 46 47 50 53 54 54 55 56 56 58

INHALTSVERZEICHNIS 4.7.1 Kriterien f¨ ur Ziele . . . . . . . . . . 4.7.2 Erreichte Ziele . . . . . . . . . . . . 4.8 Regeln . . . . . . . . . . . . . . . . . . . . 4.8.1 Coding Guidelines . . . . . . . . . 4.8.2 Meetings . . . . . . . . . . . . . . . 4.8.3 Strafen . . . . . . . . . . . . . . . . 4.9 Tools . . . . . . . . . . . . . . . . . . . . . 4.9.1 Turn Around Cylce . . . . . . . . . 4.9.2 Einheitliche Entwicklungsumgebung 4.9.3 Mailinglisten . . . . . . . . . . . . 4.9.4 Wiki . . . . . . . . . . . . . . . . . 4.9.5 Automatisierung . . . . . . . . . . 4.10 Anti Patterns / Teammord . . . . . . . . . 4.10.1 Defensives Management . . . . . . 4.10.2 Zu viele Projekte auf einmal . . . . 4.10.3 MBO . . . . . . . . . . . . . . . . . 4.10.4 Entwicklerpools . . . . . . . . . . . 4.10.5 Er passt nicht . . . . . . . . . . . . 4.10.6 Das Team im neuen Projekt . . . . ¨ 4.11 Ubersicht . . . . . . . . . . . . . . . . . . 5 XP 5.1 5.2 5.3 5.4

und Teams Teams und Prozesse . . Die Entstehung von XP The Cost of Change . . Vier Werte . . . . . . . . 5.4.1 Kommunikation . 5.4.2 Simplicity . . . . 5.4.3 Feedback . . . . . 5.4.4 Courage . . . . . 5.5 XP und Teams . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

58 60 62 62 63 63 64 64 65 66 66 68 70 70 70 71 72 73 74 76

. . . . . . . . .

77 77 78 78 80 81 82 83 84 85

6 Conclusio

88

A Danksagung

94

iv

TABELLENVERZEICHNIS

Abbildungsverzeichnis 1 2 3 4 5 6 7 8 9 10 11 12 13 14

scheiternde IT Projekte . . . . . . . . . . Team bei der Arbeit . . . . . . . . . . . erfolgreiches Rennteam . . . . . . . . . . Open Source Linux Logo . . . . . . . . . Teamleistungskurve . . . . . . . . . . . . kommunikationshemmendes B¨ uro . . . . Turm von Babel . . . . . . . . . . . . . . Videochat f¨ ur verteilte Teams . . . . . . erreichtes Ziel . . . . . . . . . . . . . . . Visualisierung eines erfolgreichen Builds Team Patterns Wechselwirkungen . . . . Traditionelle Cost of Change . . . . . . . optimale (XP) Cost of Change . . . . . . XP Story Card . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

2 7 11 21 31 38 53 56 60 68 76 79 80 83

Agiles Manifest . . . . . . . . . . . . . . . Arten von Teams . . . . . . . . . . . . . . Teamf¨ahigkeit in der Stellenausschreibung Team und Zeit . . . . . . . . . . . . . . . Team und Firmenstruktur . . . . . . . . . Team und Arbeitsplatz . . . . . . . . . . . Team und Management . . . . . . . . . . . Team und Rollen . . . . . . . . . . . . . . Team und Kommunikation . . . . . . . . . Team und Ziele . . . . . . . . . . . . . . . Team und Regeln . . . . . . . . . . . . . . Team und Tools . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

5 13 19 33 36 40 44 49 57 61 64 69

Tabellenverzeichnis 1 2 3 4 5 6 7 8 9 10 11 12

v

1 SOFTWAREENTWICKLUNG NACH EURO UND JAHR 2000

1

Softwareentwicklung nach Euro und Jahr 2000

Bang! Nach den fetten Jahren mit Euroumstellung und Jahr 2000 und dem abflauenden Internethype mussten weltweit mehrere tausend IT Firmen Konkurs anmelden. Alleine im Silicon Valley wurden f¨ ur 2004 bis zu 7.500 weitere Liquidierungen“ erwartet ([40]). Californien ist innerhalb von k¨ urzester Zeit ” von einem der reichsten Staaten der USA zu einem der schuldenreichsten geworden. Die dot-com Blase“ ist geplatzt – der Internethype ist vorbei. ”

1.1

Konsolidierung oder Faster, Faster, Faster

Das was in anderen Branchen Gang und Gebe ist, hat nun auch die IT Branche eingeholt. Auf die Dauer z¨ahlen an den internationalen B¨orsen nicht bloße Hirngespinste, sondern konkrete Umsatz- und Gewinnzahlen. Die IT Firmen versuchen auf ganz unterschiedlichen kreativen“ Wegen, ihre Gewinne zu ” erh¨ohen. Manche durch dubiose Patentklagen ([22]), aber der große Anteil der IT Firmen versucht die Effizienz zu steigern – schneller und besser zu werden. Nur wenige Firmen k¨onnen in dieser Zeit durch Innovation gl¨anzen.1 Effizient, qualitativ hochwertig und kosteng¨ unstig muss die Softwareentwicklung heutzutage sein, um im harten Konkurrenzkampf eine Chance zu haben. Das Management versucht, die Firma auf diese Schiene zu bringen. Unter dem Deckmantel des Wortes Konsolidierung“ wird aktives out-sourcing und ” down-sizing betrieben. Die angeschlagene Konjunktur und Medienberichte u unstige Arbeitskr¨afte aus den Kronl¨andern geben dem Management ¨ber g¨ den notwendigen R¨ uckenwind f¨ ur Personaleinsparungsmaßnahmen“ und f¨ ur ” die Aus¨ ubung von Druck auf die Mitarbeiter. Eine Umstrukturierung ist sicher in vielen Firmen notwendig. Zu viel Balast“ wurde in den goldenen ” IT Jahren aufgebaut. Wie aber Tom DeMarco richtigerweise erkennt, ist Ver¨anderung immer mit der Angst verbunden, gelerntes u ¨ber Bord werfen zu m¨ ussen. Diese Angst der Mitarbeiter, verbunden mit der aktuellen Arbeitsmarktsituation und der Tatsache, dass Ver¨anderung nicht von heute auf morgen m¨oglich ist, sondern seine Zeit braucht, und dabei auch Fehler passieren, bringt viele Firmen in die missliche Situation des totalen Stillstandes ([18]). Sehr oft ist dann zu beobachten, dass die so-genannten Key-Player“ ” die Firma verlassen und so das Schiff noch schneller untergeht. 1

Die Firma Apple gilt hier als r¨ uhmliche Ausnahme

1

1 SOFTWAREENTWICKLUNG NACH EURO UND JAHR 2000

1.2

gescheiterte Projekte

Studien zeigen immer wieder auf, dass gerade in der Softwareentwicklung eine hohe Anzahl von Projekten scheitern. • ein Viertel aller Projekte kommt nie zum Abschluss • ein Drittel aller Projekte muss, unter ver¨anderten Bedingungen, neu gestartet werden • 62 Prozent aller Firmen berichten von vollst¨andig gescheiterten Projekten in einem Zeitraum von f¨ unf Jahren Lediglich 1 Prozent aller Projekte werden in time and budget“ fertiggestellt ” ([46]). Von Effizienz kann hier keine Rede sein.

Abbildung 1: scheiternde IT Projekte In diversen Umfragen und Studien wird versucht, zu eruieren, welche Faktoren im Projektumfeld den erfolgreichen Projektabschluss in der Softwareentwicklung beeinflussen ([7]). Zur ewigen Hitliste z¨ahlt hier nat¨ urlich die st¨an” ¨ dige Anderung der Anforderungen“ und die damit oft verbundenen Probleme der Kommunikation mit dem Kunden, bzw. des guten Willen und klaren 2

1 SOFTWAREENTWICKLUNG NACH EURO UND JAHR 2000 Ziele des Kunden. Im Bereich des Managements sind qualifizierte, erfahrene Projektleiter, welche realistische Projektpl¨ane erstellen k¨onnen, ein wichtiger Einflussfaktor. Gerade in großen Projekten ist die hohe Fluktuation der Mitarbeiter ein schwieriges Problem, was wiederum Hand in Hand geht mit der Problematik erfahrene und f¨ahige Entwickler“ zu bekommen . Der so” genannte (etwas mackabere) Truck-Factor ([14]) ist in diesen Projekten zu niedrig. Sie sind Projektleiter eines Softwareentwicklungsprojektes. Machen sie mit ihrem gesamten Team einen Ausflug zu einer stark befahrenen Strasse. Verbinden sie sich die Augen und lassen sie ihr Team durchmischen und am Strassenrand in einer Linie aufstellen. Sobald sie einen heranfahrenden Truck h¨oren, geben sie einer Person einen Stoss. Bevor sie jemanden auf die Strasse stossen, m¨ ussen sie nat¨ urlich abw¨agen, inwiefern diese eine Person einen Einfluss auf den Erfolg ihres Projektes hat. Haben sie einen Key-Player im Team, welcher unersetzlich ist, so ist ihr TruckFactor gleich 1. Eine verlorene Person f¨ uhrt zum Scheitern ihres Projektes. Weitere wichtige Faktoren f¨ ur die erfolgreiche Abwicklung von Projekten sind ein guter Teamgeist, die Motivation des Teams und die Kommunikation innerhalb des Teams. Das Interessante an diesen Studien ist, dass die f¨ ur ein Projekt ausgew¨ahlte Technologie in den seltensten F¨allen Projekte zum Scheitern bringt. Zwischenmenschliche-, Management- und Kommunikationsprobleme sind in den meisten F¨allen f¨ ur das Scheitern von Projekten ausschlaggebend.

1.3

Management

Der englische Begriff Management (deutsch: Leitung, F¨ uhrung) entspricht im betriebswirtschaftlichen Zusammenhang der Unternehmensf¨ uhrung. Aufgabe eines Managers ist die Planung, Durchf¨ uhrung, Kontrolle und Anpassung von Maßnahmen zum Wohl des Unternehmens und aller daran Beteiligten (Anspruchsgruppen) unter Einsatz von betrieblichen Ressourcen ([1]). Managementlehre f¨ uhrt die beiden Wissensgebiete Betriebswirtschaft und Organisationspsychologie zu anwendungsorientierten didaktischen Konzepten zusammen. Die Organisationspsychologie ist ein Wissenschaftszweig der Psy3

1 SOFTWAREENTWICKLUNG NACH EURO UND JAHR 2000 chologie und befasst sich mit dem Verhalten von Menschen in der Arbeitswelt ([23]). Unternehmensf¨ uhrung (Management) ist eine professionelle Aufgabe. Entgegen einer verbreiteten Meinung, dass eine gute Fachkraft auch ein Unternehmen f¨ uhren kann, ist zum F¨ uhren eines Unternehmen (Soziales System) auch eine ad¨aquate Ausbildung notwendig bzw. hilfreich. Sechs Bereiche von Schl¨ usselqualifikationen f¨ ur Managern (vgl.Sarges (1990) S.165ff) sind: • Fachliche Qualifikation (Sache) • Konzeptionelle Qualifikation (Zielsetzung) • Methodische Qualifikation (Realisierung) • Kommunikative Qualifikation (Umgang mit Menschen) • Soziale Verantwortung (Moral und Ethik) Die Ausbildung von EDV Fachkr¨aften konzentriert sich an den Schulen und Universit¨aten vor allem auf die technische Basis (Mathematik, Logik). Wie die Realit¨at zeigt, ist aber nicht nur technisches Wissen f¨ ur den Erfolg von Softwareprojekten vonn¨oten, sondern vor allem kommunikative und soziale Kompetenzen. Diese Wissensgebiete kommen im t¨aglichen Schul- und Universit¨atsbetrieb leider zu kurz.

1.4

Prozesse als Heilmittel

One ClickTM2 und das x-te Buch u ¨ber den neuersten hypen Softwareprozess ist unterwegs ins B¨ uro. Umfangreiche Literatur existiert zum Thema Softwareentwicklungsprozesse und die meisten versprechen die L¨osung f¨ ur die vielen Probleme der Softwareentwicklung. Scheitert dann doch ein Projekt, so ist der Prozess Schuld – als ob wir Projekte des Prozesses wegen durchf¨ uhren. Die Umsetzung eines Prozesses in einer Firma ist ein schwieriges Vorhaben. Festgefahrene Verhaltensregeln m¨ ussen abgebaut und den Mitarbeitern Angst bzw. Bef¨ urchtungen genommen werden. Ein wichtiger Faktor bei der Umsetzung eines Prozesses wird leider oft vergessen. Es ist essentiell, die Praktiken bzw. Vorgehensweise eines Prozesses auf die eigenen Gegebenheiten, auf die Firmenkultur und das Betriebsklima anzupassen. Viele der 2

eines dieser wahnwitzigen Patente

4

1 SOFTWAREENTWICKLUNG NACH EURO UND JAHR 2000 Softwareprozesse entstammen genialen Gesch¨opfen aus Nordamerika. Es ist unumstritten, dass die Kultur der Amerikaner Unterschiede zur europ¨aischen Kultur aufweist ([28]). Dementsprechend ist es eine Notwendigkeit, diese Prozesse zu europ¨aisieren“. ” Softwareprozesse lassen sich in zwei Sparten kategorisieren ([35]). schwergewichtige Prozesse mit einer hohen Anzahl von Regeln, Praktiken, Dokumenten und Formularen leichtgewichtige Prozesse mit relativ wenige Regeln, welche einfach zu befolgen sind. Sehr oft wird die Entwicklung der Softwareprozesse mit einem schwingenden Pendel verglichen ([26]). Auf der einen Seite des Pendels stehen die schwergewichtigen, auf der anderen Seite die leichtgewichtigen Prozesse. In den 80er Jahren hat sich das Pendel auf der Seite der Schwergewichte befunden. Stark formale Prozesse ala Wasserfallmodell ([43]) mit strikten Phasen und umfangreicher Dokumentation wurden entwickelt. Die damals verwendeten Technologien (komplexe Programmiersprachen) mit langen compile-run-test Zyklen machten solche Prozesse sehr oft auch notwendig. Die Entwicklung der Softwareprozesse hat aber lange Zeit nicht auf die Weiterentwicklung der Technologien reagiert. Mit den leichtgewichtigen Prozessen wird nun seit 19963 das Pendel in die Gegenrichtung bewegt. Gegen formale Regeln und umfangreicher Dokumentation, stehen einfache, leicht zu befolgende Regeln, Kommunikation und vor allem der Mensch im Mittelpunkt. Mittlerweile wird unter dem Begriff agile Softwareentwicklungsmethoden“ ” eine große Anzahl von leichtgewichtigen Methoden zusammengefasst. Die Initiatoren dieser agilen Methoden einigten sich 2001 mit dem agilen Manifest auf die Kernpunkte agiler Methoden ([5], [13]). Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Tabelle 1: Agiles Manifest 3

Start von Kent Beck’s Arbeit bei der Chrysler Company und an eXtreme Programming

5

1 SOFTWAREENTWICKLUNG NACH EURO UND JAHR 2000 Die agilen Softwaremethoden konzentrieren sich auf den Menschen in der Softwareentwicklung. Anstatt wie mit Scheuklappen einen Plan zu verfolgen, ¨ wird versucht, auf die st¨andigen Anderungen (Anforderungen, Technologie, Team) im Projektumfeld zu reagieren.

6

2 TEAMS

2

Teams Der Anglizismus Team (v. altengl.: team Familie, Gespann) bezeichnet einen Zusammenschluss von mehreren Personen zur L¨osung einer bestimmten Aufgabe bzw. zur Erreichung eines bestimmten Zieles ([50]).

Abbildung 2: Team bei der Arbeit Heutzutage wird vielerorts von Teams gesprochen. Die meisten Manager sprechen gerne von ihrem Team. Einzig das Wort Team sagt aber noch nicht aus, ob eine mehr oder minder zuf¨allig zusammengeworfene Gruppe von Menschen harmonisch und effektiv zusammenarbeiten. Ganz im Gegenteil. In vielen Firmen wird innerhalb dieser Gruppen gegeneinander, oder, in Ermangelung von Zielen, ineffizient gearbeitet. Die Unterscheidung zwischen einer Gruppe von Personen, die zusammenarbeiten und einem effektiven Team ist meist nur innerhalb der Gruppe erkennbar. Ein Team ([25]) • ist eine aktive Gruppe von Menschen, • die sich auf gemeinsame Ziele verpflichtet haben • und gemeinsam die Verantwortung daf¨ ur tragen, 7

2 TEAMS • harmonisch zusammenarbeiten, • meist komplement¨are F¨ahigkeiten besitzen, • Freude an der Arbeit haben • und hervorragende Leistungen erbringen.

Unter diesen Gesichtspunkten d¨ urften vielerorts Manager ihre Gruppe nicht mehr als Team bezeichnen. Die Mitglieder eines Teams gehen bewusst eine enge Beziehung miteinander ein, um bestimmte Ziele zu erreichen. Folgende Eigenschaften machen eine Gruppe zum Team ([25], [31]). • Leistungsf¨ahigkeit: Ein Team kann Leistungen erzielen, die seine Mitglieder alleine niemals erreichen k¨onnen. Die Teamleistung ist mehr als die Summe der Leistungen der Einzelpersonen, vor allem dann, wenn die Leistung von einer Vielzahl verschiedener Erfahrungen, Fertigkeiten und Einsch¨atzungen abh¨angig ist. (2+2=5) • Teams besitzen ein gemeinsames bedeutsames Ziel. Es entsteht kein Team ohne Leistungsanforderung, die (auch) f¨ ur die Beteiligten von Bedeutung ist. • Ist Individualismus ein Hindernisgrund f¨ ur Teamarbeit? Nein! Individuelle Interessen, St¨arken und Unterschiede sind eine Quelle der Kraft. • Die Disziplin ist Grundprinzip von Teams. Gemeinsam werden Regeln definiert, welche durch jeden einzelnen befolgt werden. • Teams haben mehr Spaß. • Dynamik: Energiepotential, gegenseitiges Aufpowern, gegenseitiges Anspornen, Kraft und Freude werden durch das gemeinsame Arbeiten immer wieder belebt. • Teamarbeit steht f¨ ur ein Wertesystem, das positive Verhaltensweisen f¨ordert. – – – –

Zuh¨oren konstruktives Reagieren auf andere Meinungen jene unterst¨ utzen, die Hilfe ben¨otigen Interessen und Leistungen anderer anerkennen 8

2 TEAMS

2.1

Teamgr¨ osse

Enge Beziehungen innerhalb einer Gruppe bedingen auch eine Gr¨oßenbeschr¨ankung von Teams. Teams k¨onnen nicht beliebig erweitert und vergr¨oßert werden, da die notwendigen sozialen Beziehungen nicht mehr aufrecht gehalten werden k¨onnen. Der Kommunikationsaufwand steigt exponential. Typischerweise umfasst ein erfolgreiches Team zwischen 5 bis 15 Personen. Diese Gr¨oßenbeschr¨ankung muss vor allem bei sehr großen Projekten entsprechend gemanaged werden. Meist werden solche großen Projekte in entsprechende Subprojekte untergliedert. Jedes Subprojekt f¨ ur sich kann dann im entsprechenden Rahmen bleiben. Eine gewisse Grundsympathie zwischen den Teammitgliedern muss vorhanden sein, um erfolgreich zusammen arbeiten zu k¨onnen.

2.2

Arten von Teams

Die Art und Zusammensetzung eines Teams ist kritisch f¨ ur ihren Erfolg. Unterschiedliche organisatorische Strukturen und Aufgaben erfordern unterschiedlich organisierte Teams. F¨ ur den Erfolg jedes Unternehmen ist es daher wichtig, die f¨ ur ihre organisatorische Struktur und typischen Aufgabenstellungen, passende Teamstruktur zu finden. 2.2.1

Das Skiteam

Ein Skiteam ist eine besondere Form von Team. Die einzelnen Mitglieder sind zumeist starke Pers¨onlichkeiten, und die individuellen Ziele der Mitglieder (Sieg beim n¨achsten Rennen, Gesamtweltcupsieg, . . . ) u ¨berragen bei weitem dem gemeinschaftlichem Ziel (Nationenweltcupgesamtsieg). Trotz dieser starken individuellen Ziele ist das Team f¨ ur den Erfolg jedes einzelnen mitverantwortlich. Die j¨ ungeren Teammitglieder profitieren vor allem von der ¨ ¨ Erfahrung der Alteren, w¨ahrend wiederum die Alteren von neuen Ideen (zB: k¨ urzere Slalomski, Austesten von neuem Material) der J¨ ungeren profitieren. Rund um das Team ist die notwendige Infrastruktur aufgebaut, die f¨ ur einen einzelnen L¨aufer aufgrund der Kosten nicht m¨oglich w¨are. Man denke hier ¨ nur an die Schar von Artzen, Masseuren und Trainern. Die starken individuellen Ziele f¨ uhren zus¨atzlich zu einem starken Konkurrenzkampf innerhalb des Teams, welcher, wenn entsprechend gemanaged zu H¨ochstleistungen f¨ uhren kann (wie beim ¨osterreichischen Skiteam in den letzten Jahren 9

2 TEAMS bemerkbar wurde). Der Aufstieg des US Skiteams der letzten Jahre zeigt wie wichtig auch bei solchen Individualsportarten die Arbeit im Team ist. Das ¨ US Skiteam durfte in den letzten Jahren zusammen mit dem OSV Skiteam gemeinsam arbeiten. Die verbesserten Trainingsbedingungen und die engen Zusammenarbeit haben sich innerhalb k¨ urzester Zeit auf die Leistungen der US Sportler positiv ausgewirkt. Nach den zunehmenden Erfolgen des ame¨ rikanischen Skiteams wurde die Zusammenarbeit von US und OSV Skiteam wieder aufgelassen. 2.2.2

Das Chirurgenteam

Das Chirurgenteam ist durch eine hohe Spezialisierung gekennzeichnet. Die ¨ einzelnen Mitglieder sind speziell ausgebildet worden. Die Uberschneidung dieser speziellen F¨ahigkeiten ist eher gering. An¨asthesist wird weder der Operationsschwester aushelfen, noch wird die Operationsschwester im Falle eines Ausfalles den Chirurgen aushelfen. Die St¨arke solch eines Teams liegt in ihrer Spezialisierung und der daraus resultierenden Effektivit¨at. Diese Spezialisierung ist gleichzeitig aber auch das große Problem f¨ ur diese Art von Team. Keines der Teammitglieder kann f¨ ur ein anderes im Notfall einspringen. Das Team ist hierarchisch gegliedert. Der Chirurg tr¨agt die Hauptverantwortung und leitet das Team. Die starke Spezialisierung f¨ordert zus¨atzlich die Bildung von Stars“. Es kann durchaus sein, dass der Chirurg aufgrund seiner ” F¨ahigkeiten in einem anderen Krankenhaus mit einem anderen Team erfolgreich zusammenarbeitet. Einerseits sind klare gemeinsame Ziele erkennbar (die Operation), andererseits aber auch starke individuelle Ziele (Starchirurg) 2.2.3

Symphonieorchester

Das Symhonieorchester stellt eine Spezialform des Chirurgenteam“ dar ([46]). ” Der Dirigent u ¨bernimmt ¨ahnlich dem Chirurgen die Rolle des Leaders. Im Unterschied zum Chirurgenteam kann ein Mitglied allerdings f¨ ur einen anderen leichter einspringen. Der Bassist kann zwar nicht f¨ ur den Trompeter einspringen, sehr wohl kann aber die zweite Geige im Notfall auch die Rolle der ersten einnehmen. Das Symphonieorchester ist hierarchisch strukturiert, allerdings haben die einzelnen Mitglieder durchaus Einfluss auf die Zusammensetzung des Orchesters. Selbst Herbert von Karajan konnten nicht beliebig das Orchester zusammenstellen. Wenn die Musiker der Meinung waren, dass ein 10

2 TEAMS vorgeschlagenes Mitglied nicht passen w¨ urde, so hatten sie gute Chancen, sich durchzusetzen. 2.2.4

Fußballmannschaft

In der Fußballmannschaft gibt es einerseits durchaus spezialisierte Rollen wie ¨ Tormann, Freistossprofi, laufstarker St¨ urmer. Allerdings sind die Uberschneidungen zumeist recht groß. Dadurch kann ein St¨ urmer auch im Mittelfeld mitspielen oder in der Verteidigung aushelfen. Einzig die spezialisierte Rol¨ le des Tormanns hat typischerweise wenig Uberschneidungen mit dem Rest der Mannschaft. Eine hierarchische Zusammensetzung ist kaum vorhanden. Die Rolle des Kapit¨ans ist bei weitem nicht so stark wie beim Chirurgenteam oder beim Symphonieorchester. Innerhalb der Fußballmannschaft ist die Bildung von Stars“ m¨oglich. Diese k¨onnen aber wiederum nur durch das ” effektive Teamplay mit dem Rest der Mannschaft erfolgreich sein (und so erst zu Stars“ werden). ” 2.2.5

Rennteam

Abbildung 3: erfolgreiches Rennteam

11

2 TEAMS Das typische Rennteam ist hierarchisch mit vielen Spezialisten aufgebaut. Einerseits gibt es den Rennfahrer, der gleichzeitig als Galionsfigur fungiert, andererseits den Starkonstrukteur und den Motorspezialisten. Von dieser Struktur her ist es vergleichbar mit dem Chirurgenteam. Diese starke Spezialisierung und die Formung von Stars“ f¨ uhrt dazu, dass ein reger Menschen” ” handel“ rund um diese Stars getrieben wird. Gerade die letzten erfolgreichen Jahre von Ferrari in der Formel 1 haben aber auch einen deutlichen Umschwung im Rennzirkus gezeigt. Das zeigt sich in den diversen Aussagen von Michael Schuhmacher bei den Siegerinterviews, in welchen er immer die Arbeit des Teams in den Mittelpunkt stellt. Ferrari hat es geschafft ein Team von guten Ingenieuren aufzubauen in welchem keiner besonders hervorragt. Die Zusammenarbeit im Team, gest¨arkt durch das Vertrauen des Mutterkonzerns, macht die Erfolge aus ([37]) Viele neue Rennteam sind nur schwach hierarchisch organisiert. Spezialisten sind bis auf den Fahrer nicht vorhanden. Erfolge werden aus der Arbeit des Teams und nicht eines einzelnen gezogen. Der Halt innerhalb des Teams ist sehr stark und die Abwanderung einzelner eher selten. 2.2.6

Tennis-Doppel

Im Tennis Doppel hat jeder Spieler eine zugewiesene Aufgabe (Spiel am Netz, Spiel an der Grundlinie). Andererseits ist eine gewisse Redundanz erkennbar, da jeder Spieler auch die Aufgaben des anderen u ¨bernehmen kann. Eine Hierarchie ist nicht erkennbar. 2.2.7

Softwareteam

Nach der Untersuchung unterschiedlichster Arten von Teams stellt sich die Frage, welche Art von Team f¨ ur die Entwicklung von Software am besten geeignet ist. Besonderes Augenmerk wurde folgenden Punkten gewidmet: Stars: F¨ordert die Art von Team die Bildung von Stars, oder sind diese notwendig? Spezialisten: Sind Spezialisten f¨ ur den Erfolg mitausschlaggebend? Hierarchisch: Ist die Art von Team hierarchisch aufgebaut? 12

2 TEAMS gemeinsames Ziel: Verfolgt das Team ein gemeinsames Ziel oder stehen etwaige individuelle Ziele im Vordergrund? Folgende Aufstellung fasst die beschriebenen Arten von Teams unter diesen Gesichtspunkten zusammen. Die einzelnen m¨oglichen Werte sind schwach“, ” mittel“ und stark“. ” ” Stars Spezialisten Skiteam stark schwach Chirurgen stark stark Orchester mittel schwach Fußball mittel stark Rennteam schwach mittel Tennis schwach schwach

Hierarchisch schwach stark mittel schwach mittel schwach

g. Ziel gering stark stark stark stark stark

Tabelle 2: Arten von Teams Das Skiteam ist auf Grund des mangelnden gemeinsamen Zieles nicht f¨ ur die Softwareentwicklung geeignet, sondern sogar hinderlich. Die Art der Struktur des Chirurgenteam ist nur in Spezialf¨allen f¨ ur die Softwareentwicklng geegnet. Vorstellbar w¨are etwa eine Art von Feuerwehr-Team“ welches in brenzligen ” Projekten f¨ ur kurze Zeit aushilft und versucht, das Projekt zu retten. Das Team arbeitet effizient zusammen, bietet aber keinerlei Ausfallsicherheit und ist daher f¨ ur l¨angerfristige Projekte nicht geeignet. Wissensweitergabe ist nicht das prim¨are Ziel solcher Teams. Teams die a¨hnlich einer Fußballmanschaft organisiert sind, haben in der Softwareentwicklung erhebliche Vorteile. Spezialisten (zb.: Fachleute, Marketing oder der Kunde selbst), welche in sp¨aterer Folge f¨ ur den Erfolg des Produktes verantwortlich sind werden eingebunden. Die M¨oglichkeit, dass in Problemf¨allen Entwickler f¨ ur andere einspringen k¨onnen, erh¨oht zus¨atzlich die Erfolgsaussichten des Projektes. Die schwache hierarchische Struktur bietet jedem einzelnen die M¨oglichkeit, Verantwortung zu u ¨bernehmen und sich damit neuen Herausforderungen zu stellen. Auch die Art des Tennisteams eignet sich gut f¨ ur die Softwareentwicklung. Aufgaben werden so eingeplant, sodass zwei Entwickler damit betraut werden. Besonders in jenen F¨allen, wo ein ¨alterer- und erfahrener Entwickler mit einem j¨ ungeren Entwickler kombiniert werden kann. Der erfahrene Entwickler

13

2 TEAMS kann so die Rolle eines Lehrers bzw. Mentors u ¨bernehmen. Die Wissensweitergabe ist in solch einem Fall besonders hoch, die Ausfallsicherheit bez¨ uglich Entwickler steigt stark. Wissen wird in der Firma gehalten. Besonders bei Firmen mit einem hohen Anteil an externen Entwickler ist dies wichtig. Nachteilig ist hier nat¨ urlich der erh¨ohte Zeitaufwand, da zwei Resourcen abgestellt werden m¨ ussen. Die Art des Rennteams ist vor allem bei Gruppen von Vorteil welche ¨ahnliches gutes Know-How aufweisen k¨onnen. Unterst¨ utzt durch wenige Spezialisten (zb. externe Berater) k¨onnen sie vor allem f¨ ur die Realisierung technisch schwieriger neuartiger Probleme herangezogen werden. Die einzelnen Mitglieder besitzen gen¨ ugend Erfahrung um sich effektiv zu organisieren. Gemeinsame Merkmale (zb: Codequalit¨at) sind schnell definiert. Bei gr¨oßeren Teams (>=10) k¨onnen auch Subteams entstehen, welche technische Spezialf¨alle l¨osen. Teams k¨onnen also sehr unterschiedlich aufgebaut sein. Je nach Art des Projektes bieten sich unterschiedliche Strukturm¨oglichkeiten an. Das entscheidende dabei sind aber die einzelnen Mitglieder des Teams. Eine Person welche sich in der Fußballmannschaft“ wohl f¨ uhlt und produktiv ist, kann in ” einem Tennisteam“ untergehen, da sie nicht die sozialen Kompetenzen f¨ ur ” ein Mentoring mitbringt. Die Struktur eines Teams wird also durch die Art des Projektes, derer Mitglieder und durch das organistorische Umfeld (Management, Betriebskultur) beeinflusst. 2.2.8

Teams in Teams

Bei gr¨oßeren Gruppen (ab ca. 8 Personen) kann es auch vorkommen, dass sich innerhalb eines Teams entsprechende Subteams in unterschiedlicher Struktur formen k¨onnen. Zum Beispiel ist es denkbar, dass ein Rennteam“ von 4 ” Personen ein Framework und die technische Infrastruktur aufsetzt, w¨ahrend der Rest als Fußballmannschaft“ die eigentlichen fachlichen Anforderungen ” umsetzt. Solche Teams k¨onnen sehr effektiv zusammenarbeiten, bergen aber auch Gefahren, die sich aufgrund dieser Mischung ergeben. So leidet aufgrund dieser Spezialisierung nat¨ urlich die Ausfallsicherheit und der Resourcenausgleich darunter. Zus¨atzlich kann es sich ergeben, dass die beiden Teams teilweise unterschiedliche Ziele verfolgen. Das eine Team m¨ochte die fachlichen Anforderungen erfolgreich umsetzen, w¨ahrend das andere Team das u ¨ber ” dr¨ uber“ Framework entwickeln m¨ochte. Solche Probleme k¨onnen zu schweren Konflikten innerhalb des Gesamtteams f¨ uhren. Hier muss daher das Mana14

2 TEAMS gement besonders auf klare Zielvorgaben achten.

2.3

Eingenschaften erfolgreicher Teams

Nachdem wir uns mit den unterschiedlichen Arten von Teams besch¨aftigt haben, soll nun untersucht werden welche Eigenschaften erfolgreiche Teams aufweisen und inwiefern diese Eigenschaften f¨ ur den Erfolg von Softwareprojekten verantwortlich sein k¨onnen. Der Erfolg eines Projektes h¨angt nat¨ urlich nicht alleine vom Team ab. Ein Team steigert aber die Wahrscheinlichkeit eines Erfolges sehr – und das nicht vorhanden sein eines Teams bewirkt eine entsprechende Erh¨ohung des Projektrisikos. 2.3.1

Jelled – eingeschworene Teams Leider haben die wenigsten Entwickler das Gl¨ uck mehr als einmal in ihrem Leben in einem erfolgreichen Team arbeiten zu d¨ urfen.

Das Ganze ist mehr als die Summe der Teile([19]). Diese alte Binsenweisheit trifft vor allem auf erfolgreiche eingeschworene Teams zu. Eingeschworene Teams pflegen so enge Beziehungen untereinander, dass die Ergebnisse des Teams wesentlich gr¨oßer sind als die Ergebnisse der einzelnen Personen, wenn diese f¨ ur alleine arbeiten w¨ urden. Eingeschworene Teams haben auch mehr Spaß an der Arbeit, als man der Arbeit an sich ansieht. Manche Teams arbeiten an Aufgaben, die f¨ ur andere als langweilig empfunden werden. Erfolgreiche Teams sind nicht mehr zu bremsen – sie rasen auf den Erfolg zu. Die Aufgabe des Managements bei solchen Teams ist es, etwaige Hindernisse aus dem Weg zu schaffen. Es muss nicht im herk¨ommlichen Sinn geleitet werden. Das Team hat eine gewisse Eigendynamik entwickelt – es hat Schwung([19]). 2.3.2

Ziel

Eine der wichtigsten Eigenschaften erfolgreicher Teams ist das Vorhandensein eines gemeinsamen Zieles. Das Team hat sich auf ein Ziel eingeschworen, und unternimmt alles, um dieses Ziel zu erreichen. Etwaige individuellen Ziele verlieren an Priorit¨at – wichtig ist das gemeinsame Gruppenziel. Das Team tr¨agt gemeinsam die Verantwortung f¨ ur die Zielerreichung. Die Kooperation im Team ist das Mittel zu diesem Zweck.

15

2 TEAMS Wie wichtig das Projektziel und die Identifikation damit ist, und wie weit die Verantwortung der Erreichung des Zieles gehen kann, zeigt folgendes reale Beispiel. Bei der Entwicklung des Graphing Calculator bei Apple Computer wurde auch ein externer Mitarbeiter besch¨aftigt. Als im August 1993 das Projekt eingestellt wurde, war dieser externe Mitarbeiter derart entt¨auscht, dass er schließlich beschloss das Projekt heimlich, ohne Bezahlung, fortzuf¨ uhren. Sein Vertrag wurde zwar nicht verl¨angert, jedoch hatte er noch seine Zugangskarte sowie einen Arbeitsplatz. So arbeitete er schließlich heimlich ohne Wissen des Managements aber mit viel Unterst¨ utzung seiner ehemaligen Teammitglieder am Produkt weiter. Im Laufe der Zeit schlossen sich fr¨ uhere Mitarbeiter dem geheimen Projekt an und arbeiteten gemeinsam in den Abendstunden am Produkt. Aufgeflogen ist das ganze erst nachdem der Arbeitsplatz ben¨otigt wurde. Obwohl der externe Mitarbeiter keine Zutrittskarte mehr besass, schaffte er es, sich mit Unterst¨ utzung seiner Kollegen t¨aglich in das Geb¨aude zu schleichen. Nach mehr als sechs Monaten unbezahlter Arbeit und vieler Nachtstunden seiner Kollegen war das Projekt schließlich abgeschlossen und es wurde dem Management pr¨asentiert. Schlussendlich wurde die Software durch Apple lizenziert und als Teil des Betriebssystems ausgeliefert ([2]). 2.3.3

Motivation

Das gemeinsame Ziel der Gruppe dient als Motivationsverst¨arker. Das Erreichen des Zieles – der Erfolg – treibt das Team an. Die Motivation eingeschworener Teams ist sehr hoch, wodurch das eine oder andere kleine oder große Hindernis leichter genommen wird. 2.3.4

Vertrauen

F¨ ur die erfolgreiche Zusammenarbeit im Team ist das gegenseitige Vertrauen und Zutrauen in die F¨ahigkeiten des anderen unumg¨anglich. Dieses Vertrauen kann nur u ¨ber die Zeit aufgebaut werden. Zertifikate, Zeugnisse und Diplome k¨onnen hier nur einen Anfangsbonus f¨ ur einzelne schaffen. Einhergehend mit Vertrauen ist auch die Festlegung des Teams auf gemeinsame Spielregeln (Konventionen bez¨ uglich der kooperativen Zusammenarbeit). 16

2 TEAMS 2.3.5

Niedrige Fluktuationsrate

Eingeschworene Teams erkennt man durch eine extrem niedrige Fluktuationsrate. Keiner will das Team verlassen. Die Arbeit im Team macht so viel Spaß, dass pers¨onliche Kriterien wie Geld, Status oder Bef¨orderung gar keine oder eine nebens¨achliche Rolle spielen. 2.3.6

Teamidentit¨ at

Erfolgreiche Teams erkennt man meist auch aufgrund ihrer ausgepr¨agten Identit¨at. Das Team f¨ uhlt sich als Elitemannschaft und vergibt sich selbst einen mehr oder weniger sprechenden Namen. Red Rock, DAS Netbankingteam oder Support Ninjas sind nur einige Beispiele. Die Identit¨at kann auch so weit gehen, dass man sich zu einem eigenem Teamdress einigt. Diese Identit¨at steigert die Zusammengeh¨origkeit – man hat das Gef¨ uhl bei etwas Außergew¨ohnlichen dabei sein zu d¨ urfen – man ist besser als der Durchschnitt. Das Selbstvertrauen der Gruppe steigert sich. Die einzelnen Mitglieder werden nach außen anders wahrgenommen. Das Team hat eine kollektive IHR Identit¨at. 2.3.7

Fehler

Auch beim Umgang mit Fehlern kann man erfolgreiche Teams erkennen. Eingeschworene Teams treten gemeinsam auf. Fehler werden offen kommuniziert und es wird konstruktiv nach L¨osungen gesucht. Man hilft sich gegenseitig. Es wird nicht versucht, die Schuld auf andere abzuw¨alzen. Das Team gilt als Schutzmantel gegen die Außenwelt“. ” 2.3.8

Kommunikation

Gute, ehrliche, offene Kommunikation ist ein wichtiger Faktor bei erfolgreichen Teams. Die Kommunikation l¨auft locker ab – keiner versucht sich einen Vorteil gegen¨ uber den anderen zu verschaffen – man vertraut sich gegenseitig. Entscheidungen werden im Team getroffen und man interessiert sich f¨ ur die Arbeit des anderen. Auf effektive Weise wird technisches Know-How und fachliches Wissen ausgetauscht.

17

2 TEAMS 2.3.9

R¨ aumlichkeiten

Die R¨aumlichkeiten haben einen starken Einfluss auf die Art und Weise der Kommunikation. Nichts ist schlimmer, als wenn man in den n¨achsten Stock oder gar ins n¨achste Geb¨aude gehen muss, um mit einem Teammitglied reden zu k¨onnen. Erfolgreiche Teams erkennt man daher auch daran, dass sie in n¨achster N¨ahe zueinander arbeiten. Das kann sogar so weit f¨ uhren, dass ein achtk¨opfiges Team gen¨ ugend Platz in einem 5-Personen-Raum findet. 2.3.10

Negative Seiten von Teams

Teams k¨onnen auch negative Seiten, im Sinne des Unternehmens, haben. Unter dem Begriff inteam“ wird die Tatsache verstanden, dass pers¨onliche und ” professionelle Beziehungen nicht mehr klar voneinander getrennt werden. Dadurch k¨onnen sich familienartige Aspekte ergeben, was wiederum eine Tendenz zur Konfliktvermeidung innerhalb des Teams f¨ uhren kann. Ein weiterer schwieriger Aspekt kann die Beurteilung des einzelnen darstellen. Hat jeder im Team den Eindruck, dass seine spezifische Leistung gesehen wird? Leiden einzelne unter einem Gruppenzwang? Es kann also durchaus passieren, dass einzelne Personen zwar eine hervorragende Leistung im Team leisten, jedoch trotzdem ein gewisses Unbehagen empfinden. Dies kann dazu f¨ uhren, dass die Entfaltung individueller F¨ahigkeiten verhindert wird ([42]). Wer den Kopf aus dem Nest reckt, bekommt ihn abgeschnitten. – alte chinesische Volksweisheit Ein weiterer negativer Punkt vieler erfolgreicher Teams ist deren unbescheidenes, elit¨are Bewusstsein gegen¨ uber anderen Teams oder Abteilungen. Sozusagen ein kollektiver Gr¨oßenwahn.

18

3 TEAMS IN DER SOFTWAREENTWICKLUNG

3 3.1

Teams in der Softwareentwicklung Das Team im Arbeitsmarkt

Liest man die Stellenausschreibungen, so ist schnell zu bemerken dass auch die Wirtschaft Mitarbeiter mit ausgepr¨agtem Teamgeist, Teamf¨ahigkeit und Teamorientierung sucht. Aussagen wie ... sie sind bereit in einem dynami” schen erfolgreichen Team mitzuarbeiten ...“ sind h¨aufig zu lesen. Eine Analyse der Stellenausschreibungen im IT Sektor einer ¨osterreichischen Tageszeitung hat folgende Ergebnisse gebracht: In 15 der 17 Stellenbeschreibungen ist Teamf¨ahigkeit“ als Anforderung beschrieben worden. Die zwei Ausnahmen ” betrafen einer F¨ uhrungsposition im Vertrieb und einen Produktmanager. Die Ausschreibungen unterschieden sich nur in den Begriffen welche Teamf¨ahigkeit beschreiben. Anforderungsbeschreibung Teamf¨ahigkeit Teamgeist Teamplayer F¨ uhrung von multikulturellen Teams Teamorientierung Teamorientierte Pers¨onlichkeit

Anzahl 6 1 1 1 6 1

Tabelle 3: Teamf¨ahigkeit in der Stellenausschreibung Es ist also durchaus ein großer Bedarf an Mitarbeitern mit ausgepr¨agtem Teamgeist. Schwierig ist es allerdings diesen beim Vorstellungsgespr¨ach oder vielleicht sogar nur aufgrund der Bewerbungsunterlagen zu erkennen. Eine Person kann durchaus in einem Team H¨ochstleistungen vollbringen und in einem anderen Team verk¨ ummern. Die F¨ahigkeit, in einem Team effektiv mitarbeiten zu k¨onnen, ist von vielen Faktoren abh¨angig. Sympathie, die behutsame Einf¨ uhrung in das Team und die Akzeptanz durch das Team sind nur einige dieser Faktoren. Vor allem starke Pers¨onlichkeiten mit eigenen Vorstellungen zum Projekt k¨onnen große Schwierigkeiten bei der Integration in bereits bestehende Teams haben. Sie werden versuchen, ihre Werte und Erfahrungen einfliessen zu lassen, was sehr h¨aufig bei zu harschem Vorgehen zu einer Ablehnung durch das restliche Team f¨ uhren kann.

19

3 TEAMS IN DER SOFTWAREENTWICKLUNG

3.2

Erfolgreiche Teamprojekte

Den Großteil unseres Lebens verbringen wir in der Arbeit. Was kann also besser sein, als das Gef¨ uhl, am Montagmorgen aufzuwachen und sich zu denken JA - ich darf heute wieder arbeiten gehen“. Die Mitarbeit in einem erfolgrei” chen Team kann viele Probleme u ¨ber oder mit der Firma vergessen machen. Erfolgreiche Teams und deren Erfolg sind ansteckend f¨ ur andere Teams oder Gruppen. Meist genießen solche Teams, aufgrund ihrer Erfolge auch die besondere Anerkennung des Managements. Die Loyalit¨at gegen¨ uber der Firma steigt. Inwiefern k¨onnen aber erfolgreiche Teams zum Projekterfolg beitragen? In der folgenden Auflistung werden die oben beschriebenen Faktoren f¨ ur die erfolgreiche Abwicklung von Softwareprojekten den Eigenschaften erfolgreicher Teams gegen¨ ubergestellt. • st¨andig ¨andernde Anforderungen – Entwicklungsteams haben meist nur geringen Anteil an der Erstellung von Pflichtenheften oder Analysedokumenten. Die einzelnen Entwickler haben aber das Selbstvertrauen Unklarheiten offen zu kommunizieren. Jeder einzelne versucht etwaige Punkte, welche zum Scheitern des Zieles f¨ uhren k¨onnten, zu erkennen und fr¨ uhzeitig zu kommunizieren. Diese Tatsache beschr¨ankt sich nicht nur auf die eigenen sondern auch auf gelieferte Arbeiten. Zus¨atzlich ist das Team engagiert und motiviert, mit Fehler und Problemen konstruktiv umzugehen. Die Erfolge des Teams stiften wiederum Vertrauen zum Kunden bzw. Analytiker und f¨ordern die konstruktive Zusammenarbeit. • realistische Projektpl¨ane – Die Basis f¨ ur realistische Projektpl¨ane sind vern¨ unftige Absch¨atzungen des Aufwandes. Das Team kann den Projektleiter dabei unterst¨ utzen und im Team die Absch¨atzungen besprechen, um m¨oglichst zu vermeiden, dass kritische aufwandsrelevante Punkte vergessen wurden. • Key-Player Abh¨angigkeit – Innerhalb des Teams wird aktiv Wissensaustausch betrieben. Entscheidungen werden nicht von einzelnen sondern vom Team getroffen. Die Abh¨angigkeit zu Key-Playern wird dadurch vermindert. • guter Teamgeist und Motivation sind Kerneigenschaften erfolgreicher Teams. 20

3 TEAMS IN DER SOFTWAREENTWICKLUNG

3.3

Open Source Projekte und deren Teams

Abbildung 4: Open Source Linux Logo Nachdem nun eingeschworene Teams, deren Eigenschaften und deren Einfluss auf den Projekterfolg untersucht wurden, stellt sich nat¨ urlich die Frage warum eigentlich Open Source Projekte funktionieren. Die Entwickler von Open Source Projekten teilen die Eigenschaften obiger erfolgreicher Teams nicht. Die Kommunikation l¨auft fast ausschließlich u ¨ber Mailinglisten und Chatrooms, die Entwickler sind u ¨ber den ganzen Globus verteilt, die Fluktuation – sprich die Anzahl der Entwickler – ist meist stark schwankend. Trotzdem sind viele der Open Source Projekte erfolgreich. Vergleicht man ein Open Source Projekt mit einem herk¨ommlichen Projekt, so fallen aber sehr schnell Unterschiede auf: Budget Open Source Projekte haben die angenehme Eigenschaft, dass sie das Budget nicht u ¨berziehen k¨onnen, da es kein Budget gibt. Die einzelnen Entwickler arbeiten unentgeltlich. Zeit Viele der großen Open Source Projekte publizieren Projektpl¨ane auf deren Internetseiten. Die Einhaltung dieser Projektpl¨ane wird aber nicht gesichert. Verz¨ogerungen sind durchaus u ¨blich. Bedenkt man, dass die meisten Entwickler an Open Source Projekten zus¨atzlich zu ihrer normalen Arbeit mitarbeiten, so ist das auch nicht verwunderlich. Kunde In den meisten Open Source Projekten gibt es keinen dedizierten Kunden. Meist ist sogar der Entwickler sein eigener Kunde (so enstehen auch die meisten Open Source Projekte). Anforderungen werden meist 21

3 TEAMS IN DER SOFTWAREENTWICKLUNG sehr demokratisch u ¨ber Mailinglisten in der Community diskutiert und priorisiert. Gelassenheit Einem geschenktem Gaul schaut man nicht ins Maul. In Open Source Projekten ist jeder aufgerufen zu helfen. Daher ist es auch nicht verwunderlich, dass in Open Source Projekten der Benutzer aktiv an der Bugsuche und vielleicht sogar Behebung teilnimmt. So wird auch der Benutzer Teil dieser Community. Ziele Sehr oft ist nicht erkennbar, ob alle Beteiligten eines Open Source Projektes an ein und demselben Ziel arbeiten. Die Ziele sind oft unterschiedlich. Einerseits existiert nat¨ urlich das Ziel, ein gewisses Problem zu l¨osen, andererseits Anerkennung in der Community zu finden, idealistisch f¨ ur open source zu k¨ampfen oder einfach nur, besser als Microsoft zu sein. Hierarchie Open Source Projekte sind meist frei von Hierarchien. Nicht die Ausbildung oder der Lebenslauf z¨ahlen, sondern der Umfang der Beteiligung an der Community und der beigesteuerte Code. Gr¨oßere Projekte (Linux, JBoss, . . . ) haben aber mittlerweile eine Gr¨oße erreicht, wo eine reine demokratische Abhandlung nicht mehr ausreicht und sehr wohl Hierarchien eingezogen werden. Wie man sieht, existieren doch einige markante Unterschiede zu normalen“ ” Softwareprojekten. Open Source Projekte sind idealistisch und demokratisch. Das zentrale Element in Open Source Projekten ist die Community – vergleichbar mit einem erfolgreichen Team. Aus dieser Community wird die Motivation gesch¨opft. Einerseits um dabei sein zu k¨onnen und Anerkennung zu erlangen, andererseits um an etwas Interessantem Gr¨oßeren – etwas, was man alleine nicht schaffen k¨onnte – mitarbeiten zu k¨onnen. Die Vielzahl der Open Source Projekte gibt auch jedem Entwickler die M¨oglichkeit, in einem Themengebiet mitzuwirken, in welchem er sonst in seiner t¨aglichen Arbeit vielleicht nie die Chance dazu h¨atte. Aber auch Open Source Projekte k¨onnen in die Probleme herk¨ommlicher Softwareentwicklung geraten. So hat sich zum Beispiel ein betr¨achtlicher Anteil der Entwicklungsmannschaft des JBoss Projektes abgespalten – angeblich weil einige der Mitglieder des Projektes gutes Geld mit Consultingleistungen rund um das Produkt verdient haben, andere dazu aber keine Chance gehabt haben. Und was man auch nicht vergessen sollte, ist, dass eine Vielzahl an 22

3 TEAMS IN DER SOFTWAREENTWICKLUNG Open Source Projekte scheitert. Ein kurzes St¨obern auf Open Source Sites (zB: www.sourceforge.net) bringt tausende von toten Projekten zu Tage welche es nicht geschafft haben, das notwendige Interesse und die notwendige Community zu erzeugen. Da ist er wieder - dieser Spirit. Das Gef¨ uhl an etwas großem bedeutetem mitzuwirken. Teil einer Community zu sein in der man der realen Welt entschwinden kann. Auf ihre Art und Weise sind viele Open Source Projekte erfolgreiche eingeschworene Teams. (Achtung: Suchtfaktor)

3.4

Prozesse und Teams Does a process still solve Really hard Problems?“ ” Answer: Of course not“ ” But a good process helps people to excel as a team. The outcome is not only decided by individuals it is also decided by the effectiveness of their organization. [Booch, Jacobson, Rumbaugh]

Weltweit werden t¨aglich in Firmen Verbesserungen der Arbeitsabl¨aufe durchgef¨ uhrt. Ziel ist es die Abl¨aufe abzuschlacken (Lean Production) ([46]). Viele Firmen haben grosse Erfolge dadurch erzielt, und mittlerweile versuchen auch viele Staaten ihre Abl¨aufe zu optimieren, um so Kosten einzusparen. Leider gelingt dies derzeit sehr oft nur mit bescheidenen Erfolg. Bis zur industriellen Revolution im 19. Jahrhundert waren viele Unternehmen an Aufgaben orientiert. Jeder Mitarbeiter hatte, die ihm zugewiesene Aufgabe zu erf¨ ullen. F¨ ur die Motivation des Arbeiters oder Angestellten ist diese Organisationsform wenig hilfreich. Trotz allem ist in vielen Produktionsst¨atten diese strikte Aufgabenzuteilung nach wie vor en vogue. Man denke hier vor allem an die Arbeiter am Fliessband, welche tagein tagaus dieselbe T¨atigkeit durchf¨ uhren. In diesem Abschnitt wird der Einfluss dieser Prozesse auf die Arbeit von Teams und die Teambildung analysiert . Zus¨atzlich wird definiert, welche Themen ein Softwareentwicklungsprozess adressieren sollte, um die Wahrscheinlichkeit, ein erfolgreiches Team zu bilden, zu erh¨ohen.

23

3 TEAMS IN DER SOFTWAREENTWICKLUNG 3.4.1

Definition

In der Literatur sind unterschiedliche Definitionen eines Prozesses zu finden. • Concise Oxford Dictionary: Eine Reihe zielgerichteter Aktionen oder Schritte bzw. eine Folge von Arbeitsschritten in einer Produktion oder anderen Operationen. • Webster’s Dictionary: Ein System von Operationen, um etwas herzu¨ stellen. Eine Reihe von Aktionen, Anderungen oder Funktionen, um ein gew¨ unschtes Endresultat zu erreichen. • IEEE-STD-610: Eine Reihe von Schritten, die f¨ ur einen bestimmten Zweck unternommen werden, etwa der Software-Entwicklungsprozess. • Hammer und Champy, 1993: Eine Sammlung von Aktivit¨aten, die mit einem Input beginnt und einen Output erzeugt, der f¨ ur einen Kunden Wert besitzt. • SEI CMM, Watts Humphrey, 1993: Eine Reihe von Aktivit¨aten, Methoden und Praktiken, die f¨ ur die Herstellung und Wartung von Software eingesetzt werden. Analysiert man diese Definitionen bez¨ uglich deren Gemeinsamkeiten, so findet man folgende Aspekte eines Prozesses: • Ein Prozess muss definiert werden. • Ein Prozess muss einge¨ ubt und gelernt werden. • Ein Prozess besteht aus Subprozessen und T¨atigkeiten. Die typischen Ziele der Prozesseinf¨ uhrung innerhalb eines Unternehmens sind: • Konsistenz und Gleichklang bei bestimmten T¨atigkeiten, unabh¨angig davon, wer sie gerade durchgef¨ uhrt hat. • Die M¨oglichkeit die Leistungen eines einzelnen messen und damit beurteilen zu k¨onnen. • Die F¨ahigkeit der Wiederholung von Erfolgen, da das Unternehmen dadurch weniger auf einzelne Mitarbeiter angewiesen ist. 24

3 TEAMS IN DER SOFTWAREENTWICKLUNG • Steigerung der Effektivit¨at und der Produktivit¨at. • Identifikation von Bereichen, in welchen Investitionen get¨atigt werden sollten. ([46]) 3.4.2

Prozessmedaillen

Viele Unternehmen versuchen sich aufgrund der in ihrem Unternehmen etablierten Prozesse gegen¨ uber der Konkurrenz hervorzuheben. Um nun aber Unternehmen bez¨ uglich ihrer Prozesse miteinander vergleichbar zu machen, bedarf es einer Bewertungsm¨oglichkeit der Prozesse. In den letzten Jahren haben sich vor allem zwei Modelle etabliert: • CMM (Capability Maturity Model) bewertet Unternehmen danach, wie gut sie Software nach definierten und gelebten Prozessen entwickelt([29]). Unternehmen werden dabei in 5 Stufen eingeteilt. Desto h¨oher ein Unternehmen eingestuft wurde, um so besser und klarer ist die Vorgehensweise des Unternehmens. Mittlerweile fordern viele Ausschreibungen f¨ ur Projekte, dass anbietende Unternehmen eine gewissen CMM Stufe nachweisen m¨ ussen. • Die ISO (International Organization for Standardization) 9000 Norm beschreibt vor allem Standards bez¨ uglich der Organisation von Prozessen durch Dokumente ([24]). Der Standard definiert nicht die Qualit¨at oder das Erreichen des gew¨ unschten Endproduktes, sondern konzentriert sich auf die Definition des Prozesses. 3.4.3

Prozesse und Kulturen

Die Art und Weise von Prozessen in Unternehmen ist stark abh¨angig von der Kultur der Menschen, die diese Prozesse leben sollen. In manchen Kulturen sind Hierarchien st¨arker verankert als in anderen. Dies hat nat¨ urlich Auswirkung auf die Zusammenarbeit in Unternehmen. Im Jahre 2003 wurde in einer Studie des MIT versucht zu ermitteln, inwiefern sich die Arbeitsweise von Unternehmen bei der Softwareentwicklung aufgrund deren Lokalit¨at am Globus unterscheidet ([15]). Dazu wurden Unternehmen

25

3 TEAMS IN DER SOFTWAREENTWICKLUNG in den USA, Europa, Indien und Japan befragt. Insgesamt wurden 104 Projekte analysiert, welche sich mit den unterschiedlichsten Arten von Software (System Software, Applikationssoftware, Individuall¨osungen, ...) besch¨aftigen. Indien besitzt die mit Abstand meisten Unternehmen mit einem CMM Stufe 5 Zertifikat. Die Studie ermittelte interessante Ergebnisse. So wurde ermittelt, dass bei Projekten in Indien und Japan wesentlich mehr Wert auf m¨oglichst vollst¨andige Spezifikationen gelegt wird, als bei den Projekten in Europa und den USA. W¨ahrend in den USA gerade 32 Prozent der Projekte eine detailliertes Design erstellen, wird in Indien dies bei jedem Projekt (100 Prozent) durchgef¨ uhrt. Design Reviews werden bei jedem Projekt in Indien und Japan durchgef¨ uhrt, w¨ahrend in Europa und den USA dies nur bei zwei Drittel der Projekten gemacht wird. Zus¨atzlich wurde in der Studie versucht zu ermitteln, wie effektiv in den Projekten gearbeitet wird und wie sich dies in der Fehlerrate niederschl¨agt. Die Ergebnisse zeigen, dass in den USA die Effektivit¨at am h¨ochsten ist, bei mittlerer Fehlerrate. Die Effektivit¨at der Projekte in Indien liegt im unterem Bereich der Skala bei ebenfalls mittlerer Fehlerrate. Die Effektivit¨at der Projekte aus Japan lag im oberen Bereich der Skala bei der mit Abstand niedrigsten Fehlerrate. Europa schliesslich lag sowohl bei der Effektivit¨at als auch bei der Fehlerrate an der letzten Stelle. Die Studie zeigt sich beeindruckt von den Leistungen aus dem japanischen Raum. Einerseits besitzen sie ein klares und definiertes Vorgehen bei der Softwareentwicklung, verlieren aber andererseits - im Gegensatz zu den Projekten aus Indien - nicht an Effektivit¨at. Dies wird teilweise durch die japanische Kultur erkl¨art, welche vor allem durch hierarchischem Denken und Respekt und klaren Verhaltensregeln gegen¨ uber dem anderen gepr¨agt ist. Offensichtlich entspricht die Vorgehensweise vieler Prozesse dem Naturell der Japaner am besten. In der Conclusio der Studie wird eine sehr interessante Aussage getroffen. Kein Unternehmen aus Japan oder Indien besitzt im globalen Markt große Anerkennung bez¨ uglich deren Innovationskraft. Ob dies bedeutet, dass starke und klar definierte Prozesse die Innovationskraft in Unternehmen hemmen, wurde in der Studie nicht beantwortet.

26

3 TEAMS IN DER SOFTWAREENTWICKLUNG 3.4.4

Prozessfrust

Das Ziel eines definierten Prozesses ist es, die Arbeitsweise und Zusammenarbeit der Beteiligten zu definieren. Aufgrund der Tatsache, dass Prozesse einge¨ ubt und gelernt werden m¨ ussen, besitzt er eine gewisse Starrheit bez¨ uglich Ver¨anderung. Ein Prozess der f¨ ur ein gesamtes Unternehmen definiert wird und durch seine Mitarbeiter ausge¨ ubt wird, kann nicht einfach ge¨andert werden. Vielerorts kann dies zu folgenden Problemen f¨ uhren: • Die Tatsache, dass der Prozess starr ist, f¨ uhrt dazu, dass die Mitarbeiter/Abteilungen ebenfalls starr agieren und sich strikt an den Prozess halten, obwohl offensichtlich ist, dass der Prozess Fehler enth¨alt. • Diese Sturrheit und Starrheit f¨ uhrt wiederum zur Frustration jener Mitarbeiter, welche auf die erfolgreiche Zusammenarbeit angewiesen sind beziehungsweise mit entsprechender Motivation an die Sache herangehen. (Dies ist auch des o¨fteren bei jungen Beamten zu beobachten. Die Motivation f¨ ur die Arbeit l¨asst mit den Jahren nach, nachdem bemerkt wurde, dass das System nicht ver¨anderbar ist und als gegeben hingenommen wird.) • Die Frustration wird teilweise dadurch bew¨altigt, dass man sich mehr oder minder bewusst gegen den definierten Prozess stellt und damit die Ziele des gemeinsamen Prozesses ad absurdum f¨ uhrt. • Prozesse werden oftmals durch das Management zur Risikominimierung verwendet. Das strikte Einhalten des Prozesses gew¨ahrleistet, dass man im Falle des Scheiterns keine Konsequenzen zu bef¨ urchten hat. Man hat ja alle Schritte des Prozesses korrekt eingehalten. In diesem Fall wird ein Projekt des Prozesses willen durchgef¨ uhrt. Schlussendlich z¨ahlt aber nicht, ob ein Prozess eingehalten wurde, sondern ob der gew¨ unschte Erfolg - das Projekt erfolgreich abgeschlossen zu haben - erzielt wurde. Projekte scheitern also trotz oder gar wegen der Prozesse, mit welchen sie durchgef¨ uhrt werden sollen.

27

3 TEAMS IN DER SOFTWAREENTWICKLUNG 3.4.5

Prozess-Layers

Viele Unternehmen leisten sich den Luxus, eigene Abteilungen zu besitzen, welche sich verantwortlich erkl¨aren, die Prozesse des Unternehmens zu analysieren, zu definieren und zu verbessern. Der h¨aufigste Grund, dass Prozesse scheitern - sie werden nicht angewendet, bzw. umgangen - liegt darin, dass sie an den Zielpersonen - denjenigen die die Aktivit¨aten durchf¨ uhren m¨ ussen - vorbeidefiniert wurden. Prozessabteilungen laufen h¨aufig in die Gefahr, geblendet durch Literatur und Consultants der Prozessoptimierung, einen akademisch sauber definierten Prozess zu definieren, welcher realit¨atsfremd und daher nicht anwendbar ist. Prozesse m¨ ussen praktisch anwendbar sein. Die Unterschiede der verschiedenen Projekte, welche in Unternehmen durchgef¨ uhrt werden, spiegeln sich h¨aufig nicht in den definierten Prozessen wider. Es fehlt der Spielraum, den Prozess an die konkreten Anforderungen des Projektes anzupassen([17]). Prozesse m¨ ussen auf unterschiedlichen Ebenen beschriebenen werden. • Der grobe Prozess, welcher das Zusammenspiel eines Unternehmens mit seinen Kunden definiert. • Der Prozess, welcher das Zusammenspiel innerhalb des Unternehmens zwischen den Abteilungen definiert. • Der Prozess, welcher die grunds¨atzliche Vorgehensweise innerhalb eines Projektes definiert. H¨aufig wird versucht, den allumfassenden Prozess zu definieren. Man ”´erschl¨agt“ damit den Mitarbeiter, der den Prozess erlernen muss, mit Details und Anforderungen. Ein Ansatz zur L¨osung dieses Problems ist das Prozess Tailoring. Beim Prozess Tailoring werden nur die grunds¨atzlichen Aktivit¨aten im Prozess definiert, welche bei Projekten anzuwenden sind, n¨amlich jene Aktivit¨aten die bei den meisten Projekten notwendig und sinnvoll sind. Vor dem Projektbeginn wird die Prozessbeschreibung analysiert und entsprechend der Anforderungen des Projektes angepasst. Das Ziel ist es, jene Punkte zu identifizieren, welche bei der konkreten Projektart u ussig und ¨berfl¨ daher zu streichen sind, aber auch jene Punkte zu identifizieren, welche klarer zu spezifizieren und zu detaillieren sind. Dadurch soll gew¨ahrleistet werden, dass einerseits die Projekte des Unternehmens einer gemeinsamen Definition 28

3 TEAMS IN DER SOFTWAREENTWICKLUNG folgen, aber andererseits die M¨oglichkeit besteht, den Prozess entsprechend der Anforderungen anzupassen. Es werden Spielr¨aume geschaffen.

3.5

Wie erh¨ alt man erfolgreiche Teams Ein Team aufzubauen ist schwer – eines zu zerst¨oren ist einfach

Leider gibt es kein Patentrezept f¨ ur den Aufbau erfolgreicher Teams – ansonsten w¨ urden nur noch erfolgreiche Teams in der Weltgeschichte umherlaufen. Viele Wege f¨ uhren nach Rom, und so ist es auch beim Aufbau erfolgreicher Teams. Viele Faktoren sind ausschlaggebend, ob sich in einer Firma ein erfolgreiches Team entwickeln kann oder nicht ([20]). Es k¨onnen Teams in Firmen entstehen in welchen dies gar nicht beabsichtigt wurde, in anderen Firmen bem¨ uht man sich vielleicht vergeblich, erfolgreiche Teams zu bilden. Teams bilden sich nicht von einem Tag auf den anderen. Menschen ben¨otigen Zeit, um einander abzutasten, Grenzen zu erkennen und um sich kennen- und sch¨atzen zu lernen. Jede Firma kann aber versuchen die entsprechenden Rahmenbedingungen zu schaffen, welche f¨ ur die Bildung von erfolgreichen Teams notwendig sind. Im n¨achsten Kapitel werden einige Praktiken beschrieben welche sich in der Praxis f¨ ur die Bildung von Teams bew¨ahrt haben.

29

4 TEAM PATTERNS

4

Team Patterns

In diesem Kapitel werden Praktiken und Rahmenbedingungen beschrieben, welche in der Praxis gezeigt haben, dass sie die Bildung von erfolgreichen Teams unterst¨ utzen bzw. erforderlich sind. Die Befolgung dieser Sammlung an Praktiken stellt aber keine Garantie f¨ ur die Bildung erfolgreicher Teams dar. Die Individualit¨at jedes einzelnen und die Individualit¨at einer Gruppe von Personen ben¨otigt auch ein angepasstes, individuelles Vorgehen, um aus einer Gruppe ein erfolgreiches Team zu bilden.

4.1

Zeit Teambuilding ist ein st¨andiger Prozess — Man baut gemeinsam ” ein Haus, und einigt sich darauf, dass man Reperaturen gemeinsam ausf¨ uhrt. Man weiss, dass die Bausubstanz M¨angel aufweist, dass schon mal eine Fliese von der Wand f¨allt. Aber wir m¨ ussen darauf Vertrauen, dass wir alle bereit sind, das Haus instandzuhalten. Man muss sich darauf freuen, gemeinsam in dem Haus zu leben“ [32]

Erfolgreiche Teams entstehen nicht von heute auf morgen. Das Zusammenfinden unterschiedlichster Charaktere, unterschiedlicher Wertvorstellungen und Meinungen erfordert Zeit. Erfolgreiche Teams wird man nur in Ausnahmef¨allen innerhalb von einem Monat bilden k¨onnen. Umso wichtiger ist es, Teams langfristig zu halten. Es macht wenig Sinn wenn man Teams jedes Quartal neu strukturiert und Personen zwischen den Teams st¨andig wechseln. Die meisten Menschen brauchen eine gewisse Kontinuit¨at um sich wohl zu f¨ uhlen. Wenn ein Unternehmen es geschafft hat, ein erfolgreiches Team auf die Beine zu stellen, so kommt doch irgendwann der Zeitpunkt, an dem das Projekt zu Ende ist. Die Gefahr ist groß, dass die einzelnen Teammitglieder an unterschiedliche Positionen im Unternehmen versetzt werden. Dieser Umstand ist bedauerlich, da das Team erfolgreicher als viele andere Projekte im Unternehmen war. Es sollte daher versucht werden das Team zu halten. Es muss also ein neues Projekt f¨ ur das Team gefunden werden. Prinzipiell gibt es daf¨ ur zwei Alternativen: • Das Management sucht in anderen Abteilungen oder Bereichen des Unternehmens nach neuen Aufgaben f¨ ur das Team 30

4 TEAM PATTERNS • Das Team u ur externe dritte. ¨bernimmt die Entwicklung von Software f¨ Der Prozess der Teambildung hin zu leistungsf¨ahigen Teams ben¨otigt Zeit und durchl¨auft unterschiedliche Entwicklungsstadien. Bruce Tuckman beschreibt 1965 vier Stadien, welche ein Team typischerweise durchl¨auft ([47]). ¨ Ver¨anderte Umst¨ande, die Anderung der Teamzusammensetzung, neue Ziele, usw. k¨onnen dazu f¨ uhren, dass das Team in ein vorhergehendes Stadium zur¨ uckf¨allt und gegebenenfalls entsprechende Maßnahmen notwendig werden ([11]).

Abbildung 5: Teamleistungskurve

4.1.1

Forming/Orientierung

In diesem Stadium lernt sich das Team kennen – die Gruppe organisiert sich. Die Teammitglieder orientieren sich im Hinblick auf die anderen Mitglieder 31

4 TEAM PATTERNS und die verschiedenen Ziele. Es wird versucht die anderen und die eigene Position im Team einzusch¨atzen. Jedes Mitglied hat eine Vorstellung von seiner Rolle, welche aber meist nicht mit der Sicht der anderen Teammitglieder u uhlen sich unter Umst¨anden verunsichert, trauern ¨bereinstimmt. Einzelne f¨ dem alten Team nach und/oder sind vorsichtig. Aufgrund der Tatsache, dass typischerweise nur langsame Fortschritte in diesem Stadium gemacht werden, empfinden aufgabenorientierte Menschen dieses Stadium gegebenenfalls als l¨ahmend, behindernd oder gar frustrierend. Das Erwecken von Interessen, die Definition und Vermittlung der Ziele des Projektes und gemeinsames Planen sind hilfreich f¨ ur die Beschleunigung des Prozesses. Dieses Stadium kann als Vollendung des Teambuildingprozesses missverstanden verwenden ([25]). 4.1.2

Storming/Redefinition

Dieses Stadium wirkt meist chaotisch. Sie ist gepr¨agt von Auseinandersetzungen und Konflikten die ausgetragen werden. Die Teammitglieder benennen ihre eigenen Interessen und die Kommunikation wird offener. Sowohl Pessimismus ( das schaffen wir nie“) als auch Ehrgeiz ( starten wir endlich“) ” ” k¨onnen in diesem Stadium auftreten. Bereiche mit Gemeinsamkeiten sollten gekl¨art und die St¨arken, die jedes Mitglied in das Team mitbringt, betont werden. M¨oglichkeiten der Zusammenarbeit sollten herausgearbeitet werden. Die Leistung kann in diesem Stadium zur¨ uckstehen. Dieses Stadium kann leicht als Auseinanderfallen des Teams missverstanden werden. 4.1.3

Norming/Zusammenfinden

Die Betonung verschiebt sich von internen Spannungen hin zu den Herausforderungen, die die Arbeit mit sich bringt. Spielregeln werden vereinbart, der Konsens wird gefunden. Allgemein akzeptierte Methoden kommen zum Einsatz. Die Aufgaben werden im Team verteilt und die einzelnen Personen finden ihre Rolle im Team. Es entwickelt sich ein Zugeh¨origkeitsgef¨ uhl und Spaß an der gemeinsamen Arbeit. Die Leistung des Teams nimmt gegen¨ uber des Storming Stadiums sprunghaft zu. Dieses Stadium kann daher f¨ ur zufriedenstellend gehalten werden, doch sind noch weitere Verbesserungen der Teamleistung zu erzielen.

32

4 TEAM PATTERNS 4.1.4

Performing/Leistungsst¨ arke

Die Teammitglieder beginnen noch effektiver, koordinierter, kooperativer und engagierter zusammenzuarbeiten. Die Lust auf neue Herausforderungen mit h¨oherem Risiko steigt. Das Team ist in der Lage sich gegenseitig offenes Feedback zu geben und kann konstruktiv Konflikte austragen. Das Zusammengeh¨origkeitsgef¨ uhl und Identit¨atsgef¨ uhl ist sehr stark ausgepr¨agt. Das Team wehrt sich gegen eine Aufl¨osung und hat eine sehr niedrige Fluktationsrate. Die Teammitglieder entwickeln sich weiter und lernen voneinander. Feste Beziehungen zu anderen Teams werden aufgebaut. Die Leistung des Teams steigt weiter. Dr. Bruce Tuckman f¨ ugte 1970 eine f¨ unfte Stufe dem Modell hinzu. 4.1.5

Adjourning/Zerfall

Im f¨ unften Stadium zerbricht das Team, hoffentlich erst wenn die Aufgabe erfolgreich abgeschlossen ist ([38]). Die einzelnen Teammitglieder suchen neue Herausforderungen und nehmen die positive Erfahrung und das gute Gef¨ uhl, etwas geschafft zu haben, mit. Unternehmen sind hier gefragt diese Phase in Teams rechtzeitig zu erkennen und unter Umst¨anden auch zu f¨ordern. Sobald das gemeinsame Ziel in den Hintergrund tritt, werden die pers¨onlichen Ziele (Weiterentwicklung, Karriere) umso wichtiger. Ein k¨ unstliches Zusammenhalten eines Teams ohne richtige Herausforderungen kann schnell negative Auswirkungen bewirken. Dies kann soweit f¨ uhren, dass Mitarbeiter das Unternehmen verlassen. Andererseits kann ein zu schneller Zerfall eines Teams ¨ auch große soziale Angste bei einzelnen verursachen. Das Team bot ihnen einen sozialen Schutzmantel und Sicherheit. F¨ orderlich Hinderlich Zeit zum Teambuilding kurze Projekte (500 Mitarbeiter) besitzen naturgem¨aß viele Hierarchieebenen. Zur Kostenkontrolle wird das Unternehmen in Bereiche, Abteilungen und Zentralabteilungen untergliedert. Dementsprechend hat die B¨ u” rokratie“ in diesen Firmen Einzug gehalten. Dies zeigt sich oft an Antr¨agen f¨ ur Schreibutensilien und Hardwareupgrades, zentralem Management von Software und Hardware, komplexen Zeiterfassungssystemen und zentralistischen Methodik- und Architekturabteilungen. Vielfach behindern diese b¨ urokratischen H¨ urden die Bildung von erfolgreichen Teams. Ein erfolgreiches Team agiert meist zu schnell“ f¨ ur die anderen Abteilungen und wird durch endlosen ” Meetings und Abstimmungen mit anderen Abteilungen gebremst – was wiederum der Motivation schadet und vielfach zu einer gewissen Gleichg¨ ultigkeit f¨ uhrt. Umso mehr ist in solchen Strukturen das Management der Abteilung oder des Bereiches aufgefordert ein unb¨ urokratisches Umfeld f¨ ur das Team zu schaffen. Diese teilweise Abkapselung“ des Bereiches/Abteilung von der ” restlichen Firma f¨ uhrt andererseits zur Bildung von Subfirmen“ innerhalb ” der Firma. Das kann einerseits zu einem gesunden Konkurrenzkampf f¨ uhren, kann sich aber leicht auch negativ im Sinne des Unternehmens entwickeln. Gemeinsame Projekte und die Wiederverwendung von Wissen und Softwarekomponenten werden dadurch erschwert. 4.2.2

Mittlerer Produkthersteller

Mittlere (100-200 Mitarbeiter) und kleine (