|
Einleitung
Mitte Februar 2005 hat mich ein Kollege für 2 Tage besucht, um mit mir zu besprechen,
welche Möglichkeiten ihm eine Agile Vorgehensweise in seinem anstehenden Projekt
bieten könnte.
Er kommt aus unserem amerikanischen Standort und soll in unserem zweiten Werk
hier in Deutschland ein Software-Projekt abwickeln.
Bisher hat er von Agilen Vorgehensweisen nur gehört: er weiß, daß wir hier am Standort
mehr und mehr Projekt "agil" abwickeln, und daß wir damit immer erfolgreich waren.
Sein Interesse ist stark geweckt ...
Während unserer Gespräche in diesen beiden Tagen fiel mir auf,
daß wir sehr oft über Projekt-Probleme sprachen
und wie denn die Agile Lösung dazu aussehen könnte.
Immer wieder mußte ich darauf hinweisen, daß Agiles Vorgehen (= (Scrum + XP)
in unserem Fall ) nicht an sich die Lösung ist,
sondern vielmehr "nur" ein guter Weg zur Lösung.
Wie dieser letzte Satz zu verstehen ist, möchte ich in diesem Online-Artikel beschreiben.
(für Ihre Rückmeldung zu diesem Artikel erreichen Sie mich immer per Email an
h.franzke@t-online.de)
Seitenanfang
"Bad Customer!?"
Wir hatten uns für unsere Gespräche sozusagen einen Agilen Roten Faden vorgenommen:
wir wollten als erstes einen Überblick über das Ganze bekommen
(eine "Exploration" auf 10.000m Flughöhe), um später auf die
wichtigsten Punkte aus Sicht meines Kollegen detailierter (Flughöhe 1.000m) einzugehen
-- und natürlich war die ganze Aktion "timeboxed".
Mein Kollege war überrascht über die kurzen Start-Phasen in unseren Agilen Projekten:
- kurze Einarbeitung in die Fach-Domäne um die Sprache zu kennen (ca. 1 Woche);
- ca. 2-wöchige "Exploration" um die groben Anforderungen festzuhalten
(Flughöhe 10.000m, Projekt-Backlog mit User Stories);
- anschließend sofort die erste Release-Planung (bzw. Sprint-Planung);
- wir teilen ein Release auch noch in Iterationen (XP-Ansatz, Flughöhe 1.000m) ...
- ... und schon startet das Team mit der "wirklichen" Arbeit!
Ich konnte deutlich spüren: das erzeugt Angst! So wenig Wissen, so wenig Planung,
so viel Ungewißheit, so viel notwendiges Vertrauen zwischen den Beteiligten
-- so wenig Absicherung!
Wir waren auf unserem 10.000m-Flug noch nicht lange unterwegs,
da kommt die erste skeptische Frage:
"What if you have a bad customer?"
Irgendwie war ich überrascht: hatte ich doch mit Fragen gerechnet wie
"was ist eine User Story?", "wie lange dauert die Exploration wirklich?",
also Fragen zur eigentlichen Umsetzung.
Nein, mein Kollege wollte wissen, was ich mit einem "bad customer" mache.
In meiner Überraschung platzte ich mit einer Gegenfrage heraus (was nicht nett war,
mir aber etwas Zeit gab):
"naja, was machst Du mit Deinem schlechten Kunden in einem Wasserfall-Projekt?".
Seine Antwort (smiling): "I let him sign the Requirements Document."
Ich hake nach: "Und -- löst das Dein Problem, wird das Projekt damit erfolgreich(er)?"
"No, not really ..."
Wir wissen beide aus Erfahrung, daß ein "bad customer" im klassischen (Wasser-) Fall
seine Böswilligkeit (oder das, was die Entwickler dafür halten)
erst am Ende des Projekts zeigen kann; vorher beugt er sich allen
Formalismen des Projekts und hofft nur, daß endlich begonnen wird.
Mein Kollege und ich haben uns nicht damit beschäftigt,
welche Arten von "Böswilligkeiten" wir kennen
(z.B. "der Kunde ändert ständig seine Meinung"), sondern haben uns etwas allgemeiner
über "Probleme im Projekt" unterhalten.
Seitenanfang
Kopf in den Sand
Aus der (neuen) Perspektive der Agilität heraus betrachtet erkenne ich mehr und mehr,
daß die klassischen Vorgehensweisen meist nur eines bewirken: man schiebt alle
Probleme vor sich her Richtung Projekt-Ende.
Wir hoffen, daß wir durch den Zeitgewinn auch eine Lösung gewinnen ... aber wir stecken
eigentlich nur den Kopf in den Sand ... und die Probleme können reifen ...
In dieser Vogel-Strauß-Taktik werden wir auch noch bestärkt, wenn wir die Projekt-Arbeit
stark formalisieren und vorschreiben: Anforderungs-Dokumente, natürlich unterschrieben
und freigegeben; vertragliche Festschreibung der Leistungen (am besten gleich
"Fest-Preis"); Prozeß zur Änderungs-Kontrolle; u.v.m.
Für mich ist das mittlerweile reine Absicherungs-Technik,
um in der Großen Abrechnung am Projekt-Ende gut aus der Sache heraus zu kommen,
d.h. die Schuld am Scheitern des Projekts jemand anderem zuschieben zu können.
All das bewirkt nur, daß wir relativ lange Zeit im Projekt relativ sicher dahinschwimmen
und hoffen, daß wir nicht auf einen Wasserfall zutreiben ... Vogel-Strauß!
Fazit: unser klassisches Vorgehen hilft uns bei der Absicherung ("aber Sie haben doch
damals das Anforderungs-Dokument geprüft und abgezeichnet!") und nur äußerst selten
bei der Lösung der Probleme im Projekt;
oder haben Sie schon einmal jemanden Schwierigkeiten bekommen sehen, weil er zu viel
geplant hat?
"Okay, but what are the solutions provided by Agile???"
Seitenanfang
Augen auf!
Ich mußte zugeben: "Nein, Agiles Vorgehen wird Dir nicht sagen, was Du
mit einem "bad customer" machen mußt, sorry!"
Aber ... unser Agiles Vorgehen deckt sofort auf, falls Du ein Problem mit Deinem
Kunden hast: "no way", daß Du Dich durch Analyse, Planung, Design, Erstellung,
vielleicht sogar Abnahme-Test (gemäß 2 Jahre altem Test-Plan) schleichst, nur
um am Ende festzustellen, daß das Projekt-Ergebnis nicht (voll) brauchbar ist.
Wie ein Minensuch-Boot mit allerlei Sensorik ausgerüstet ist, um Minen zu finden,
so deckt auch Agiles Vorgehen Schwächen und Probleme im Projekt schonungslos und
ohne Zeitverzögerung auf ([01]).
Ein anderes Bild, das den Sachverhalt vielleicht sogar noch besser beschreibt
verwendet William C. Byham
("ZACK", [02]):
ein böser Mutter-Drache hinterläßt überall seine Drachen-Eier; gut versteckt
können Sie reifen, schlüpfen, heranwachsen und als erwachsener Drache endlich
überall Feuer legen.
Was ich sagen will: nicht, daß es in Agilen Projekten keine Drachen-Eier mehr gibt.
Natürlich gibt es die Eier auch hier.
Aber: die Agile Vorgehensweise (oder besser Verhaltensweise) sorgt dafür, daß
die Drachen-Eier entdeckt werden, nicht reifen können und sich letztendlich
nicht zu einem ausgewachsenen und wild feuerspeienden Drachen entwickeln werden.
Das wichtigste in einem (Software-) Projekt ist es wohl, Schwierigkeiten und Probleme
früh zu erkennen und sie eben auch früh aus dem Weg zu räumen.
Ein Agiles Projekt stoppt sofort, falls ein Problem bestehen bleibt. In bester
Just-In-Time-Manier muß man sich sofort damit auseinandersetzen und man hat keine Chance,
es auf die lange Bank zu schieben (vergleichen Sie z.B. die Probleme der
Diesel-Einspritzpumpen bei den Automobil Herstellern Anfang dieses Jahres).
"Augen zu!" gibt es nicht mehr. Es heißt jetzt "Augen auf!" und der Wahrheit sofort
in die Augen sehen.
Seitenanfang
Schmerzvolle Erkenntnis
An diesem Punkt kann ich meinem Kollegen klar machen,
daß der Agile Weg nicht notwendigerweise zu einer direkten Lösung von Problemen
im Projekt führt. Aber sicher führt der Agile Weg zu schneller Erkenntnis:
ja, ich habe Probleme in der Zusammenarbeit mit dem Kunden;
ja, wir beherrschen diese neue Technologie einfach noch nicht;
ja, unsere Entwickler werden viel zu oft gestört und können nicht ausreichend am Projekt
arbeiten; u.v.m.
Und solch ungeschminkte Wahrheiten können sehr schmerzvoll sein ...
... ja, Erkenntnis kann schmerzvoll sein, keine Frage.
Nur, wie groß wird der Schmerz erst sein,
wenn viele Monate vergangen sind, viele Stunden investiert worden sind, viel Geld
ausgegeben worden ist, nichts vernünftiges erreicht worden ist,
der Kunde unzufrieden ist und die Entwickler frustriert sind?
So schmerzvoll die frühe Erkenntnis auch immer sein mag, so heilsam wird sie letztendlich
doch sein:
entweder es gibt eine Lösung für das Problem, dann sollten wir sie schnell anwenden;
oder aber es gibt einfach keinen Lösung: dann laßt uns den Schaden begrenzen und
aufhören ...
(okay, ich gehe davon aus, daß Sie nicht in einer dieser Organisationen leben (müssen),
von denen z.B. Edward Yourdon [[04]] oder
Tom DeMarco [[05]] berichten:
dort ist es besser, es versucht zu haben und gescheitert zu sein,
als der Wahrheit ins Gesicht zu sehen und "nein" zu sagen)
Seitenanfang
Agile Sensorik
Aufgrund meiner Erfahrungen mit unseren Agilen Projekten kann ich dem Kollegen
aus den USA noch ein paar konkrete Hinweise zum Thema "Agile Sensorik" geben:
- die Anforderungen ändern sich:
als erstes: das ist keine "Böswilligkeit";
vielmehr hat der Kunde entweder selbst mit neuen Herausforderungen zu tun,
oder aber wir haben ihm geholfen zu lernen und seine Situation besser zu überdenken;
=> Agile Reaktion: Anpassung je Iterations-/Release-Planung möglich;
- Häufige Störungen der Entwickler:
in unserem Fall sind die Entwickler oftmals in 2 parallelen Projekten tätig;
dazu kommt oft auch eine gewisse Mitarbeit bei der Wartung und Pflege von Systemen;
vom Management werden die Ressourcen aber oft zu einem unrealistisch hohen Maß
für ein Projekt "zur Verfügung gestellt";
=> Agile Reaktion: Iteration für Iteration bemerken wir sofort die tatsächliche
Verfügbarkeit; zusätzlich läßt sich durch einfache Hochrechnung abschätzen,
ob Handlungsbedarf gegeben ist;
- Technologie funktioniert nicht:
einen vielversprechende neue Technologie hält nicht, was sie in der Dokumentation
verspricht;
=> Agile Reaktion: auch hier zeigt der mangelnde Fortschritt am Ende der ersten
Iteration, daß ein Problem vorhanden ist;
- Kommunikation im Team:
mit Team meine ich hier alle, d.h. Lieferanten und Kunden zusammen;
die klassische Kommunikation bzw. die Verhaltensmuster sind meist geprägt
von Absicherung gegen Übervorteilung: keiner will einen Nachteil erlangen,
jeder will seinen möglichen Verlust minimieren;
das allein sorgt bereits für eine "kühle" Atmosphäre im Projekt;
=> Agile Reaktion: ein Agiles Lieferanten-Team wird dem Kunden niemals
das Gefühl geben, im Nachteil zu sein;
vielmehr erkennt der Kunde die Chance zu Lernen und dadurch (später) besser
zu steuern;
das führt zu einer grundsätzlich konstruktiven Kommunikation;
man diskutiert nicht, wer laut Vertrag für welche Schwierigkeiten zuständig ist,
sondern man räumt die Schwierigkeiten gemeinsam aus dem Weg;
So weit, so gut: nach unseren Gesprächen bleibt eine gehörige Portion Skepsis bei
meinem amerikanischen Kollegen; Absicherung hat doch eben auch ihr gutes, oder?
Er wird das Gehörte verdauen und überdenken; er meldet sich wieder ...
Seitenanfang
Zusammenfassung
Agiles Verhalten in einem Projekt verhindert, daß sich Probleme in dunklen Ecken
verstecken und dort zur Krisen reifen können.
Agiles Verhalten deckt Schwachstellen im Projekt sofort auf: der Fortschritt wird
beeinflußt oder gar verhindert. Damit ist die Störung für alle sichtbar;
eine Reaktion muß sofort erfolgen.
Grundsätzlich glaube ich, daß Agiles Verhalten im Projekt viele Probleme bereits
im Keim erstickt: die Form der Zusammenarbeit ist auf Gewinn-Maximierung und nicht
auf Verlust-Minimierung gerichtet.
Übrigens: 2 Tage nach seiner Abreise bekomme ich die Nachricht, daß sich mein Kollege
entschlossen hat, den Agilen Weg zu gehen. Ich werde ihm dabei helfen ...
Seitenanfang
Verweise
Folgende Quellen wurden zum Teil zitiert bzw. werden empfohlen zur Vertiefung und
für weiterführende Informationen:
Seitenanfang
|
