Ich weiß, jetzt kommt der Aufschrei der Anhänger der Agilen Entwicklung, aber das nehme ich gerne in Kauf.
# Die Agilen Prinzipien einmal kommentiert: Die Forderungen der Agilen Entwicklung sind mehr als gerechtfertigt!
Ich gehe auf die Forderungen ein, und ich kommentiere diese:
Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
Das heißt aber nicht:
Prozesse und Werkzeuge sind irrelevant. Prozesse ermöglichen Organisationen, im Laufe der Zeit zu lernen und sich zu verbessern, und die Verfahren führen (hoffentlich) zu reproduzierbaren Ergebnissen. Tools können die Art und Weise, wie ein Team Probleme erkennt und darauf reagiert, grundlegend verändern. Wer als Führungskraft oder Projektleiter nicht begriffen hat, das Menschen sein Kapital sind und das Menschen die höchste Aufmerksamkeit genießen sollten hat seinen Job verfehlt und gehört da nicht hin! Prozesse sind Interaktionen.
Wenn diese Prozesse nicht funktionieren, ist der Prozess schlecht! Leider werden Prozesse oftmals von denen erstellt, welche vom Prozess nicht betroffen sind und danach in Stein gemeißelt. Das ist absolut kontraproduktiv. Ein guter Prozess hilft allen Beteiligten, wie zum Beispiel das Fahren auf der rechten Seite, oder das Bilden einer Rettungsgasse.
Wenn man in England oder Australien fährt ist der Prozess halt anders, die Rettungsgasse bleibt! Entscheiden ist, dass das Ergebnis erzielt wird und NACHHALTIG ist! Werkzeuge/Tools sind Klass Aber nur, wenn es gute Werkzeuge sind! Oftmals sind Werkzeuge „uralt“ und man richtet seinen Prozess und am Tool aus. Na dann – nix wie weg mit dem Tool – oftmals ist es besser Dinge manuell zu machen. A Fool with a Tool is still a Fool! Wenn Sie es manuell nicht können, hilft Ihnen kein Tool! Das Tool hat dem Zweck zu dienen und kein Mensch dem Tool! Das Ändern von Tools ist aber oftmals das Schwierigste was es im Unternehmen gibt – auch hier gibt es „Religionskriege“ Technische oder sachlogische Begründungen werden bei der Toolauswahl sehr selten verwendet. Funktionierende Software ist wichtiger als umfassende Dokumentation.
Was das NICHT bedeutet:
Dokumentation ist altmodisch / überbewertet. Ohne ausreichende Dokumentation Ihrer Anforderungen wird es noch zeitaufwendiger die Software zu erstellen, von einer Überarbeitung ganz zu schweigen. Wenn Sie nicht wissen, wo Sie sind, ist es sehr schwer herauszufinden, wie Sie dahin kommen, wo Sie hin wollen, besonders dann, wenn das nicht vernünftig beschrieben ist. Und vergessen Sie nicht, dass Menschen krank werden, aussteigen und in Rente gehen:
Sie nehmen dann Ihr gesamtes Wissen und die institutionellen Kenntnisse mit, welche für den Rest des Teams erforderlich ist, um ihre Arbeit fortzusetzen. Was ist denn funktionierend? Das habe ich gerade== mit Stand heut im März 2018 so schön
Es geht/funktioniert!…. Hast Du es getestet? Ja! Wo sind denn die Testfälle … ähhh ne – das war nur hier so…. Ich muss noch debuggen…à Wie jetzt – ich dachte es funktioniert! Funktionierend heißt im Sinne von Qualität: “Compliance with Requirements“ Dabei ist es völlig unwichtig ob ich nun ein EPIC, eine User Story oder eine klar definierte Anforderung habe. Faktisch sind es alles Anforderungen, welche unterschiedlich detailliert formuliert wurden. Dokumentation ist, ganz besonders im normativen Umfeld ein Muss. Da steht jedoch nie, dass Sie nun exzessiv dokumentieren – die Dokumentation muss DEM ZWECK GERECHT WERDEN! Zusammenarbeit mit dem Kunden hat Vorrang vor der Vertragsverhandlung
Was das NICHT bedeutet:
Vertragsbedingungen sind nicht wichtig. Sie sind. Wenn beide Seiten wirklich zusammenarbeiten, dann sollten beide am Ende zufrieden sein. Machen Sie keine Geschäfte mit Leuten, die mit Ihnen eine Art Sklavenverhältnis etablieren wollen! Kunden verlangen – gerade die Großen Kunden – oftmals ein Wunschkonzert, natürlich kostenfrei – Nada Kunden ändern gerne, aber es darf nichts kosten – Nada Kurz vor der Serie müssen noch Änderungen einfließen (und validiert werden), ohne das der Zeitplan verschoben wird - Nada Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans
Was das NICHT bedeutet:
Planung wird nicht benötigt. Pläne sind wichtig, aber sie sollten nicht in Stein gemeißelt werden. Wer je mit Plänen gearbeitet hat weiß, dass diese typischerweise den ersten Kontakt mit der Realität nicht überleben. Auch kurzfristige Pläne können geändert werden, um die Bedürfnisse eines Unternehmens zu erfüllen. (Steht übrigens auch in den Normen)
Schließlich wird das gesamte Produkt nicht um seiner selbst willen hergestellt - es ist darauf ausgelegt, den Bedürfnissen des Unternehmens gerecht zu werden. Wer nicht in der Lage ist die Arbeitsaufgaben eines großen Projektes in kleine – Zielgruppengerechte „Happen“ – aufzuteilen, hat weder im Management noch in der Projektleitung etwas zu suchen! Warum ist Agile denn nun ein Irrweg? # Der Wichtigste Grund ist:
Es wird als Religion verstanden – ich bin im Recht – Du bist im Unrecht! Das Verhalten (Ich bin im Recht, Du im Unrecht) widerspricht der Tatsache des Gesetzes von Conway – die Kommunikation wird abgeschnitten.
Dadurch sinkt die Produktqualität drastisch! Abgeschnittene Kommunikation „die da (haben doch keine Ahnung)“ führt zu Spannungen.
Die Anwendung der Agilen Prinzipen ist auch im klassischen V-Modell oder Wasserfall möglich! Nicht jedes Problem lässt sich mit einem Hammer lösen, nicht alle Probleme heißen „Nagel“
Das bedeutet, dass man, statt des klassischen technischen Ansatzes einer sachlogischen Überlegung immer mit dem gleichen Prinzip arbeitet ….
Das Arbeiten mit immer gleichen Methoden unter unterschiedlichen Bedingungen ist sachlogisch nicht begründbar!
Wir sind dann im Bereich der Hype oder der Religion == des Glaubens“ == von Beweisen unabhängigem Wissen. Ohne „nach allen Seiten hin offen zu sein“ – dann wären sie „nicht ganz dicht“ – Richten Sie die Augen auf das Ziel, dann wird es klar ob das Auto, der Trecker, die Bahn oder das Flugzeug richtig ist Es wird verwendet um Chaosmanagement zu überspielen Ich habe sehr oft erlebt, dass man im Management das Wort „Agile“ benutzt um damit die Unfähigkeit einer strukturierten Herangehensweise zu verdecken. Es wird munter drauf los entwickelt, ohne „die Entwicklung“ einen Zusammenhang mit den anderen Bedürfnissen zu bringen. Studienergebnisse zeigen, dass die Methode NICHT die Ursache für gute und schnelle Produkte ist Agile skaliert nicht! Abgesehen von den Studienergebnissen z.B. im Automobilsektor, wo man dann doch wieder zu den klassischen Methoden schwenkt. SAFe® und LESS sind auch keine Lösung - besonders wenn den Anwender fragt.
„Ja, das Management ist begeistert, aber es ist schlimmer als vorher“ (Aussage bei einem großen Deutschen Unternehmen)
„Wir müssen das machen, aber es geht nicht“ (Tier 1)
…… Der Schlüssel zu Erfolg ist – wie in umfangreichen Studienergebnissen belegt ist:
Erfahrung Wenn die Methode nicht die Ursache für gute und schnelle Realisierung ist, sollte man ganz einfach die Methode so wählen, wie es dem Zweck entspricht!
