Ich bin ja ein großer Freund von agilem und schlankem Vorgehen in der Softwareentwicklung. Aber derzeit scheint mir die Agilität ein bisschen unbescheiden. Sie hebt immer mal wieder ab. So auch in diesem Artikel von Henrik Kniberg (meine Hervorhebung):
Was soll das denn? Vor 2000 wussten Softwareunternehmen nicht, wie man Software ausliefert? Ja, ist das so gewesen?
Und vor 2000 haben Unternehmen keine nützliche, funktionierende Software (“working software”) ausgeliefert, falls sie es denn überhaupt geschafft haben, welche aus der Tür zu bekommen? Ja, ist das so gewesen?
Ich hatte in den 1980ern und 1990ernn schon den Eindruck, mit “working software” zu arbeiten. Und ich habe mit meiner Branchensoftwarefirma 10 Jahre lang selbst “working software” ausgeliefert. Sonst hätten mein Partner und ich uns und unseren Angestellten kein Gehalt zahlen können. (Er liefert übrigens immer noch “working software” aus und lebt davon – obwohl er ganz unagil arbeitet.)
Dass etwas im Argen war mit der Art, wie wir in unserer Branchensoftwarebude Software entwickelt und ausgeliefert haben, ist unbenommen. Und es liegt auch heute noch viel im Argen bei dem, wie Software entwickelt wird. Natürlich bin ich dafür, dass mehr Teams, agil und/oder schlank werden.
Aber wir sollten doch bitteschön nicht verkennen, wie viel geleistet wird ganz ohne Agilität und Schlankheit. Die Softwareentwicklung hat nicht erst mit der Agilität angefangen. Und Agilität ist bei weitem nicht in alle Köpfe, Teams und Unternehmen bisher vorgedrungen. Sind deshalb die, die noch nicht agil oder schlank sind, Hinterwäldler und Dummköpfe? Kriegen die nichts gebacken?
Ein bisschen Bescheidenheit stünde der Agilitätsbewegung gut zu Gesicht, finde ich. Mit solchen Aussagen gewinnt man keine neuen Freunde. Eine abgehobene, arrogante Agilität nützt niemandem.
Und wie kann das Abheben vermieden werden? Ich glaube weiterhin, dass dafür eine glasklare Definition von Agilität nötig ist. Henrik Kniberg bleibt Sie trotz Link auf das agile Manifest schuldig. Und Martin Fowler weiß es nicht besser, sondern erkennt sie einfach, wenn er ihr mal begegnen sollte.
Ob Sie nun meiner persönlichen Definition von Agilität zustimmen oder ihre eigene haben… Wir sollten uns darüber unterhalten, was Agilität im Kern ausmacht. Dass mit ihr “working software” hergestellt werden kann, ist nichts Neues und nichts Besonderes. Ein bisschen mehr Butter bei die Fische darf schon sein.
Was ist also das klar umrissene Nutzenversprechen der Agilität, das sie vom Bisherigen abhebt? Wie kann Agilität einem gestandenen Geschäftsführer, der seit 20 Jahren nützliche und funktionierende Software an den Markt bringt und 20 Leute damit ernährt, in nicht arroganter Weise nahegebracht werden?
Und dann: Mit welchen Merkmalen, Hilfsmitteln, Methoden, Konzepten, Paradigmen versucht Agilität dieses Nutzenversprechen einzulösen? Warum sollen die funktionieren und nicht anderes?
Mein Empfinden ist, dass es bei all der Literatur zu Agilität noch Erklärungsbedarf gibt. Die Marketing-Arbeit der Agilisten ist nicht vorbei. Die Zeit für siegerhafte Arroganz ist noch nicht gekommen. Und sollte am besten auch nie kommen.
PS: Und dass das heutige Problem vor allem sei, das falsche Produkt zu bauen, halte ich auch noch nicht für ausgemacht. Sicherlich ist das ein nicht zu leugnendes Problem – nur hat das nicht speziell mit Softwareentwicklung zu tun. Für viel dringender halte ich das Problem mangelnder Evolvierbarkeit. Die Unwartbarkeit, das Brownfield, die Legacy Code Berge… sie drohen überall. Denn was will man denn machen, wenn man denn nun endlich weiß, welches Produkt man bauen will – und man kriegt es nicht hin? Dann ist das Händeringen umso größer. Deshalb: Ich bin dafür, zuerst die Bedingung für die Möglichkeit des richtigen Produktes anzugehen. Und das ist eine Codebasis, die sich in welche Richtung auch immer geschmeidig anpassen lässt.
12 Kommentare:
ACK.
Und ich glaube Herr Kniberg sagt es sogar doppelt falsch, wenn man den zweiten Satz noch mitliest. Ein Hauptziel von Agile ist in meinem Verständnis doch genau durch das regelmäßige Feedback eben NICHT die falsche Software zu bauen.
"Working software" ist das Ziel der Softwareentwicklung an sich; völlig unabhängig von "Agile" und "Lean"...
Stimmt, Agilität ging es schon immer um die richtige Software. Insofern könnte man aus Knibergs Einleitung herauslesen, dass er Agilität in einem wesentlichen Punkt für gescheitert erklären muss.
Für mich macht das nur umso dringender, sich über Zweck und unverbrüchliche Mittel zu unterhalten. Was bedeutet Agilität wirklich?
Wie so oft die Welt ist grau. Man baut kein Haus agil oder fliegt agil zum Mond. Manchmal passt es sehr gut, manchmal weniger.
Es herrscht eben eine gewisse Religiosität. Dabei waren wir VBler ja schon immer total agil ;-)
In meinem Verständnis von Agilität gibt es zwei Dinge auf die es ankommt:
1. "agile Software" mit einem kontrollierten, möglichst gleichbleibenden Maß an Softwareentropie, die darüber hinaus nicht altert, also mit der technologischen Entwicklung Schritt hält.
2. "agile Anforderungen", die dafür sorgen dass alles "im Fluss" bleibt und keine Spitzen produziert. Die früher übliche Einstellung "Wir sammeln mal bis es sich lohnt" ist also kontraproduktiv, da sie Punkt 1. erschwert.
Ich stimme deshalb Fowler zu, dass man eine "agile Methode" nicht allgemein gültig formulieren kann - jedenfalls nicht so, dass irgendjemand sagt - "Ahhhh, so machen wir das jetzt". Man kann aber erkennen, ob das Ergebnis "agil" ist. Das lässt sich beobachten und messen. Und daraus lassen sich Aussagen darüber treffen, ob und ggf. wie die Methode verändert werden muss.
Scrum hat anfangs die Messgröße Velocity eingeführt. Damit kann man die Geschwindigkeit der Umsetzung auf Konstanz hin messen und Schwankungen in der Planungsgenauigkeit (als Standardabweichung) feststellen.
Im aktuellen Scrum Guide sind Techniken nicht mehr angeführt.
Deshalb ist Scrum auch keine Methode sondern nur ein Framework. Die Methode ergibt sich als Zusammenfassung der vom Team getroffenen Entscheidungen zum Vorgehen und ist - objektorientiert formuliert - nur eine momentan gültige Instanz einer "Meta"-Methodik mit den Eigenschaften "Wie Machen", "Was Messen", "Was Auswerten" und "Was Verändern".
Ich denke dass einem Pragmatiker wie Fowler so eine Metadefinition nicht der Rede wert wäre, da sie Entwicklern mit "Here-You-Can-Read-How-To-Do-Your-Job"-Mentalität nicht weiterhilft. Uns schmerzt das sicher weniger, denn "we-try-to-find-out-ourself ..." - Oder?
@Christian: Doch, Christian, mich schmerzt es, wenn sich leute hinstellen und sagen, "Ich erkenne Agilität, wenn ich sie sehe - aber ich sag dir nicht, woran. Meine Kriterien kann und/oder will ich nicht offenlegen."
Abgesehen mal von einem Gefühl der Willkür überkommt mich da auch die Angst vor Dogma (das an einzelnen Personen hängt) und Instrumentalisierung.
Wie Knibergs Beitrag zeigt, ist Agilität dann nämlich ganz schnell für alles Positive verantwortlich.
Ich behaupte nicht, dass Agilität so konkret formuliert werden muss, dass einzelne Handlungen vorgeschrieben werden. Insofern hat Scrum einen richtigen Schritt getan.
Für die Agilität fehlt mir der. Ganz einfach, weil Menschen in Unternehmen eben ganz konkret praktisch einen Leitstern brauchen. Sie mühen sich mit Scrum ab und schaffen die Implementation nicht. Sind sie deshalb nicht agil?
Wer will das beurteilen ohne eine Definition von Agilität? Ken Schwaber mag beurteilen, ob ein Team Scrum schafft oder nicht. Aber Scrum ist nur einer von vielen Wegen zu Agilität.
Kann man bei der überhaupt ankommen und sagen, "Jetzt sind wir agil!"?
Agilität täte auch gut daran, sich zu definieren, um sich abzugrenzen. Denn wenn alles agil sein kann, ist "agil" eine leere Worthülse.
Einerleis. Aussagen wie die von Kniberg und von Fowler helfen niemandem. Was nicht von jedem erkannt werden kann und was Erfolge für sich reklamiert, die auch andere Ansätze erzielen, verliert an Glaubwürdigkeit.
Das Problem mit den Agilisten ist, dass sie (fast) alle nur das Manifest nachbeten, und noch gar nicht gemerkt haben, um was es wirklich geht.
Agil zu sein ist wichtig — aber nur, wenn man den Begriff definiert sieht, wie auf Seite Best Practice Agile definiert und erklärt.
@ggreiter: Na, das ist doch was. Die Grafik am Ende der Seite kann als Definitionsbasis herhalten. Dann ist agil, wer...
-inkrementell arbeitet,
-in kurzen Iterationen,
-Anforderungen nicht ein für alle mal fixiert
-und den Kunden eng an die Entwicklung anbindet.
Damit kann ich leben. Damit kann selbst ich ein Team beurteilen, ob es agil arbeitet. Dafür muss nicht Martin Fowler anreisen.
Auch in dieser Definition muss man noch schauen, was das eine oder andere bedeutet. Wir kurz ist kurz? Wieviel Fixierung ist ok? Was ist enge Anbindung?
Entscheidend ist jedoch, finde ich, dass man in so einer Diskussion erstmal überhaupt eine Definition teilt. Da kann einer auch sagen, 3 Monate seien kurz genug in seiner Domäne - und begründet das dann. (Unwahrscheinlich, dass ich da zustimmen würde. Aber erstmal sind auch 3 Monate erlaubt, wenn am Ende ein Inkrement rausfällt ;-)
Meine eigene Definition enthält 3 von diesen Punkten auch - allerdings auf einem etwas höheren Abstraktionsniveau bzw. allgemeiner. Und der vierte Punkt ergibt sich dann von ganz allein, weil man sonst die anderen nicht leben kann.
Agile Methoden und besonders Test First Development sind durchdrungen von arroganten Haltungen und Dogmen. So wird selbst die brillianteste Idee verwässert und mißbraucht.
Dabei ist es erstaunlich, wie gut Dogmen selbst bei hoch gebildeten Menschen funktionieren.
Deshalb ist auch der ganze Clean-Code-Developer Kram aus meiner Sicht kontraproduktiv.
Sorry, Ralf. Da warst du auch schon abgehoben.
@Andreas: Etwas Selbstkritik habe ich ja schon geübt. Nun legst du noch oben drauf :-) Fein, dann lass uns konkreter werden.
Warum die Agilität aus meiner Sicht abhebt, habe ich ja an Aussagen festgemacht:
-Mit Agilität haben Entwickler nun endlich gelernt, nützliche Software zu liefern. (Kniberg)
-Agilität kann man nicht definieren, die kann man nur erkennen, wo sie waltet. (Fowler)
Woran machst du nun fest, dass auch CCD abhebt und Dogma ist?
Nur weil einer Empfehlungen für Regeln gibt, ist er ja nicht gleich arrogant. Das behaupte ich auch nicht von der Agilität.
CCD behauptet auch nicht, dass man ohne CCD keine gute Software schreiben könne. Aber CCD behauptet, dass der, der heute Schmerzen leidet an seiner Software, die durch Anwendung der Prinzipien und Praktiken lindern kann.
Ist das arrogant/abgehoben? Hm...
@Ralf
Die Schmerzen kann ich Dir nicht ersparen.
Die agilen Prinzipien gibt es nicht erst seit 2001, sondern an diesem Treffen ist lediglich zusammengefasst worden, was sich in der Wahrnehmung dieser 17 ITler in vielen Jahren vorher als Kern erfolgreicher Softwareentwicklung herauskristallisiert hat.
Das hat man dann als "agil" bezeichnet und 4 Werte und 12 Prinzipien aufgeschrieben. Amerikaner machen das so und verdienen damit Geld. Deutsche schreiben eine wissenschaftliche Notiz, die dann 2 Profs lesen und das war es dann.
Da hat nichts begonnen - außer dem Kommerz vielleicht. Inkrementelles Ausliefern ist definitiv nicht erst 2001 erfunden worden.
Da läge auch Kniberg daneben, falls er diesen Zeitpunkt meint. Und Du regst Dich drüber auf, dass er das denkt. Lass' es - es gibt Millionen andere die das auch glauben. Da kommt man nicht gegen an. Das kann ich aber doch nicht "agil" ankreiden.
Deine 3 Kriterien mögen Dir genügen - mich interessieren auch nur wirklich 2 Extrakte (s.o.). Aber ich kann das nicht zur Ersatzdefinition von "agil" erheben.
Das ein Selbständiger das Prinzip "Selbstorganisation" nicht besonders berücksichtigt, ist nachvollziehbar, denn da ist vielleicht kein Handlungsbedarf mehr. Das werden etliche Arbeitnehmer in n-stufigen Hierarchien aber durchaus anders sehen.
Aber davon abgesehen: "Inkrementell - Lernen - Unmittelbar" ist keine Methode. Davon handelt Fowlers Artikel - agile methods.
"Lernen" kann jeder im Lexikon nachlesen - die eine richtige "Lernmethode" gibt es aber nicht.
Fowler erwähnt "XP" und "Scrum" und fragt nach der besseren Methode und nicht danach ob die eine agil ist oder nicht.
Das war 2005. Heute ist Scrum gar keine Methode mehr.
Ob ein Scrum-Team agile Prinzipien einhält, soll der Scrum-Master überwachen. Das ist sein Job und dafür braucht er keinen Außenstehenden.
Ob das Team die für sie richtige Methode hat, muss es aber selbst herausfinden. Vielleicht ist das "Lernen" für manche zu schnell, für andere zu langsam. Vielleicht degeneriert die Software trotz TDD und CleanCode. Vielleicht wollen Sie mal ein neues Tool ausprobieren. Oder Email abschaffen.
Und wenn die richtige Methode dann "da" ist, dann "spürt" man sie. Wenn ein Sportler den richtigen Trainingsplan gefunden hat, spürt er es am Erfolg. Vielleicht spürt er auch, ob ein völlig neu gestalteter Trainingsplan besser ist als der andere (Fowler).
Vorher muss er probieren, Blutwerte messen und justieren. Und vielleicht ist dieses Vergnügen nur von kurzer Dauer. Deshalb wird Hochleistungssport heute "wissenschaftlich" betrieben - und Scrum basiert auf "Empirie". Man soll es also möglichst nicht nur "spüren", sondern auch "messen" können. Das ist das genaue Gegenteil von Fundamentalismus, weil die eigenen Überzeugungen objektiven Kriterien weichen müssen.
Das Problem mit den Gurus ist gelegentlich, dass sie aus "ihrer" Methode ein Prinzip machen wollen um es besser zu vermarkten. Das ist natürlich Trickserei. Und die anderen Gurus ziehen da auch nicht mit. Deshalb ist das agile Manifest auch nicht 25* geändert worden. Gut so!
@Andreas
Clean Code ist deshalb kein agiles Prinzip und TDD ist auch keines - jedenfalls nicht im agilen Manifest.
Aber: Wie bei Modellen und Metamodellen gibt es verschiedene Ebenen. Wenn ein Team herausgefunden hat, dass TDD ihnen hilft, dann können Sie es natürlich zum Prinzip für sich erklären. Oder ein Systemhaus erklärt es zum Prinzip für seine Angestellten. Damit verändern sie aber nicht die Bedeutung von "agil" das überhaupt keine Aussage zu den zu verwendeten Techniken / Methoden verliert.
Genau da liegt für mich auch der praktische Wert des agilen Manifest. Dort kann man schnell prüfen, ob ein neuer Hype der als "agiles Prinzip" verkauft wird, dort wirklich angegeben ist oder ob es sich wieder nur um Marketing-Trickserei handelt.
@Christian: Tut mir leid, das ist mir jetzt zuwenig. Wenn Agilität sich aufs Lernen reduziert, dann brauchen wir den Begriff nicht. Dann muss auch das agile Manifest nicht her.
Ein Sportler, der Blutwerte und Geschwindigkeit und sonstwas misst, folgt keiner Methode. Der sucht nur Feedback. Der geht in bestimmter Weise vor. Wunderbar.
Sobald aber einer einer Vorgehensweise ein Etikett verpasst, muss mehr drin sein als "Lernen".
Ich behaupte nicht, dass irgendjemand agil arbeiten muss. Mir reicht es, wenn alle sich aufs Lernen konzentrieren. Und wenn sie dafür einen "Lernmeister" einstellen, der ihn da auf die Finger schaut, damit das Lernen nicht untergeht im Tagesgeschäft, dann wunderbar. Das ist aber kein Scrum. Dafür braucht es immer noch kein Etikett.
Ergo: Mit Etikett kommt eine Notwendigkeit zur Definition, um zu zeigen, was unter dem Etikett mehr drin ist als schnödes Lernen.
Die Leute lesen ja Scrum- und XP- und Kanban- und CC-Bücher und nicht einfach nur "Die fünfte Disziplin". Da muss also etwas dran sein an diesen Etiketten.
Das behaupten nicht nur deren Vertreter, sondern suchen auch die Leser. Ergo: Es mögen die Vertreter dann auch sagen, was dran ist. Was unterscheidet Scrum, Agil, Lean etc. von Lernen im Allgemeinen?
Insofern gibt es Agilität auch nicht vor dem Manifest. Denn erst das Manifest gibt einem Satz von Merkmalen (die explizit formuliert wurden oder nur gedacht werden) einen Namen.
Dass schon vorher irgendwer irgendwie gearbeitet hat, wie es dann beschrieben wurde... egal. Dann hat er es halt gut gemacht. Ist hoffentlich zufrieden.
Aber ich verstehe natürlich auch, dass man sich scheut, das Etikett möglichst präzise zu definieren. Dann wird man nämlich angreifbar. Es könnte sich ja herausstellen, dass das Definierte nicht so funktioniert wie beworben. Ohjeeee... dann ist das ganze Business, das auf der Definition aufbaut dahin.
Also besser schwammig bleiben. Was nur in meinem Auge als Betrachter existiert, was nur ich definieren kann, kann keiner kritisieren. Zur Not sage ich nämlich, "Das ist es nicht, was ich gemeint habe. Die implementieren es nicht." Wunderbare Welt der Pseudowissenschaft.
... die umfassende Beschäftigung mit dem Thema Agilität - schönes neues Buzzword - ist aus meiner Sicht der Ausdruck der Menschen auszubrechen. Nämlich aus dem in der 80er und 90er Jahren produzierten Korsett der Prozesslehre. Vorsichtig bitte in der Aussage, die Dir informierter Leser jetzt vielleicht auf der Zunge liegen möge!
Ich bin als angewandter Wirtschaftsinformatiker selbst jahrelang in Vorbereitung auf die Einführung von ERP-Systemen in Unternehmen, mit der Lehre des Prozessmanagements durch die Unternehmen gewandelt. Wir haben dadurch ganze Branchen mittels "Referenzprozessen" gleichgeschalten, sie oftmals ihrer Individualität beraubt und sie mit betriebswirtschaftlicher Standard-Software in ihren eigenen Prozessen "einbetoniert".
Sehr bezeichnend, dass jetzt die IT-Branche als ehemaliger "Betonlieferant" für Agilität wirbt. Es ist landauf und landab (ich überblicke dabei vor allem den deutschsprachigen Wirtschaftsraum) zu beobachten, dass der Wunsch nach Agilität aus den "Software-Fabriken" der IT-Branche in andere Branchen übergeschwappt ist. Und nicht nur durch den Einsatz von Scrum als Projekt Mgmt. Methode in F&E Projekten der Pharma-, Automotive- und Nahrungsmittelbranche. So gesehen, habe ich selbst eine hohe Affinität zu dem Thema und den aktuellen Blog-Artikel begeistert verfolgt.
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.