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

14 Gedanken zu „Ein agiler Bastard zwischen einem Karnickel und einer Rummelfliege“

  1. Hallo Peter,

    Du hast vollkommen Recht. Viel zu häufig nehmen wir Begriffe in den Mund, ohne diese ausreichend zu hinterfragen, zu definieren oder abzugrenzen. Dies ist im Zusammenhang mit Agilität / Agilem PM sehr häufig der Fall.

    In einem Punkt möchte ich Deine Gedanken ergänzen. Ich denke nämlich nicht, dass agile Prinzipien, Rollenkonzepte und Vorgehensweisen nur im Bereich der Softwareentwicklung Anwendung finden können oder sollen. Ein kurzer (vereinfachender) Gedanke, der diese Hypothese begründen soll:

    Klassisches Projektmanagement = Management von Stabilität: Klassische (Projekt)Managementmethoden sind dann sinnvoll, wenn das Projekt (und das entsprechende Systemumfeld) relativ stabil ist.
    Agiles Projektmanagement = Management von Instabilität: Agile Prinzipien, Rollen und Prozedere machen dann Sinn, wenn das Projektthema (inkl. Umfeld) sehr komplex ist und sich dynamisch entwickelt.

    Natürlich ist das Schwarz-Weiß gedacht, aber ich denke, einfache Gegenüberstellungen können uns an dieser Stelle helfen, ein gemeinsames (Begriffs)Verständnis zu kreieren.

    Viele Grüße, Stefan

  2. Hallo Stefan

    Nochmals: Der Begriff “agil” basiert auf dem Agilen Manifest, das mit den Worten beginnt: “Wir zeigen bessere Wege auf, Software zu entwickeln”. Z.B. auf Bauprojekte kann der Begriff einfach nicht angewendet werden. Das wäre, wie Du sagen würdest: “Die Glocke leuchtet aber sehr laut”. Das kannst Du in poetischem Kontext als eine Art Metapher tun, aber wenn wir von Projekten reden, wollen wir uns ja nicht in Hexametern unterhalten

    Zwar kann ich vermuten, was Du meinst. Aber genau darum ging es in meinem Beitrag: In komplexen, fluktuativen Migrationsprojekten kann ich eben gerade das nicht gebrauchen, was unter agilem Projektmanagement angedacht ist! Meine Migrationsprojekte sind sehr dynamisch. Als Technologieprojekte aufgezogen, bewegen sie sich fast ausschliesslich auf politischem Terrain und enden in Organisationsentwicklungsprojekten, weil sie Machtstrukturen zur Disposition stellen.

    Was mich nervt ist, dass es für viele der Agilen nur klassisches und agiles Projektmanagement zu geben scheint. Aber es gibt viel mehr Ausprägungen. In meinen Projekten wende ich systemisch-evolutionäres (nach Loch, De Meyer und Pich) oder virtuoses (nach Saynisch) Projektmanagement an. Dann gibt es z.B. das transmethodische PM nach Wohland oder Team Syntegrity nach Beer, etc. Während Agiles PM von Programmieren entwickelt wurde und auf Prinzipen gründet, kommen viele alternative Ansätze aus der Theorie und basieren auf wissenschaftlichen Ansätzen. Die verschiedenen Theorien auszuloten, auf denen PM basieren kann, ist dann das Ziel der GPM Forschungswerkstatt Ende November in Berlin.

    Herzliche Grüsse,
    Peter

  3. Danke, Peter, für den Schutz, den du mir mit der Anonymität gewähren wolltest. Aber ich bewege mich mal aus der Deckung heraus.

    Ja, ich habe in einer Email-Konversation auf Nachfrage deinerseits zu diesem Blog-Artikel von mir (http://blog.ralfw.de/2012/07/pseudowissenschaft-agilitat.html) mit den vier genannten Punkten als meine persönliche Definition von Agilität geantwortet.

    In einem weiteren Blog-Artikel habe ich dann aber nochmal nachgebessert durch Reduktion: http://blog.ralfw.de/2012/08/agil-personlich-definiert.html

    In zwei Punkten möchte ich zunächst jedoch das Bild, das du von mir skizziert hast, korrigieren:

    -Ich bin kein “glühender Verfechter” der Agilität. Du als Freund präziser Worte solltest verstehen, dass ich mich dagegen wehre. Denn “glühend” suggeriert Dogmatismus oder gar Fundamentalismus. Nichts läge mir jedoch ferner. Allerdings vertrete ich meine Meinung auch mal bei Gegenwind :-)

    -Du suggerierst weiterhin, dass ich kein so großer Freund präziser Sprache sei, weil ich in einem Zusammenhang mit Begrifflichkeit “Geschmackssache” gesagt habe. Das finde ich schade. Denn es unterschlägt, dass ich mit meinem ersten Blog-Artikel über Martin Fowlers laxe Haltung zu einer Definition von Agilität mir gerade mehr Präzision gewünscht hatte. Und auch zum Beispiel in einer Diskussion im Lean Software Dev Forum bei XING habe ich mich mehrfach für mehr Präzision ausgesprochen: http://bit.ly/W6081I

    Dies aus dem Weg geräumt nun zu deinem Artikel hier. Wenn ich ihn richtig verstehe, dann sagst du, “Leute, nicht alles ist agil oder sollte agil genannt werden. Wenn der Begriff inflationär benutzt wird, verliert er seine Bedeutung.”

    Da bin ich durchaus dabei. Deshalb ja mein Vorstoß bei einer Definition.

    Aber ich bin nicht mehr dabei, wenn du sagst, Agilität sei nur etwas für die Softwareentwicklung. Zwei Gründe habe ich dafür:

    1. Solange wir keine präzise Definition für Agilität haben, können wir die Reichweite des Begriffs nicht beurteilen.
    2. Nur weil ein Begriff in einer Domäne geprägt wurde (z.B. “Nachhaltigkeit” in der Forstwirtschaft), heißt das doch nicht, dass er nicht in einer anderen Domäne auch nützlich sein kann.

    Du führst an, dass ein allgemeines IT-Projekt (z.B. Migration) nicht agil betrieben werden kann.

    Da frage ich: Warum? Aber ich frage eben mit einer Definition von Agilität im Hinterkopf. Nein, damit meine ich nicht das agile Manifest. Das mag Martin Fowler meinen, ich aber nicht. Ich habe von ihm abstrahiert für meine Definition. Denn du hast Recht, solange in Agilität immer “Softwareentwicklung” drin steckt, kommen wir damit nicht weiter.

    Meine Definition ist diese: http://blog.ralfw.de/2012/08/agil-personlich-definiert.html. Und da frage ich dich:

    a. Kann man ein IT-Projekt inkrementell durchführen? Und bevor du “Nein!” rufst, frage ich auch noch: Wäre es wünschenswert, es inkrementell durchzuführen?
    b. Kann man ein IT-Projekt lernend durchführen? Wenn das nicht ginge, wäre das schade für alle Beteiligten. Und der arme Peter Senge hätte ein Problem mit seiner lernenden Organisation.
    c. Kann man ein IT-Projekt in möglichst unmittelbarer Kommunikation aller Beteiligten durchführen?

    Wenn du 3 x mit Ja antworten solltest – was ich ja hoffe :-) -, dann ist das für mich der Beleg, dass man IT-Projekte agil durchführen kann. Ob du das einem CIO so sagst, ist eine zweite Sache. Aber der Anschlussfähigkeit in andere Richtungen könnte diese Titulierung dienen.

    Meine Ahnung ist aber, dass du insb. bei a. zögerst. Das tun auch Softwareentwickler. Ich kann das verstehen – aber ich bleibe dabei: ein inkrementelles Vorgehen ist viel häufiger möglich, als wir uns vorstellen. Es ist nur nicht so etabliert. Es verlang mehr Nachdenken. Doch es ist wünschenswert, wann immer es Unsicherheiten gibt.

    Wenn du allerdings sagst, “Ach, ein IT-Projekt ist einfach nur abarbeiten von Aufgaben. Stumpfes Wegschaffen. Keine Kreativität, keine Unwägbarkeiten.”, na dann muss das nicht agil gemacht werden. So würde ich zum Beispiel über meinen Abwasch reden. Oder die Reparatur eines Fahrrades. Aber IT-Projekte nicht trivialer Größe… die sind ohne Unwägbarkeiten, da ist am Anfang alles sonnenklar, was am Ende rauskommen soll? Nein, tut mir leid, das kann ich nicht glauben.

    Vigilantes (oder norddeutsch: wachsames) und flexibles Vorgehen forderst du ja schon. Finde ich gut. Nur ist das nicht auch gleich inkrementell. Warum eigentlich nicht?

    Bottom line: Ich behaupte nicht, dass Agilität immer und überall zum Einsatz kommen muss. Aber Agilität abzuweisen, nur weil sie mal grad irgendwo nicht erfunden wurde, finde ich auch nicht hilfreich. (Dass übrigens schon seit Jahrzehnten überall woanders agil gearbeitet wurde, kann ich nicht glauben. Und der einfache Beweis: sonst wäre die Softwareentwicklung nicht in das Problem des Wasserfalls gelaufen. Sie hätte ja tolle Rollenmodelle überall gehabt.)

  4. Hallo Ralph

    Ja, ich habe tatsächlich aus einem Deiner Mails zitiert, allerdings ohne Dich persönlich zu adressieren. Du dientest mir einfach als ein Repräsentant der agilen Szene. Ich hatte kürzlich mit einem anderen Freund eine ähnlich Diskussion und hätte auch seine Worte zitieren können. Ich wollte Dich also keineswegs kritisieren. Und ja, das Adjektiv “glühend” mag unbedacht heftig sein. Aber Du bist für mich nun mal mit “agil” verknüpft, und Deine durchaus starke Replik auf meinen Artikel zeigt ja, dass Dir eben auch sehr daran gelegen ist, Agilität zu verteidigen.

    Selbstverständlich kann ich alle Deine drei Fragen grundsätzlich mit “Ja” beantworten, was für mich noch lange nicht heisst, dass die Projekte agil durchgeführt werden sollen/können.

    a. Kann man ein IT-Projekt inkrementell durchführen? Und bevor du “Nein!” rufst, frage ich auch noch: Wäre es wünschenswert, es inkrementell durchzuführen?

    Ein Migrationsprojekt kann ausschliesslich in kleinen, iterativen Schritten durchgeführt werden. Ich habe nie etwas anderes gemacht! Sicher mussten wir am Anfang für den Qualitätspolizisten so etwas Stupides wie einen Projektstrukturplan (Work Breakdown Structure) erstellen. Aber effektiv haben wir rekursiv gehandelt (nicht inkrementell!).

    b. Kann man ein IT-Projekt lernend durchführen? Wenn das nicht ginge, wäre das schade für alle Beteiligten. Und der arme Peter Senge hätte ein Problem mit seiner lernenden Organisation.

    Ein Projekt, ob Entwicklungs- oder Migrationsprojekt, kann man ausschliesslich lernend durchführen! Wobei ich nun keine Diskussion darüber führen will, was wir unter “lernend” verstehen. Das ist ein ähnlich verwaschener Begriff wie “agil”. In einer hitzigen, überaus dynamischen Situation eines Projekts würde es mir herzlich wenig nützen, wenn mir jemand sagen würde, ich solle “lernend” vorgehen.

    c. Kann man ein IT-Projekt in möglichst unmittelbarer Kommunikation aller Beteiligten durchführen?

    Tja, wenn ich bei einem Punkt zögere, ist es dieser. Eigentlich wollte ich zu diesem Punkt auch noch einen Blogbeitrag schreiben. Würdest Du fragen: “Wäre es hilfreich, ein IT-Projekt in möglichst unmittelbarer Kommunikation aller Beteiligten durchzuführen?”, würde ich ohne zu zögern “Ja!” antworten. Aber ob man kann? Ich denke nicht, nein. Der Kunde will möglichst viel zu wenig Geld, der Lieferant will möglichst wenig Arbeit und eine möglichst hohe Marge. Dieses Dilemma lässt sich nun mal – zumindest in einer kapitalistischen Gesellschaft – nicht überwinden.

    Warum muss denn alles agil sein? Warum kannst Du einen Approach, den Du mit Deinen drei Fragen andeutest, nicht einfach “systemisch” nennen? Warum überlässt Du “agil” nicht den Entwicklern?

    Herzlichst,
    Peter

    P.S. Ich weiss, “systemisch” ist auch verwaschen. Aber immerhin hat “agil” die Chance, im Entwicklungsumfeld klar und pränant zu sein, wenn man es lässt. Wir sollten in anderem Umfeld einen passenden Begriff suchen!

  5. Ich glaube, wir haben ein Missverständnis. Du schreibst auf meine Frage nach inkrementellem Vorgehen: “Ein Migrationsprojekt kann ausschliesslich in kleinen, iterativen Schritten durchgeführt werden. Ich habe nie etwas anderes gemacht!”

    Du scheint den Begriff “Iteration” synonym zu “Inkrement” zu benutzen. Das widerspricht aber zumindest meinem Verständnis.

    -“Iteratives Vorgehen”: Wenn ein Ergebnis X in Phasen hergestellt wird – P1, P2, P3 -, dann kann man diese Phasen einmal durchlaufen (Wasserfall) – oder mehrfach. Falls Teilergebnisse x1, x2, x3 sich herstellen lassen und dabei ebenfalls Phasen P1, P2, P3 durchlaufen werden, dann lässt sich das Gesamtergebnis X iterativ produzieren, indem für x1..xn nacheinander immer wieder die Phase P1..Pn durchlaufen werden.

    -“Inkrementelles Vorgehen”: Inkrementelles Vorgehen ist iteratives Vorgehen. Inkremente sind Teilergebnisse. Aber Inkremente i1, i2, i3 sind eben nicht einfach beliebige x1, x2, x3, sondern nur solche, die für sich einen Kundennutzen bieten. (Oder zumindest solche, zu denen der Kunde ein Feedback geben kann, ob die Produktion von X auf dem richtigen Weg ist.)

    Beispiel Auto: Ein Auto wird aus Teilen hergestellt. Als xi können Räder, Motor, Karosserie, Lenkrad, Getriebe angesehen werden. Insofern könnte man ein Auto vielleicht auch iterativ herstellen, weil für alle xi dieselben/ähnliche Phasen durchlaufen werden, z.B. Maschine einrichten, produzieren, Qualität prüfen, einlagern usw.

    Wenn ich aber ein Rad oder einen Motor oder das Getriebe als Teilergebnis hergestellt habe und dem Kunden gebe, dann wird der sagen, “Was soll ich damit?” Das bringt ihn im wahrsten Sinn des Wortes nicht weiter.

    Anders, wenn ich ein Auto inkrementell herstelle. Dann frage ich mich, womit der Kunde schonmal etwas anfangen könnte. Mit einem Motor alleine nichts. Aber ich könnte ihm vier Räder mit Achsen und einer Lenkung “auf einem Brett” montieren, sozusagen eine Seifenkiste. Mit der könnte er schonmal zumindest einen Berg runter sich transportieren lassen.

    Als nächstes käme dann vielleicht ein Motor hinzu und eine Chassis. Dann könnte er den Berg auch wieder hoch fahren – säße aber immer noch im Freien.

    Als nächstes kämen Sitze. Dann wäre das Fahren schon bequemer. Usw.

    Ja, ja, das Beispiel ist künstlich. Aber man sieht zumindest den Unterschied zwischen Iteration und Inkrement. Es sind Äpfel und Birnen: das eine bezieht sich auf das Voranschreiten, das andere auf das Arbeitsergebnis.

    Agilität zeichnet sich durch inkrementelles Vorgehen aus! Iteratives Vorgehen gab es schon vorher.

    Der Vorteil inkrementellen Vorgehens ist, dass der Kunde schneller etwas in die Hand bekommt. Damit kann er schon etwas anfangen – oder zumindest kann er dazu kompetent Feedback geben. Daraufhin könnte die weitere Produktion den Kurs anpassen.

    Häuser lassen sich schwer inkrementell bauen. Aber Siedlungen werden sicherlich inkrementell gebaut. Da legt man nicht erst überall Fundamente und dann überall Wände drauf und dann überall Dächer drauf usw. Sondern es wird Haus für Haus Wohnnutzen hergestellt.

    Das halte ich für ein wünschenswertes Vorgehen überall. Und je größerer die Unsicherheiten in dem, was hergestellt werden soll, desto wichtiger ist es, inkrementell zu arbeiten.

    Bei Reproduktionen ist das nicht wichtig. Klar. Bei jeder Form von Entwicklung, also letztlich ungewissem Ausgang, scheint es mir jedoch das Gebot der Stunde.

    Mit dem Begriff “systemisch” bin ich vorsichtig. Ich gebrauche ihn auch – aber sicher nicht statt “agil”.

    Dass du die Unmittelbarheit für so schwierig erachtest, kann ich verstehen. Aber das macht es aus meine Sicht nur umso wichtiger, sich um sie zu bemühen. Ja, auch in ihrer Betonung sehe ich eine Leistung der Agilitätsbewegung – die damit über die Softwareentwicklung hinaus strahlt.

  6. Hallo Herr Addor,

    ich kann Ihnen, nur zustimmen.
    Habe mich viele Jahre mit Softwareprojekten,
    in denen Software selbst entwickelt UND im Unternehmenskontext
    eingeführt wurde beschäftigt….

    Es liegen “Welten” zwischen der Entwicklung der Software
    und einer Umsetzung / Einführung / Mirgration derselben.

    Zur besseren Orientierung verwendeten wir Demingkreise für die Umsetzung / Einführung / Integration.

    Die Entwicklung der Software war dabei teilweise inkrementell, aber leider geht das nicht immer ;-) also war sie auch teilweise iterativ…

    Der Demingkreis findet Analogien: Beispielsweise im Scrum-Vorgehensmodell (Agil).
    Leider ist es aber nicht so, dass man zB Scrum durchgehend im Demingkreis findet ;-)

    Sehr gut finde ich dazu diesen Beitrag aus dem Open-Loops-Blog:
    http://blog.setzwein.com/2009/05/25/der-deming-cycle-und-scrum/

    Dieser zum Demingkreis mE zugehörige (Meta)Prozess:

    Step-x -> Definieren (also: Dokumentieren, Schulen, Institutionalisieren)
    Step-y -> Verwenden & Analysieren (also: Messen, Auswerten, Lenken)
    Step-z -> Ändern (also: Anpassen, Schwächen eliminieren, Automatisieren)

    hilft einem evtl. dabei weiter, einen Konsens zu finden, in welchen Bereichen
    Agilität (auch als Begriff) gefordert wird und in welchen eher nicht.
    Zudem macht er deutlich, dass man nur mit vielen! Ansätzen & Begriffen weiterkommt…

    Mir hätte die begriffliche Trennung in der Vergangenheit geholfen, da ich sowohl für die Weiterentwicklung der Software, als auch für die Einführung / Integration, als auch für den darin enthatenen Prozess, dessen Optimierung, Test und Schulung ;-) “zuständig” war.

    Heute wird eine solche Software” mit “Scrum” von einem Team entwickelt und die übrigen Bereiche können auch so “organisiert” werden, wie es für die jeweiligen Bereiche paßt…

    Da es sich um vebundene Bereiche handelt, mit jeweils unterschiedlichen Rahmenbedingungen, aber einem gewünschtem Endergebnis, finde ich persönlich den Begriff “System” völlig ok.

  7. Lieber Peter,

    danke für deinen Artikel und auch für die Diskussion auf Xing.

    Ich frage mich, ob es wichtig ist, “agil” präzis zu definieren:
    – Agile Methoden gehören zu den “emergenten Praktiken” (gemäss Cynefin), d.h. es ist von keinem Nutzen, sie im voraus genau definieren zu wohlen. Darum entwickeln sich auch aus den agilen Prinzipien fortlaufend hybride Methoden.
    – wichtiger als eine genaue Definition scheint mir die Fähigkeit, im Dialog ein gemeinsames, situationspezifisches Verständnis von was unternommen wird zu entwickeln. Situationspezifisch heisst für mich am jeweiligen Projekt, mit allen Betroffenen. Dass die Welt komplexer wird heisst auch, dass es immer wichtiger wird, multidisziplinär und multikulturell zu arbeiten. In einem solchen Kontext ist eine genaue Sprache kaum von Nutzen, dafür die Dialogfähigkeit ist entscheidend.
    – und zum Schluss: egal wie das Ding heisst (mir sind gewisse von dir erwähnte Ansätze auch bekannt), wir wollen ja Mehrwert schöpfen. Für das sind einschränkende Begriffe nicht immer hilfreich: Wörter sind und bleiben nur Konzepte und sind keine Realität, wir wollen an dieser Realität arbeiten und nicht an deren Beschreibung.

    Lieber Gruss

    Philippe

    1. @Philippe: Puh, “wir wollen an der Realität arbeiten und nicht an deren Beschreibung”… Ich weiß nicht, ob ich da so einfach hurra rufen kann. Etwas besser machen, ist natürlich ne gute Sache. Aber ich bin im Zweifel, ob das gut funktioniert, wenn man nicht an Beschreibung interessiert ist. Alles beginnt doch mit Wahrnehmung, geht weiter über die Beschreibung (Bewusstmachung) und erst dann in die Analyse und den Entwurf von Neuem mit schließlicher Handlung.

      Da ziehe ich auch mal die Gewaltfreie Kommunikation (GfK) an Zeugen heran. Die arbeitet an einer Verbesserung der Kommunikation. Und das beginnt damit, dass man insgesamt bewusster wird und mit einer expliziten Wahrnehmung beginnt und die zunächst beschreibt. Deutungen kommen erst danach. Und Wünsche (für Handlungen) stehen am Ende.

      Ich merke es auch immer wieder in Analyse- und Entwurfssitzungen bei der Softwareentwicklung, wieviel dort daneben geht, wenn nicht auf eine präzise Sprache geachtet wird. Missverständnisse lauern überall. Präzise Sprache ist ja auch nur bei präzisem Denken möglich. Wo die Sprache unpräzise ist, ahne ich daher schnell unpräzises Denken. Und das ist der Tot jeder Software. Anders kann ich mir das für kein komplexes Produkt vorstellen.

      Und in komplexen Situationen? Da soll Präzision nicht wichtig sein? Für mich steht das nicht im Widerspruch. Ich muss mir nur bewusst sein, wie weit die Präzision reicht. Innerhalb meines Beobachtungshorizonts halte ich sie für unabdingbar.

  8. @Ralf
    Einverstanden mit dem Kommentar, es braucht eine Beschreibung, eine Bewusstmachung. Ich ziehe meine Argumentation noch etwas weiter…

    Eine gemeinsame Sprache ist mir wichtiger als eine präzise Sprache. Wichtig ist, sich gegenseitig zu verständigen, und nicht unbedingt, in voraus definierte “richtige” Wörter anzuwenden. D.h. eben Dialog vor Wörterbuch.

    Wörter sind nur Konzepte, Konventionen, Abmachungen, die uns das Leben erleichtern sollen. Gewisse Wörter finden konsensuales Verständnis und Akzeptanz (wie zB. “Haus” oder “Tisch”) – und noch, verlangen wahrscheinlich doch Dialog (“was für ein Haus”) .

    Ich sehe wenig Nutzen, “agil” präzis definieren zu wollen. Eine präzise Definition ist an sich keine Garantie für ein gemeinsames Verständnis – im Gegenteil, könnte zu Scheinverständnis führen, à la Bullshit-Bingo. Wichtiger ist, wie die Aktören “agil” verstehen und wie sie es praktisch umsetzen (eben, emergente Praktiken), insbesondere in komplexen Situationen.

    Oders anders gesagt: es geht über Dialog um der Konstruktion einer gemeinsamen Realität, die handlungsfähig macht – aber es wäre ja schon eine philosophische Frage…

    1. @Phillipe: Bedeutungen entstehen (und verändern) sich im Diskurs. Da bin ich dabei.

      Bedeutungen a priori festzuzementieren ist weder immer möglich noch hilfreich.

      Deshalb jedoch auf Präzision zu verzichten oder sie als quasi unmöglich anzusehen, erscheint mir auch keine Lösung.

      In einer Gruppe kann und sollte zu jedem Zeitpunkt eine möglichst genaue gemeinsame Vorstellung davon existieren, was Begriffe bedeuten. In dem Moment. Nicht auf ewig. Nicht dogmatisch. Aber eben in der Gegenwart auf der Höhe des Diskurses.

      Dann kann auch jemand neu zum Diskurs stoßen und fragen, “Was bedeutet X denn?”

      Meine Projekterfahrung zeigt mir einfach, dass auf solche Fragen ob nur schwer geantwortet werden kann. Oder es gibt gleich mehrere Antworten. So auch der Begriff “Agilität”. Was bedeutet der denn? Wenn wir das nicht auf der Höhe unserer Zeit genau sagen können… dann müssen wir im Grunde ganz nach Wittgenstein schweigen.

      Immer wieder werden Begriff lax gebraucht in dem guten Glauben, alle Diskursteilnehmer würden ja schon dasselbe darunter verstehen. Das tun sie aber nicht. So entstehen Missverständnisse und Konflikte. Die kosten viel, viel Zeit und Geld.

      Mehr Obacht bei der Sprache scheint mir daher ein wichtiges Gebot. Wir wollen doch nicht einfach so daherreden. Ich möchte dich verstehen, ich möchte dich “beim Wort nehmen” können. Dafür müssen wir eine präzise gemeinsame Sprache sprechen. Im Softareprojekt ist das zum Beispiel auf die Problemdomäne bezogen die Ubiquitous Language (vgl. Eric Evans, Domain Driven Design).

  9. Philippe, ich hoffe ich verstehe Dich richtig:
    Mit meinen Worten verstehe ich Dich so:


    Man muss eine Tür öffnen, um in ein Zimmer zu gelangen.
    Mit der Sprache öffnest Du die Tür und mit den Begriffen stattest Du das Zimmer aus.

    Meine Erfahrung ist die, dass es oft nicht um die Sprache geht, sondern um Interessen und Dominanz. Man kann auch sehr freundlich, oder wortlos Türen verschließen…
    …wenn eine Einigung mit “Nachteilen” verbunden ist.

    _______________________________

    Da fällt mir noch ein, das Stefan einen Begriff für ein “neues” PM gesucht hat.
    Ich würde dafür den Begriff “Humanistisches PM” nehmen. Man könnte sich dadurch auch auf die Humanistische Psychologie beziehen, die davon ausgeht, dass der Mensch Potentiale hat, die es zu entwickeln gilt. Die GfK kann übrigens auch der Humanistischen Psychologie zugeortnet werden…
    Die GfK könnte daher als “Haltung/Sprache” durchaus zu den Tools gehören ;-).
    Ebenso wie Agile Methoden….

  10. @ Ralf: Danke für den Austausch, ich stimme zu!

    @ Bernd: schöne Metapher! und ich bin gleicher Auffassung: es geht eigentlich nicht um Wörter, sondern um Werte und Bedürfnisse.
    “Humanistisches PM”: ich wäre dabei. Persönlich nenne ich diese Art PM – oder Management allgemein – zu betreiben “real life PM”, abseits von technokratischen, gewaltsamen, imaginären, unbewussten, reduzierenden, dogmatischen, giftigen etc. Vorgehensweisen.

  11. @Philippe:
    Wenn “real life PM” so für Dich ist, kann ich Dir nur raten dabeizubleiben
    und genauso weiterzumachen!

    Für Andere kann das “real life (PM)” bedeuten nicht zu den “Auserwählten” zu gehören…
    …und spätestens da fängts dann an richitig komplex zu werden ;-)

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>