Schlagwort-Archiv: Entwicklungsprojekte

Ein agiler Bastard zwischen einem Karnickel und einer Rummelfliege

Alle sprechen von agilem Projektmanagement. Das geht so weit, dass man sogar noch das “Projektmanagement” weg lässt. Plötzlich ist einfach alles agil. Als ich im vergangenen Sommer einen glühenden Anhänger von Agilität gefragt hatte, was er denn nun eigentlich unter “agil” verstehe, war seine Antwort:

Meine Definition von Agil? Jetzt hast du mich aber… ;-) Da muss ich mal über eine Formulierung nachdenken.

So auf die Schnelle würde ich sagen, agile Entwicklung ist:

  • Inkrementell: es wird in Durchstichen gedacht, Nutzenorientierung
  • Lernend: daher auch die iterative Entwicklung oder die Retrospektive in Scrum
  • Haldenreduziert: es wird versucht, kein B*UF herzustellen (Big {Design, Documentation, …} Up Front)
  • Unmittelbar: Kommunikation soll direkt stattfinden (Kunde:Entwickler, Code:Entwickler usw.); also nicht lange rumspezifizieren und Papierberge produzieren, nicht lange rumdokumentieren, sondern den Code sprechen lassen

Interessant ist, dass er zunächst selber überfragt war. Dann kam eine Definition für “agile Entwicklung”. Das ist immerhin konsequent, denn agiles Projektmanagement war in der Tat für IT-Entwicklungsprojekte angedacht. Kent Beck et al. stellten 2001 ihr agiles Manifest vor, in welchem nebst agilen Prinzipien auch die vier agilen Werte stehen1:

Wir zeigen bessere Wege auf, Software zu entwickeln, indem wir es selber tun und anderen dabei helfen, es zu tun. Durch unsere Arbeit sind wir zu folgender Erkenntnis gekommen:

  1. Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  2. Funktionierende Software ist wichtiger als umfassende Dokumentation.
  3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
  4. Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan

Es ist deutlich von Software entwickeln sowie funktionierender Software die Rede. Das ist das Entscheidende. Agiles Projektmanagement ist eine Philosophie für Entwickler. Nur: hier in Mittelwuropa sind IT-Projekte vowiegend Integrations- und Migrationsprojekte, in deren Verlauf manchmal tatsächlich auch Skripte entwickelt oder Schnittstellen angepasst werden müssen, z.B. mit in einem SAP-Projekt mit der Programmiersprache ABAP. Aber solche Entwicklungen stehen in Migrationsprojekten nicht an vorderster Stelle und können in einem mit agilen Methoden durchgeführeten Teilprojekt gekapselt werden. Für das übergeordnete Migrationsprojekt jedoch, sind die agilen Werte, so wie sie im Agilen Manifest stehen, nichtssagend oder selbstverständlich.

Die nicht direkt entwicklungsbezognene Werte Interaktionen vor Prozessen und Zusammenarbeit mit dem Kunden sind in Logistik- und Migrationsprojekten schon immer selbstverständlich gewesen. Ich habe schon in den Achzigern – lange vor Kent Beck – in Referaten auf der Notwendigkeit von kollaborativem Vorgehen mit den Handelspartnern – Kunden und Lieferanten – insistiert. Meine Zusammenarbeit mit den Kunden in Migrationsprojekten geht zuweilen so weit, dass meine Mandanten murren. In Projekten will der Lieferant eine möglichst gute Marge und der Kunde eine möglichst gute Qualität. Ich achte immer zugunsten des Kunden auf Qualität, was manchmal an der Marge meiner Mandanten zehrt.

In einem Integrations- oder Migrationsprojekt wird ein Softwareprodukt installiert, dessen Entwicklung abgeschlossen ist. Dokumentation ist ausserordentlich wichtig. Der Kunde wil nicht ständig vom wohlwollenden Support und den teuren Trainings des Lieferanten abhängig sein, sondern erwartet eine möglichst gute Dokumentation des Produkts. Er will keine grünen Bananen, die bei ihm reifen sollen, sondern funktionierende Software und umfassende Dokumentation. Hier unterscheiden sich Migrationsprojekte grundsätzlich von Entwicklungsprojekten.

Die Forderung Veränderung vor Plan zieht sich wie ein roter Faden als eines der Hauptthemen durch meinen Blog. Es geht mir seit jeher um vigilantes und flexibles Vorgehen. Den längst zerredeten Begriff “agil” vermeide ich tunlichst, weil er in den Bereich von Entwicklungsprojekten gehört.

Es ist äusserst gefährlich, zunächst recht präzise Begriffe einfach auszuweiten und über alles und jedes zu stülpen. Die Begriffe erfahren dabei eine Inflation und verlieren ihren Inhalt.

Uwe Friedrichsen schreibt in seinem interessanten Überblicksartikel Agilität heute und morgen: eine Bestandesaufnahme und ein Blick in die Zukunft2

Nachhaltig geändert hat sich die Situation für mich vor circa zweieinhalb Jahren. Mein damals neuer Arbeitgeber setzte nicht nur in der Projektdurchführung, sondern in allen Bereichen auf Agilität.

Ich bedauere, dass man angesichts erhöhter Komplexität nicht auch erhöhten Wert auf präzise Sprache legt. Nicht nur, dass man den Begriff “agil” missbräuchlich verwendet, wo man einfach nur “flexibel” oder vielleicht “vigilant” meint. Die Vertreter der Agilität-auf-Teufel-komm-raus benutzen auch Begriffe wie “Kanban” oder “inkrementell”, ohne sich jedoch im Klaren darüber zu sein, was sie wirklich bedeuten. Kanban ist eine Just-in-Time-Methode in der Fertigung und hat gar nichts mit agiler Projektmanagement zu tun. Kanban ist im agilen Projektmanagement allenfalls eine Metapher. Inkrementell ist ein Vorgehen, bei dem periodisch ein festes Inkrement dazu kommt3. Agiles Projektmanagement meint aber rekursives Vorgehen, wo der nächste Schrit auf dem bisher Erreichten aufsetzt. Mein Freund, den ich eingangs erwähnte, meinte dazu:

ich denke, die begrifflichkeit ist hier geschmackssacke. “rekursiv” ist aus meiner sicht weniger anschlussfähig

Das ist genau, was ich meine: Die Bedeutung von Begriffen erklärt man ebenso zur Geschmacksache, wie die Gross- und Kleinschreibung. Dann kann jeder machen, wie er will. Das ist schon gut. Nur darf man sich nicht wundern, wenn sich die Menschen nicht mehr verstehen. Während der eine über agiles Projektmanagement spricht, meine ich, es gehe um Softwareentwicklung, das ziemlich ausserhalb meiner Erfahrungen liegt. Ich spreche von vigilantem oder systemisch-evolutionärem Projektmanagement, und obwohl er weitgehend dasselbe meint, reden wir die längste Zeit aneinder vorbei. Schade eigentlich!

1Z.B. Wikipedia, Agile Softwareentwicklung

2Friedrichsen, Uwe. Agilität heute und morgen: eine Bestandesaufnahme und ein Blick in die Zukunft, OBJEKTspektrum, Ausgabe Februar 2011

3z.B. Wikipedia, Inkrement und Dekrement

Titel frei nach Fletcher's satirisches Fußballdiktionär

Ist agiles Projektmanagement immer anwendbar?

Im Umgang mit Komplexität sind agile Methoden heute in aller Leuten Munde. Wenn man unter einer komplexen Situation aber eine Situation versteht, die

  • unübersichtlich
  • vernetzt
  • unbestimmt

ist, dann sind agile Methoden im Umgang mit Komplexität meines Erachtens nicht notwendigerweise hilfreich. In Entwicklungsprojekten ist agiles Projektmanagement ein sehr nützlicher Ansatz, wenn man aus einem Produktebacklog gerade so viele Funktionen entnehmen kann, wie man in einer bestimmten Zeit entwickeln mag. Für Migrations- und Intregrationsprojekte (MIP) sind agile Techniken jedoch weniger geeignet1. Um das einzusehen, erinnern wir uns, dass Migrations- und Integrationsprojekte oft mit der Aufgabe starten, gelieferte Hardware zu entpacken, in einem Rack zu montieren, an ein Netz anzuschliessen und in Betrieb zu nehmen. Dazu gehören natürlich erste Funcional Tests, insbesondere Pingtests zu gewissen Servern in der bestehenden Umgebung.

Für die Montage und Grundinstallation sind z.B. 10 Tage geplant. Wenn die agile Projektmethodik eine Timebox von 4 Wochen vorgesehen hat, lässt sich aus der Montage keine Timebox machen.
Das agile Prinzip, innerhalb einer Timebox keine Changes zuzulassen, greift hier auch nicht, denn Changes sind in einem MIP nicht das grosse Schreckgespenst. Wenn der Kunde das Rack innerhalb des Serverraums zig Mal umplazieren will, nervt das zwar, ist aber weiter kein Problem. Changes machen auch noch keine Komplexität aus. Das Schwierige in MIP sind Ereignisse, die sowohl für den Kunden als auch für den Lieferanten gleichermassen unvorhergesehen sind. Eine typische Unvorhersehbarkeit während einer Montage ist die Tatsache, dass irgendwelche Firewalls nicht richtig konfiguriert sind (das ist mittlerweile derart typisch, dass es schon keine Unvorhersehbarkeit mehr ist, sondern als vorhersehbares Risiko behandelt werden kann. Aber sagen Sie das einmal dem Kunden…).

Ein weiteres agiles Prinzip ist der Kundennutzen. Jede Iteration soll einen bestimmten Kundennutzen haben. Jede weitere Iteration erhöht den Kundennutzen. Eine Reihe von Iterationen werden zu einem Release zusammen gefasst, der eigentlich schon ein fertiges Produkt darstellt. Das geht bei MIP nicht. Das Resultat der Monatge enthält kaum Kundennutzen, musst aber dennoch gemacht werden. Daraufhin folgt die Installation der Software und anschliessend monatelange Tests bis zur Migration oder der Abnahme. Man kann nicht eine Iterationfolge “ein bisschen Montage, ein bisschen Software, ein bisschen Tests” machen, um einen ersten Release zu haben. Das geht in MIP nicht. MIP sind wie eine Schwangerschaft: man installiert einen bestimmten Release; alles oder nichts. Ein weiterer Release ist ein neues MIP.
Da eine vollständige Benutzerdokumentation zum Lieferumfang eines MIP gehört, gilt auch das agile Prinzip “funktionstüchtige Produkte vor umfangreicher Dokumentation” hier nicht. Ob das Produkt funktionstüchtig ist, liegt nicht in der Macht des MIP, sondern des vorangegangenen Entwicklungsprojekts. Eine vollständige und umfangreiche Dokumentation ist jedoch ein typisches Deliverable eines MIP.

Für Entwicklungsprojekte mögen agile Techniken eine hervorragende Methode sein. Auf ein Entwicklungsprojekt kommen hoffentlich viele Migrations- und Integrationsprojekte. Schliesslich will man das entwickelte Produkt oft verkaufen und ausrollen. Agile Techniken sind aber für das Management von Migrations- und Integrationsprojekten nicht sehr geeignet.

1Addor, P. Projektdynamik – Komplexität im Alltag. Liebig Verlag, Frauenfeld 2010, S. 65ff

Projekten in den Rachen geschaut

Eines der ersten Projektmodelle veröffentlichte Ed Roberts 19641. In den frühen achtziger Jahren ebnete das Modell von Pugh-Roberts2 den Weg zum berühmten Modell mit dem sogenannten Rework Cycle. Ausgehend von einem Bestand an unerledigter Arbeit, der entsprechend der vorhandenen Produktivität abgearbeitet wird, fliesst ein Teil der erreichten Resultate in einen Bestand an erledigter und abgeschlossener Tasks, während ein anderer Teil Fehler enthält und in einen Bestand undiscovered Rework fliesst. Das sind also solche Tasks, die unbrauchbar sind und später nachgearbeitet werden müssen. “Später” ist dann, wenn das Projektteam die Fehler wahrgenommen hat. Dann existiert ein Bestand an unerledigter Rework, der neben der geplanten Arbeit zusätzlich gemacht werden muss. Das führt zu einer Verzögerung in der Projektabwicklung. Folgende moderne Darstellung des sogenannten Rework Cycle lieferte Cooper 19933:

Zum Vergrösseren klicken Sie auf die Figur, die aus dem Überblicksartikel von Lyneis und Ford stammt4. Nach diesem Modell flacht der Fortschritt während der Laufzeit des Projekts vorübergehend ab, bevor er wieder anwächst. Das führt zum bekannten 90 % Syndrom. Nähere Einzelheiten hat James Lyneis in einer aufschlussreichen Powerpointpräsentation festgehalten5. Der Rework Cycle ist eines der best untersuchten Phänomenen im Projektmanagement. Unglücklicherweise betreffen alle diese Untersuchungen vor allem Entwicklungsprojekte und nicht so sehr Migrations- und Integrationsprojekte. Für diese steht ein valides Modell noch aus. In Migrations- und Integrationsprojekte kommt neben dem Rework Cycle vor allem ein “New work Cycle” in’s Spiel, der viel gravierender ist.

Quellen:

1Ed B. Roberts. The Dynamics of Research and Development. Harper and Row. New York 1964

2Richardson, George P. and Pugh III, Alexander L. Introduction to System Dynamics Modeling with Dynamo. MIT Press. Cambridge, MA 1981

3Kenneth G. Cooper (1993). The Iteration Cycle: Benchmarks for Project Managers. Project Management Journal. Vol. 24, No. 1 and
Kenneth G. Cooper (1993). The Iteration Cycle: How Projects are Missmanaged. Project Management Journal. Vol. 24, No. 1

4James M. Lyneis and David N. Ford. System dynamics applied to project management: a survey, assessment, and direction for future research. In System Dynamics Review, 23/2007, No. 2-3. S. 157-189.

5James M. Lyneis. Dynamics of Project Performance (2003). Powerpoint Presentation. Massachusetts Institute of Technology MIT

Migrations- und Integrationsprojekte sind anders

Der Standish Chaos Report erscheint seit 1994 alle zwei Jahre. Er beruht auf einer Umfrage unter mehr als 300 amerikanischen Entwicklungsunternehmen und untersucht über 8000 Projekte. Aus der Reihe der bisher erschienenen Reports geht hervor, dass der Anteil erfolgreicher Projekte bei ungefähr 28% konstant blieb, während der Anteil derjenigen Projekte, bei denen der Kosten- oder Zeitrahmen beträchtlich gesprengt wurde, zu Lasten der abgebrochenen Projekte konstant angewachsen ist. Aber es handelt sich ausschliesslich um Softwareentwicklungsprojekte. Als Grund, dass immer weniger Projekte abgebrochen werden, wird die Anwendung formaler Methoden angegeben1. Aber trotz dieser formalen Methoden – was immer das für welche sind – schiessen doch um 70% aller betrachteten Projekte an den Zielen vorbei. Als wichtiger Grund für das Scheitern von Entwicklungsprojekten ist die ungenügende Benutzereinbindung genannt. Wie soll denn das geschehen? Wie soll z. B. Microsoft die hunderten von Millionen Benutzer einbeziehen, die auf der ganzen Welt verstreut sind und in verschiedenen Kulturkreisen leben? Erhöhte Komplexität aufgrund der Globalisierung lässt grüssen. Microsoft kann nicht einmal ein signifikantes Sample von Benutzern begrüssen, das ist schlicht unmöglich. Selbstverständlich gehört eine tiefgehende Marktuntersuchung allem voran, aber von einer Benutzereinbindung kann keine Rede sein. Oder wie soll ein Hersteller von Telekommunikations- oder Bankenlösungen die Benutzer einbeziehen? Benutzer sind nämlich nicht die Betreiber, die die Lösungen kaufen und bezahlen, sondern deren ihre Kunden, also die vielen Millionen Endkunden, die telefonieren oder via E-Banking ihre Zahlungen machen.

Interessanterweise werden in der Literatur fast ausschliesslich Softwareentwicklungen untersucht, wenn es um IT-Projekte geht. Andere IT-Projekte werden eher stiefmütterlich behandelt. Dabei sollten doch auf ein Entwicklungsprojekt mehrere Dutzend Migrations- und Integrationsprojekte (MIP) folgen, denn schliesslich möchte man ja auch ausrollen, was man einmal mühsam entwickelt hat. Warum denn MIP in der Literatur ein derart steifmütterliches Dasein fristen, kann ich nicht verstehen. Es ist zu befürchten, dass sich die Zertifizierer, wie PMI und IPMA, und auch andere Herausgeber formaler Projektmanagementmethoden, an den Gegebenheiten von Entwicklungsprojekten orientieren. Aber die viel zahlreicheren MIP gehorchen anderen Gesetzen. Der mangelnde Einbezug des Kunden ist da z. B. kein Thema. Vielmehr laufen MIP die Gefahr, dass der Anwender den Hersteller zu wenig einbezieht. Es besteht momentan ein Trend weg vom Projektleiter des Herstellers. Die Anwender denken, dass es reicht, wenn sie den Projektleiter stellen. Aber wie man sich denken kann, funktioniert das nie, denn wer sorgt z.B. dafür, dass dem Projekt genügend Expertise seitens Hersteller-Entwicklungscenter zukommt? Sicher nicht der Projektleiter des Kunden, der aus der Sicht des Entwicklungscenters irgendwo auf der Welt in einem unbedeutenden Land sitzt. Sie erinnern sich ja an den Beitrag Staus im Projektmanagement vom 25. Juli 2008. Natürlich sind das Angelegenheiten, für die sich der Kunde nicht interessiert, und natürlich ist es verständlich, wenn er in der Offerte keinen entsprechenden Posten sehen will. Aber der Projektleiter des Lieferanten ist am Abend auch hungrig und kann die Arbeit nicht für Gottes Lohn machen. Hier entwickelt sich gerade eine neue Mode, die zur Komplexität beiträgt. Die Kräfte, welche die Randbedingungen liefern sind:
• Preisstandards für die Services, die mit dem System angeboten werden sollen
• Globalisierte Herstellerorganisationen vs. national operierende Betreiber
• Zunehmende Spezialisierung der Systeme für immer mehr konvergierende Applikationen
Die Players sind die Hersteller und ihre Subcontractors, die Betreiber entlang einer mehrstufigen Supply Chain sowie Millionen von Endbenutzern. Alle diese Players richten sich im herrschenden Kräftefeld so aus, dass sie das kleinste Leid haben, so wie sich ein Windzeiger in den Wind stellt, damit er der Windkraft am wenigsten ausgesetzt ist. Das führt möglicherweise zu einer Mode, die die Players „versklavt“, so dass sie schlussendlich ihre Ausrichtung nicht mehr selber wählen können. Was die Begriffe Mode und versklaven anbelangt erinnern Sie sich gewiss an den Beitrag Was ist komplex am Bierspiel vom 21. Juli 2008.

1 Wiki Softwaretechnik, Artikel Chaos-Report