Follow my new blog

Montag, 30. Juli 2012

Pseudowissenschaft Agilität

imageWas Agilität ist, weiß selbst Martin Fowler nicht zu definieren. Das sagt er in seinem Blogartikel:

[…] lack of rigorousness is part of the defining nature of agile methods, part of its core philosophy. […] Any attempt to define a rigorous process that can be tested for conformance runs contrary to [the agile] philosophy.

Es sei also vergeblich, einen rigorosen Prozess agilen Vorgehens definieren zu wollen. Das entspräche nicht der Philosophie der Agilität, dem agilen Denken.

Ich bin erschüttert.

Was für eine Bankrotterklärung der Agilität! Ausgesprochen von einem Unterzeichner des agilen Manifests.

Damit stellt sich die Agilitätsbewegung das Zeugnis einer Pseudowissenschaft aus: Sie entzieht sich der Falsifizierbarkeit und macht sich vom Urteil von “Geweihten” abhängig. Denn:

  • Wo keine Definition, da kein Vergleich der Realität mit einer Definition und also keine (Miss)Erfolgsmessung. Behauptet jemand, agil zu arbeiten, vermisst jedoch den erhofften Erfolg, dann kann nicht überprüft werden, ob er denn überhaupt und wirklich agil arbeitet. Das erschwert die Implementation agilen Vorgehens. Und das leistet andererseits der Leugnung von Misserfolgen bei agilem Vorgehen Vorschub.
  • Auch wenn es an einer Definition der Agilität mangelt, ja – wie Fowler sagt - mangeln muss, können Martin Fowler und “der erfahrene Praktizierer” dennoch erkennen, ob agil vorgegangen wird. Ohne Definition von Agilität, bedeutet das allerdings eine Kette von “Weihungen” ausgehend von Martin Fowler (oder vielleicht einem anderen Unterzeichner des agilen Manifests). Denn wie sonst könnte jemand zum “erfahrenen Praktizierer” werden? Ohne Definition kann ja niemand selbst feststellen, ob er/sie agil arbeitet.

Definitionslosigkeit und “I know it when I see it” [Zitat Fowler] sind nun leider die besten Voraussetzungen für Fundamentalismus, Dogma, Abgeschlossenheit, Kritikimmunität.

Nicht, dass wir davon in den vergangenen Jahren nicht schon Anzeichen gesehen hätten. Die Diskussionen mit Agilitätsvertretern konnten immer schon, hm, “intensiv” werden… Aber dass nun der Martin Fowler dafür die Rechtfertigung liefert… Nein, das kann ich kaum fassen.

Was sollen denn jetzt Laien von der Softwareentwicklung denken? Was sollen angehende Informatikstudenten von der Agilität denken? Ich kann das schenkelklopfende Lachen in Universitäten wie Chefetagen schon hören. “Was haben sich die Softwarefuzzis da denn ausgedacht? Meinen, mit dieser agilen Mode etwas besser zu machen – und wissen dann nicht mal zu sagen, was es ist? [ROFL]”

Die Alternative: Wissenschaftlichkeit

Wenn Martin Fowler es nur schwer fiele, Agilität bzw. agiles Vorgehen zu definieren, dann wäre ich ganz bei ihm. Vom agilen Manifest bis zu einer Definition und dann auch noch der Messung des Erfolges von Implementationen dieser Definition… das ist ein weiter Weg.

Doch auch wenn es sich schwierig ausnimmt, sollte man es nicht unversucht lassen, glaube ich. So ist das halt mit der Wissenschaftlichkeit.

imageNur mit einem wissenschaftlichen Ansatz kann die Agilität (oder auch Lean usw.) hoffen, jenseits von Glaubensbekenntnissen und Hype und anekdotischen Erfolgen ernst genommen zu werden. All die, auf die sich auch Agilisten gern berufen – von Turing über Parnass bis Kay – sind Wissenschaftler (gewesen). Es stünde der Agilität daher gut zu Gesicht, sich vertrauensvoll in deren Tradition zu stellen. Das heißt, die Agilitätsbewegung müsste ihre Methode oder Philosophie als Hypothese anerkennen.

Denn mehr ist es nicht, was das agile Manifest und alles, was zur Agilität geschrieben wurde, darstellt: eine bloße Behauptung.

Eine wie auch immer (nicht) definierte Methode und Philosophie steht im Raum; ein mehr oder weniger schwammiges Erfolgsversprechen ist daran geknüpft. Und das gilt es nun auf Wahrheit zu überprüfen. Ganz ergebnisoffen. So ist das mit der Wissenschaftlichkeit.

Was immer Agilisten auch behaupten mögen, ist ja ok. Da gibt es keine Grenzen. Das mag grob oder fein sein, konzeptionell oder technologisch, abstrakt oder konkret… Egal. Nur steckt in der Behauptung eben noch keine allgemein akzeptierbare Wahrheit. Die muss erst in einem Diskurs und durch Experimente entwickelt werden. Dazu gehört natürlich eine Messlatte. Das ist eine klare Definition inkl. Ergebniserwartung. Die müssen vorliegen, bevor ein Experiment gemacht wird.

Und dann… dann schaut man, ob die Definition im Experiment implementiert wurde und das vorhergesagte Ergebnis eingetreten ist. Vielleicht hat es geklappt, vielleicht nicht. Dann ist Ursachenforschung zu betreiben. Dabei kann herauskommen, dass die Hypothese angepasst werden muss. Und vielleicht kommt dadurch heraus, dass die Agilität nicht so einfach heilsbringend ist, wie sie gern möchte. Es kann also passieren, dass auch Agilisten etwas lernen müssen.

Aber ist das nicht normal? Ist das nicht im Grunde im Sinne der Agilität? Ach so, das kann man nicht so genau wissen. Denn es gibt ja keine allgemeine Definition.

Fazit

Ich halte ja eine ganze Menge von der Agilität. (Jedenfalls von der, für die ich meine eigene kleine Definition habe. Ob und inwiefern die allerdings mit dem “Gefühl” von Martin Fowler übereinstimmt, weiß ich natürlich nicht. Ich bin von ihm nicht “geweiht”.) Aber ich sehe eine große Gefahr für die Agilität heraufziehen, wenn Martin Fowlers Position allgemein akzeptiert wird. Der Dogmatisierung ist dann nichts mehr entgegen zu setzen. Und das würde sie diskreditieren.

“Die Agilität” täte aus meiner Sicht also gut daran, alle Anzeichen von Immunisierung und Unwissenschaftlichkeit zu zerstreuen. Das mag weh tun, wenn man sich denn endlich mal hinsetzen muss für eine Definition… aber es hilft halt nichts. Auch im Definitionsschmerz kann eine wertvolle Erkenntnis stecken.


PS: Hm… Nun kann es natürlich sein, dass Martin Fowler & Co nicht daran interessiert sind, die Agilität wissenschaftlich zu machen oder einfacher: überprüfbar zu gestalten. Wenn das so ist, na, dann müssen sie das nicht tun. Nur dürfen sie sich dann aber auch nicht darüber beklagen, dass die Ergebnisse gemischt ausfallen und Akzeptanz auf der Strecke bleibt. Wer nicht genau sagen kann, was er meint, der kann eben auch nicht verstanden werden.

Dasselbe gilt übrigens für die Objektorientierung, würde ich sagen. Oder auch SOA. Mit ihnen stehen auch Hypothesen im Raum. Versprechen wurden mehr oder weniger genau, in jedem Fall blumig gegeben. Die Überprüfung allerdings, die fällt schwer.


PPS: Und was ist mit der Clean Code Developer Initiative? Verspricht die nicht auch etwas? Stellt sie nicht auch eine Hypothese dar? Klar. Aber erstens scheuen wir uns bei CCD nicht vor eine Definition. Schon gar nicht glauben wir, dass es CCD inhärent sei, einer Definition zu widerstehen. Zweitens scheint uns die Hypothese von CCD schon recht klar:

  • Das Wiki definiert, was man tun muss, um ein CCD Experiment zu starten: Folge den Prinzipien, setze die Praktiken ein. Je mehr, desto besser. Ob das passiert, lässt sich auch von “Ungeweihten” nachvollziehbar feststellen :-)
  • Das Wiki formuliert (implizit) als Hypothese: Die Korrektheit, Evolvierbarkeit und Produktionseffizienz steigen, wenn man den Prinzipien und Praktiken folgt. Auch das lässt sich von “Ungeweihten” nachvollziehbar feststellen :-)

Sicherlich könnte die Hypothese noch klarer werden. Wer dazu beitragen will, ist herzlich eingeladen. Grundsätzlich empfinden wir uns aber schon auf dem wissenschaftlichen Weg. Und wenn wir CCD damit “angreifbar” (falsifizierbar) machen, dann ist das völlig ok. Wir stellen das Ziel “bessere Software” über den Weg.

17 Kommentare:

pvblivs hat gesagt…

Ich würde Scrum als relativ rigoros bezeichnen. Aber nicht einmal Scrum ist ein Prozess sondern nur ein Prozessgerüst. Selbst wenn man mit Scrum anfängt gibt einem Inspect&Adapt die Anregung, um das Team noch besser zu machen, die schon relativ rigorosen Grenzen von Scrum einzureißen.

Pseudowissenschaft hin oder her. 'Agile' ist nicht ein spezifischer Prozess. In erster Linie bedeutet 'agile' mal sich schnell und einfach bewegen zu können. Agile als Wort im Kontext der Softwareentwicklung benennt also das Ziel wie Softwareentwicklung sein sollte. Und sagt bewusst: Der Prozess dafür ist zweitrangig, die Menschen arbeiten, wie sie es brauchen, sagt das agile Manifest. Und wenn es nicht mehr passt, dann ändern sie es.

Und alles was Fowler nun sagt, ist, dass man nicht viel spezifischer werden kann. Das es ausreichen muss, dass Menschen aus verschiedenen Disziplinen an einem Ort zusammenkommen um möglichst nah am Kunden Software schnell live zu bringen. Warum denn auch genauer?

Prozesse schreiben keine Software. Wozu also der Schrei nach mehr Rigorosität in der Prozessdefinition? Wirklich nur, weil jemand der Bedürfnis nach mehr Kontrolle hat sonst den Erfolg nicht genau genug einem Budget zuordnen kann? Dann lasst uns doch wieder anfangen zu kontrollieren. Je genauer desto besser. Bis wir endlich alle konform sind. Oder den Arbeitgeber dorthin wechseln, wo beste Ergebnisse zählen, nicht Konformität.

Anonym hat gesagt…

„Definitionslosigkeit und “I know it when I see it” [Zitat Fowler] sind nun leider die besten Voraussetzungen für Fundamentalismus, Dogma, Abgeschlossenheit, Kritikimmunität.“ Glücklicherweise sind das auch die besten Voraussetzungen für Kreativität, Fantasie, Offenheit und ermöglicht z.B. Kunst.

Thomas hat gesagt…

Prozesse haben einen gravierenden Nachteil, sie abstrahieren den Menschen, sie versuchen den Menschen über Rollen gleich zu machen, sie gehen nicht auf die Individualität der einzelnen Personen ein. Daher ist es unmöglich mit den Mitteln einer Prozessbeschreibung "agile Vorgehensweisen" zu beschreiben, da ja diese den Menschen, die Person mit seinen Fähigkeiten in das Zentrum der Betrachtung rückt. Ich denke über Beschreibung über Regeln, lässt sich Agilität" nicht greifen.

Ralf Westphal - One Man Think Tank hat gesagt…

Ich verstehe gar nicht, dass ihr (@pvblivs und @Thomas) mich auf Prozessbeschreibungen festlegen wollt.

Es geht mir nicht darum, eine agile Technologie oder einen agilen Prozess im Speziellen rigoros beschrieben zu bekommen.

Viel allgemeiner geht es mir um Eigenschaften von Handlungen, Prozesse, Werkzeugen, Methoden oder sonstwas.

Wenn Agilität da keine klar formulierbare "Idee" hat, wie agile Eigenschaften aussehen... dann frage ich mich "Was ist denn Agilität?"

Vielleicht sind Wenn-dann-Formulierungen ein Definitionsmittel? Beispiel: "Wenn die Entwicklung periodisch über sich reflektiert, dann ist sie agil."

Oder ist euch das zu prozessbezogen? Dann vielleicht: "Wenn Software ohne Kommentare verständlich ist, dann ist sie agil entwickelt worden." Das wäre eine "agile Eigenschaft" von Code.

Wie gesagt: Mir ist egal, auf welchem Abstraktionslevel die Definition ansetzt. Nur solange die Hypothese "Mit Agilität wird Software besser" nicht genauer sagt, was denn Eigenschaften von Agilität sind (oder welches "besser" sie meint), solange kann Agilität nicht überprüft werden.

Und solange kann auch jeder für sich behaupten, agil zu sein. Dann kommen wieder andere, die behaupten, man sei nur agile-but. Dafür gibt es aber keine Grundlage, weil es keine Definition gibt usw. usf. Das kostet doch alles nur Kraft. Daran kann niemandem gelegen sein.

Keine klare Hypothese aufzustellen, mag weise klingen. Dann sind Interpretationen möglich usw. Ist auch ne schöne Haltung. Nur darf man sich dann nicht wundern, wenn diese Interpretationen dann munter ins Kraut schießen. Das sehen wir ja munter am Werk bei den Religionen. Da geht von Waffensegnung bis Mutter Theresa alles unter dem selben Dach. Alles nur Interpretationen.

Wie gesagt: auch schön. Kann man machen. Wäre für mich nur nicht das passende Weltbild für ein Business. Kunden wollen Ingenieure und keine Ausleger einer agile Kabbala.

pvblivs hat gesagt…

Du hast ja 2 Beispiele genannt, Ralf. Beide Beispiele kann man im agilen Kontext in Frage stellen:

Regelmäßige Reflektion kann so agil werden, dass Retrospektiven stattfinden, wenn 3 Impediments irgendwo an der Wand kleben. Und wenn die Zettel nicht kommen, das Team aber sehr gut funktioniert und 'liefert', dann ist das für einen Zeitraum sicher auch ok, wenn man dann keine Retro von außen erzwingt. Die Frage ist ob das Deinen Business-Kontrolleuren ausreicht, wenn man das so wischi-waschi formuliert. Da ist es doch schöner, wenn jedes Team alle 2 Wochen Retrospektiven macht und man hinterher Verbesserungsvorschläge zählen kann.

Wenn Software ohne Kommentare verständlich ist, ist sie dann im Sinne von agil? Vielleicht ja. Vielleicht ist auch BDD agil, wo die Dokumentation Teil des Codes ist aber nicht wirklich der Code selbst. Vielleicht ist es auch agil, wenn man die JavaDoc seiner API eigenverantwortlich immer 'good enough' im Rahmen der Story mitpflegt.

Vielleicht ist auch TDD agil. Aber ist es nicht auch ok, mal Software ohne viel Testabdeckung rauszudrücken, wenn sie nur ein Experiment ist und man gar nicht weiß ob man tollen Code braucht, weil man hinterher eh wieder wegwirft?

Ein Teil der Agilität sind die Tools wie Taskboards, TDD, lesbarer Code, Retrospektiven. Ein anderer Teil dessen ist, dass man die Tools bedacht einsetzt oder auch nicht.

Und nun noch "[So ganz ohne klar abgrenzendes Prozessrahmenwerk] wäre für mich nur nicht das passende Weltbild für ein Business": Vielleicht erklärt es das auch. Wenn die Softwareentwicklung als Vorgang oder Dienstleistung das Business ist, dann braucht man vielleicht eine solche Rechtfertigungsgrundlage. Wenn man Produkte entwickelt, dann zählen die Ergebnisse. Und da, plakativ gesagt, sperrt man einfach die besten Ingenieure, Tester, Maschinenhersteller, Materialspezialisten etc. in einen Raum und setzt ihnen eine enge Frist. Und vermeidet es, mit Prozessen reinzuquatschen. Und füllt mir ja alle Eure Anwesenheitszeiten aus, bevor ihr abends nach Hause geht. Und vergesst nicht dieses und jenes Update-Meeting zu besuchen.

Der Kern der Agilität ist es eben, alles zu tun, außer alles das, was nicht notwendig ist.

Thomas hat gesagt…

Bis vor einem halben Jahr habe ich von Agilen Entwicklungsprozessen gedacht "Was soll der Scheiß?". Ich bin in Projekten sehr gut gefahren, mit Projektplanung und Durchführung (es gab bei mir auch Abweichungen, die Zukunft lässt sich nicht vorhersagen). Dann kam mir das Buch "Lean Startup" von Eric Ries zwischen die Finger. Mit diesem Buch habe ich überhaupt erst mal Verstanden, welchen Grundgedanken der Agile Prozess folgt, dann ergab es für mich auch einen Sinn.
Folgendes Zitate beschreiben es sehr passend:
-"Schlankes Denken definiert den Nutzen als Bereitstellung von Vorteilen für den Kunden, alles andere ist überflüssig"
- "Wenn man Nutzer fragt, geht es ums zuhören und nicht um das Umsetzen ihrer Ideen/Anforderungen"
-"Diskussionen über die Qualität setzen voraus, dass ein Unternehmen bereits weiß, welche Produktmerkmale der Kunde erstrebenswert findet."

Die Basis dafür ist die Infragestellung grundlegender Denkweisen der Produktion (auch Quellcode wird produziert) Ein sehr gutes Beispiel in diesem Buch ist, welche Methoden es gibt und welche am effizientesten sind, um Einladungen für einen Geburtstag anzufertigen. Dieses Beispiel, stellt den kompletten Denkansatz für unsere heutige (Massen)Produktion in Frage und natürlich auch die der Softwareproduktion (z.B. wiederverwendbarer Quellcode)

Um jetzt noch ein konstruiertes Beispiel zu geben.
Ich habe einen Prozess, der vorschreibt, dass jede Funktion einer Software mit einem autom. Test abgedeckt wird. Befinde ich mich jetzt in der Entwicklung würde ich die Funktion implementieren und danach den Test (oder andersrum). Agil wäre, wenn sich während der Entwicklung herausstellt, dass die Funktion keinen wahren Nutzen bringt. Stelle ich mir doch die Frage, soll ich daran weiter entwickeln und eventuell noch Zeit investieren für die Tests, damit alles schön sauber ist?
Agil wäre es, zu dem Zeitpunkt der Feststellung der "nutzlosen" Funktion die Kehrtwende zu schaffen und alle Arbeiten, die mit dieser Funktion zusammenhängen (Entwicklung, Test, Marketing) über Bord werfen zu können um dadurch Ressourcen zu sparen.
Denn:
"Es gibt nichts, was nutzloser wäre, als mit großer Effizienz eine Arbeit zu verrichten, die überhaupt nicht verrichtet werden sollte" (Peter Drucker)

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: Schön gesagt. Ich finde das Buch auch sehr lesenswert.

Nur was du am Ende beschreibst, fällt nicht unter Agilität. Sag ich mal. Weil du mir nicht das Gegenteil zeigen kannst. Es gibt ja keine Definition von Agilität.

Was haben wir also von dem Begriff, wenn jeder ihn benutzen kann wie er will. Du kannst behaupten, das von dir Beschriebene sei agil - ich behaupte das Gegenteil. Da stehen wir dann. Keinen Schritt weiter. Nur um einen Streit reicher, weil wir uns am Begriff aufreiben. Der Grund: er ist nicht definiert.

Da sag ich mal: dann lassen wir ihn doch einfach fallen. Ohne Definition brauchen wir keine Agilität.

Thomas hat gesagt…

Hallo Ralf,
mir fällt es auch schwer ein passende Definition für "Agile" Vorgehensweisen zu finden. Ich vereine für mich darunter alles was irgendwie im Kontext steht mit den Methoden Kanban, Scrum, usw.... das ist natürlich keine Definition, das hat eher was von einer Kategorie oder Sammelbegriff.

Mir ist heute Früh noch ein Beispiel eingefallen, was ich sehr treffend finde. Eine Firma X möchte ein neues Softwareprodukt an den Markt bringen.Würde die Firma klassisch vorgehen, würde sie für das Produkt ein Entwicklungsbudget bereitstellen, das Produkt (mehr oder weniger) sauber entwickelt, es wird auf Architektur und Tests geachtet, es wird darauf geachtet das die Software evolvierbar ist usw., es wird Marketing betrieben. Dann kommt der Tag Y in dem das Produkt an den Markt kommt. Die Kunden sagen "nö brauchen wir nicht, interessiert uns nicht" und kaufen das Produkt nicht. Das bedeutet doch, dass alle Tätigkeiten die wir zuvor ausgeführt haben Verschwendung sind. Dass der gut evolviebare Quellcode uns überhaupt nichts bringt (ausser Erfahrung).
Nun möchte ich kurz beschreiben wie dies eine Firma Z durchführt. Die Firma entwickelt ein Produkt mit minimaler Funktion (MFP - Minimal Funktionierendes Produkt) Die funktionen sind die Hauptfunktionen der Produktidee. Dieses MFP ist so gering, das es innerhalb von wenigen Tagen, Wochen fertiggestellt wird, es ist so gering, dass sich nur ein manueller Test lohnt. Geschweige denn automatische Test, es steht ja noch nicht fest ob das Produkt weiterentwickelt wird, ob es überhaupt einen Release 2 gibt. Mit diesem Produkt ist die Firma Z sehr schnell am Markt und holt sich Rückmeldungen der Kunden ab. Anhand diese Rückmeldungen kann die Firma entscheiden ob der eingeschlagenen Weg richtig ist oder Teile oder der gesamte Weg verworfen werden muss. In diesem Punkt wäre der Verlust relativ gering (verglichen mit dem Vorgehen der Firma X), da für das MFP nicht sehr viel Arbeit angefallen ist. Nehmen wir an es zeichnet sich ein Erfolg ab, das Produkt wird durch die ersten "First Adopter" gekauft und genutzt und die Firma will diesen Weg weiter gehen. Den First Adoptern ist z.B. wichtiger das sie ein Produkt zuerst haben und verzichten lieber auf Standards oder sogar auf funkt. Qualität (z.B. erste IPhone, Minecraft). Die Firma möchte jetzt aber in den Massenmarkt. Der Massenmarkt benötigt Referenzen (vorhanden durch die First Adopter) und er erwartet hohe funktionale Qualität. In diesem Fall ist es dann wichtig das Produkt sauber zu entwickeln, mehr Features zu integrieren und das ganze sauber abzusichern. Es muss sich also von der prototyphaften Implementierung getrennt werden. Dies kann z.B. erreicht werden indem das ganz Produkt auf eine neue Codebasis gestellt wird.

Fazit:
Firma X hat eine Vorgehensweise für die Produkterstellung
Firma Z hat für die Produktentwicklung zwei Vorgehensweisen, die Abhängig davon sind an welche Kundentyp das Produkt verkauft wird (schon strange oder ;))

Ich denke, dass mit dieser "Regellosigkeit", "Definitionslosigkeit" einfach diese situationsangepassten Vorgehensweisen gemeint sind.
Der Fokus wird auf das Produkt gelegt, in dem Sinne was beim Kunden ankommt, was der Kunde kauft. Architektur, Clean Code,Test wirken in einem Projekt auf die Effizienz, aber nicht auf die Effektivität (Mein Produkt wird nicht gekauft weil es eine besondere Architektur hat). Also ich erreiche dadurch eine schnellere Produktion von Features aber wenn diese Features nicht zum Kundennutzen beitragen, nützt mir diese Effizienz nichts.

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: Im besten Fall haben wir immer noch ein Missverständnis. Das liegt wohl daran, dass für dich etwas implizit ist, was für mich explizit sein muss: das Ziel.

Du beschreibst Herangehensweisen an die Produktentwicklung, vielleicht traditionell und lean.

Bei der Softwareentwicklung gibt es dann z.B. Wasserfall/Phasenmodell, Agil, Lean. Oder konkreter Scrum, XP, VModel-XT, Kanban usw.

Das sind doch aber alles nur Mittel.

Hinter denen steckt aber ein Ziel. Es gibt für Leute, die sie einsetzen eine Erfolgsdefinition. Und deshalb gibt es eine Beziehung wie "Wenn ich Mittel M einsetze, dann erreiche ich Ziel Z." oder "Wenn ich Mittel M einsetze, dann habe ich Erfolg." (Und implizit ist, dass das Ziel eher erreicht, der Erfolg eher hergestellt wird, als wenn man ein anderes Mittel einsetzt.)

Diese Wenn-dann-Beziehung ist nun nichts weiter als eine Hypothese. Genauso ist es eine Hypothese, wenn ich sage "Mit einem Hammer (M) kriege ich den Nagel schneller in die Wand (Z)." (und in Gedanken dahinter: "als mit einem Schuh") (Habe hier Wenn-dann durch Mit-Komparativ ersetzt.)

Ebenfalls eine Hypothese: "Mit Flow-Design (M) funktioniert A, B und C bei der Softwareentwicklung besser (Z)."

Und die Agilisten sagen: "Mit Agilität (M) funktioniert der Softwareentwicklungsprozess besser (Z)."

Das ist die Hypothese. Nicht mehr, nicht weniger.

Allerdings gehört eben zu einer Hypothese dazu, dass man die Bedingung (Wenn) und das Ergebnis überprüfbar formuliert. Ein Experiment zur Prüfung der Hypothese muss feststellen können, ob es die Bedingung erfüllt und ob das vorhergesagte/hypothetische Ergebnis eingetreten ist.

Was ist als "Agilität"? Was ist "funktioniert Softwareentwicklungsprozess besser"?

Dieselbe Frage muss sich CCD und Flow-Design gefallen lassen. Und Scrum und XP usw.

Alle Agilisten haben eine solche Hypothese im Kopf, ganz einfach weil sie mit irgendwas auftreten und sagen, macht es so und so, dann wird dies und das besser.

Fowler erhebt es nun aber zum Prinzip, dass man als Agilist nicht sagen muss (nein, nicht sagen kann!), was "so und so" genau ist. Und er definiert auch nicht, was "dies und das" ist.

Wenn er nur sagen würde: "Zeige mir, dass du dies und das besser machst als andere, dann bin ich zufrieden.", dann wäre ich noch fast bei ihm. Dann könnte ich ihm zeigen, dass ich z.B. mit meinem eigenen tollen Phasenmodell "dies und das" besser mache als andere.

Ich bin mir aber sicher, dass er dann die Stirn runzeln würde. Er würde sich fragen, ob das sein kann. Denn er hat ja im Hinterkopf eine Theorie, wann "dies und das" besser sein kann - und in der ist das Phasenmodell wohl eher nicht drin.

Und damit sind wir wieder bei einer (impliziten) Definition von Agilität. Die hat er. Er erkennt ja auch Agilität, wenn er sie sieht. Also soll er sagen, was sie ist. Und nicht rumeiern.

Wenn er sie nicht hat und mit allem zufrieden ist, was "dies und das" besser macht... Auch gut. Dann soll er das sagen. Aber das ist dann bestimmt keine agile Haltung, sondern, hm, vielleicht eine sokratische oder sonst wie.

Solange es einen Begriff wie Agilität in Abgrenzung zu Lean und sonst was gibt, braucht der Begriff auch eine Grenze. Die gibt ihm eine Definition. Ansonsten ist er hohl und beliebig und damit nutzlos.

Nochmal: Mir ist völlig Wurst, wie die Definition aussieht. Aber ohne geht es nicht - wenn wir auch nur einen Hauch von Anspruch an Wissenschaftlichkeit bzw. Diskursfähigkeit haben.

Thomas hat gesagt…

Nur so am Rande:
Villeicht trifft ja auf Martin Fowler, bzgl. Agilität die 5 Stufe des Dreyfus Modells zu. "Die fünfte und letzte Stufe des Modells heißt „Experte“ (Expertise), wobei regelmäßig sehr gute Leistungen erreicht werden. Experten sind in ihrem Arbeitsgebiet nicht auf Regeln, Richtlinien und allgemeine Prinzipien angewiesen. Sie können auch besondere bzw. seltene Situationen intuitiv erfassen und den Kern des Problems schnell erkennen. Ihnen gelingt ein relativ routinierter Umgang mit Neuem." ... Er ist villeicht gar nicht in der Lage seine Expertise zu formulieren zu definieren, weil sie zusätzlich durch ein Gefühl (Bauchgefühl ?) geprägt wird.

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: Das glaube ich schon lange, dass die ursprünglichen Agilisten etwas "aus dem Bauch heraus" richtig gemacht haben (im Kontrast zu dem, was damals vorherrschte) und richtig machen.

Darüber haben sie natürlich reflektiert. Daher das agile Manifest. Nur reicht diese Reflexion eben nur so weit. Jeder hat seine blinden Flecken. Ich, du und alle Gurus ebenfalls. (Wir wollen hoffen, dass die das auch wissen ;-)

Bei aller Reflexion, die aus der unbewussten Kompetenz der Gurus dann etwas vermittelbares herausgekitzelt hat, ist dadurch aber nicht zwangsläufig reflektive Kompetenz geworden, d.h. "Lehrerkompetenz". Der Experte, der etwas "im Schlaf" und jenseits der Konventionen beherrscht, ist nicht automatisch auch ein guter Lehrer.

Ich denke, daran rührt "Ich erkenne es, wenn ich es sehe". Wir wollen glauben, dass Martin Fowler (hier nur ein Stellvertreter für viele andere) etwas besser kann - nur kann er das dann auch angemessen weitergeben? Oder braucht es dazu einen Experten in Sachen Didaktik? (Der selbst dann nicht auch noch Experte in Agilität ist.)

Thomas hat gesagt…

Deshalb wende ich meine Erkentnisse auch nur auf mich an. Ich weis dass ich nicht gut im der Wissensvermittlung bin und lasse das auch lieber sein. Auch wenn es im Blog eventuell so rüber kommt, als wolle ich dich von den Vorzügen von Agilen Vorgehensweisen überzeugen, so ist dies nicht von mir gewollt. Ich denke nicht einmal das meine Vorgehensweise in der Entwicklung "Agil" ist. Es ist die Vorgehensweise mit der ich für mich die bisher besten Ergebnisse erziele, alle neueren Vorgehensweisenhaben mich nicht mal soweit begeistert, dass ich sie ausprobiert hätte.
Mich interessiert das Thema aus dem Grund, dass es die Basis userer heutige Entwicklung, Produktion, in Frage stellt. Das egal welche Techniken oder Vorgehensmethoden wir verwenden oder neu entwickeln, wir doch nicht den heutigen Anforderungen gerecht werden, und alte Grundgedanken des 18. / 19. Jahrhunderts immer mitschwingen.
Ich möchte Meinungen und Ansichten von Anderen zu diesem Thema hören, damit ich weitere Erkenntnisse für mich hinzugewinnen.

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: Wie gesagt, wir müssen halt unterscheiden.

Es gibt die konkrete Ebene des Tuns.

Und es gibt die Ebene des Nachdenkens über das Tun.

Und dann gibt es noch die dritte Ebene, wo man über das Nachdenken nachdenkt :-)

Ich würde sagen, Martin Fowlers Beitrag bewegt sich auf dieser dritten Ebene. Er denkt darüber nach, ob man Agilität überhaupt definieren kann.

Auf dieser Ebene ist meine Meinung: Man muss Agilität definieren, sonst kann man nämlich nicht auf der zweiten Ebene nachdenken.

Ohne Definition von Agilität ist es mir unmöglich festzustellen, ob ich agil bin und was mir dieser Ansatz gebracht hat.

Wenn du schließlich arbeitest, dann ist es egal, ob du agil bist oder nicht. Du schaffst halt auf die eine oder andere Weise weg.

Erst wenn du innehältst und dich auf die zweite Ebene begibst, wird Agilität als Begriff wichtig.

Nochmal eine Analogie: Vor 100+ Jahren war der Begriff der Äthers sehr im Schwange. Man glaubte, der umgäbe die Erde und würde halt das Licht transportieren.

Das war eine legitime Annahme von anerkannten Leuten. Aber die wussten auch, dass es nur eine Hypothese war. Und dass sie deshalb konkret werden mussten. Und so haben dann Experimente, die Definitionen und Vorhersagen mit der Realität verglichen, ergeben, dass es keinen Äther gibt. Nun ist der Begriff schon lange vom Tisch. Dafür reden wir heute über Dunkle Materie :-)

Genauso die Agilität. Sie muss sich definieren, um ihre Vorhersagen an etwas zu binden. Sonst hat sie schlicht keine Erklärungsmacht. Wenn sie sagt, "Agilität ist, was immer erfolgreiche Softwareentwicklung ausmacht", dann ist sie nutzlos. Denn damit kann ich ja nicht mein noch nicht erfolgreicher Projekt erfolgreich machen.

Und wenn sie sagt, "Du musst experimentieren!"... dann ist sie nur eine Kopie des wissenschaftlichen Prinzips. Dann brauchen wir sie auch nicht.

Thomas hat gesagt…

Da stimme ich dir zu.

pvblivs hat gesagt…

Ich sehe, denke ich, nicht den Konflikt. Vielleicht ist das auch der Grund, warum hier darüber eine Diskussion aufkommt.
Fowler sagt nicht es gibt keine Definition. Er sagt es gibt seiner Ansicht nach keine strenge Definition. Bzw. man sollte nicht versuchen eine strenge zu finden. Denn ein gewisses Maß an Undefiniertheit sei Teil der Natur, welche Agilität ausgestaltet.

Und dann definiert er doch genauer, indirekt, nämlich beispielsweise, dass sich die Wahl der Mittel nach dem zu lösenden Problem [und dem Team und den verfügbaren Ressourcen und anderen Constraints] richtet.

Ohne im Detail weiter auf Fowler einzugehen, ich glaube er trifft es damit sehr gut.

Ich versuche nochmal, einen Wenn-Dann-Anlauf zu nehmen:
Wenn man wenig Zeit hat, und noch nicht weiß ob der Kunde das überhaupt braucht, dann ist ein geringerer Level of Done akzeptabel.
Ein geringerer Level of Done verringert den Aufwand, das Produkt kann schneller live gehen, dafür ist es nicht so gut wartbar, aber leichteren Gewissens wegwerfbar und natürlich schneller validierbar.

Ist das, die Sorte validierbarer Hypothesen für eine Definition, die Du Dir vorstellst? Das ist die erste die mir eingefallen ist (ohne perfekt ausformuliert zu sein) die nicht zu rigoros ist, sondern den Kern von Agil gut (exemplarisch) ausgestaltet.

Ralf Westphal - One Man Think Tank hat gesagt…

@pvblivs: "Rigorose Definition" ist für mich ein Pleonasmus. Entweder man definiert was oder eben nicht. Eine Definition mag eng sein ("Agilität ist, wenn in Iterationen von 2 Wochen entwickelt wird.") oder sie mag weit sein ("Agilität ist, wenn die Entwicklung über sich reflektiert."). Aber die Rigorosität da noch ins Spiel zu führen, finde ich überflüssig. Natürlich erwartet niemand eine Definition mit Mitteln der Mathematik.

Und dass Fowler eben nicht nur keine rigorose, sondern überhaupt keine Definition äußern will, erkennen wir doch daran, dass er nur sagt: "Ich erkenne sie, wenn ich sie sehe." Damit macht er die ganze Agilität subjektiv, d.h. von Personen abhängig. Er erkennt sie, aber wenn du irgendwo Agilität meinst sehen zu können, dann kann Fowler immer sagen, "Ne, ist keine Agilität. Ich erkenne sie nicht." - und du hast keine Handhabe, dagegen etwas zu sagen. Denn: Es gibt ja keine unabhängige Definition.

Wenn sich die Wahl der Mittel nach dem zu lösenden Problem zu richten haben... sorry to say, dann finde ich das nicht neu und schon gar nicht speziell agil. Das ist schlicht gesunder Menschenverstand. Oder von mir aus ist das Ingenieursdenke. (Apropos, dazu kann ich übrigens dies empfehlen: http://www.amazon.de/Discussion-Method-Conducting-Engineering-Technology/dp/0195155998 Da hat sich nämlich mal einer Gedanken zu einer Definition von "ingenieursmäßiges Arbeiten" gemacht. Das finde ich beispielhaft.)

Ich bin heute schon per Email gefragt worden, was denn meine Definition von Agilität sei. Werde das mal demnächst in einem Blogartikel darlegen.

Anonym hat gesagt…

Hi,

ich habe mich inspirieren lassen; meine Gedanken zum Thema findet man hier.

Gruß,
Volker