Viele Leute, mit denen ich zu tun habe, sind frustriert, enttäuscht oder abgeneigt gegenüber Agilität. Ihre Firmen führen Agilität ein über Scrum oder Kanban oder LeSS oder SaFe – und wie sie alle heissen. Den Mitarbeitern werden diese Ansätze als agile Methode vorgestellt, welche bestimmte Strukturen (Meetings, Rollen, Abläufe) mit sich bringt. An diesen Strukturen halten sich Mitarbeiter nur zu gern fest. Das ist menschlich. Denn etwas Neues bedeutet Veränderung – logisch. Und wir Menschen suchen immer wieder Orientierung, um uns sicher zu fühlen, uns zu stabilisieren. Nur orientieren sich die meisten, welche agil werden wollen, am Falschen: an (scheinbar) starren Strukturen vermeintlicher Methoden zur Agilität. Ich höre dann Aussagen wie: „Agilität ist Blödsinn!“ oder „Agilität funktioniert bei uns nicht“. Und ja, agile Methoden sind Blödsinn!
Doch die oben genannten agilen Ansätze sind keine Methoden. Sie sind kein planmässiges und folgerichtiges Verfahren. Es sind Rahmenwerke. Die Strukturen, welche diese anbieten, dürfen nicht als die absolute Wahrheit oder eben „one-size-fits-all“-Lösung verstanden werden. Ich sehe in ihnen mehr eine gute Praxis, eine erste Anregung. In der Theorie machen die dargebotenen Strukturen total Sinn…doch sie sind in einem kontextlosen Raum. In der Realität treffen sie immer auf einen bestimmten Kontext…und machen mehr oder weniger Sinn – meist weniger. Dann sind sie Blödsinn.
Agilität ist eben nicht Strukturen, sondern Prinzipien. Alle agilen Rahmenwerke bauen auf bestimmten Prinzipen* auf. Und diese übersehen die meisten leider bzw. sie übergehen sie schnell.
Für mich sind neue Strukturen, also organisationelle Veränderung, nicht Agilität, sondern eine inherente Folge davon. Nicht die Agilität gestalten die Organisation neu, sondern die Mitarbeiter aufbauend auf agilen Prinzipien. Und ja, richtig gelesen. Mitarbeiter (!!!) sollen zusammen gestalten, wie sie sich organisieren. Und zwar alle Mitarbeiter einer Organisation (Führung miteingeschlossen) im Dialog. Das verstehe ich unter den im Zusammenhang mit Agilität oft benutzten Schlagwörtern „Selbstorganisation“ und „Ko-Kreation“.
Agilität ist keine fertig gebackene Lösung, geschweige denn ein Rezept. Agilität ist ein Kompass. Der Kompass zeigt auf Prinzipien, an denen sich die Mitarbeiter orientieren sollen, um so die beste Lösung in ihrem Kontext gemeinsam und kontinuierlich zu gestalten.
* Das agile Manifest, Scrum Säulen & Werte (S.4), Kanban Prinzipien, LeSS Prinzipien
Wozu braucht man agile Coaches oder Chapter Heads? So ein Schwachsinn! Noch mehr Leute, die im Unternehmen den ganzen Tag rumhängen, Kaffee trinken, unnötige Meetings veranstalten und für Nichts Geld bekommen. Während der arbeitende Rest der Belegschaft gar nicht weiss, wo zuerst hinlangen weil es zuwenig Leute für zuviel Arbeit gibt….
Es ist so zum Kotzen….die Arbeitsmotivation sinkt in den Keller wenn man sieht wie diese unnötigen Leute nichts anderes tun als den ganzen Tag über Privates zu quatschen und wo sie in den nächsten Urlaub fahren und wie lieb wir uns doch hier alle haben….
Gerne wäre ich jetzt schon Privatier und müsste mir den ganzen Schwachsinn nicht mehr geben. Sollen doch die agile Coaches mal anfangen was produktives zu arbeiten…
Hallo B. Herzlichen Dank für deinen Beitrag.
Mir scheint als ob du nicht viele gute Erfahrungen mit Coaches gemacht hast.
Aus meiner Erfahrung sind Coaches sehr hilfreiche Arbeiter, welche helfen die Misstände, Dysfunktionen und Probleme in einer Organisation zu identifizieren und zu beheben.
Wenn das in deiner Firma nicht so läuft müsste wohl jemand den Mut haben die Rolle der Coaches und der Führungskräfte anzusprechen und ihnen helfen einen grösseren Beitrag an die Wertschöpfung zu leisten.
Viel Erfolg beim Versuch die Welt zu verbessern!
Ich habe vor fast 20 Jahren etwas über Pair-Programming gelesen. Irgendein wichtiges Buch, dessen Titel ich nun leider vergessen habe. Das agile Manifest und über agile Softwareentwicklung habe ich auch gelesen. Was aber Scrum angeht, da bin ich ein bisschen auf den Kriegsfuß, weil es nicht funktioniert. Ich erlebte es direkt mit dem Berufseinstieg. Wir planten ein paar Sprints, aber das zerlief sich nach ungefähr sechs Monaten.
Ich sehe ein paar Probleme:
Die zwanghafte Planung in Sprints. Manche Themen lassen sich nicht in einem Sprint abhandeln. Gerade „algorithmisch harte Nüsse“ sind da ganz schwer zu integrieren. Ich habe den Eindruck, dass Scrum von Entwicklern geboren wurde, die ohnehin nur an der Oberfläche kratzen und nur Aufgaben in Form von „Stelle eine Maske für X“ bereit, „Stelle Funktionalität A bereit“, kennen. Da ich die etwas komplexeren Aufgaben abgekam, weil ich da schon Ideen hatte, konnte im Daily Meeting oft nur sagen, dass ich noch an diesem einen Problem arbeite. Das machte einen schlechten Eindruck, obwohl meine Arbeit hinterher mehr Früchte trug. Ich kam ja damals frisch von der TU und löste eines unser Probleme ganz klassisch mit Graphentheorie und Dijkstra. Nun hatte ich aber mit Leuten zu tun, für die war das alles unbekannt, weil es offenbar an vielen Fachhochschulen und leider auch an manchen Universitäten die Graphentheorie nicht zum Pflichtprogramm gehört. Das finde ich echt schade, weil ich sehr viel gewinnbringendes aus der Graphentheorie ziehe. Die Unkenntnis darüber bei bei vielen Entwicklern, Architekten und Projektmanagern ist ein echter Malus.
Man macht sich oft doppelte Arbeit. Mehrere Entwickler arbeiten an etwas, das ähnlich ist , wo man 80 bis 90 % des Codes in gemeinsam genutzte Oberklassen und Funktionen verlagern kann. Nur wird das zu spät gesehen. Nicht nur, weil mehrere Entwickler parallel arbeiten, sondern auch, weil der Entwickler sprinten muss. Er sieht nur Aufgabe A. Setzt das um. Dann bekommt er zwei Sprint später Aufgabe B. Vielleicht erkennt er hier schon, dass hier 80 % durch A abgedeckt ist, aber weil es nicht von Anfang berücksichtigt wurde, sind die Strukturen schlecht wieder verwendbar und ein denkfauler Programmierer macht an der Stelle Copy’n’paste. Er rechnet auch nicht damit, dass im nächsten Sprint eine Aufgabe C kommt, die von gemeinsamen Teilen von A und B profitieren könnte. Sicherlich ist dies kein Argument gegen Scrum, weil das Problem überall woanders auch sieht, aber Scrum forciert diese Scheißegalmentalität, Hauptsache der Sprint wird fertig.
Für das Refactoring wird keine Zeit. Ich stoße in meinen Projekte häufig auf Widerstand, wenn ich offensichtliche Fehler im Bestandscode beheben will. Natürlich sind Kollegen brüskiert, weil es ihr Code, aber im Scrum-Sprint war es besonders verwerflich, weil ja keine Funktionalität hinzukommt. Dabei kann man in vielen schlauen Büchern lesen, wie wichtig Refactoring ist.
Ich hatte mal einne Experten im Team, der es schaffte, komplette Strukturen per Copy’n-Paste immer wieder zu bringen, immer geringfügig angepasst für den neuen Fall. Das waren locker über 100 Klassen mit den immer gleichen Methodenimplementierungen. Ich habe es gesehen und zusammengeführt. Im Sprint war das nicht vorgesehen und dafür gab es eins auf den Deckel. Aber es war richtig aus mehrere Gründen: a) Der Kollege hat auch einen Bug immer wieder Copy’n’paste dupliziert. b) Auch duplizierte er suboptimale Implementierungen, was die Performance angeht. c) Der Code war ungetestet. – Ich dampfte den Code stark ein per Extrahierung von Oberklassen. Die Folge war, dass die Testabdeckung des Gesamtprojektes von 60 % auf 85 % hochschnellte, weil einfach weniger Code vorhanden war. Bugs und Performance-Probleme konnten auch schneller identifiziert und gefixt werden denn es war nur plötzlich nur noch eine Stelle im Code, die geändert werden musste und nicht 40. Es wäre aber besser für alle Beteiligten gewesen, hätte der Copy’n’Paste-Entwickler viel früher mal über ein Refactoring nachgedacht. Auch diese Problematik ist kein Alleinstellungsmerkmal von Scrum, aber Scrum forciert es durch die Sprinterei.
Es heißt, Scrum nehme keine Rücksicht auf Hierarchien. So steht es in der Wikipedia. In der Wikipedia wird es aber nicht als Malus angesehen, dass auch keine Rücksicht auf Kompetenz in Sinne von Befähigung nimmt. Man kann aber nicht alle Entwickler gleich behandeln, weil sie ja nicht gleich sind. Es heißt doch, dass ein sehr starker Entwickler die Produktivität von 10 durchschnittlichen aufweisen kann. Das heißt ja gerade nicht, dass er zehn mal so viel Code schreibt, sondern dass er abstrahiert und den Code klein hält und robuste Lösungen entwickelt. Genau die Leute werden durch Scrum ausbremst und weniger starke Entwickler können auch nicht davon lernen, weil ja der Sprint fertig werden muss und der starke Entwickler kann seine Konzepte nicht umsetzen, aber von denen sollten man doch lernen können.
Meine Erfahrungen mit Scrum sind insgesamt negativ. Es muss einen Pool von unterschiedlichen Entwicklern geben. Es muss klar sein, wessen Designentscheidung Zweifelsfall zu nehmen ist. Schwache Entwickler müssen von erfahrenen lernen. Dem Refactoring muss viel Raum eingeräumt werden.
Hi Johannes. Merci für deinen Beitrag! Sehr cool.