Schlagwort: Anforderungsmanagement

Agil, digitaler Wirbel oder des Kaisers neue Kleider

Agil, digitaler Wirbel oder des Kaisers neue Kleider

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:

Agilität ist nicht New-Work

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. Im agilen Manifest stehen lediglich 4 Prinzipien, die zudem keinen Absolutheitsanspruch haben:

  • 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
Continue reading “Agilität ist nicht New-Work”
Das wundersame Projekt-Wachstum

Das wundersame Projekt-Wachstum

projekt_cartoon_024_extrawurstEs ist schon etliche Jahre her, E-Commerce steckte noch in den Kinderschuhen. Das Projekt rankte sich um einen B2B Shop der ersten Generation. Das Kernproblem des Shops war, dass die technischen Betriebskosten deutlich höher waren als die Erlöse, die mit dem Shop erzielt wurden. Genau genommen waren die Betriebskosten sogar höher als der Umsatz, der mit dem Shop gemacht wurde. Das Projektziel für einen Neubau des Shops war demzufolge glasklar formuliert: Reduzierung der Betriebskosten auf eine Maximalsumme von x DM (der Euro war damals noch nicht eingeführt). Aufgrund neuer Technologien, die zur Entstehungszeit des Altsystems noch nicht verfügbar waren, wäre das Ziel ganz leicht erreichen zu gewesen. Selbst bei voller Berücksichtigung der Entwicklungskosten des neuen Systems wäre ein ROI in wenigen Monaten erzielt worden. Ein kleines schnelles Projekt, das sich in wenigen Monaten bezahlt macht! Was will man mehr. Das „Mehr“ könnte darin bestehen, dass in einem neuen prestigeträchtigen Arbeitsgebiet Meriten zu verdienen sind, das Projekt könnte zum strategischen Vorreiter für alles Mögliche dienen – und so geschah es. Aus der Ein-Satz-Formulierung des Projektzieles entstand ein mehrseitiges Elaborat, in dem eine rosige Zukunft des gesamten Unternehmens skizziert wurde. Mit dem Elaborat wuchs das Projektteam, aus einem Team in operativer Größe wurde eine Gruppe, die sich ein eigenes Organigramm geben musste. Projektleiter und Teilprojektleiter wurden installiert. Die Vision des Zielsystems wurde immer größer, komplizierter und am Ende völlig unverständlich. Immer neue Fragen wurden aufgeworfen, die einfache Fragestellung entwickelte sich so lange, bis sie den Anschein von Komplexität hatte. Epilog 1 Das Ende der Geschichte, es wurde ein System gebaut, das noch mehr Betriebskosten verursachte als das alte. Umsatzsteigerungen wurden nicht erzielt. Die Maßnahmen, die eventuell den Umsatz erhöht hätten, waren der Kompliziertheit des Projektes zum Opfer gefallen. Epilog 2 Das Aufblasen von kleinen effizienten Vorhaben zu monströsen Projekten, die vor allem viele Manager-Sessel und Gremien generieren, kann in unseren heutigen, aufgeklärten Zeiten natürlich nicht mehr vorkommen. 😉  
Agil oder klassisch?

Agil oder klassisch?

2013_10_13_projektBLOG_Klassisch_AgilBlogger- und Projekt-Kollege Marcus Raitner hat diese Woche in seinem Artikel “Wider den Heilsversprechen im Projektmanagement” eine Lanze für die situationsangepasste Verwendung von Standards und Methoden gebrochen. Dem stimme ich zu. Der sklavische Einsatz EINER Methode kann sogar schädlich sein. Das ist mir in den letzten Tagen in einem Projekt wieder sehr deutlich vor Augen geführt worden. Einige der Meilensteine und Abhängigkeiten sind durch äußere Rahmenbedingungen unverrückbar vorgegeben. Es liegt daher nahe eine klassische Grobplanung des Projektes durchzuführen. Eine vollständige Durchplanung der Arbeitspakete ist derzeit noch nicht möglich, weil die Erhebung der Anforderungen von einigen Entscheidungen im Laufe des Projektes abhängen wird. Insofern ist es eine kluge Entscheidung statt einen fiktiven Detailplan zu erstellen einige Arbeitspakete als agile Teilprojekte aufzufassen. Die Zieldefinition eines großen Arbeitspaketes liefert den ersten Input für das agil arbeitende Teilprojekt. Die nebenstehende Grafik veranschaulicht die Situation unter Verwendung einiger Begrifflichkeiten aus Scrum. Ist das Gesamtprojekt jetzt agil oder klassisch? Ich denke die Frage alleine zeigt schon auf wie unsinnig eine »entweder-oder« Diskussion sein kann.  
Das Hey-Joe-Prinzip

Das Hey-Joe-Prinzip

Der Begriff des Hey-Joe-Prinzips entstammt dem Service Umfeld ist aber ebenso häufig in der Softwareentwicklung zu finden. In der Wikipedia findet sich eine knappe und treffende Definition:
Das Hey-Joe-Prinzip beschreibt die Auswirkungen der im IT-Support problematischen “Nachbarschaftshilfe” (Peer Support), die dabei den vorgesehenen Arbeitsprozess (Workflow) umgeht. Das geschieht, indem der Anwender die Hilfe für eine Problemlösung über eine inoffizielle Anfrage in seinem firmeninternen Bekanntenkreis erfragt, anstelle den eigentlich dafür vorgesehenen Service Desk zu kontaktieren, was plakativ mit “Hey Joe” beschrieben wird.
Für einen Anforderungssteller ist das ein höchst verführerisches Prinzip. Wenn der angesprochene Programmierer sich die Zeit nimmt, die Anforderung wirklich umzusetzen, ist das schneller als jeder Dienstweg. Die Probleme tauchen dann in der Regel später an anderer Stelle auf:
  • Es treten leicht Terminkollisionen auf, da der Entwickler auch Aufgaben aus dem normalen Entwicklungsprozess erhält.
  • Die Hey-Joe-Anforderungen sind meistens weder fachlich noch technisch gut dokumentiert.
  • Problematische Altlasten in großen Systemen bestehen häufig aus Bergen von Hey-Joe-Anforderungen.
Da irgendwann aufgrund der Altlasten auch die Hey-Joe-Geschwindigkeit sinkt, überwiegen die Nachteile und es sollte eigentlich ein Leichtes sein für alle einzusehen, dass es besser wäre sich von diesem Prinzip zu verabschieden. Die Realität sieht aber oft anders aus, das Prinzip hält sich mit erstaunlicher Hartnäckigkeit. Das hat mehrere Gründe, der erste liegt im psychologischen Bereich ein weiterer liegt in einem Missverständnis begründet. Zu guter Letzt gibt es tatsächlich Konstellationen in denen das Prinzip Sinn machen kann, diese werden dann gerne als leuchtende Beispiele zitiert, wenn mal wieder erbittert um die Einhaltung des Prozesses diskutiert wird. Ein Schlüssel zum Verständnis sind die Begriffe “Nachbarschaftshilfe” und “peer” aus der Definition. “Nachbarschaften” und “peer-groups” vermitteln ein Gefühl von Heimat und Sinnhaftigkeit. Der Entwickler enthält direkte Anerkennung von einem Kunden, das liefert Sinnhaftigkeit für die Arbeit. Im direkten Dialog zwischen Anforderer und Programmierer und schnellem gemeinsamen Erfolgserlebnis entsteht das Gefühl gut, wirkungsvoll und sinnvoll gearbeitet zu haben. In einem hoch regulierten Prozess arbeiten viele Entwickler ohne direkten Kundenkontakt, die Anerkennung wird oft vom Projekt- oder Abteilungsleiter abgeschöpft. Die Empfänglichkeit für einen Hey-Joe Ruf ist dann oft nur ein Verlangen nach direkter Anerkennung. Direkte Anerkennung ist noch wichtiger als das Salz in der Suppe. Wenn dann noch eine Unsicherheit des Arbeitsplatzes hinzukommt erscheint ein Ausweichen auf das Hey-Joe- Prinzip gewissermaßen als Rückversicherung. Es erscheint als Möglichkeit sich unentbehrlich zu machen. Das erwähnte Missverständnis besteht darin, dass “Agile Entwicklung” mit “ohne Prozess” übersetzt wird. Im agilen Manifest heißt es “interaction over processes” und nicht “without processes”. Auch wenn z.B. Scrum mit wenigen Artefakten und Rollen auskommt, so ist der Vorgang der Anforderungserhebung und Umsetzungsplanung hoch reguliert und stellt genau genommen einen “interaktiven Prozess” dar. Wirklich Sinn macht das Hey-Joe-Prinzip nur in 1:1 Beziehungen zwischen Kunden und Entwickler. Diese finden sich in sehr kleinen Projekten oder in großen Altsystemen, die von (aussterbenden) Spezialisten gewartet werden. In allen übrigen Kontexten überwiegen die Nachteile. Was ist also zu tun, wenn das Hey-Joe-Prinzip eingedämmt werden soll. Reine Überzeugungsarbeit hilft hier nur wenig, die psychologischen Gründe erschweren eine rein fachliche Diskussion. Wenn Mitarbeiter sich verstärkt dem Hey-Joe-Prinzip zuwenden weist es darauf hin, dass das Bedürfnis nach Anerkennung auf dem anderen Weg nicht befriedigt wird. Es ist daher besonders wichtig die gefühlte Anerkennung bzw. das Job-Sicherheitsgefühl im Auge zu behalten.  
© pentaeder 2019 / 2020