Welche Bücher sind zum Einlesen in agile Vorgehensweisen geeignet?

Scrum ist m.E. der am gründlichste ausgearbeitete und diskutierteste agile Ansatz, deshalb ist ein Scrum Buch ein guter Einstieg in die agile Welt. So z.B. das Buch von Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen (kein Affiliate Link)

Wo klemmt die Einführung agiler Methoden am häufigsten?

Agile Arbeitsweise setzt ein anderes Verständnis eines Teams voraus, daraus ergeben sich veränderte Rollen, die es so in der klassischen Organisation nicht gibt. So ist z.B. ein Scrummaster keine Führungskraft im klassischen Sinne, meistens fehlt ihm auch die Unterschriftsberechtigung, die für eine schnelle Beseitigung von Hindernissen hilfreich wäre. Verhindern die Schnittstellen die Arbeit des Srummasters kann das die Motivation des Teams nachhaltig stören.

Wie kann in agilen Projekten vor Beginn verlässlich der Gesamtaufwand geschätzt werden?

Hier gebe ich eine etwas provokante Antwort. Vorab-Schätzungen sind immer schwierig. Wenn vor Start des Projektes vermeintlich alle Anforderungen auf dem Tisch liegen kann man auf dieser Basis eine Schätzung vornehmen. In vielen Projekten fällt ein Teil der Anforderungen im Laufe des Projektes wieder weg und wird durch andere ersetzt, die neuen Anforderungen sind damit oft aufwandsneutral.

Woher kommen die Daten?

Die Daten wurden in mehreren Erhebungsrunden teilweise im Rahmen von Diplomarbeiten erhoben. In den nachfolgenden Veröffentlichungen sind Datenerhebung und Auswertung näher beschrieben:

• Eberhard Huber, Sven Lindenhahn: TEAMWORK: Warum Projektteams erfolgreicher sind als Projektgruppen, Objektspektrum Ausgabe 02 / 2010
• Sven Lindenhahn, Sebastian Günther, Eberhard Huber: Einfluss agiler Praktiken auf Teammerkmale und Erfolg von Softwareentwicklungsprojekten, Technical Report der Uni Magdeburg: Nr. FIN-014-2008, Arbeitsgruppe Wirtschaftsinformatik

Ist die Team- oder Gruppendynamik in allen Projekten gleich wichtig?

Nein – bei Gruppengrößen von 4 bis 8 Personen ist ihr Einfluss am größten. Dies ist ausführlich in der oben genannten Veröffentlichung “Einfluss agiler Praktiken auf Teammerkmale und Erfolg von Softwareentwicklungsprojekten” beschrieben.

Wie werden sehr große Projekte erfolgreicher?

Gute Frage, meiner Erfahrung nach hilft nur eine Zerlegung in Teilprojekte. Dabei muss den Teilprojekten so weit wie möglich ein autarkes Arbeiten ermöglicht werden. In den Teilprojekten muss ein Stück weit ein Gefühl herrschen an einem eigenen Projekt zu arbeiten. Das Projektergebnis wird dann eben an ein anderes Projekt geliefert.

Benötigt man weiterhin Projektmanager wenn man konsequent agil arbeitet?

Die Bedeutung des überwachenden controlenden Projekt-Managements wird geringer. Die Rollen verändern sich. Aufgaben werden verlagert. An der grundsätzlichen Existenz der Aufgaben Planung, Mitarbeiterführung, Anleitung, Coaching usw. ändert sich jedoch nichts. Sie werden von anderen Menschen übernommen und sind nicht mehr per Definition an einzelnen Personen verankert.

Auch bei noch so gründlicher Vorarbeit sind in der Regel zu Beginn eines (Software-) Projektes nicht alle Anforderungen bekannt (siehe Bild bzw. Beitrag: agil ist besser?! ). Dass sich die bekannten Anforderungen dann auch noch verändern gehört zum Alltag. Nicht umsonst gibt es den Begriff des “moving target” – das Ziel bewegt sich, das Treffen wird erschwert. Agiles Vorgehen ist eine Antwort auf das “moving target”. Solange sich das Ziel nur bewegt besteht wenig Grund zur Sorge. Mit gründlicher Beobachtung und etwas Überlegung lässt sich erahnen wohin der Hase läuft. Fatal wird es jedoch wenn der Hase einen Superkräfte-Möhrensaft-Cocktail trinkt und mit Riesenkräften einen Sprung in die andere Richtung macht und plötzlich verschwunden ist. In dieser Situation befinde ich mich gerade. Eine SW-Entwicklung kurz vor dem Abschluss, dann kommt ein Anruf, dass eine grundlegende Konzeptänderung notwendig ist. Wie das neue Konzept aussehen wird ist aber noch nicht klar. Klar ist nur, dass das alte nicht passt. Innerhalb von Minuten sitzt man vor einem scheinbaren Scherbenhaufen:

• möglicherweise ist ein großer Teil des Codes für den Mülleimer
• Projektpläne und Berichte haben nur noch Altpapierwert
• das Gefühl “gleich haben wir es geschafft” ist weg
• ein (Schuld)-Gefühl “warum ist das nicht aufgefallen” kommt hoch
• Budget(planungen) sind im Eimer

Tief durchatmen – keine Panik. Was ist zu tun?

• Ordentliches Release fertig bauen,
  vielleicht wird der Umbau doch nicht so schlimm wie befürchtet.
• Erste spontane Ideen für den Konzeptumbau sichern.
• Mit anderen Aufgaben, zu denen keine Abhängigkeiten bestehen, weiter arbeiten.
• Pläne werden erst angepasst wenn der Hase wieder sichtbar ist.

Dann nochmal durchatmen und in Ruhe eine Tasse Heißgetränk (in meinem Falle Kräutertee) konsumieren. Was ich aus dieser unerwarteten Wendung lerne, weiß ich noch nicht, sie hat mir aber deutlich gezeigt, wie wichtig eine gewisse Ordnung, Dokumentation und Werkzeugeinsatz sind. Der Zielwechsel wird auf Basis einer geänderten Spezifikation, den bisher im Bugtracker dokumentierten Fällen und den lauffähigen Releases im Versionsmanagementsystem halbwegs stressfrei möglich sein. Nicht auszudenken, wenn der Code unversioniert und nicht lauffähig wäre. Wie dem auch sei, auf jeden Fall ist mein Anekdotenschatz wieder um eine Geschichte reicher.

Dieser Satz ist einer Schlagzeile meiner Tageszeitung entnommen. Eine Regierung, die gemeinsam voller Teamgeist arbeitet – das ist eine schöne Vorstellung. Die aktuellen Berliner Regierungsgeschäfte scheinen davon jedoch weit entfernt zu sein. Teamgeist lässt sich aber nicht einfordern. Teamgeist muss wachsen. Der Samen für den Teamgeist ist eine gemeinsame Vision. Möglicherweise fehlt es genau daran. Ich sehe mich, wenn ich mich in die Lage der Regierung versetze, nicht in der Lage eine kurz formulierte Vision für die Regierungsarbeit der nächsten Jahre zu formulieren. Ich befürchte manchem Regierungsangehörigen geht es ähnlich.

Keine Teamarbeit ohne Vision! Und was hat das mit Projekten zu tun?

Dass unklare Ziele einen gewichtigen Misserfolgsfaktor darstellen, ist unbestritten. Über den konkreten Zielen oder Anforderungen steht aber noch die Vision. Auch Projekte brauchen Visionen. Eine kurze Kontrollfrage lautet: “Warum machen wir das Projekt?” Die Antwort auf diese Frage sollte von allen Mitarbeitern ohne zu zögern kurz und prägnant beantwortet werden können. Es bleibt noch anzumerken, dass sich die Antworten ähneln sollten. Wenn bei der Frage nach dem “Warum” schon Differenzen bestehen, werden sich bei der Ermittlung der konkreten Anforderungen zwingend Widersprüche ergeben. Damit schließt sich der Kreis zur Politik Widersprüchliche Maßnahmen haben derzeit Hochkonjunktur.

Ein Tipp zum Schluss: Es lohnt sich die Frage nach dem “Warum” explizit zu stellen und ggf. einen Konsens herzustellen. Damit lassen sich viele Missverständnisse vermeiden.

Anforderungs-, Change- und Scopemanagement sind genau genommen Versuche das Wasserfallmodell zu verbessern. Im Laufe der Zeit verbreiteten sich iterative Ansätze und mündeten in den 90er Jahren des letzten Jahrhunderts in agile Vorgehensweise. Das tragische Element an dieser Geschichte ist, dass die Grundaussage der Veröffentlichung eine andere ist als jene die in das Bewusstsein der Branche drang.

Winston Royce schreibt in der Zusammenfassung:

In my experience, however the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed.

Die erwähnte “simpler method” ist der klassische oben skizzierte Wasserfall. Die Mehrkosten durch den aufwändigeren Prozess (Iterationen) sind geringer als jene, die durch Nachbesserungen (Terminüberschreitungen) am einfachen Modell entstehen. Er schreibt also sinngemäß: “Das hat noch nie funktioniert“. Dementsprechend sind in der Veröffentlichung einige andere Grafiken enthalten, mit denen er bereits 1970 eine iterative Vorgehensweise bis hin zu wiederholtem Coding vorschlägt – das würde man heute Refactoring nennen.

Ein wenig erinnert mich das an die Legende vom Eisengehalt des Spinats

… den bis heute noch gelegentlich behaupteten, außergewöhnlich hohen Eisenanteil besitzt Spinat jedoch nicht – der Schweizer Physiologe Gustav von Bunge hatte 1890 den Wert zwar richtig berechnet, doch bezogen sich seine Angaben auf getrockneten Spinat, wurden aber später irrtümlich frischem Spinat zugeschrieben, der zu ca. 90 % aus Wasser besteht. (Wikipedia)

Die gefühlte Antwort auf die obige Frage lautet: “Ein großer Teil der Anforderungen ist zu Beginn des Projekts noch nicht bekannt”. Der erste Blick auf die Daten scheint dies zu bestätigen. Nur bei 10% der Projekte sind alle Anforderungen zu Beginn des Projektes bekannt. Bei 26% sind es immer noch ca. 80%. Bei 29% zwischen 50 und 80% der Anforderungen. Bei einem immer noch nennenswerten Teil von 25 % ist weniger als die Hälfte der Anforderungen zu Beginn bekannt. Diese Prozentzahlen scheinen zudem relativ unabhängig von der Art des Projektes zu sein – zumindest die IT-Projekte und die nicht-IT-Projekte zeigen die gleichen Werte. Eine genauere Differenzierung wird allerdings erst bei einer größeren Zahlenbasis möglich sein.

Diese Zahlen zeigen auf wie notwendig ein funktionierendes Anforderungs- und Changemanagement oder eine agile Vorgehensweise ist. Eine Schlussfolgerung lässt sich schon jetzt ziehen. Die einmalige Erstellung eines endgültigen Planes, der nicht mehr geändert werden muss, ist eine Illusion.

Wenige Wochen später sollten diese Fragen nochmals geprüft und ggf. durch weitere ergänzt werden. Dieser Termin hat inzwischen stattgefunden. Von den ursprünglichen Fragen sind nur noch zwei relevant. Die anderen haben sich durch Ergebnisse aus anderen Projekten und veränderte Rahmenbedingungen praktisch erledigt bzw. ihre Priorität hat sich erheblich verändert. Auch der Projektplan wird sich dadurch erheblich verändern. Mit anderen Worten: Die erste Version des Planes ist für die Tonne.

Der erste Reflex die veränderten Fragestellungen im alten und modifizierten Plan abzubilden ging zum Glück schnell vorüber. Ich erinnere mich aber durchaus an Projekte in denen dieser erste Impuls in die Tat umgesetzt wurde. Das hilft aber niemandem weiter. Wenn sich die Bedingungen für den Plan grundlegend geändert haben, muss sich das auch im Plan wiederfinden. In meinem konkreten Fall setze ich einen neuen Plan auf. Mit drastischen Worten zusammengefasst:

Wenn schon für die Tonne gearbeitet wurde, dann aber richtig.

oder

Sackgassen müssen als Sackgassen akzeptiert werden.

Ein solcher Einstieg in ein Projekt ist ein deutlicher Hinweis, dass hier eine agile Vorgehensweise keine schlechte Lösung wäre