Analyse von Agil: Eine PDF

 Zur Info: "Analyse von Agil"

Eine PDF zum lernen.

Nicht nur auf einfache Projekte anwendbar

 Aus aktuellem Anlass:

Es muss ein Mechanismus existieren, dass die Schweigsamen auch ihre Meinung äußern dürfen: Es kann und soll nicht sein, dass nur weil die intelligentesten den Mund nicht auf machen ein Projekt schief läuft (Buch "Adrenalin Junkies und Formular Zombies", Tom Demarco, Kap. 25). 

 

Hier zu lesen:  FlePA

Über Management und Effektivitätsteigerung - im Zeitalter der Informatik

Wie immer sind die Bücher von DeMarco und Konsorten ein großes Lesevergnügen.


Vom Buch: Wien wartet auf Dich!
Tom DeMarco, Timothy Lister, Peter Hruschka


"Trotz all dem Gerede über "smarteres Arbeiten" ist die Meinung weit verbreitet, dass richtiges Management nur damit zu tun hat, wie man seine Leute dazu bewegt, härter und länger zu arbeiten, meistens auf Kosten ihres Privatlebens. Manager geben immer damit an, wie viele Überstunden ihre Mitarbeiter leisten und welche Tricks man anwenden kann, um noch mehr aus ihnen herauszuholen."


Die Ideen in diesem Text sind nicht neu, doch schön auf dem Punkt gebracht.
Auffallend, auf jeden Fall, ist die dadurch zum Vorschein kommenden Einstellung (Arbeitsverständnis) des Managements: es wird nicht "geführt" oder "geleitet" ('gemanaged') sondern lediglich mit allen Mitteln versucht, das maximale Möglich von den Mitarbeitern herauszupressen. Dies, natürlich, ist nicht die richtige Vorgehensweise.

Eine Folge aus dieser Vorstellung bezüglich der Führung von Unternehmen (und auch Projekten) ist die, dass die Arbeiten, die Management-Inhärent sind, schlicht nicht durchgeführt bzw. an die Belegschaft weitergeleitet werden (manchmal ist das gut, manchmal aber auch nicht... nur: Was für eine Rolle soll eigentlich das Management dann spielen?).

Nun kann ich diese Gedanken weiter auf die "agilen" Methoden übertragen: Sind diese "Methoden" (insbesondere das "Gedraenge", Scrum, weil sehr stark Prozess-orientiert) doch nicht lediglich noch ein Versuch, nicht "managen" zu müssen, sondern mit Hilfe sogenannter "agilen" Vorgehensweisen sich noch weiter von den Management-Aufgaben (planen, schätzen, koordinieren/organisieren) zu entfernen?



Wenn Sie ein besseres agiles Arbeiten wünschen: http://amtrs.de/savap.htm


Doch wenn Sie überhaupt besser arbeiten wollen: http://amtrs.de/flepa.htm

Produktivitätsteigerung als Folge von "Investitionen", nicht als Folge von dem Einsatz irgendwelchen (agilen) Methoden

Aus dem Buch: Der Termin
Tom DeMarco (1997)

»Im Prinzip ist Prozessverbesserung eine gute Sache. Sie bedeutet, dass Sie Ihren Job immer besser machen. Aber ich bin wenig begeistert von Programmen wie dem CMM-Ansatz, die sich Prozessverbesserung auf ihre Fahne schreiben. Sie werden leicht zum Selbstzweck.«

»So etwas wie eine schnelle Lösung gibt es in unserer Branche nicht. Es gibt keine Möglichkeit, die Produktivität kurzfristig zu steigern. Die Produktivität, die Sie heute erreichen, ist das direkte Ergebnis der langfristigen Investitionen, die vor Ihrer Zeit getätigt wurden. Und auch Sie können die Produktivität nur beeinflussen, wenn Sie Ihrerseits eine langfristige Investition tätigen, die Ihren Nachfolgern zugute kommt.«

Soll man glauben (dürfen), dass man Produktivitätssteigerungen durch Einsatz von "agilen" Methoden erzielen kann?

Ich finde den Text im Buch ganz gut, denn einerseits halte ich auch sehr wenig von CMM und andererseits scheint mir die Erklärung mit der Investition sehr "bodenständig". So etwas fehlt heute in der IT-Industrie.

Auf jeden Fall finde ich die Aussage im Buch sehr interessant.

Kann man Produktivität schätzen? - Und, wichtiger eigentlich: Bringt das was?

Die Bücher von Tom DeMarco sind, irgendwie zeitlos, ein Lesevergnügen 1. Klasse für alle Projektbeteiligten :-)

Vom Buch: Wien wartet auf Dich!
Tom DeMarco, Timothy Lister, Peter Hruschka
Seite 27ff:

Lawrence und Jeffery wollten die Produktivitätseffekte verschiedener Schätzverfahren ermitteln. Ihr Ziel war es, den alten Glauben zu bestätigen oder zu widerlegen, wonach Entwickler (in diesem Fall Programmierer) härter arbeiten, wenn sie ihre eigenen Schätzungen einhalten wollen. Für jedes der 103 Projekte entwickelten Lawrence und Jeffery eine gewichtete Metrik für die Produktivität. Dann teilten sie ihre gesammelten Daten in Gruppen ein, gegliedert nach der Art, wie die ursprünglichen Schätzungen zustande kamen.
[...]
Systemanalytiker sind die besseren Schätzexperten; besser als die Programmierer und besser als die Manager. Sie verstehen typischerweise die Arbeit bis ins Detail, sind aber nicht von dem natürlichen Optimismus der Personen befallen, die die Arbeit durchführen müssen, und auch nicht von den politischen oder budgetären Randbedingungen des Chefs beeinflusst.
[...]
Schlechte Schätzungen und hoffnungslos enge Terminpläne schwächen die Energie von Entwicklern. Capers Jones, der für seine Metrikstudien über Entwicklungsmodelle bekannt ist, hat es folgendermaßen ausgedrückt: "Wenn der Terminplan eines Projekts von Grund auf unrealistisch und unvernünftig ist, so dass selbst mit einer Menge von Überstunden nichts erreicht werden kann, wird das Projektteam zornig und frustriert... und die Moral sinkt auf den Nullpunkt." (Capers Jones, Programming Productivity (New York, McGrawHill, 1986), S. 213)

Dabei spielt es fast keine Rolle, ob die von Grund auf unrealistischen und unvernünftigen Termine vom Chef oder von den Entwicklern stammen.

Das überraschendste Ergebnis der Studie von Lawrence und Jeffery aus dem Jahre 1985 stand ganz am Schluss, als sie die Produktivität der 24 Projekte untersuchten, für die es überhaupt keine Schätzungen gab. Diese Projekte wiesen eine viel höhere Produktivität auf.

[Siehe Tabelle im o.g. Buch. Inhalt: Produktivität ohne Schätzung = 50% mehr als die Schätzung der Programmierer.]

Die Projekte, bei denen der Chef keinerlei Druck bezüglich des Fertigstellungstermins ausübte ("Weckt mich auf, wenn ihr fertig seid!"), wiesen die höchste Produktivität auf.

Mein Fazit: Nun muss ich unbedingt als Systemanalytiker zwar schätzen, der PM muss die Entwickler aber sich selbst überlassen.

Heute was gelernt!

Wie auch immer, bei Projekten sind Schätzungen sehr wichtig, denn es wäre wirklich irrsinnig etwas anzufangen ohne klare Vorstellungen von Zeit und Kosten zu haben. Doch das Mikroschätzen der "agilen Methoden" ist, meiner Meinung nach, overkilled, demnach auch die Einteilung in starren, unflexiblen, "Time Boxen" ("Agilität" lässt gerade ganz lieb grüßen...). Viel besser natürlich: FlePA.

Aber wenn Sie es doch nicht sein lassen können, dann machen Sie es zumindest so richtig wie möglich: SAvAP.

Agile: Das Laetrile für den Projekt Manager?

Die Bücher von Tom DeMarco sind, irgendwie zeitlos, ein Lesevegnügen 1. Klasse für alle Projektbeteiligten :-)


Vom Buch: Wien wartet auf Dich!
Tom DeMarco, Timothy Lister, Peter Hruschka
- Seite 32 -


Laetrile ist eine farblose Flüssigkeit, die aus dem weichen Inneren von Aprikosenkernen herausgepresst wird. In Schweden kann man diese Flüssigkeit in Lebensmittelgeschäften ungefähr für denselben Preis wie Mandelaroma kaufen. Man benutzt sie beim Backen so wie andere Extrakte. In Mexiko wird diese Flüssigkeit für 50 Dollar pro Tropfen als "Heilmittel" für die tödliche Geißel Krebs verkauft. Natürlich heilt sie gar nichts. Alle Anzeichen deuten darauf hin, dass alles nur grausamer Betrug ist. Aber da sonst niemand den Todeskandidaten irgendetwas anbieten kann, werden die Versprechungen der Laetrile-Quacksalber ernst genommen, ganz egal wie schändlich diese sind.
Personen, die extrem verzweifelt sind, prüfen Behauptungen nicht allzu kritisch nach.
Manche Manager sind in einer ähnlich "extrem verzweifelten" Lage und diese Verzweiflung macht sie zu einfachen Opfern für vielerlei technische Laetrile, die vorgeben, die Produktivität zu steigern. Nur selten gibt es Belege für die Wirksamkeit der offerierten Versprechungen. Aber auch sie verzichten auf Belege, weil ihre Not so groß ist.


Das  ganze 6. Kapitel: "Laetrile" ist sehr lesenswert!!!

Kommentare hierzu halte ich für überflüssig.

Abhilfe "De Luxe": FlePA .

Abhilfe für den normalen, praktischen Fall: SAvAP .

Wenn Sie es schon nicht sein lassen können, so gestalten Sie es aber bitte so gut wie möglich

Seit dem Jahr 2009 arbeite ich mit agilen Teams und schon davor hatte ich mich mit den Kerngedanken des "Agilismus" auseinander gesetzt.

Die Theorie um die agilen Methoden ist wirklich hübsch, besagt etwas von Frieden, Freude, Eierkuchen...
Grundlage der agilen Methoden ist ein "Manifesto" und ornamentiert wird sie (die Grundlage) durch die bekannten (und berüchtigten) "12 Prinzipien".

Was ich davon halte habe ich schon früher dargelegt.

Dennoch habe ich in der letzten Zeit die Gelegenheit gehabt und ausgenutzt noch mehr dazu zu lernen.

7 Jahre Arbeit im "agilen Umfeld"

Mit mehr als 7 Jahren Arbeit in agilen Teams bei verschiedenen Firmen muss ich doch zugestehen, dass ich mich teilweise geirrt habe.

So z.B. sind die agilen Entwicklungsmethoden keine Totgeburt wie ich meinte: scheinbar wachsen sie und gedeihen wider besseres Wissen... sogar bei echt großen Firmen!

Ungefähr die Hälfte der in agilen Teams involvierten Mitarbeiter scheinen agile Ansätze zu mögen, die andere Hälfte aber nicht. Geteilte Meinungen also. Sowohl die eine als auch die andere Methode hat Vor- und Nachteile, wie es eigentlich auch zu erwarten war.

Aus den mir vorliegenden Studien bezüglich das Ergebnis (Aufwand/Leistung Verhältnis) der Agilen (ACHTUNG! Gemeint sind nicht die subjektiven Meinungen von Teilnehmer an Fragebogen oder von Internet-Quizzen, sondern erhobenen Zahlen), scheinen sie sich mit den planungslastigen Methoden (BDUF: Big Design Up Front) in der Waage zu halten: Weder die eine noch die andere Vorgehensweise kristallisiert sich eindeutig als Sieger heraus (1). Hier ist aber eine verlässliche Aussage eher unmöglich, denn ein Vergleich ist nicht unter wirklichkeitsnahen Bedingungen realisierbar.

Was folgere ich daraus?
Nun:

1. Die Agilen sind da und werden aller Anschein nach nicht so schnell wieder verschwinden (m.a.W. es wird eine -lange- Weile dauern, bevor man sie wieder ersetzt, unabhängig von guten oder schlechten Ergebnissen, unabhängig vom Vorhandensein besserer Methoden).

2. Die Agilen sind nicht besser oder schlechter als die BDUF-Methoden, sondern ziemlich gleichwertig. Doch das Management möchte sicherlich die Agilen beibehalten, denn dadurch sind sie von einem (guten) Brocken Arbeit entlastet (dies, werter Leser, gilt zu berücksichtigen).

3. Historisch gesehen hat sich das klassische Projekt Management (BDUF) über eine (sehr) lange Zeitspanne entwickelt; die agilen Methoden aber sind ein relativ neuer, noch sehr junger Ansatz (2). Als solches sind sie einerseits für Fehlentwicklungen und Missverständnissen recht anfällig (da noch unzureichend untersucht), andererseits sind sie aber aus eben denselben Gründen besonders verbesserungsbedürftig.


Als Analytiker bin ich an Zahlen, Analysen und Ergebnissen sehr interessiert.
Aus Erfahrung, meiner kritischen Haltung gegenüber der Agilen und meinen Drang, Prozesse zu verbessern (siehe z.B. mein "Kaizen destilliert": http://amtrs.de/downl/Kaizen_Destilliert.pdf), entstand folglich die:

Strukturierte Analyse von agilen Prozessen (SAvAP)

Ziel und Zweck von SAvAP (wie der Name schon sagt) ist es, die agilen Methoden vom Nimbus des Esoterischen, vom Dogmatischen aus dem Manifesto und den 12 Prinzipien zu befreien und sie zu verständlichen, produktiven und an einer (Ihrer) Umgebung (sei es Team, Abteilung oder Firma) angepassten Methoden zu entwickeln.

Doch dem kurzen Sinn langer Rede ist hier zu lesen: http://amtrs.de/savap.htm

_______________________________________________________________

Was für Erfahrungen haben Sie mit agilen Methoden?

Halten Sie „agil“ oder „klassisch“ für besser?

Hätten Sie vielleicht sogar Vergleichszahlen zwischen beiden Ansätze?

Und was meinen Sie; sind die agilen Methoden wesentlich oder unwesentlich zu verbessern?

_______________________________________________________________


(1) "One of the greatest tragedies in life is the murder of a beautiful theory by a gang of brutal facts." Benjamin Franklin

(2) FlePA (siehe http://amtrs.de/flepa.htm) ist sicherlich die Zukunft, aber, wie weiter oben angemerkt (1. Punkt); es wird ziemlich lange dauern bis dieser Ansatz Einzug in der gegenwärtigen Projekt Management Disziplin findet. Bis dahin müssen wir alle wohl oder übel mit den Agilen Vorlieb nehmen.


und...

Heute ist der längste Tag des Jahres !!!

Vergleich "Agile" vs. "nicht Agile"

Ich kann mir sehr schwer vorstellen, dass Scrum oder "Agile" (wirklich) besser als einer klassischen Methode funktioniert.

Deswegen suche ich harte Vergleiche; Vergleiche die auf Fakten basieren.

Folgende Punkte möchte ich vergleichen:

1. Produktivität

2. Zufriedenheit der Projekt-Teilnehmer
2.1. Anzahl der Projekt-Teilnehmer, die ein nicht-Agiles Projekt in einer gegebenen Zeit verlassen haben, und
2.2. Anzahl der Projekt-Teilnehmer, die ein Agiles Projekt in einer gegebenen Zeit verlassen haben.

3. Last but not least, der Wunde Punkt der SW-Entwicklung; Bugs!
3.1. Anzahl Bug pro Zeiteinheit (oder TLOC oder Funktionspunkte)
3.2. Kritikalität der Bugs pro Zeiteinheit (Anzahl Bug pro Zeiteinheit und Kritikalität)
3.3. Durchschnittliche Verweildauer eines Bugs (wie lange braucht man, es zu beheben)
3.4. Durchschnittliche Verweildauer der Bugs nach Kritikalität (wie lange braucht man, Bugs nach Kritikalität zu beheben)




Es gibt leider leider noch mehrere wichtigen Punkte zu vergleichen...
Stoff für mehrere Arbeiten!

Hier mein Schreiben zu diesem "Vergleich": Bitte runterladen.

Auf Kommentare und weiterführende Infos bin ich sehr gespannt ;-)

Gedankenfehler im Ansatz bei den Agilen - Teil 3 von 3

Von:
https://de.wikipedia.org/wiki/Agile_Softwareentwicklung

Hier:
Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung

Das ist noch ein Meeting.

Die Idee dahinter ist wie immer eine gute Idee, stammt eigentlich von dem Toyota Production System und wird "Hansei" genannt. Hansei ist viel mehr als einfach eine Selbstreflexion; Hansei ist das Anstreben einer totalen Ehrlichkeit bezüglich der eigenen Schwächen; es geht darum, diese Schwächen auszumerzen.

Das ist was ganz anders als das, was man bei den "Agilen" vorfindet.

Bei den Retrospektiven, so wie sie normalerweise ausgeübt werden, werden Spielchen gespielt (so offensichtlich mit dem Ziel, die Leuten zu unterhalten, als wären sie im Kindergarten), bestenfalls werden hier ansatzweise wunde Punkte angesprochen, wobei meistens ohne jegliche Kommentare (Schweigen im Walde) oder gar Konsequenzen (wer sich bewegt hat verloren, m.a.W. wer zugibt, dass tatsächlich Probleme existieren - Postbote schlechter Nachrichten - wird [symbolisch] exekutiert); Keiner wagt "unangenehm" auf zu fallen oder mehr als nur dezent (leichte) Probleme anzusprechen.
Somit ist der ganze Sinn und Zweck einer solchen Retrospektive für die Katz.

Dazu kommt, dass diese Retrospektiven als fester Bestandteil eines Sprints betrachtet und handhabt werden, dergestalt, dass sie als notwendige Zeremonie angesehen werden, ...und die normalen Mitglieder eines Teams lassen das Ganze - geduldig - über sich ergehen. Sie wissen doch, dass es sich um (noch) eine Zeremonie ohne Folgen handelt.

Der Leitgedanke hinter dieser Retrospektive ist, wie fast alles, was aus der Toyota kommt, richtig und wichtig.
Leider, wie bei so vielen positiven Ideen, bei den Agilen ins Gegenteil umgewandelt.

Man soll berücksichtigen, dass die "agilen" als Antwort auf die Probleme der klassischen Methoden entstanden sind und ein gewichtiges Teil dieser Problemen ist nun mal ein unfähiges Management (daher so viele Meetings, um das Management zu ersetzen), leider und aus Gründen die mir unbegreiflich sind, werden alle gute Ideen, die die Agilisten anfassen, zu unnützlichen, hemmenden Brocken, die am Halse der Projektmitarbeiter hängen und ihr Handeln zu lahmen drohen.

Gedankenfehler im Ansatz bei den Agilen - Teil 2 von 3

Hier:

2. The team is authorised to take decisions (Das Team hat die Befugnis, Entscheidungen zu treffen).

Within a cycle, the project team must be authorised to do what they think is best. If
the project team does not have this power, the cyclical model of project management will not work.
(Im Laufe eines Zyklus muss das Team die Befugnis haben, das zu tun, was sie als das Beste erachten.
Sollte das Team diese Erlaubnis nicht haben, so wird das zyklische Modell des Projekt Managements nicht funktionieren).

Das ist noch so eine Idee, die in Teile richtig ist aber dadurch, das sie nicht zu Ende gedacht ist, nicht wirklich dienlich (zweckdienlich) ist.
Die Leute, die Ahnung haben, sollen Entscheidungen treffen können.
Menschen müssen die Macht haben, Fehler anzusprechen und Probleme bekannt zu geben, doch nicht jeder muss sich die Freiheit nehmen, irgendetwas zu ändern nur weil es ihm so besser gefällt, ohne zu wissen was er genau macht.
Das mündet doch in der Verantwortungslosigkeit, wenn alle Fehler machen dürfen und keiner muss für Fehler gerade stehen.

Darüber hinaus sind die Teams - aus der Sicht der Agilisten gesehen - überbewertet. Die Agilisten scheinen zu glauben, dass alles durch die Selbststeuerungsfunktion eines Team geheilt und in die richtige Bahn gebracht werden kann. Das ist: Überbewertung.

Die Aussage "[...] Team diese Erlaubnis nicht haben, so wird das zyklische Modell des Projekt Managements nicht funktionieren" ist auch nicht richtig: ein zyklisches Modell ist unabhängig von 1. Teams und 2. von den Befugnissen des Teams.

Man soll jedoch nicht vergessen, dass die "agilen" als Antwort auf die Probleme der klassischen Methoden entstanden sind, wo Teams eigentlich einzelne Mitarbeiter waren, mehr oder minder isoliert von dem Rest der Mitarbeiter gearbeitet und von dem Management als "Ressource" betrachtet wurden. Daher ist dieses (agile) Umdenken, wenn auch radikal, schon gewissermaßen gerechtfertigt.

Das "Richtige" ist es aber noch nicht...

Gedankenfehler im Ansatz bei den Agilen - Teil 1 von 3

Hier:

1. Users/customers are actively involved (Benutzer und Kunden nehmen aktiv im Entwicklungsprozess teil).

Das bringt nicht wirklich viel und es macht für den Kunden überhaupt keinen Sinn, ständig bei dem Lieferanten antanzen zu müssen. Die Idee ist gut, die Implementierung ist mangelhaft (bisweilen eine Katastrophe).

In der Praxis sieht das so aus, dass der "Kunde" einmal pro Sprint (oder so; nicht "täglich", das ist Nonsense) bei dem Auftragnehmer erscheint, ihm wird das vorgeführt, was funktioniert, der "Kunde" sagt; 'hübsch hübsch!' und geht wieder.
Eigentlich ein Zeitverlust für alle, das Schlimmste aber ist es, dass es für den AG keine wirkliche Verpflichtung gibt, sich mit dem Entwicklungsstand auseinander zu setzen.
Aussagen sind mündlich und somit nicht bindend.
Die Einstellung des AG ist in Allgemeinen so, dass er sowieso vom AN erwartet, dass die SW erstellt wird; seine Anwesenheit ist eine zu "leichte" Sache; er testet nicht, lässt sich lediglich die SW vorführen.
Es gibt natürlich Firmen, wo das etwas anders abläuft.

Also...
Vorteile:

• Der Kunde gibt Rückmeldung (Wichtig).
• Die Entwickler könnten einen Eindruck erhalten, wie der Benutzer mit der SW umgeht (Wichtig!) - wenn es einigermaßen gut durchgeführt wäre... eher seltener als die Ausnahme -.

Nachteile:

• Zeitverlust für die Teilnehmer die an Meetings teil nehmen, die nichts zu melden haben
• Zeitverlust für den Kunden, denn oft fahren mehrere Personen zum AN und verschenken die eigene Zeit, sowohl in Meetings als auch bei den Fahrten - ohne konkretes Ergebnis (nichts spezifiziert => kein Ergebnis) -.
• Dass der Kunde vor Ort ist garantiert in keiner Weise, dass die SW fehlerfrei ist.
• Kommunikationsschwierigkeiten können auftreten, die Möglichkeit und Einfluss von Missverständnissen erhöht sich durch die eher nicht strukturierte Vorgehensweise - im Gegensatz zu dem, was postuliert wird -.

Scheint mir so eine wischi-waschi Lösung zu sein für das Problem "Anforderungsmanagement" zu sein, welche mittels einer Art "Meeting" eine Pseudo-Lösung herbeizuführen wünscht.



Und überhaupt; sieht ganz so aus, als würden die "Agilen" versuchen, alle Schwierigkeiten mittels Meetings zu lösen.

Man soll immer bedenken, dass die "agilen" als Antwort auf die Probleme der klassischen Methoden entstanden sind. Das heißt nicht, dass sie nicht ihre eigene Probleme herbeiführen und auch nicht, dass die Lösung auch eine ist.

Das "agile Manifesto": Ein Manifesto der Frust?

"Agil" sollte eigentlich bedeuten, dass man die SW-Entwicklung an die Menschen anpasst (Manifesto!). Leider ist wieder mal das Gegenteil von dem geschehen, was man sich vollmundig versprochen hat: Die Menschen werden in Wirklichkeit an einem (nunmehr "agil" genannten) Prozess (stark bis sehr stark) angepasst.

Eine Entwicklungsmethode muss mit den Menschen, die man hat, klar kommen.

"Nehmen Sie die Menschen, wie sie sind, andere gibt es nicht", so hat ein Politiker, Konrad Adenauer, mal gesagt.

Sowohl die klassischen Methoden als auch die sogenannten "agilen" (insbesondere Scrum - das Gedränge) wollen die Menschen an einem Prozess anpassen. Vielleicht soll man sich Gedanken machen, ob dieses "Wollen" nicht in Wirklichkeit ein "Sollen" sein soll: Ist es nicht so, dass ein Prozess gegeben sein muss, um eine bestimmte Arbeitsleistung zu erbringen?

Wenn dem so ist, so brauchen wir tatsächlich einen Rahmen (Methode), der uns ein Prozess definiert, wo aber die Mitarbeiter sich so weit entfalten können wie möglich. Das ist weder mit den klassischen noch mit den sogenannten "agilen" der Fall.

Auch "KanBan" [das "agile" KanBan, hat mit dem wirklichen (Toyota-) KanBan wenig zu tun] will die Menschen an einem bestimmten Prozess angepasst haben.

Das kann funktionieren, muss aber nicht, und auf jeden Fall funktionieren solche Methoden dann "suboptimal":
Klassische Methoden haben den Manko, dass sie ziemlich starr sind und die Mitarbeiter die Freiheit nicht haben, seine Arbeit zu verbessern (Stichwort Kaizen).

Die sogenannten "agilen" Methoden auf der anderen Seite haben aber den Manko, dass sie eine falsche Freiheit versprechen. Dies hat wahrscheinlich seinen Ursprung in der Tatsache, dass normale (schlichte) Entwickler das "Manifesto" geschrieben haben.

Siehe meine Homepage und die alten Blogeinträge:
- http://www.ruynk.com/ruynk_agilismus_analyse.htm
- http://ruynk.blogspot.de/2015/03/wie-agil-ist-eigentlich-agil-was-kann.html
- http://ruynk.blogspot.de/2015/05/agile-prinzipien-schwammig-schwach-lahm.html
 
Das "Manifesto" wurde aller Anschein nach aus Frust geschrieben (die "klassische" SW-Entwicklung kann ser frustrierend sein!) und mangelt sowohl an wissenschaftlicher Stringenz als auch an der notwendigen Flexibilität um es an die wirklichen Gegebenheiten in den Firmen anzupassen.

Zwar wird behauptet, dass die "agilen" Teams die "agilen" Methoden anpassen können und sollen, doch... das ist zu viel der Freiheit; der "falschen" Freiheit (Stichwörter: Chaos, Willkür, Unverantwortlichkeit, Dogmatismus u.a.).

Eine echte Lösung muss versuchen, die Menschen (MA) jeder für sich optimal einzusetzen.  FlePA verfolgt diesen Ansatz.

Über die magische Entstehung von "Agilität" durch den Einsatz von Tools

In der "agilen" Welt, so wie ich sie in den letzten Jahren bewundern durfte, ist einen lustigen Ansatz zu beobachten:
Erstens: Es existieren eine Serie an Tools, die "agil" sind und diese Agilität auch gewährleisten sollen, darunter z.B. "Jira"; den Einsatz solchen Tools wird nun erzwungen.
Zweitens: Es existieren eine Serie an Praktiken, die "agil" sind und diese Agilität auch gewährleisten sollen, darunter z.B. "CI/CD" (Continuous Integration / Continuous Deployment); den Einsatz solchen Praktiken wird nun erzwungen.

Der Ansatz wird wohl in der Hoffnung oder dem Glaube verfolgt, dass lediglich eine geistlose Anwendung einer Mechanik ausreichend ist um ein Ergebnis herbeizuzaubern.

Das ist ein Glaube an einer (einfachen) mechanischen Kausalität.

Doch wir haben es eigentlich hier mit sehr komplexen Interaktionen in einem sozialen Gebilde (kein "System" sondern eher ein "Organismus") zu tun. Hieraus erklärt sich der Denkansatz der überwältigen Wichtigkeit des "Teams" als solches: Deshalb schwafelt man gerne von den sich selbst organisierenden Teams und dass das Ergebnis mehr sein soll als den Beitrag jeden einzelnen usw.

Nun, es sieht so aus, als würden die sogenannten "agilen" Methoden erwarten, dass durch die mechanische Anwendung bestimmter Rituale (Praktiken) und Tools ein organisiertes (organisches) Team entstehen soll: Das kann (könnte) passieren, muss aber nicht. Und wenn Jemand erwartet dass etwas passiert, was passieren "könnte", pflegt diese Person eigentlich nichts anderes als "Wunschdenken".

Nehmen wir z.B. CI/CD als Untersuchungsobjekt:

CI/CD scheint eine Technik zu sein, die in Zusammenhang mit den sogenannten "agilen" Firmen mehr und mehr eingesetzt wird.

Dazu möchte ich auf 2 Punkten aufmerksam machen, die mir bei der Arbeit in den letzten Jahren aufgefallen ist.

1) CI/CD ist eine Technik die eigentlich für Projekte weniger bis gar nicht anwendbar ist: Viele 'Manager' wollen sie jedoch haben, weil sie scheinbar "agil" ist. Doch eigentlich sollte sie nur für die Serienproduktion einzusetzen sein. Die Idee stammt doch von der Toyota Serienautoproduktion. Als solche erzeugt sie bei der Projektarbeit eine schwer zu beherrschenden Overhead-Verwaltung. Vor Allem im Zusammenhang mit den ach so wichtigen automatischen Tests (mehr dazu lesen Sie hier: http://www.ruynk.com/ruynk_irrlicht_agil.htm - unter "Negative Eigenschaften der agilen Methoden" den letzten Punkt, über automatische Tests).

2) Bei vielen Firmen, die sich "agil" benennen wollen, werden Tools zur CI/CD eingeführt und eingesetzt, ohne wirklich verstanden zu haben, was CI/CD bedeutet. Und was bedeutet CI/CD? Die Idee hinter CI/CD ist wohl, das man ständig Änderungen und Verbesserungen (quasi in einem immerwährenden Prozess) im fertigen "Produkt" einfließen lassen kann.

Ich denke, dass man als erstes das Prozess so anpassen und optimieren soll, dass eine CI bzw CD Sinn macht. Das wird selten gemacht: Das wäre doch eher die Arbeit von Analysten, doch Analysten werden von den Firmen nicht mehr nachgefragt.

Davor jedoch sollte man sich Gedanken machen, was für einen Sinn CI/CD hat, sowohl für die Entwickler als auch für den Kunden. Solche Überlegungen werden auch (sehr) selten, manchmal gar nicht durchgeführt.

Vielleicht hofft das 'Management', dass CI/CD sich beim bloßen Anwenden von Tools einstellt.

Vielleicht hofft das 'Management', dass die "Agilität" sich beim bloßen Anwenden von Tools (und Praktiken) einstellt.

Das wird selten vorkommen. Das ist Wunschdenken.

Post-Agile... ein Begriff von Kritekern des "Agilismus"...

Einige Seiten, die sich mit "Post-Agile" auseinandersetzen:

Interessanter Vergleich klassisch-agile mit vielen Anmerkungen:
https://www.artefactgroup.com/articles/post-agile-a-design-thinking-approach-to-software-development/

Startseite des Blogs:
https://postagilist.wordpress.com/

"Scrum" als magisches Werkzeug:
https://postagilist.wordpress.com/2011/04/05/the-flawed-rhetoric-about-scrum-and-organizational-dysfunction/




"Agile" als kommunistisches Regime:
https://postagilist.wordpress.com/2011/04/09/scrum-as-the-new-command-and-control/

Interessant, viele Punkte, die ich selber schon bemängelt habe, hier:
http://www.ruynk.com/downl/SW_Entwicklung_Untersuchung.pdf

Neue Homepage für "AMTRS"

Neue Homepage für "AMTRS" (Analysieren - Modellieren - Trainieren - Reorganisieren - Systematisieren)

Hier: http://www.amtrs.de

Die Seite über "Systemanalyse" ist wert zu lesen, und
Downloads sind interessant!