Breaking Info: Voraussetzungen für Extreme Programming
Welche Voraussetzungen machen Extreme Programming überhaupt möglich? Die Methoden und Regeln bei dieser Agilen Methode sind ja tatsächliche "extrem". Deshalb wurde ich in den vergagenen Tagen immer wieder mit der Aussage konfrontiert: "Das ist a schön und nett - funktioniert aber nur im Labor und bei amerikanischen Buch-Autoren. Ich kann davon gar nichts lernen."
Ich halte eine solche pauschale Ablehnung für falsch und möchte deshalb darauf eingehen - bevor ich mich mit wie versprochen damit beschäftige, was wir "normalen" Projektmanager von Extreme Programming lernen können. Es gibt in den zahlreichen Unterlagen im Internet zu XP einige sehr konkret genannte Rahmenbedingungen, die selbst begeisterte Extreme Programmer als Voraussetzung für das Gelingen eines XP-Projektes bezeichnen:
- Die richtige Firmenkultur. Mit Agilen Methoden werden Sie nur in den Unternehmen eine Chance haben, in denen die Mitarbeiter (und die Unternehmensführung!) aufgeschlossen sind und unkonventionellen Vorgehensweisen eine Chance geben. Sie glauben, weil Sie in einer Internet-Company arbeiten, ist das wohl der Fall? Nun, ich kenne eine Menge super-spießiger New-Economy-Manager. Seien Sie sich also nie sicher…
- Hohe Sozialkompetenz. Liebe Entwickler, das ist nicht böse gemeint. Aber eine ganze Menge Techniker sind einfach nicht teamfähig. Sie können (und wollen?) in der Gemeinschaft ihre Stärken nicht aktivieren - und manche behindern damit dann sogar das ganze Team bei der Arbeit. Der Management-Trainer Fredmund Malik betont immer wieder, dass die ganz großen Werke (z.B. Beethovens 9. Symphonie oder Maradonnas Super-Tore) von Einzelpersonen geschaffen wurden und nicht von Teams.
- Kleine Teams. Mein Lieblings-Kommentator hier im Weblog, Nicolas Kübler, hat es beim letzten XP-Eintrag schon dazu geschrieben. Die maximale XP-Team-Stärke liegt bei 10 bis 15 Entwicklern. Sind es mehr, wird die Kommunikation leiden - und damit die gesamte Aufstellung.
- Geringes Risiko. In einem High-Risk-Proekt, bei dem in der Risiko-Analyse womöglich sogar von "politischen Rahmenbedingungen" die Rede ist, sollte der Proektleiter sich und das Team absichern und traditionell mit einer detaillierten Anforderung vorgehen.
- Gewaltenteilung. Das gefällt mir besonders gut. Von beiden Seiten muss akzeptiert werden, dass der Kunde die Business-Entscheidungen trifft und die Entwickler für die Technik zuständig sind. Hat z.B. der Kunde dezidierte technische Phantasien oder das Team möchte eigentlich ein anderes Produkt entwickeln, sollte man von XP die Finger lassen.
- Nähe. Das Team und der Kunde müssen nah beieinander sitzen. Es ist nicht unbedingt notwendig, dass alle ständig in einem Flur zu finden sind. Aber die enge Kommunikation funktioniert nun mal nur direkt.
- Erfahrung. Mit einem Haufen Berufseinsteiger ist XP wohl sehr riskant. (wobei ich der Meinung bin, dass das schon auch gut gehen kann.)
- Technische Grundlagen. Die Teams arbeiten auf funktionierenden technischen Systemen, die zu jedem Zeitpunkt und an jedem Ort automatisierte Tests in der Entwicklungsumgebung zulassen.
So, ich bin gespannt, ob ich hierauf Wiederspruch erhalte. Natürlich freue ich mich auch über weitere notwendige Rahmenbedingungen. 
2 Responses to “Breaking Info: Voraussetzungen für Extreme Programming”
By Nicolas Kübler on Feb 6, 2006
Guess who’s back…sehr sehr schön, vor allem die persönlichen Kommentare zu den ersten beiden Listenpunkte
Die richtige Firmenkultur kann ich nur bestätigen, es gibt sehr viele Firmen, die zwar sagen, sie würden XP nutzen, aber betonen dann kleine Abstriche, wie keine große Nähe zum Kunden, kein Pairprogramming, keine 100% Tests etc… wo bleibt da XP?
Teamarbeit ist sehr wichtig, gerade Pairprogramming erfordert dies, dass 2 Personen an einer Workstation arbeiten, da muss man sich gegenseitig vertrauen können und für Kritik offen sein.
Ich möchte hier gleich etwas zum Punkt über die Erfahrung sagen. In XP ist es immer wichtig, dass ein Experte neben Neulingen sitzt, die lernen dann automatisch damit umzugehen. Bei völlig neuen Teams ist das natürlich etwas völlig anderes, da muss man eben versuchen jeweils einen Erfahrenen mit einem Frischen zusammen zu bringen. Wichtig ist auch der stetige Wechsel, so dass keine Wissensträger entstehen, die dann das Projekt in Gefahr bringen, wenn sie das Team verlassen.
Zum letzten Punkt: Generell gilt, dass ein Code erst abgegeben wird, wenn dieser 100% getestet wurde und erst dann wird er in das Gesamtprodukt integriert, d.h. unfertige Teile werden nie in einem Release veröffentlicht. (hier könnte man vielleicht beim nächsten Mal auch die Terminplanung ansprechen … :))
Abschließend über Nähe: In sog. “Collocated Teams” gibt es die “50 Foot Rule of Collaboration”, die besagt:
Intimate = 0-50 cm
Personal = 50 cm - 4 m
Social = 4 m - 12 m
Public = 12 m - 25 m
Was geben nun diese Werte an? Sie entsprechen der Art und Häufigkeit der Kommunikation, während beim ersten eine andauernde Kommunikation besteht, ist letztere schon eher selten. Bei weiter als 25 m befindet sich wohl die Person in anderen Gebäuden oder Stockwerken, hier wird oft nur bei Bedarf Kontakt aufgebaut.
Bei 10-15 Mitarbeitern, wobei immer 2 einen Arbeitsplatz besetzen, sollte man möglichst versuchen diese in einem Flur zu platzieren.
Noch ein Gedanke zu 10-15 Mitarbeiter, ich weiß nicht mehr, ob es Kent Back selbst war der die These aufstellte, aber es gibt schon Möglichkeiten diese Grenze zu überschreiten, man muss dann natürlich viele Experten haben die Neuline zu sich nehmen, so würde man sogar zu 40 Mann Teams kommen, allerdings stelle ich mir die Kommunikation recht anstrengend vor und auch Meetings werden problematisch, da hier sicher nicht mehr das ganze Team einbezogen werden kann, alleine wenn man schon an das tägliche Stand up Meeting denkt!
By Benutzer on Mrz 6, 2006
…wir arbeiten eigentlich ziemlich gut mit xp-methoden, allerdings
- in sehr kleinen teams
- in einem komplette neu gegründeten unternehmen
- unter hohem zeitdruck, in dem jedes auch noch so kleine ergebnis zählt.
die gefahren die ich sehe, sind
- testzyklen: tester gewöhnen sich auch leicht eine freestylehaltung an, vor allem retests werden gern ausgelassen, gesamttests finden nur selten statt
- dehnung des gesamtzeitplans: xp verleitet zum ewigen “habs gleich”, dem ich als projektmanager schon manchmal streng begegnen muss
- auf keinen fall einsteiger verwenden - die gewöhnen sich nur was schlechtes an
- keinen zu engen kontakt zum kunden (oder zumindest klar inhaltliche abgrenzung): die gewöhnen sich sonst auch nur an, dass alles schnell mal ausprobiert wird (…hast du mal kurz zeit), und abgesehen davon, dass zeit verschwendet wird, entstehen nebenprojekte, die am projektleiter vorbeigeschleust werden
- 2 an einem arbeitsplatz lasse ich nur eingeschränkt zu - dass ist nur in gewissen phasen produktiv, in anderen nervt es ganz einfach (vor allem die anderen)