Bericht von der Bitkom zu Agil vs. Industrialisierung – IT-Entwicklung am Scheideweg?

Am 21.September habe ich an dem Arbeitskreis der Bitkom „Software Development Prozesse und Tools“ teilgenommen. Die Veranstaltung stand unter dem Thema „Agil vs. Industrialisierung – IT-Entwicklung am Scheideweg?“ und versprach anhand der Agenda ein paar spannende Vorträge.

Meine Eindrücke möchte ich an dieser Stelle schildern. Die Folien zu den beschriebenen Vorträgen stehen zum Download zur Verfügung.

1. Vortrag: Wertorientierung – nicht nur für agile Projekte

Jonathan Streit (Itestra GmbH)

Wie der Titel schon verrät ging es hier um den Wert (Business Value) einer Software. Der Wert soll nicht nur in den Vordergrund gestellt, sondern auch gemessen und mit verschiedenen Ansätzen transparent gemacht werden. Hintergrund ist, dass in vielen Fällen bei Investitionen in der IT nur Kosten betrachtet werden, nicht aber die Leistungen die erbracht werden. Laut Herrn Streit wird der Vergleich von Leistungen in der Regel auf den geschätzten Entwicklungsaufwand reduziert und betrachtet nicht die darauf folgende Fehlerbehebung (die laut Statistik das 1,74 fache des geschätzten Aufwands bedeutet).

Nach Meinung des Vortragenden sollte zur besseren Bewertung des erzeugten Business Value die Einflussfaktoren der Entwicklungs- bzw. Wartungskosten gemessen werden. Die Einflussfaktoren sind aus Sicht von Herrn Streit, der Software Umfang, die rel. Änderungsrate und die Produktivität.

Einflussfaktor 1: Brutto- / Nettoumfang einer Software.
Nettoumfang ist die Anzahl Features (gemessen mit manueller Function Point Analyse) abzgl. des im Bruttoumfang enthaltenen Dead Code (vom User ungenutzt bzw. unerreichbar), Code Cloning usw.,  in denen zusätzlich die Messung der Lines Of Code Anwendung findet.

Einflussfaktor 2: Änderungsrate
Womit beschäftigt sich das Entwicklungsteam hauptsächlich? Mit tatsächlich nutzenbringenden Anforderungen, Fehlerbehebung oder technischen Anpassungen? Um das herauszufinden, wird eine prozentuale Verteilung über diese Faktoren gelegt. An dieser Stelle hätte ich gerne im Vortrag mehr darüber erfahren, wie Herr Streit zur Verteilung kommt. Wie wurde vorgegangen, um z.B. nutzenbringende Anforderungen von nicht nutzenbringenden zu unterscheiden.

Einflussfaktor 3: Produktivität
Betrachtet werden die Kommunikationswege, der eventuelle Einsatz veralteter Werkzeuge, mangelnde Projektstrukturen und fehlende Qualifikationen. Auch hier hätte ich gerne Praxisbeispiele gesehen, wie die Messungen der Produktivität durchgeführt wurde und wie der Bezug zu einer Referenzgröße gemacht wurde.

Zu guter Letzt ergibt die Differenz zwischen Ist und Soll bezogen auf:

•   Kosten
•   Umfang(Brutto/Netto)
•   relative Änderungsrate
•   Produktivität

Aufschluss über das Verhältnis zwischen Investition und Business Value.

Dies wird über den Projektverlauf mit definierten KPIs gemessen.

Symptome dafür, dass der Business Value nicht größer als die getätigte IT-Investition ist, sind:

• niedrige Entwicklungsgeschwindigkeit
• hohe Fehlerrate
• niedriges Wachstum neuer Features

Fazit: Der Vortrag wurde flüssig und anschaulich rübergebracht, bei mir sind allerdings einige Fragen offen geblieben. Es wurde z. B. dargestellt was gemessen wird, aber nicht, wie das in Zusammenhang mit agilen Projekten steht. Bei der Erhebung der Messdaten hätte mich an der einen oder anderen Stelle auch genauer interessiert, wie das erfolgsversprechend umgesetzt wurde, bzw. welche Erfahrungswerte dort gesammelt wurden.

2. Vortrag „Wie viel Agilität verträgt klassisches Projekt Management?“

Robert Reinholdt & Mattias Gärtner (CDI AG)

  In diesem Vortrag sollten folgende Fragen beantwortet werden:

• Was könnte reizvoll an Agilität im Projektmanagement sein?
• Ist eine Kombination von Projektmanagement und Agilität möglich?
• Welche Auswirkungen hat Agilität auf klassisches Projektmanagement und Projektbeteiligte?

Diese Fragen auf der ersten Folie versprachen einen spannenden Vortrag, der sich in erster Linie als Vorstellung der Scrum Grundlagen entpuppte. Im Anschluss daran wurde das selbstentwickelte Prozessmodell für Projektmanagement vorgestellt, das ebenfalls keine Antworten auf obige Fragen lieferte.
Erst im letzten Drittel des Vortrages wurde darauf eingegangen, wie Scrum mit der zuvor beschriebenen Projektmanagement Methode funktioniert. Dabei nimmt der Projektmanager die folgenden Aufgaben war:

• Projektauftrag entwickeln
• Projektorganisation
• Beschaffung
• Kostenmanagement
• Risikomanagement
• Stakeholder / Kunden managen
• Information und Kommunikation des Projektstatus
• Projektabschluss

Alle anderen Aufgaben werden durch die bekannten Scrum-Rollen (PO, SM und Team) verantwortet und umgesetzt. Bei mehreren Scrum-Teams bilden die POs dieser Teams selbst auch wieder ein Team, das mit dem Chief-PO kontinuierlich den Visions-, Sprint-, und Backlogabgleich herstellt.

Fazit: Vom reinen Informationsgehalt hatte ich mir von diesem Vortrag mehr versprochen. Auf die Beantwortung der zu Beginn gestellten Fragen wurde mit der letzten Folie viel zu kurz eingegangen. Der Vollständigkeit halber habe ich Sie hier aufgeschrieben:

• Was könnte reizvoll an Agilität im Projektmanagement sein?
  Hohe Visionsnähe, schnelle Reaktion auf Änderung, effektivere Umsetzung

• Ist eine Kombination von Projektmanagement und Agilität möglich?
  Ja

• Welche Auswirkungen hat Agilität auf klassisches Projektmanagement und Projektbeteiligte?
  Rollenwechsel schwierigste Aufgabe

3. Vortrag „Motivation in großen Projekten“

Heiko Scharding (Kühne & Nagel) und Wolf-Gideon Bleek (BLUECARAT)

Wer an dieser Stelle etwas über intrinsische oder extrinsische Motivation erwartet hatte, wurde enttäuscht. In diesem Vortrag wurden wichtige Schlüsselfaktoren aufgeführt, in denen sich agile und klassische Projekte unterscheiden.
Folgende Schlüsselfaktoren wurden dabei näher umschrieben:

1. KommunikationMit einem aufschlussreichem Diagramm wurde die Effektivität von verschiedenen Kommunikationsmöglichkeiten (Papier, Mail, Videokonferenzen, face-to-face, usw.) dargestellt, das gleichzeitig die Unterschiede zwischen gebräuchlichen agilen und klassischen Methoden deutlich machte.
2. FeedbackAnschaulich wurde präsentiert mit welchen Mitteln schnelles Feedback in agilen Projekten erzeugt wird und das mit diesen unter anderem auch Projektrisiken vermieden werden können.
3. Einbeziehung von Entwicklern / Testern
4. Workload über den Projektverlauf
5. Projektmonitoring durch Velocity und geschätztem Product Backlog
6. frühes Testen

Weiterhin wurde die Auswirkung von Retrospektiven auf die Gesamtstimmung im Projekt als letzter Schlüsselfaktor beschrieben.

Verdeutlicht wurde von den Vortragenden, dass alle oben genannten Schlüsselfaktoren die Motivation in Projekten verbessern sollen.

Fazit: Sehr enthusiastisch und praxisnah vorgetragen. Als sehr gut empfand ich, dass Heiko Scharding bei allen möglichen Prozessen und Methoden den Mensch und vor allem den Entwickler in den Vordergrund gestellt hat. Mehrfach wurden laut Scharding die externen Berater, die in der Rolle als Scrum Master bei Kühne & Nagel unterstützten, ausgetauscht, bis letztendlich die Individuen genügend berücksichtigt wurden.

4. Vortrag: Einführung eines adaptiven Scrum Vorgehens

Christian Männchen (IT Frankfurt GmbH)

Der Vortrag begann mit einer Kernthese, die besagt, dass sich klassisches Projektmanagement wenig um das Managen von Inhalten kümmert, sondern vielmehr um Ressourcen und Geld. Im Gegensatz dazu wird in agilen Projekten insbesondere der Inhalt in den Vordergrund gestellt.
Die Kernfrage des Vortrages lautete: Wie schafft man die Adaption von Agilität in das Projektmanagement?
Der Schlüssel für die Antwort liegt laut Herrn Männchen im „Feature Driven Scrum“. Dabei zeigte er auf, wie er Planungs- und Controlling-Ansprüchen des klassischen Projektmanagement „begegnet“.

Klassisches Projektmanagement betrachtet aus seiner Sicht folgende vier Aspekte:

• Projektziel
• Aufwand
• Plan
• Verantwortlichkeiten

Dem Projektziel begegnet Männchen mit einer zugesagten Feature-Liste. Die einzelnen Features aus der Liste werden vor Projektbeginn geschätzt. Während der Projektphase werden Features in Stories herunter gebrochen und ebenfalls geschätzt.

Auf Basis der fertiggestellten Feature-Liste wird der zeitliche Fortschritt an das Projektcontrolling übermittelt.

Das Fazit dieses Vortrages ist, dass alle vier Aspekte des klassischen Projektmanagement bedient werden müssen. Die Feature Liste dient dabei als Basis für die Einigung zwischen Besteller und Hersteller.

Eine Randbemerkung des Vortragenden bezüglich ingenieurmäßigen Vorgehens in der Softwareentwicklung löste am Ende des Vortrags eine Diskussion bei den Zuhörern aus, die losgelöst vom eigentlichen Vortragsinhalt, aber durchaus spannend in der Argumentation war. Leider musste sie aus zeitlichen Gründen nach kurzer Zeit gestoppt werde. Durch die spontane Diskussionsrunde waren Fragen zum eigentlichen Vortrag und deren Antwort auf die Kernfrage jedoch nicht mehr möglich.

5. Vortrag Agil mit Prince2

Hang Chung (Opitz-Consulting)

An den letzten Vortrag des Tages stellte ich besondere Erwartungen, da in meinem aktuellen Kundenumfeld ebenfalls Prince2 zum Einsatz kommt.

Zu Beginn stellte Herr Chung die Grundprinzipien und Themen von Prince2 vor. Im Anschluss daran ging er kurz auf die Motivation für Agilität ein. Da in den vorangegangenen Vorträgen bereits das agile Manifest und auch Scrum vorgestellt worden waren, verzichtete der Vortragende erfreulicherweise auf eine Wiederholung. Stattdessen ging es mit dem Unterschied zwischen agilem und klassischem Projektmanagement weiter. Es wurde betont, dass in agilen Projekten lediglich am Umfang und nicht an den Kosten oder der Zeit gedreht werden kann, während im klassischen Projektmanagement der Umfang fest steht und Kosten bzw. Zeit die Stellschrauben sind.

Darauf folgend wurden anhand der Prince2 Themen agile Elemente eingestreut, leider ohne näher darauf einzugehen wie gut die agilen Elemente die Prince2 Themen bedienen. Ich hätte mich über eine nähere Betrachtung dieses Themas sehr gefreut.

Zu den einzelnen Prince2 Themen wurden folgende Informationen ergänzt:

• Business Case
  • der Lieferumfang ist nicht genau festgelegt
  • der Fokus ist stärker auf den Nutzen ausgerichtet
• Organisation
  • hier wird in Kunden- und Lieferantensicht unterschieden: der Lieferant stellt das Scrum-Team dar
  • ein Mapping der in Scrum definierten Rollen ist erforderlich
• Planung & Prozesse
  • die Masterplanung erfolgt nach Prince2: sie wird herunter gebrochen in Sprintplanungen, die nach Scrum Regeln erfolgen
  • während die Methode Scrum für das Team genutzt wird, wird Prince2 für das Management verwendet
  • pro Prince2-Stage werden ein oder mehrere Sprints angesetzt.
• Risikomanagement
  • ein Unterschied ist laut Herrn Chung nicht erkennbar, ebenso wenig existiert ein Widerspruch von klassisch zu agil
• Qualität und Änderungen
  Hier steht der Umgang mit Änderungen im Zwiespalt Änderungen als Ausnahmen zu behandeln vs. Änderungen als Regel zu betrachten. Ein Lösungsweg um beide Ansätze zu erfüllen, wurde nicht vorgestellt.
• Fortschritt & Reporting
  • Statusberichte vs. Burn Down Charts

Fazit des Vortrags:

• Agilität und Prince2 sollten insbesondere dann kombiniert werden, wenn zu erwarten ist, dass das Ziel nicht genau bekannt ist (moving target)
• die Menge der möglichen einzubringenden agilen Elemente ist stark vom Umfeld abhängig
• wichtige Voraussetzung ist ein gut funktionierendes Change Management

In diesem Vortrag hätte ich mir ein paar Erfahrungswerte ausgehend von der Kombination Agil / Prince2 gewünscht. Eine Bewertung, wie gut sich die agilen Elemente in vergangenen Prince2-Projekten integrieren ließen, blieb leider aus.

Mein Fazit zur Gesamtveranstaltung:

Die Bitkom bietet mit dem Softwareentwicklungsforum Unternehmen eine gute Plattform, um sich zu verschiedenen Gebieten in der SW-Entwicklung zu informieren. Die Vorträge waren an diesem Tag sehr straff organisiert. Hier würde die Möglichkeit zur ausgiebigeren Diskussion helfen, die Vortragsinhalte genauer zu verstehen und einzelne Aspekte zu schärfen. Die Veranstaltung stand unter dem Motto „Agil vs. Industrialisierung – IT-Entwicklung am Scheideweg?“; auch zu dieser Frage hätte ich mir eine ausführlichere Diskussion gewünscht. Der Business Case für Agilität konnte insbesondere den Fürsprechern von klassischer / traditioneller SW-Entwicklung nicht ausreichend transparent gemacht werden. Die zukünftig geplanten Themen versprechen aber weitere spannende Vorträge.