Schlagwort: agil

Des (agilen) Pudels Kern – Fragen an den Vortrag

Des (agilen) Pudels Kern – Fragen an den Vortrag

Diese Woche habe ich zwei Vorträge gehalten. Thema der Vorträge war der Kern bzw. die Essenz erfolgreicher Projekte. In mehreren Untersuchungen wurden in rund 500 Projekten die verschiedensten Korrelationen zwischen unterschiedlichen Faktoren und dem Projekterfolg aufgespürt. Zwei Korrelationen stechen in ihrer Signifikanz deutlich hervor. Alle weiteren bzgl. Teamzusammensetzung (männlich, weiblich), Technikeinsatz (PM Werkzeuge, Kommunikationswerkzeuge), räumliche Verteilung der Teams usw. sind gegenüber diesen vernachlässigbar. Eine genauere Analyse der methodischen Elemente zeigt, dass vor allem jene Projekte, die Iteration, Reflektion und regelmäßige Treffen einsetzen funktionierende Teams und eine hohe Erfolgsquote hervorbringen. Eine neutrale Fassung der Folien gibt es hier. Nach den Vorträgen wurden viele Fragen gestellt, die das Thema ergänzen auf die ich heute noch eingehen möchte: 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.
Was ist des (agilen) Pudels Kern?

Was ist des (agilen) Pudels Kern?

So lautet der Titel des Vortrages, den ich auf der webtech Konferenz gehalten habe. Die Folien gibt es hier zum herunterladen (pptx, 632 KB). Die erwähnten Veröffentlichungen in denen die Kernaussages auf einer kleineren Datenbasis bereits getroffen wurden finden sich hier:
  • Eberhard Huber, Sven Lindenhahn: TEAMWORK: Warum Projektteams erfolgreicher sind als Projektgruppen, Objektspektrum Ausgabe 02 / 2010
  • Eberhard Huber, Cleo Becker: Entstehung von Projekt- und Teamkulturen und ihr Einfluss auf den Projekterfolg in: Projekte als Kulturerlebnis, dpunkt.verlag 2009 ISBN 978-3-89864-629-1
  • 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
Was ist des des (agilen) Pudels Kern?

Was ist des des (agilen) Pudels Kern?

Ich arbeite zur Zeit an einer Reihe von Vorträgen. Frei nach Goethe der Mephisto als des Pudels Kern identifizierte versuche ich herauszuarbeiten was der Kern erfolgreicher Projekte ist. Eine wichtige Rolle spielen hierbei bestimmte Elemente agiler Vorgehensweisen. Mehr wird an dieser Stelle aber noch nicht verraten. Auf folgenden Veranstaltungen werde ich die Vorträge halten: Zum PM-Camp werde ich den Vortrag natürlich auch mitbringen – hier entscheiden aber die Teilnehmer ob er Gehör finden wird. Das war jetzt vielleicht eine etwas holprige Ãœberleitung zum PM-Camp – macht aber nichts. Auf das PM Camp freue ich mich am meisten. Ich erhoffe (und erwarte) mir fruchtbare Diskussionen über die tägliche und manchmal schwierige Projektarbeit. So wie ich Projektarbeit verstehe ist eine “Barcamp-artige” Veranstaltung mit Diskussionen auf Augenhöhe angemessener als eine klassische Konferenz. Noch gibt es freie Plätze, der Teilnehmerbeitrag ist mit 99 Euro zzgl. Mehrwertsteuer sehr überschaubar. Informationen zu Termin, Anreise, Ãœbernachtung und Anmeldung sind hier zu finden.
target hopping

target hopping

Heute eine kleine Anekdote zum Wochenende. Das heißt es ist ein kurzer Aufschrei einer geplagten Projektleiterseele, die nach 25 Jahren Projektarbeit eine völlig neue Erfahrung machen musste durfte. 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.
Die agile Essenz

Die agile Essenz

Projekte, die agile Vorgehensweisen einsetzen, sind erfolgreicher. Anderseits gibt es einen noch ausgeprägteren Zusammenhang zwischen Teamqualität und Projekterfolg. Meine These lautet: Es kommt darauf an, dass sich während des Projektes ein echtes Team bildet. Wenn agile Methoden eingesetzt werden, gelingt dies ein wenig leichter. Diese These möchte ich im Folgenden erläutern. Wie sieht der gemeinsame Kern agiler Vorgehensweisen aus?
  • Es wird akzeptiert, dass zu Beginn nur ein Teil der Anforderungen definiert ist.
  • Es besteht permanenter und enger Kontakt zu denen, die das Arbeitsergebnis geliefert bekommen.
  • Es wird in wiederkehrenden Intervallen gearbeitet.
  • Am Ende jeden Intervalls wird ein verwendbares Zwischenergebnis fertig gestellt.
  • Jedes Arbeitsintervall wird ausgewertet. Es werden Konsequenzen für das nächste formuliert und auch gezogen.
  • Die produktive Arbeit wird von einem Team geleistet, das selbstorganisiert arbeiten darf.
Aus der Formulierung der Merkmale wird schon deutlich, dass diese Arbeitsweise nicht nur für Software-Entwicklung sondern für viele verschiedene Projektarten möglich sein wird. Wie die Merkmale in der Praxis konkret umgesetzt werden (z.B. mittels Scrum) ist letztendlich egal. Genauer betrachtet lässt sich diese Arbeitsweise auch mit “klassischem Projektmanagement” zuzüglich ordentlichem Changemanagement, kooperativer Führung und transparenter Kommunikation verwirklichen. Agilität ist ohnehin eher als Geisteshaltung denn als Prozessbeschreibung zu verstehen.1 Nehmen wir an, dass in einem Projekt wie oben beschrieben gearbeitet wird. Das Team arbeitet und liefert nach einer gewissen Zeit ein (hoffentlich) verwertbares Zwischenergebnis ab. Sollte im ersten Intervall nichts Brauchbares fertig werden, muss eben nach den Gründen gesucht werden um dann im zweiten Anlauf erfolgreicher zu sein. Egal ob im ersten oder zweiten Anlauf, das Team hat sehr früh ein Erfolgserlebnis. Konkrete (Erfolgs)-Erlebnisse und Erfahrungen beschleunigen die teaminternen Klärungsprozesse wie Rollenklärung oder die üblichen Machtkämpfe erheblich. Ein simples Beispiel: Ein Kollege bezeichnet sich selbst als Spezialist für ein bestimmtes Thema. Stimmt das? Können sich Team und Projekt wirklich darauf verlassen? Nach der Lieferung des ersten Zwischenergebnisses hat sich das bestätigt (oder eben nicht). Die Bestätigung der Fähigkeiten, der Verlässlichkeit, das Erproben der Zusammenarbeit, das Wachsen des aufkeimenden Vertrauen – all dies erfolgt schneller wenn mit greifbaren Zwischenschritten gearbeitet wird.2 Im negativen Fall wird ebenfalls schneller klar, dass der Kollege vielleicht nur eine große Klappe hatte und er mit einer anderen Aufgabenstellung mehr für das Projekt tun kann. Wichtige Grundvoraussetzungen für eine erfolgreiche Teamentwicklung wie die Klärung der Fragen “Wer gehört dazu?” bzw. “Wie sieht die gemeinsame Aufgabe aus?” werden bei einer solchen Vorgehensweise quasi im Vorbeigehen erledigt. Wer agil arbeitet, stellt gewissermaßen ganz nebenbei gute Rahmenbedingungen für eine konstruktive Teamentwicklung bereit. Eine konstruktive Teamentwicklung innerhalb des Projektes ist m.E. DER Erfolgsfaktor für Projekte. Scrum stellt hierfür bessere Rahmenbedingungen als das Wasserfallmodell bereit. Dennoch gibt es keinen Königsweg. Auch in Wasserfall-Projekten lässt sich ein Teil des agilen Gedankenguts (siehe obige Merkmale) leben. Ein gutes Team schafft fast alles, eine zerstrittene Projektgruppe kann jedes Projekt scheitern lassen.
  1. Insofern kann ich Stimmen, die Scrum als alten Wein in neuen Schläuchen bezeichnen durchaus verstehen. []
  2. Ein Meilenstein in einem Projektplan ist nicht zwingend ein greifbarer Zwischenschritt. Die Softwareentwicklung hat es hier relativ leicht. Hier entspricht dies einem lauffähigen Release. In anderen Projekten muss die Definition der Meilensteine genau bedacht werden. []
© pentaeder 2019 / 2020