Projektarbeit in allen Facetten

Schlagwort: agil

Agilität ist nicht New-Work

Posted on by Dr. Eberhard Huber

Agil ist cool, modern, menschenfreundlich, new-workig, demokratisch, selbstorganisiert und rasend schnell. Derzeit wird vieles in einen Topf geworfen, das nichts miteinander zu tun hat. Agil bedeutet im Sinne des Wortes nur “beweglich. Der Kern des agilen Manifest sind vier einfache Prinzipien

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plan

Genau genommen sind das lax formulierte Prinzipien, die einer beweglichen Arbeitsweise förderlich sind. Da steckt nichts von “New Work” oder Geschwindigkeit drin.

Es ist hilfreich sich zu vergegenwärtigen wie das agile Manifest entstand. Kluge Köpfe aus der Software-Entwicklung trafen sich um aus vielen Methoden vielleicht die beste oder eine gemeinsame zu finden. Das ist nicht gelungen, stattdessen wurde das agile Manifest als gemeinsame Wertebasis funktionierender Vorgehensweisen formuliert.

Hier wäre auch anzumerken, dass Scrum nicht “DIE agile Methode” ist, sondern nur eine von vielen, die damals diskutiert wurden. Scrum ist 6 Jahre älter als das agile Manifest.

Agil arbeiten bedeutet auf Veränderungen zu reagieren. Veränderungen können viele Ursachen haben. Ob die zu Beginn formulierten Anforderungen ungenau waren und im Laufe des Projektes präziser wurden bzw. bisher unbekannte Anforderungen hinzukommen ist völlig nebensächlich.

Die Kunst ist es, sich von ursprünglich Geplantem zu verabschieden und Neues zu beginnen. Wenn das gelingt, erhöht sich die Wahrscheinlichkeit, dass am Ende etwas Brauchbares rauskommt. Das ist eigentlich alles.

Geschwindigkeit ist eine andere Baustelle, die hängt mit der Qualität der Kooperation aller Beteiligten zusammen. Gute Kooperation zu entwickeln ist nicht immer einfach, aber mitnichten irgendeiner Methode vorbehalten. Dass manche Methoden mehr förderliche Elemente enthalten als andere ist unbestritten. Es ist jedoch ein Trugschluss, dass die Huldigung einer Methode automatisch zu gelungener Kooperation führt.

Agil, digitaler Wirbel oder des Kaisers neue Kleider

Agil, digitaler Wirbel oder des Kaisers neue Kleider

Posted on by Dr. Eberhard Huber

Nachstehender Text ist ein pointierter Beitrag zur Blogparade des Projekt-Magazins. Im Aufruf stehen die folgenden Sätze:

“Wir arbeiten jetzt agil / digital / selbstorganisiert!”

Mehr Erfolg durch neue Freiheiten im Projekt oder viel Wirbel um nichts?

Die Überschrift verrät schon, dass ich eher zur “viel Wirbel um Nichts”-Fraktion gehöre. Ich beginne meine Argumentation mit drei Aussagen, die ich nach und nach erläutern möchte:

  • Agil hat nichts mit Methode und / oder Technologie zu tun.
  • Erfolgreiche Projekte waren schon immer agil.
  • Selbstorganisation ist nur eine Facette agiler Arbeit.

Agil bedeutet nicht mehr und nicht weniger als beweglich. Gleichsetzungen mit Methoden wie z.B. Agil = Scrum sind schlichtweg falsch. Das agile Manifest wurde von Menschen geschrieben, die selbst Methoden entworfen hatten und auf der Suche nach der besten bzw. nach grundlegenden Prinzipien waren um Software-Entwicklung erfolgreicher zu gestalten. Die Kernaussagen, die am Ende des Treffens getroffen wurden, sind methoden-agnostisch. Schnell greifbare Ergebnisse zu erzielen und diese mit dem Kunden zu besprechen, statt lange Verträge zu schreiben ist trivial, sehr sinnvoll aber nach wie vor in vielen Projekten keine gelebte Praxis.

Die Digitalisierung läuft schon seit Jahrzehnten. Das Problem, dass sich die Anforderungen an ein Projekt während der Laufzeit ändern, besteht noch länger. Erfolgreiche Projekte haben schon immer einen Weg gefunden neue Anforderungen zu integrieren und die Planung permanent den sich verändernden Rahmenbedingungen anzupassen. Ob diese Beweglichkeit (Agilität) mit einem ausgefuchsten Change-Management-Prozess oder mit einer anderen Methode erreicht wurde ist nebensächlich. Letztendlich erhöht agiles Arbeiten die Wahrscheinlichkeit, dass ein Ergebnis entsteht, das den Kunden zufrieden stellt. Ein zufriedener Kunde ist der wichtigste Baustein des Projekterfolgs.

Bei der Selbstorganisation wage ich ebenfalls die Aussage, dass erfolgreiche Projekte immer einen gewissen Anteil an Selbstorganisation enthalten müssen. Jedes Projekt enthält per Definition Unbekanntes. Dementsprechend wird sich die zu Beginn gewählte Organisation eines Projektes im besten Fall als unvollständig, im schlechtesten Fall als untauglich erweisen. Die Vorstellung während eines Projektes parallel einen Organisations-Entwicklungs-Prozess mitlaufen zu lassen, halte ich für unrealistisch. Lösen lässt sich dieses Problem nur, wenn ein gewisser Freiheitsgrad für Selbstorganisation eingeräumt ist.

Jetzt drängt sich die Frage auf warum ich diesen Text überhaupt geschrieben habe. Ich befürchte, dass in dem aktuellen Wirbel die wichtigen Aspekte der Agilität verloren gehen, Nebeneffekte überbetont werden und am Ende das Gegenteil erreicht wird. Vor nicht allzu langer Zeit hörte ich einen Projekt-Manager eines IT-Unternehmens folgenden Satz sagen:

Wir machen nur Scrum um unsere Mitarbeiter besser kontrollieren zu können.

Eine andere Aussage, die mir begegnet ist, lautet:

Wenn wir agil arbeiten, können wir uns Pläne und Konzepte sparen.

Diese Aussagen sind nicht vollständig falsch, weisen aber in eine ungesunde Richtung. Es wird leicht übersehen, dass in der agilen Arbeit so viel geplant wird im klassischen Projekt-Management. Es geschieht nur zu einem anderen Zeitpunkt und wird gemeinschaftlich erledigt. Eine ordentliche abgearbeitete Einzel-Anforderung trägt die Konzeption in sich, es gibt lediglich kein Konzept-Dokument im klassischen Sinne. Elemente wie Backlogs, Boards, Charts, Reviews und Retrospektiven dienen dem selbstverantwortlichen “Inspect & Adapt” und nicht einem Mikro-Management-Kontrollbedürfnis.

Zum Schluss mein grusliges Lieblingszitat:

Sprints – das hört sich so schön schnell an.

Sprint auf Sprint ohne abgesicherte Pause machen die Menschen kaputt. Hier ziehe ich einen Vergleich zum Sport. Zwei 100 Meter-Läufe lassen sich ohne große Pause absolvieren. Ein 400 Meter-Lauf ist die längste Sprint-Distanz überhaupt. Wird das missachtet übersäuert die Muskulatur und am Ende läuft niemand mehr.

Ergänzende Texte:

Der Weg zur Agilität / die Autonomie des Lernens

Der Weg zur Agilität / die Autonomie des Lernens

Posted on by Dr. Eberhard Huber

Die Retrospektive ist ein unverzichtbarer Bestandteil agiler Vorgehensweise. Im klassischen Projektmanagement gibt es schon die „lessons learned“. Wenn ohnehin iterativ gearbeitet wird (siehe vorangegangener Beitrag) ist es scheinbar ein Leichtes regelmäßig nach Abschluss einer Iteration einen Lernschritt einzufügen und zu fragen: „Was war gut?“, „Was können wir verbessern?“. Aus den Ergebnissen der zweiten Frage lassen sich Experimente definieren, die während der nächsten Iteration durchgeführt und danach geprüft werden. Hat sich ein Experiment bewährt, wird es in den Ablauf übernommen.

Das hört sich leicht an, ist es aber nicht. Es ist wesentlich, dass sich jene Menschen die Fragen nach den Verbesserungen stellen, die die Arbeit getan haben. Insbesondere die Entscheidung über das Experiment muss von den Arbeitenden getroffen werden. Die hierfür notwendige Entscheidungsfreiheit ist die erste wirklich große Hürde auf dem Weg zur Agilität. Wird den Menschen zugestanden, dass sie Abläufe ändern, oder schreiten Prozess- und Qualitäts-Einheiten bzw. Vorgesetzte ein?

Wenn diese Autonomie nicht gewährt wird, kann man echte Agilität vergessen. Die Vision eines Hochleistungs-Teams bleibt dann Illusion. Es ist sogar noch schlimmer. Pseudo-Retrospekiven, in denen Ansätze zur Verbesserung gefunden werden, die danach nicht umgesetzt werden können, sind außerordentlich demotivierend. Dann ist es sogar besser, auf die Retrospektiven ganz zu verzichten.

Die Autonomie des Lernens ist die notwendigste Bedingung für Agilität.

 

Der Weg zur Agilität / erste Schritte

Der Weg zur Agilität / erste Schritte

Posted on by Dr. Eberhard Huber

Viele Unternehmen sind heute immer noch in einer Weise organisiert, dass das Wasserfallmodell als der passendere Ansatz erscheint. Das Problem dabei ist, dass der Wasserfall noch nie funktioniert hat, und über Jahre hinweg ein totes Pferd trainiert wurde. Die gute Nachricht: lautet: Agile Elemente lassen sich auch in Unternehmen einsetzen, die auf den ersten Blick alles andere als agil sind. Insbesondere die Prinzipien

  • Iteration,
  • lebendige, sortierte Listen statt epischer Dokumente
  • sowie vergleichendes „Schätzen“ statt Raten

lassen sich umsetzen, ohne eine Neuorganisation zu erzwingen. Wenn nach diesen Prinzipien gearbeitet wird, ist schon viel gewonnen. Noch besser wird es, wenn mann*frau die Menschen in echten Teams arbeiten lässt, das wird aber Gegenstand  des nächsten Artikels werden.

Iteration

Das Ergebnis eines Projektes ist zu Beginn ein Fantasie-Gebilde. So schön die Fantasie ausgemalt ist, so präzise sie beschrieben sein mag, es bleibt Fantasie. Nicht selten gibt es eine Enttäuschung, wenn nach langer hoffnungsvoller Wartezeit das vermeintlich fertige Produkt in Augenschein genommen wird. Dagegen hilft nur eines: So früh wie möglich ein Muster bauen und dieses dann in vielen Iterationen fertigstellen. Damit steigt die Wahrscheinlichkeit, dass am Ende sinnvolles herauskommt. Das gilt im Übrigen für fast alle Arten von Projekt-Ergebnissen.

Lebendige, sortierte Listen statt epischer Dokumente

Wann sind Anforderungen bekannt?Wenn das Prinzip der Iteration eingeführt ist, sollten als Nächstes die häufig zu Beginn des Projektes erstellten, epischen Dokumente abgeschafft werden. In schnell wandelnden Zeiten ist der Inhalt von Dokumenten, die in monatelanger Kleinarbeit erstellt wurden, bereits veraltet bevor das fertige Dokument überhaupt zum ersten Mal gelesen wird. (siehe Cartoon „Was fertig wirklich bedeutet“). Dazu kommen noch neue Anforderungen, die es aus vielfältigen Gründen nicht mehr in die Dokumente schaffen. Nebenstehende Grafik zeigt die Antworten einer Studie aus dem Jahr 2008 auf die Frage „Wieviel Prozent der Anforderungen zu Beginn des Projektes bekannt waren“1. Projekte, in denen alle Anforderungen bekannt waren, stellen eher die Ausnahme dar. Ein signifikanter Teil der Anforderungen wird erst während der Projektlaufzeit bekannt. Statt dicke Dokumente mühsam weiter zu pflegen und seitenlange Versions-Tabellen zu erstellen, kann man gleich in Listenform arbeiten. Wenn die Liste noch eine für den Kunden relevante Sortierung bekommt (z.B. nach Wert, Anwendernutzen o.Ä.) ist auch sofort klar, was in der nächsten Iteration umgesetzt wird.

Vergleichen statt Raten

Eine Gesamtschätzung auf Basis eines umfangreichen Anforderungsdokumentes ist in den meisten Fällen eine bessere Rate-Aktion. Etwas Unbekanntes zu schätzen ist Menschen ohnehin kaum möglich. Letztendlich versuchen wir immer zu vergleichen. Wir suchen instinktiv bekannte Größen, mit denen wir das Unbekannte vergleichen können. Dieses Prinzip lässt sich in iterativ arbeitenden Projekten mit Anforderungslisten elegant umsetzen. Neue noch nicht geschätzte Listeneinträge werden einfach mit den bereits umgesetzten Anforderungen verglichen.

Wenn dieses drei methodischen Prinzipien umgesetzt werden, sind immerhin die ersten Schritte in Richtung Agilität getan. Den Geist des agilen Manifests umzusetzen erfordert dann noch vieles mehr. Dafür zählen hier noch keine Ausreden, diese drei Schritte können auch in großen, starren Organisationen gegangen werden.

Der nächste Schritt ist dann das zyklische Lernen bzw. die Autonomie des Lernens.

 

  1. Technical Report der Uni Magedburg: “Einfluss agiler Praktiken auf Teammerkmale und Erfolg von Softwareentwicklungsprojekten” von Sven Lindenhahn, Sebastian Günther, Eberhard Huber 5. Dezember 2008 [↩]
© pentaeder 2019 / 2020