CfP: Workshop „Evolution und Wandlungsfähigkeit von Vorgehen“ auf der GI Jahrestagung

Marcus Kuhrmann und Patrick Keil von der TU-München veranstalten heuer ihren „4. Workshop: Vorgehensmodelle in der Praxis – Evolution und Wandlungsfähigkeit“ auf der GI Jahrestagung in Lübeck vom 28.9 bis 2.10. Ich denke, der Workshop ist vor allem auch aus agiler Sicht interessant, deshalb ein Ausschnitt aus dem Aufruf zu Beiträgen:

  • Wandlungsfähigkeit und Agilität
  • Retrospektiven und projektspezifische Lernschleifen
  • Rückfluss in einen organisationsweiten Erfahrungsschatz
  • Rolle Agiler Ansätze als unternehmensweites Vorgehen

Termin für Einreichungen ist der 28. April 2009, Details findet man auf der Workshop-Seite.

Umfangreiche Feedliste zu (englischen) Quellen über Agilität

Martining & Associates hat eine lange Liste von Blogs zu agiler Entwicklung zusammen getragen, die man unter http://www.agilevoices.com/aggregator/sources findet. Nicht alle Quellen sind wirklich gut und die Sammlung beschränkt sich auch auf englisch-sprachige Blogs, aber für einen Überblick finde ich die Liste hervorragend.

Agil und V-Modell XT

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.

Roman Pichler zu Produktvisionen

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.

Refactoring mit PHP

Dass Refactoring in Java mit Eclipse so richtig Spaß macht und auch die Kombination von Visual Studio mit Resharper oder DevExpress ganz brauchbar ist, dürfte zumindest unter Agilisten hinreichend bekannt sein. PHP-Entwickler haben es da deutlich schwerer, wie Roy Ganor in seinem Blog-Eintrag „Refactoring PHP Code“ beschreibt. Zend scheint zumindest ein paar Basisfunktionen anzubieten, aber selbst der Beitrag (auf dem Firmenblog!) klingt nicht wirklich enthusiastisch. Dennoch kann es sich für PHP-Entwickler lohnen, hineinzuschauen und zumindest zu beobachten, was dort die nächste Zeit passiert.

Achtung: Ich selbst habe keinerlei Erfahrung mit Refactoring unter PHP! Wer da mehr weiß, ist herzlich eingeladen, hier Kommentare zu ergänzen.

Klinsmann und Management

Schon seit den XPDays 2006, als Martin Heider einen Vortrag über Klinsmanns Leistung bei der Fußball WM und seine Techniken zu Teambildung gehalten hat, wollte ich darüber schreiben. Jetzt ist mir Katja Roth „zuvorgekommen“ mit ihrem lesenswerten Blogeintrag „Erfolgreiches Change-Management – Was wir von Klinsmann lernen können„. Viel Spaß beim Lesen!