Archiv für den Monat: Januar 2009

Agil und V-Modell XT

Veröffentlicht am von

Krishan Mathis fasst in seinem Beitrag „Scrum and the German V-Model XT“ das Ergebnis einer Diskussion auf dem letzten Agile Tuesday in München zusammen. Der Beitrag enthält eine sehr lesenswerte Kurzfassung des V-Modell XT und geht auch auf die „Agile Durchführungsstrategie“ ein: „There is very little overlap between this ‚agile‘ model and how Scrum structures activities“. Die Aussage lässt sich durchaus auf die meisten agilen Verfahren übertragen.
Krishan kommt zu dem Schluss, dass man den Product Owner als „Schnittstelle“ zwischen den Welten „missbrauchen“ kann, aber nicht ohne eine Warnung: „It puts however a high degree of tension on the product owner and an associated risk of project failure.“

Ich denke, für alle agilen Verfahren ist die „mechanische“ Kopplung beider Welten über eine „Schnittstelle“ eine mögliche Lösung, nicht nur für Scrum. Man sollte sich dabei aber auch darüber im klaren sein, dass man sich damit auf sehr dünnes Eis begibt. Wird vom Auftraggeber das V-Modell XT verlangt, hat das normalerweise einen von zwei Gründen:

  • Der Auftraggeber ist gesetzlich und per Ausschreibungsrichtlinie gezwungen, das zu verlangen
  • Der Auftraggeber hat sich bewusst für ein hoch-zeremonielles Verfahren wie das V-Modell XT entschieden

In beiden Fällen ist der Schluss naheliegend, dass die interne Kultur des Auftraggebers so gestaltet ist, dass Mechanismen und Ideen des V-Modell XT zur Kultur passen. So kann zum Beispiel die Einhaltung von Vorschriften und unveränderten Verträgen wichtiger sein, als ein schneller RoI, selbst wenn sich das als projektgefährdend herausstellen sollte. Auch kann die Bereitschaft, individuell Verantwortung zu übernehmen, deutlich geringer sein, als zum Beispiel bei einem Startup.

Ist das der Fall, ist die Wahrscheinlichkeit hoch, dass weder Auftraggeber noch Auftragnehmer glücklich werden mit agilen Ansätzen. Der Wunsch, hinter einer V-Modell-Fassade agil zu arbeiten, sollte meines Erachtens also vom Auftraggeber ausgehen, und dieser sollte auch in der Lage sein, die notwendigen Entscheidungen zeitnah zu treffen — und später auch die Verantwortung dafür zu übernehmen. Zudem sollte man sorgfältig abgewogen haben, ob die Fassade wirklich sein muss, oder ein offener Ansatz möglich ist und man sollte sich ggf. auch mit Hilfe eines Spezialisten für Ausschreibungsrecht absichern und mit der zuständigen Innenrevision gesprochen haben.

Das klingt jetzt zwar alles wenig agil, aber man sollte sich auch im Klaren sein, dass die freundliche Gruppenleiterin, mit der man gerade verhandelt, wenig zu melden hat, wenn sich die Herrschaften des Rechnungshofes ankündigen. In diesem Sinne muss man sich nicht nur prozesstechnisch anpassen, sondern eben auch kulturell.

Aber um auch mal etwas positives zu sagen: Verglichen mit dem V-Modell 92 und 97 ist das V-Modell XT bereits ein riesiger Schritt in die richtige Richtung und hat bereits so manche Kritik an den alten Modellen aufgegriffen. Ich glaube, dass sich die Lücke in den nächsten Jahren weiter schließen wird, nachdem die Diskussion, ob agile Entwicklung überhaupt „echtes Software-Engineering“ sei zugunsten der agilen Verfahren ausgestanden sein dürfte.

Cutter IT Journal „Exploring the Agile Frontier“ derzeit kostenlos erhältlich

Veröffentlicht am von

Das von mir 2007 herausgegebene Heft des Cutter IT Journal mit dem Titel „Exploring the Agile Frontier“ ist derzeit im Zuge einer Marketinginitiative von Cutter kostenlos erhältlich, statt des üblichen Preises von ca. $40.00. Das Heft sammelt Analysen und Projektberichte aus Bereichen, die üblicherweise als „wenig geeignet“ für agile Verfahren gelten. Es enthält unter anderem:

  • Einen Projektbericht über agiles Arbeiten in weltweit verteilten Teams bei Schlumberger von Lise Hvatum
  • Einen Beitrag über agile Entwicklung bei großen und verteilten Teams von Jutta Eckstein
  • Einen Projektbericht über die agile Entwicklung von Beatmungsgeräten von Klaus Marquardt der nach meinen Informationen nirgendwo anders veröffentlicht ist
  • Einen Projektbericht über agiles Arbeiten bei einer „Wasserfall-Behörde“ von Matt Ganis und Tom Hawkins

Sie finden das Heft, auf der Cutter Homepage unter „Sample Our Research“ oder direkt hier.

Roman Pichler zu Produktvisionen

Veröffentlicht am von

Roman Pichler hat einen schönen Artikel zur Vision geschrieben, die jedem Produkt (und jedem Projekt) zugrunde liegen sollten („The Product Vision„). Für mich waren die fünf Elemente einer guten Vision am wertvollsten, auch wenn sie zum Standard einer guten Produktstrategie gehören:

1. Who is going to buy the product? Who is the target customer?
2. Which customer needs will the product address?
3. Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product?
4. How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?
5. What is the target timeframe and budget to develop and launch the product?

Hinzufügen könnte man noch die beiden Fragen, wer das Produkt eigentlich will (und wer nicht!) und was geschehen würde, sollte das Produkt nicht (rechtzeitig) kommen.

Der Schlüssel einer guten Vision ist der richtige Kompromiss zwischen Verständnis und Kürze. Roman verlangt, dass man die Produktvision innerhalb einer Fahrstuhlfahrt erklären können muss — allerdings stammt der „Elevator Pitch“ aus den USA, wo Bürogebäude in der Regel deutlich höher sind, als bei uns… Wichtig ist auch das Verständnis, dass die Vision im Laufe des Projektes reift. Man sollte nicht am Anfang ein halbes Jahr investieren, um die Vision zu erstellen bevor man anfängt zu arbeiten und damit durch die Hintertür den Wasserfall wieder einführen. Kundenfeedback und eigene Erfahrung sind wichtige Bestandteile einer Produktvision und beides bekommt man erst, wenn man schon ein Stück unterwegs ist.

Ich persönlich versuche, die Vision am Anfang eines zwei- bis dreitägigen Kickoff-Workshops erstmals zu fixieren. Das ist zwar häufig nur der allererste Anfang, er stellt aber sicher, dass alle Teammitglieder an ihrer weiteren Ausarbeitung beteiligt sind. Zugegebenermaßen kann man auch deutlich mehr Zeit in eine Vision investieren, ohne gleich dem Wasserfall zu verfallen, doch habe ich die Erfahrung gemacht, dass der Diskussions- und Lernprozess im Team wichtiger ist, als das formale Ergebnis. Und es schadet durchaus nicht, wenn einige Fragen erst im Laufe der ersten Iterationen geklärt werden.