3. Einflussfaktoren

Basierend auf den Erkenntnissen zur Identität und Rolle des Agile-Teams innerhalb des Team-Ökosystems, ist es von Interesse zu erfahren, welche einflussnehmenden Faktoren auf das Scrum-Team wirken. Hierzu werden nachfolgend sowohl weiche[54] als auch harte[55] Faktoren betrachtet. Ausgehend von einer Gruppe befähigter Teammitglieder stellt jede Person zunächst eine individuelle Persönlichkeit innerhalb eines Systems dar. An dieser Stelle taucht in der Theorie der Begriff „Peopleware“ auf:

3.1 Peopleware

Als „Peopleware“ wird gemeinhin die soziale Komponente bezeichnet, die neben der Hardware und der Software noch den Menschen (siehe Abb. 11) im Prozess der Softwareentwicklung berücksichtigt. Der Begriff[56] stammt aus dem im Jahr 1987 von Tom DeMarco[57] veröffentlichten Buch „Vienna waits for you!“ und umfasst folgende Bereiche[58]: der arbeitende Menschen in seinen unterschiedlichen sozialen Rollen als Individuum, Gruppenmitglied, Vorgesetzter und/oder Untergebener und des Weiteren die Arbeitsfeldbedingungen, die Unternehmenskultur und -philosophie.

Abb. 11: Peopleware

Bei der näheren Betrachtung von Peopleware wird die Verbesserung der nachfolgenden vier soziologischen Inhalte[59] angestrebt, nämlich:

Mitarbeiterführung im Sinne von Menschenführung

Angemessene Gestaltung der Büroumgebung

Auswahl geeigneter Mitarbeiter

Förderung der Teambildung

Peopleware betrachtet den Mensch in seinen unterschiedlichen Rollen, in seinen Arbeitsfeldbedingungen und unter Berücksichtigung einer übergeordneten Unternehmenskultur. In der Gesamtheit sind alle genannten Aspekte in der Betrachtung untrennbar, da sie in gegenseitiger Wechselwirkung stehen: Mitarbeiter sind die Grundlage für eine Unternehmenskultur und bestimmen im gleichen Maße auch die Arbeitsfeldbedingungen. Arbeitsfeldbedingungen wiederum beeinflussen die Unternehmenskultur und die Mitarbeiter im Unternehmen. Jeder Mitarbeiter wird in der Konsequenz beeinflusst und übt auch Einfluss in seinem Sein und Handeln auf seine Umgebung aus.

3.1.1 The Human Resource

Der erste Aspekt bei der Betrachtung von Peopleware ist das Grundverständnis für die menschliche Ressource. Dieser wird in Agile neu definiert, weil durch den menschzentrierten Ansatz von und für den Menschen entwickelt wird. Während die erste und zweite Epoche des Computerzeitalters noch von Hardware und Software sowie der Optimierung dieser Aspekte geprägt war, wurde die dritte Epoche durch Jerry Weinbergs „The Psychology of Programming“ im Jahre 1971[60] eingeläutet. Die Anstrengung, die menschliche Komponente in einer von Ingenieuren und Computer-Spezialisten dominierten Domäne herauszustellen, war lange Zeit eine eher gewagte Angelegenheit; wer dies tat, konnte mit nur wenig Anerkennung rechnen, denn zu dieser Zeit lagen die Schwerpunkte noch weit fernab des User Interfaces.

Peopleware is really the third frontier of the computer revolution. First came the hardware crisis. At one time we thought our problems were really due to hardware. If only we had faster and more powerful computers, we thought, with more memory and better peripherals, then we could build better systems; we could solve our problems.[61]

Es verdichtete sich die Annahme, dass der wahre Grund für das Scheitern von Projekten der Mensch sei, denn neben fehlerhaften Anforderungen begründet sich das Scheitern laut der nachfolgenden Auswertung einer Studie in unterschiedlichen soziologischen Aspekten:

We observe that about 15 percent of all projects studied came to naught: They were canceled or aborted or „postponed” or they delivered products that were never used. For bigger projects, the odds are even worse. Fully 25 percent of projects that lasted 25 work-years or more failed to complete. In the early surveys, we discarded these failed data points and analyzed the others. Since 1979, though, we’ve been contacting whoever is left of the project staff to find out what went wrong. For the overwhelming majority of the bankrupt projects we studied, there was not a single technological issue to explain the failure.[62]

Als Gründe für das Scheitern von Projekten können hinsichtlich der menschlichen Komponente folgende Faktoren[63] genannt werden: Generelle Kommunikationsprobleme, Probleme beim Staffing, Differenzen mit dem Vorgesetzten oder Klienten, ein Mangel an Motivation, hohe Fluktuation, es gilt: „The major problems of our work are not so much technological as sociological in nature.”[64] Um der beschriebenen Problematik Ausdruck zu verleihen, soll im Folgenden der besondere Unterschied bei der Führung von Menschen im Vergleich der Areale von Entwicklung und Produktion gezogen werden. Besonders für den Wandel zu einem mehr agilen Ansatz sollen hier die Unterschiede und Vorteile deutlich werden. Entwicklung unterscheidet sich inhärent von der Produktion; es ist naheliegend, dass ein verantwortlicher Manager in der Art und dem Ursprung seines Handelns sowie in der Führung seiner Mitarbeiter zunehmend durch ein wirtschaftliches Denken gesteuert wird, welches sich näher an einer Produktionsumgebung bewegt. Im Vergleich zur Entwicklung handelt es sich bei der Produktion um einen Prozess aus sequenziell festgelegten Schritten.

Entwicklung hingegen hat zunehmend individuelle und empirische Tendenzen. „Most of us managers are prone to one particular failing: a tendency to manage people as though they were modular components.”[65] Agile Thinking berücksichtigt im besonderen Maße die Führung der Mitarbeiter und jedes einzelnen Individuums[66], indem das Management dieser denkenden Individuen effektiv gefördert wird. Der agile Ansatz berücksichtigt im Beispiel Scrum z. B. eine etablierte Fehlerkultur[67], die sich aus der Erkenntnis ergibt, dass Projekte nicht vorab und vollständig geplant werden können bzw. sollten. Ein früher Fehler vermag entscheidende Lerneffekte zu fördern, während ein zu spät erkannter Fehler das Scheitern eines Projektes zur Folge haben kann. Die Entwicklung hin zu einer agilen Projektumgebung erfolgt weg von einem „industrial paradigm“, das sich mehr auf die Praktiken der Produktion[68] stützt, hin zu einem Ansatz, der Freiraum für Individualität und wahren Mehrwert bietet. Diese Tatsache spiegelt sich sowohl kurzfristig in der Zusammenarbeit in einem Team, als auch langfristig im Produkterfolg wider:

Yet the way we assess people´s value to a new project is often based on their steady-state characteristics: how much code they can write or how much documentation they can produce. We pay far too little attention to how well each of them fits into the effort as a whole.[69]

Dieser Umstand führt die Argumentation hin zur Frage von Produktivität im Verhältnis zur Qualität und danach, was den entscheidenden Mehrwert in Summe ausmacht. So wurde in der Vergangenheit die Meinung vertreten, dass Menschen unter Druck gesetzt werden müssten, um effektiv mehr Stunden in Arbeit zu erbringen. „Someone who can help a project to jell is worth two people who just do work.”[70] Produktivität wird gemeinhin definiert als „benefit divided by cost. „The benefit is observed dollar savings and revenue from the work performed, and cost is the total cost, including replacement of any workers up by the effort.”[71] Die Erkenntnisse aus einem agileren Ansatz stellen das Verhältnis von Qualität zu Quantität her, indem die Unterschiede zwischen Entwicklung und Produktion deutlich werden: „People under time pressure don’t work better – they just work faster.”[72] Um tatsächlich schneller zu arbeiten, muss schließlich der Schwerpunkt in der Gewichtung verlagert werden: Bei gegebener Gewichtung der Dimensionen Zeit, Umfang, Qualität und Ressource misst Agile der Qualität mehr Bedeutung zu, wobei alle anderen Aspekte (ausgenommen Umfang) konstant verbleiben. „Quality, far beyond that required by the end user, is a means to higher productivity.”[73] Bei der generellen Betrachtung im Hinblick auf das Agile-Projektmanagement muss besonders das veränderte Menschenbild bei Scrum berücksichtigt werden. Folgende...