|
Einleitung
(eigentlich wollte ich als Titel "Back to the Roots" wählen;
aber das wäre nicht korrekt: trotz der starken Veränderung, die "Agil" bei mir selbst
bewirkt hat, bin ich doch nicht (ganz) zum Programmieren zurückgekehrt ... leider)
Seit ca. 3 Jahren beschäftige ich mich stark mit Agilen Vorgehensweisen in der
Software Entwicklung: ausgehend von eXtreme Programming
([01], [02]),
ergänzt durch Scrum
([03], [04])
und wesentlich beeinflußt durch die Lean-Gedanken von Mary Poppendieck
([05], [06]).
Der wachsende Frust darüber, daß trotz ständiger "Verbesserung" und Verfeinerung der
klassischen Vorgehensweise (=Wasserfall) keine besseren Projekt-Ergebnisse
erreicht wurden,
mußte zwangsläufig zu "Agil" führen.
Bei aller Freude und Begeisterung angesichts der vielen Erfolge, die wir in diesen
letzten 3 Jahren erleben durften, habe ich eine wesentliche Veränderung bei
mir selbst (beinahe) übersehen!
Erst eine aktuelle Diskussion unter der Überschrift "Extreme Leadership" in der
Yahoo-Group 'extremeprogramming' ([07], ab 15. Februar 2005)
hat bei mir eine Reihe von Gedanken über mein eigenes Verhalten in Projekten ausgelöst:
- wie hat eigentlich "Agil" mich selbst als 'Projekt-Leiter' verändert?
- wie sehe ich heute meine Rolle in einem Software-Projekt,
wie war das vor 10 Jahren?
- was ist heute für mich persönlich wichtig in Projekten?
- wie stehe ich heute zu "Projekt-Management"?
Darüber möchte ich hier berichten.
Aber lassen Sie mich zuerst kurz zurückblicken ...
Seitenanfang
Erkennen
Mit guter theoretischer Basis, aber nur vage vorbereitet auf ein Leben in
Projekten wurde ich als Informatiker von meiner Uni ins Berufsleben entlassen.
Bald war erkannt, daß zum Thema "Projekte" mehr Grundlagen notwendig waren.
Immerhin hatte man uns wenigstens den Anfang des Roten Fadens mit in die Hand
gegeben: jedes Projekt beginnt mit einer gründlichen Analyse!
In einem Firmenumfeld, in dem Software nicht das Produkt an sich ist, sondern
zur Unterstützung der Firmenabläufe (inklusive Fertigungsbereich) benötigt wird,
waren die wichtigen Personen in der Forschung, in der Technik und vor
allem in der Fertigung zu finden. Die meisten dieser Größen waren Ingenieure,
die uns Informatikern "ingenieur-mäßiges Vorgehen" vorlebten.
Und sie begannen ihre (wichtigen) Arbeiten mit einer gründlichen Analyse!
Da war sie, die Bestätigung: die Analyse war tatsächliche der richtige
Anfang unseres Roten Fadens. Und mehr noch: wir erkannten mit Staunen, daß
unser Wasserfall-Modell eigentlich nichts anders war als
"ingenieur-mäßiges Vorgehen".
Von da an war der Weg eindeutig vorgegeben: eine gründlichen Planung sichert
jeden Projekt-Erfolg! Und stellt sich der Projekt-Erfolg nicht wie geplant
ein, so ist das ein Zeichen dafür, daß die Planung nicht gründlich genug war.
Etwa bei diesem Grad an Erkenntnis trennen sich wohl zwei Wege: man bleibt
Software-Entwickler, oder aber man konzentriert sich auf die Projekt-Planung
und -Abwicklung. Der zweite Weg ist der hin zum Management -- und wer wollte
nicht gern "Manager" sein.
Auf dem zweiten Weg war schnell erkannt: hier genießt man mehr Ansehen,
hier ist man sichtbarer und vor allem: hier ist man "prozeß-verantwortlich";
hier kann (nein muß) man wie ehemals Frederick Taylor den Prozeß "Projekt"
unter die Lupe nehmen, zerlegen, formalisieren, beschreiben und
Arbeiten verteilen.
Aber eines mußten wir notgedrungen auch erkennen: trotz des
planungs-schwergewichtigen Vorgehensmodells, in das bereits alle
Erfahrungen unserer vorangegangenen Projekte eingeflossen waren, wurden
wir vom Ergebnis her nicht wirklich besser ...
... aber was sollten wir noch tun: V-Modell ([08]),
PMBOK® ([09]), ISO-9000 ([10])
-- alle sagten uns doch, daß wir auf dem richtigen Weg waren, oder?
Seitenanfang
Verstehen
Eines war schon bemerkenswert: die meisten Beschreibungen zu unserem
Wasserfall-Vorgehen beschäftigten sich ausschließlich mit der
Management-Seite der Projekt-Abwicklung.
Über die eigentliche Software-Entwicklungs-Arbeit waren die Aussagen
(wenn überhaupt) nur sehr oberflächlich.
Jeder Projekt-Manager kannte ja die dafür notwendige Regel:
er benötigt "gute" Programmierer -- aber was bedeutet "gut" ...
mir wurde langsam bewußt: ich weiß diese Frage nicht mehr wirklich
zu beantworten.
Ja, und wo ich schon dabei war zu hinterfragen: was ist überhaupt von einer
Beschreibung zu halten, die bei so viel hinein gesteckter Energie so wenig
Erfolg zuläßt, aber umso mehr Frust produziert?
Meine letzte Anstrengung im Schatten des Wasserfalls war die Ausarbeitung
einer kompletten Anleitung zu einem verbesserten Risiko-Management-Prozeß
-- als konkrete Umsetzung des "Continuous Risk Management Guidebook" von SEI/CMU
([11]) ...
Ich begann zu ahnen (nein, noch nicht zu verstehen), daß es so ähnlich sein muß
wie in Paul Watzlawick's "Anleitung zum Unglücklichsein" mit den Glücksbringern:
wer fest an die Wirkung von Glücksbringern glaubt, den bringt erlebtes Pech
höchstens zu der Einsicht "ich habe nur zu wenige Glücksbringer"
-- na dann: viel Glück!
Von diesem Zeitpunkt an war es nur mehr ein kleines Stück und der Artikel von
Jens Coldewey ([12]) stieß sozusagen die Türe zum Agilen
Vorgehen auf. Und Martin Fowler's kompakte Übersicht zu den wichtigsten
Agilen Vorgehens-Modellen ([13]) hat mich endgültig
durch diese Türe treten lassen.
Jetzt hatte ich verstanden: wir hatten es nicht (nur) mit schwierigen Projekten
zu tun, sondern unsere Vorgehensweise war ein wesentlicher Teil des Problems.
Seitenanfang
Entscheiden
Wenn wir wirklich etwas für den nachhaltigen Erfolg in unseren
Projekten tun wollten, dann mußten wir eine grundsätzliche Alternative
zum Wasserfall etablieren.
"Grundsätzlich" bedeutet: wir müssen mutig einen Paradigmen-Wechsel einleiten,
denn "Agil" heißt eben nicht nur "eine Reihe von Mini-Wasserfällen".
Ein solcher Wechsel ist nicht in allen Organisationen einfach zu
vollziehen. Insbesondere in Organisationen, in denen Deming's
Qualitäts-Philosophie nur soweit Eingang gefunden hat, daß alle Prozesse
dokumentiert sein müssen (in einer solchen Organisation ist man froh,
mit seiner Prozeß-Dokumentation endlich den Genehmigungs-Prozeß
geschafft zu haben -- dann nur nichts mehr ändern ...).
Durch Workshops mit einigen Schlüssel-Kunden ("Was stört Sie an unserer Arbeit?")
und mit den Software-Entwicklern ("Was stört Euch an Eurer Arbeit?")
wurden die Argumente für eine solch gravierende Änderung gesammelt.
Interessant: beide (Kunden und Entwickler) hatten im Top-Bereich die selben
Problem-Punkte identifiziert.
Durch eine Aufstellung einer Kriterien-Liste für den "idealen"
Software-Entwicklungs-Prozeß bei uns und eine konkrete Bewertung der
einzelnen Modelle (einschließlich Wasserfall) wurde die Entscheidung
untermauert und abgesichert.
Die Entscheidung: Crystal Clear, XP und Scrum erreichen jeweils eine
erstaunliche Übereinstimmung mit unserer Ideal-Vorstellung.
Wir wählen als Startpunkt XP (eXtreme Programming) und betten diese
Vorgehensweise durch Dekoration mit Scrum in unser
organisatorische Umfeld ein.
(wohl dem, der an dieser Stelle der Veränderung einen vorgesetzten Manager
hat, der an den gesunden Menschenverstand aller seiner Mitarbeiter glaubt
und auch mutige Vorschläge zuläßt und unterstützt!!!)
Seitenanfang
Handeln
Was bedeutet "handeln" an dieser Stelle?
Erst einmal heißt das aus meiner Sicht: die bisherigen Manager in Projekten
müssen ihren ganzen Mut zusammennehmen (XP-Value Nr.4). Sie werden ihr
bisheriges Rollen-Verständnis und ihre Verhaltensweisen in Projekten
gründlich ändern müssen. Mit dieser Veränderung scheint erst einmal
ihre Wichtigkeit (für das Projekt) nicht mehr in dem Maße nach außen
sichtbar zu sein, wie das in der Vergangenheit der Fall war.
Für die Software-Entwickler ist die Hürde wesentlich geringer: sie werden
ganz offensichtlich mit ihren neuen Rollen wesentlich aufgewertet;
lediglich die neue Form der Disziplin bzgl. der Arbeitsweisen erfordert eine
gewisse Achtsamkeit.
Mit Selbst-Studium, Training, gezielter Beratung und vor allem viel
gegenseitiger Unterstützung der "infizierten" Projekt-Manager bereiten wir
uns (kurz) auf das erste Pilot-Projekt vor.
Die Skepsis bei den Kunden ist groß. Zu weit reicht ihre Erfahrung mit
Informatik-Projekten zurück und sie fragen sich, ob es sein wird wie immer:
zu langsam, zu spät, zu teuer ... ?
Hier hilft nur eines: mutig gehandelt und mit schnellem Feedback
(d.h. kurzes Release mit Iterationen und mit viel direkter Kommunikation)
zeigen, daß wir tatsächlich anders arbeiten als früher.
Die Kunden danken es uns nach Iteration 1 mit ihrem Staunen und ab
Iteration 2 (=erste Lieferung) mit ihrer Begeisterung.
Seither konnten wir diesen Erfolg in jedem unserer Agilen Projekte
wiederholen und die Kunden zufrieden stellen.
Trotzdem tun wir uns schwer, diese Vorgehensweise noch breiter einzusetzen:
das hohe Maß an notwendiger Veränderung insbesondere im Management-Bereich
scheint aus meiner Sicht das größte Hindernis zu sein.
Seitenanfang
Verändert
Abgesehen von meiner für alle sichtbaren/spürbaren/hörbaren Begeisterung für
Agiles Vorgehen hat sich mein Verhalten in Projekten sehr stark verändert.
Und mir sehr wohl bewußt, daß genau diese Veränderung das größte
Hindernis für eine flächendeckende Verbreitung Agilen Vorgehens darstellt:
viele Manager haben ihren Blick "nach oben" gerichtet, nämlich dorthin,
wo sie persönlich hin streben.
Eine kurze und sicher nicht vollständige Liste meiner persönlichen Veränderungen
durch Agiles Vorgehen könnte z.B. so aussehen:
- nur noch kleine Projekte in Serie:
schwierig, denn je größer das Projekt (Zeit, Budget, Personal), desto
größer ist das Ansehen des Projekt-Leiters/-Managers;
in diesem Sinne ist es natürlich "negativ", wenn man jetzt
mit kleinen Teams, in weniger Zeit, mit bescheidenen Mitteln
mehr abliefert ... war eben nur ein "kleines" Projekt;
- das Innerste nach außen kehren: Programmierung ist wichtig:
ich lege heute sehr bewußt einen Schwerpunkt auf die Arbeitsweisen
der Software-Entwickler: von den trainierten und eingesetzten
Praktiken (Pair Programming, TDD, Refactoring, Continuous Integration,
Automatic Builds, etc.) bis hin zum engen und unmittelbaren Kontakt
mit den Kunden (ohne Umweg über die Projekt-Leitung);
- die Kunden kennen die Entwickler besser als mich:
früher war ich einer der wenigen Kanäle, durch die Informationen
vom Kunden zum Projekt-Team geflossen sind;
heute ist mindestens das Entwickler-Kernteam bereits in der
Explorations-Phase mit am Tisch und stellt die wirklich schlauen Fragen;
ja, so ist das: wenn das Spiel beginnt, ist der Trainer nicht auf
dem Spielfeld ...
- "gesund bleiben":
meine Teams machen keine Überstunden mehr;
das stößt bei den "anderen" Managern auf völliges Unverständnis:
man könnte doch noch viel mehr "herausholen" wo wir doch so viel Arbeit haben;
und sind wir doch ehrlich: ein bißchen Druck hat noch nie geschadet ...
- realistische Ziele:
die Release- und Iterations-Ziele werden direkt zwischen Kunden
und Software-Entwicklern festgelegt;
Basis ist die überstunden-freie Produktivität im bisherigen Projekt-Verlauf;
kein "motivierender Druck", aber immer bereit, eine Änderung im Plan sofort
als Wettbewerbs-Vorteil umzusetzen ...
wenn es für den Kunden wichtig genug ist;
- Spielräume sind wichtig:
diesen Ausdruck leihe ich mir von Tom DeMarco ([15]):
da wir jetzt in den Projekten leichtgewichtig marschieren, bleibt uns/mir
durchaus Zeit, den Kopf zu heben und nach Verbesserungs-Möglichkeiten im
laufenden Projekt Ausschau zu halten;
ich persönlich halte aktiv Ausschau, motiviere meine Team-Mitglieder dazu
und initiiere manches Training während(!) des Projekts;
- Dienstleister im Projekt:
wir haben unsere regelmäßigen Retrospektiven (nach Iteration und Release);
aber eigentlich höre ich immer in meine Teams hinein, um zu spüren,
wie ich ihre Arbeitsumgebung noch produktiver gestalten kann;
in der Regel wird ein gut geführtes Team ohnehin sofort mitteilen,
falls etwas verändert werden sollte ...
- ich erschrecke nicht mehr, wenn ich unverhofft einen Kunden treffe:
früher war das so: nach dem x-ten "Change Request" und der n-ten
Termin-Verschiebung war die Stimmung zum Kunden hin nicht mehr so toll;
natürlich war ich im "Recht" (Festpreis-Vertrag!), aber der Kunde
hatte kaum noch Vertrauen ...
- ... mir ist es schon lange nicht mehr so gut gegangen ... :-)
ja wirklich: die Arbeit macht wieder Spaß, mehr noch als ganz am Anfang,
als wir als frische Informatiker mit viel Tatendrang unser Arbeitsleben
begannen;
Das und sicher noch mehr hat sich verändert. Die größte Veränderung sehe ich
jedoch in den Projekt-Teams, die mit Freude und dem damit verbundenen Schwung
täglich ans Werk gehen und sich regelmäßig durch ihre Lieferungen die
verdiente Anerkennung des Kunden holen.
Dazu paßt eine Stelle aus der anfangs erwähnten Diskussion über
"Extreme Leadership" ([07]):
"... The officer knows full well that winning must become a habbit, ...".
Seitenanfang
Zusammenfassung
Eine Veränderung vom klassischen Wasserfall hin zu Agiler Vorgehensweise
belohnt jeden, der sich darauf einläßt mit Erfolg "in der Sache"
(d.h. im Projekt).
In den allgemein vorherrschenden Management-Kulturen dürfte man aber
schnell auf Widerstand stoßen: dieses Agile Vorgehen fordert die Manager
zu sehr auf, vieles von ihrer angestammten Macht und Kontrolle
abzugeben.
Vielleicht ist das der Grund, warum Ken Schwaber in seinem persönlichen
Blick in die Zukunft zum Jahreswechsel 2004/2005 meint:
"2. Only 1/3 of the companies that develop software will adopt Agile
because it is very hard to implement." ([16], Seite 48)
(zur Beruhigung des geneigten Lesers sei hier auch die nächste Aussage von
Ken Schwaber an gleicher Stelle zitiert:
"3. 2/3 of the companies that develop software will outsource their work
to companies that use Agile.")
Seitenanfang
Verweise
Folgende Quellen wurden zum Teil zitiert bzw. werden empfohlen zur Vertiefung und
für weiterführende Informationen:
Seitenanfang
|
