|
Einleitung
Der hohe Motivations-Grad in Agilen Software-Projekt-Teams wird von den "traditionellen"
Software-Organisationen oft als Argument gegen(!) Agile Vorgehensweisen benutzt:
Über solch eine Argumentation sollte man nachdenken ...
und ich bin der festen Überzeugung, daß die obige Aussage den Nagel tatsächlich
auf den Kopf trifft:
Agile Leute sind hoch motiviert!!!
Wie es dazu kommt möchte ich hier beschreiben.
Seitenanfang
Ein Henne-Ei-Problem
Für die "Traditionalisten" (bzw. generell die meisten Skeptiker) scheint "Ursache und
Wirkung" in diesem Fall klar auf der Hand zu liegen:
Hoch motivierte Entwickler => bringen Agile Projekte zum Erfolg;
Man kann die Beobachtung aber auch so deuten:
Agile Projekte => machen Entwickler hoch motiviert;
Die "Wahrheit" liegt sicherlich in beiden Aussagen. Und damit haben wir ein klassisches
"Henne/Ei-Problem": was ist zuerst da?
- ja, Motivation der Entwickler hat einen starken (wenn nicht entscheidenden)
Einfluß auf den Erfolg eines Projekts;
jedes Projekt profitiert davon, auch nicht-agile;
- und ja, Agile Projekte schaffen ein Projekt-Umfeld, das Motivation bei den
Entwicklern zuläßt und aktiv fördert; sozusagen als Nebenprodukt;
Lassen Sie mich erst einmal erklären, was ich unter einem "motivierten Team" verstehe
bzw. wie Motivation in Projekt-Teams für mich erkennbar ist.
Seitenanfang
Motiviertes Team
Es gibt sicher auch andere Beschreibungen/Definitionen, aber für mich ist ein
"Motiviertes Team" durch folgende Eigenschaften gekennzeichnet:
(die Liste stellt keine Reihenfolge oder Wertigkeit dar)
- ein gemeinsames Ziel wird verfolgt;
- zielstrebiges Handeln erfolgt ohne "Anordnung";
- Abstimmung im Team erfolgt selbstständig;
- der Team-Leiter/-Manager/-Coach muß den persönlichen Einsatz
der Team-Mitglieder eher bremsen (=gesund bleiben) als einfordern;
- es wird viel fachlich diskutiert und Information "fließt" im Team;
- notwendige Entscheidungen werden schnell getroffen;
- Entscheidungen werden gemeinsam getroffen;
- in kritischen Situationen sind alle bereit zu helfen, keiner zieht sich zurück;
- niemand scheint wirklich Angst zu haben: vor niemandem (dem Kunden,
dem Projekt-Leiter, ...) und nichts (neuen Anforderungen, Fehlern ...);
- es gibt ein hohes Maß an Zusammenarbeit und gemeinsamer Verantwortung;
- sie wollen alle (gemeinsam) Erfolg haben;
- man unterstützt und hilft sich gegenseitig;
- es wird gelacht, die Leute haben Spaß an ihrer Arbeit;
D.h. natürlich nicht, daß man diese Beobachtungen nur in Agilen Software-Projekten
machen kann. Man wird wohl auch Wasserfall-Projekte finden, auf die obige Beschreibung
zutrifft (insbesondere dann, wenn der Liefertermin noch weit weit entfernt liegt!).
Wie kommt nun ein Team in einen solchen "Motivations-Zustand"?
Liegt es am Gehalt oder den Prämien?
Oder irgendwelche andere Vergünstigungen?
Braucht man interne Konkurrenz und "Wettkampf-Stimmung?
Ich denke es ist hinlänglich bekannt, daß "Geld" wenn überhaupt ein eher schwacher
und wenig nachhaltiger Motivator ist (man denke doch nur an den deutschen
Bundesliga-Fußball mit seinen Star-Mannschaften und deren mäßigen Erfolgen).
Und es ist auch bekannt, daß es neben einem Gewinner immer viele Verlierer gibt
-- wir brauchen doch aber ein "Motiviertes Team" für unser Software-Projekt.
In Agilen Projekten kommen aus meiner Sicht einige der "wahren" Motivatoren zum Einsatz.
Seitenanfang
Motivatoren -- ein kurzer Ausflug in die Theorie
Ein kurzer Ausflug in die Theorie soll helfen, die weiter unten beschriebenen
Beobachtungen als Motivatoren besser einordnen zu können:
Bedürfnispyramide nach Maslow
Maslow definiert 5 Klassen von menschlichen Bedürfnissen, die in einer hierarchischen
Beziehung zueinander stehen:
Abb. 1: Bedürfnispyramide nach Maslow;
Supermotivation nach Dean Spitzer
Dean Spitzer beschreibt 1995 in seinem Buch "Supermotivation" die folgenden Motivatoren:
(Spitzer's Annahme: je mehr Motivatoren im Umfeld einer Tätigkeit vorkommen,
umso motivierender empfindet eine Person diese Tätigkeit:
Das sollte uns soweit genügen, um zu "verstehen", wie Agile Vorgehensweisen auf die Motivation
der beteiligten Personen wirken.
Seitenanfang
Agile Motivation
Im folgenden unterstelle ich, daß das Ziel eines Software-Projekts ist ...
... den Kunden voll zufrieden zu stellen
durch qualitative Software,
die einen optimalen Geschäfts-Nutzen bringt,
einen fairen Preis hat und
pünktlich geliefert wird.
(ich beziehe mich bei meinen Aussagen auf eine Kombination aus
Scrum (Management-Praktiken) und
eXtreme Programming
(Entwickler-Praktiken))
Aktive Teilnahme -- das ist mein Projekt
Das Projekt-Team erhält kein Tayloristisch vorbereiteten (Teil-) Aufgaben, sondern
ist von Beginn an aktiv beteiligt: in der Exploration werden zusammen mit den Kunden
und Anwendern die Anwendungsfälle besprochen und analysiert; mit dem gewonnenen
Wissen werden die Aufwandsschätzungen gemeinsam durchgeführt; die Priorisierung
wird mit dem Kunden/Anwender besprochen; usw.
Die Mitglieder in einem Agilen Software-Projekt erhalten vielfältige Möglichkeiten,
um Einfluß zu nehmen, Ideen einzubringen und nicht nur reine
"Ausführer" von fremdem Plänen zu sein.
Abwechslung -- die Arbeit im Team ist vielseitig
Die Aktivitäten Analyse, Design, Codierung, Testen, Demonstration, etc.
werden in Agilen Teams gemeinsam erledigt. "Gemeinsam" muß nicht wirklich
heißen "alle zusammen", sondern soll bedeuten: die Aufgaben werden durch das
Team verteilt und Neigungen/Können werden dabei voll ausgenutzt.
Es kommt aber auch noch ein starker zeitlicher Aspekt der Abwechslung hinzu:
in klassischen Wasserfall-Projekten sind reine Codierungs-Phasen
von 8, 10 oder auch 12 und mehr Monaten die Regel;
d.h. in dieser Zeit werden vorab erstellte Design-Vorgaben ausprogrammiert --
jeden Tag, monatelang. Agile Teams liefern alle 4-6 Wochen(!) einsatzfähige Software
an den Kunden/Anwender aus -- d.h. sie durchlaufen in dieser kurzen Zeit
jedesmal die Bandbreite eines komplette Software-Projekts (von Planung
bis Auslieferung)!
(eigene) Wahl/Auswahl -- wir entscheiden gemeinsam, wie wir vorgehen
Agile Software-Entwickler haben oftmals Wahl-Möglichkeiten: z.B.
Pair-Programming -- mit wem?
User Stories -- an welcher möchte ich arbeiten?
Zusätzlich rückt noch ein weiterer Aspekt ins Rampenlicht: der Review oder die
Retrospektive! Ca. alle 2 Wochen reflektiert das Team gemeinsam darüber, was gut
gelaufen ist, was weniger gut, was verbessert/verstärkt werden sollte, was fehlt.
Hier haben sie eine echte Chance, die eigenen Arbeitsbedingungen zu beeinflussen.
Arbeiten in Teams und Beratung -- ich finde hier Unterstützung
Personen, die neu mit den Agilen Vorgehensweisen in Kontakt kommen, sind vor allem
von Pair-Programming angetan: nach 2-3 Wochen fühlen sie sich "unbehaglich", falls
sie wieder einmal alleine eine Aufgabe erledigen müssen. Ihnen fehlt ein Stück eigener
Mut und die Möglichkeit, sich jederzeit und sofort beraten zu können.
Pair-Programming ist eine sehr intensive Form eines Teams und zeigt die Wirkung auf die
Entwickler damit auch sehr stark. Wenn auch nicht so deutlich sichtbar, so hat aber
auch das gesamte Agile Team dieselben positiven Wirkungen auf die Mitglieder:
sie spüren und erleben Rückhalt, Beratung, Hilfe und gemeinsames Schaffen.
Fehlertoleranz -- ich darf mutig sein
Hätten wir es mit einem Massenartikel zu tun, der x-tausendfach immer wieder gleich
gefertigt werden muß, dann sollte man Fehler-Freiheit erwarten. Aber Software-Entwickler
betreiben eben Entwicklungs-Arbeit, d.h. ein (Software-) Produkt wird zum erstenmal
erstellt.
Die Mechanismen in Agilen Teams sorgen dafür, daß mögliche Fehler
schnell sichtbar werden, damit nicht lange überleben können
und so auch keinen (großen) Schaden anrichten können:
Unit Tests, Continuous Integration, enger Kunden-Kontakt, Pair-Programming, ca.
4-wöchiger Lieferrhythmus dienen zur Sicherung vor unliebsamen Überraschungen
und vor folgenschweren Entwicklungen.
Rückmeldungen -- ich weiß, wo wir stehen
Agile Projekt-Teams verwenden eine ganze Reihe von Rückmeldungs-Mechanismen,
die den Beteiligten zeigen, wo man selbst und wo das Team steht:
wieder sind es die Unit Tests;
regelmäßig lauffähige Software;
zeitnahe Demonstrationen von abgeschlossenen User Stories vor dem Kunden;
automatisierte Abnahme-Tests;
regelmäßig einsatzfähige Software;
Rückmeldungen von den Anwendern der frühen Lieferungen.
Es gibt kein "Wandern im Dunklen mit verbundenen Augen", sondern jeder weiß,
daß es fühlbaren Fortschritt gibt,
daß die Richtung des Fortschritts stimmt,
mit welcher Geschwindigkeit man vorankommt
und was das für das Ankommen am Projektende bedeutet.
Erfolgs-Messung -- ich weiß, wie es im Projekt steht
Bei Software-Projekten ist es nun einmal so: nur der Kunde definiert am Ende(!),
ob das Projekt ein Erfolg war oder nicht. Nur sehr theoretisch gibt es so etwas
wie "moralische Sieger". Eigentlich schade für die "Wasserfaller": der (echte)
Erfolg in ihren Projekten wird i.d.R. nur einmal gemessen --
am Projektende. Und da ist eine
Korrektur nur noch sehr schmerzhaft möglich (wenn überhaupt; siehe Toll-Collect).
Aber wir wollen doch Erfolg haben -- und Agile Teams holen sich ihre Erfolgs-Meldungen
wie tägliche Vitamin-Pillen durch regelmäßig Messungen: die Unit Tests sind grün;
die Abnahme-Tests laufen;
den Kunden/Anwendern gefällt, was wir ihnen mehrmals wöchentlich zeigen;
die automatischen Builds laufen fehlerfrei durch und auch das Auto-Deployment
funktioniert;
ah, und die Anwender draußen sind zufrieden (und sagen uns das bei unseren regelmäßigen
Treffen auch).
Anerkennung -- meine Leistung wird bemerkt
Mitglieder in Agilen Projekt-Teams sind sichtbar -- man kennt sich: die Kunden,
die Anwender, die Entwickler, der Projekt-Coach. Anerkennung (aber auch Kritik)
fließt direkt und jeder nimmt daran teil.
Wer hört das nicht gern: "das funktioniert genau so, wie ich mir das vorgestellt habe --
gut gemacht!" Agile Teams bekommen das regelmäßig und es kein Trick, sondern
ernst gemeint. Falls Kritik notwendig ist, dann kommt sie in kleinen Portionen;
durch den engen Kontakt zwischen Entwicklern und Kunden handelt es sich oft
nur um kleine Anpassungs-Wünsche; etwa: "falls Ihr das noch so-und-so abändert, dann
habe ich genau das, was ich brauche". In kleinen Portionen ist das leicht
zu verdauen und mit einer schnellen Reaktionszeit für die Änderung ist alles
wieder im Lot.
Spaß -- ich empfinde Freude bei der Arbeit
Bei all den positiven Aspekten bei Agilen Projekten geht es den Beteiligten gut --
sie fühlen sich wohl. Das heißt ja wirklich nicht, daß man eine lustige
Gesellschaft ist, die nur Späße macht. Nein, man arbeitet konzentriert,
zielorientiert, ergebnisorientiert, qualitätsbewußt.
Das erinnert mich an eine Aussage von Dierck König in seiner Keynote beim
XPedition-Training 2001 in Karlsruhe (frei zitiert): "es ist wichtig,
den Unterschied zwischen 'Job' und 'Beruf' zu kennen -- und wir sollten
danach streben, einen 'Beruf' auszuüben!" Ich denke, Agile Entwickler
üben einen Beruf aus.
Sicherheitsmotive -- Schutz und Ordnung
Egal ob Scrum, XP, Crystal: alle wissen ein "Nachhaltiges Tempo" als wichtiges
Element des Prozesses zu schätzen. Dieses Element bringt zum Ausdruck,
daß uns die Gesundheit der Beteiligten wichtig ist. Wie wollen nicht
für einen kurzfristigen "Erfolg" das langfristige Ziel verpassen müssen.
Die Spielregeln in einem Agilen Projekt sorgen dafür, daß in Krisen-Situationen
eher das Nachhaltige Tempo im Vordergrund steht (und damit die Gesundheit
der Beteiligten) als der zweifelhafte Versuch, einen Plan stur einzuhalten
(und damit den Grundstein für die nächste Krise zu legen).
Und auch die Agilen Vorgehensweisen haben einen Prozeß-Rahmen, innerhalb
dem sich die Entwickler bewegen, den sie nutzen und der sie unterstützt.
Seitenanfang
Zusammenfassung
Meine Ausführungen mögen für außenstehende phantastisch (im negativen Sinne)
klingen. Aber man muß es wohl erlebt haben.
Aus meiner praktischen Erfahrung mit der Durchführung Agiler Projekte
(in der Kombination Scrum + eXtreme Programming)
kann ich nur feststellen:
Agiles Vorgehen in Software-Projekten läßt Motivation und Zufriedenheit der Entwickler
(aber auch die der Kunden) deutlich steigen.
Das sollte eigentlich auch bei "traditionellen" Organisationen die Bereitschaft bringen,
dieser Vorgehensweise eine echte Chance zu geben.
Die Mitarbeiter und die Kunden werden es danken!
Seitenanfang
Verweise
Folgende Quellen wurden zum Teil zitiert bzw. werden empfohlen zur Vertiefung und
für weiterführende Informationen:
Seitenanfang
|
