Scrum, Extreme Programming (XP) & Co.: Die agile Lüge // deutsch

[@thenativeweb]

Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Scrum-XP-Co-warum-keiner-mehr-agil-arbeiten-will-9846824.html

[@yannick5099]

Das was aktuell in manchen Firmen als "Agil" betitelt wird (also Fake/Dark Agile) nimmt mir die Lust an der Softwareentwicklung. Nichts wird fertig. Qualität ist niedriger. Der Prozess an sich verbraucht den Großteil der Zeit. Entwickler haben nahezu 0 Einfluss. Es ist schlimmer als jede Karikatur des Wasserfallmodells. 😮‍💨

[@minimal3734]

Unser Konzern wurde vor 4 Jahren auf "agil" umgestellt. Seitdem sind wir nur noch Soldaten, die stumpfsinnig Aufträge abarbeiten. Früher wurde den Mitarbeitern vertraut. Sie hatten die Freiheit, selbst zu denken und in jedem Moment das jeweils Richtige zu tun. Nun ist alle Intelligenz, Flexibilität und Verantwortungsbereitschaft ausgetrieben worden.

[@svr5423]

hatte die letzten 4 Jahre einen Kunden der "agil" war. Ich glaube ich habe noch nie so wenig tatsächlich geleistet in meinem Leben. Dinge die man mit ein paar Tagen Vorlaufzeit einfach gemacht hat, brauchten plötzlich ganze PIs als Vorbereitung.

[@codingcrashcourses8533]

@@danielchristopherpre Jop, man braucht sich nicht einbilden, dass wenn man genervt das Unternehmen wechselt, es dann besser werden würde.

[@Skoell1983]

So. Genau so!

[@minimal3734]

Der Software-Konzern, in dem ich seit 16 Jahren arbeite, wurde vor 4 Jahren "agil". Seitdem sind wir Soldaten, die stumpfsinnig Tickets abarbeiten. Intelligenz, Flexibilität und Verantwortungsbereitschaft wurden abgeschafft.

[@thk4711]

Wir haben bei uns Bewerber, deren erste Frage ist: Wie viele Meetings macht ihr so pro Tag? Die kommen vor lauter Scrum bedingten Meetings nicht mehr zum Arbeiten und sind nur noch am Reporten, was alles nicht geworden ist. So haben die dauernd ein schlechtes Gewissen und keine Möglichkeit, daran etwas zu ändern. Die wollen einfach wieder mal in Ruhe Code schreiben.

[@hirkdeknirk1]

Interessant. Mir wurde gesagt, dass wir trotz permanenter Misserfolge auf den agilen Quatsch nicht verzichten können weil sich sonst keiner mehr bewirbt.

[@svr5423]

würde ich mich für eine interne Stelle bewerben, wäre dies auch meine erste Frage. Oder zumindest ganz oben auf der Liste. Als Externer tut man das was der Kunde will. Wenn das täglich 4h Meetings, Passwortmanagement für 12 SSO Accounts und 50 IAM Rollen auf einer verkrüppelten Windows-Möhre ist, dann ist das halt so. Am Ende schiebt man die Stories im Jira Board umher und malt postits im virtuellen whiteboards beim retro bunt an. Hauptsache die Zahlen stimmen und alle sind glücklich. Die *nager verstehen sowieso nicht was die internen und externen engineers tatsächlich machen oder machen könnten.

[@tribonian3875]

@@hirkdeknirk1 Es gibt halt Mitarbeiter, die lieben Meetings. Vielleicht um sich selbst darstellen zu können, so oft wie möglich. Aus Problemen reden die sich dann irgendwie heraus. Oder die Leute wollen halt "agil" im Projektprofil stehen haben. Ich habe mir jedenfalls vorgenommen: in strenger agiler Arbeit mit Massen an Meetings werde ich nicht mehr mittun. Bin nun mal der Wasserfalltyp. Nur so kann ich Qualität liefern.

[@troi951]

Im Home-Office sind diese ganzen Retros und Reviews ein Träumchen. Kann man optimal nutzen die Bude aufzuräumen.

[@MetalheadAndNerd]

Oder kochen, wenn das Bluetooth-Headset so weit reicht. ​@@troi951

[@joechip4822]

Für agil und SCRUM gilt dasselbe, dass für zig andere Methoden vorher auch gegolten hat: sie helfen maximal einem GUTEN TEAM dabei, ein überdurchschnittlich komplexes Projekt zu stemmen. Sie helfen aber so gut wie nie dabei, aus einem SCHLECHTEN TEAM ein Gutes zu machen. Sage ich mit über 35 Jahren Erfahrung als Full-stack Entwickler in 6 verschieden Branchen.

[@kassipopassi]

Ein schlechtes Team wird wohl per Definition ein schlechteres Ergebnis liefern als ein gutes, egal welche Methodik angewendet wird

[@ich3601]

Ich würde es akzetuierter Formulieren: Ein gutes Team wird mit, auf das Team angepassten agilen Methoden und in der passenden Organisation, besser. Ein schlechtes Team schlechter. Jedes Team in einer schlechten Organisation verbrannt. Je nach eingesetzter Variante sind die Anforderungen an die Teammitglieder, die Unternehmensorganisation und den Kunden erheblich. Vor Eintritt in ein Entwicklungsteam: Würdet ihr euch die Einführung der 5W-Methode in eurem Unternehmen trauen?

[@berndbeimdick7244]

Super Zusammenstellung der Schwierigkeiten. Ich möchte dieser noch drei hinzufügen: 1. Dogmatische (fast religiöse) Handhabung der Methodik 2. Einschlafen der Selbstoptimierung in SCRUM (Retros sind inhaltlich repetitiv) 3. Nicht teamfähige Mitglieder und die fehlende Konsequenz diese aus dem Team zu entfernen.

[@christianibendorf9086]

„Nicht teamfähige Mitglieder entfernen“. Na, das klingt ja nach nem heiteren Team … wer entscheidet das denn, der kleinfaschistoide Mob? Und was sagt das über die Teamfähigkeit des Restteams aus, wenn man Leute entfernen muß, weil man mit ihnen nicht klarkommt?

[@HelmutQ]

Hätte man nicht teamfähige Mitglieder aus dem Team entfernt, gäbe es keinen Linux Kernel. Keine andere Software läuft gleichzeitig in so vielen Instanzen, was Thorvald auch immer für ein Kotzbrocken sein mag.

[@maximilianziener3744]

Ich würde mir wünschen wenn die Methodik mal durchgezogen wird. Wenn ich mich umschaue, dann sehe ich Projektleiter die PO und Master sind, außerdem haben die noch ein Teamlead und drehen sich dann natürlich im Kreis, dann geht nichts voran und dann ist Agil oder Scrum Schuld, dann kommt die nächste Consulting Agentur und dann gibts wieder hierarchische Mikromanagement Wasserfallprojekte, die laufen dann 9 Monate gut, bis die wichtigsten kündigen, die Projekte laufen nicht mehr und es wird wieder auf Scrum umgestellt....die Consultants sind hier einfach das Problem.

[@PabloRamon-h1n]

Sektenhafte Handlungen

[@DemokratieErwacht]

Frage des POs: Wann ist mein Feature fertig? Rückfrage des Teams: Du meinst so richtig fertig, fertig, dass es zum Kunden kann? Dann 2 Monate. PO: Was? Ich wollte doch nur einen anderen Text im Menü! Was macht ihr eigentlich? Unsere Antwort: Refinements, 2h über den Text diskutieren, Storyboard, Testkonzept, automatische Tests, Testcoverage, statische Codeanalyse, ... Und übrigens wird die Übersetzung in die 35 Sprachen von einer externen Firma gemacht, dafür schreiben wir Arbeitsaufträge, Akzeptanzkriterien, .....

[@thenativeweb]

Was ich super finde - Ihr denkt in "Feature Complete" und nicht in "Code Complete" 😊

[@DemokratieErwacht]

@@thenativeweb es muss ja so fertig sein, dass man es einem Kunden geben kann. Nach dem ScrumTeam, schaut sich bei uns niemand das Produkt mehr an. Testabteilung wurde leider abgeschafft. Von daher ist Übersetzung freigaberelevant.

[@tobiasmogdans7878]

@@DemokratieErwacht Also müsst ihr eigenverantwortlich arbeiten, um gute Qualität zu liefern?! Das gehört für mich zum agilen Arbeiten ganz vorne mit dazu und wird leider vielerorts ignoriert.

[@Shmbler]

@@DemokratieErwacht Das ist für mich das übelste überhaupt. Vor 25 Jahren hatten wir noch einen massiven Systemtest mit dutzenden Mitarbeitern und entsprechend Knowhow, durch das man als Dev effektiv die Produktqualität im Griff hatte. Bis zur Freigabe wurden die geplanten Features getestet bis zum Erbrechen. Heute wird ein Feature nach dem anderen in den Code geprügelt und der Test mehr oder weniger dem Dev selbst überlassen, welcher nach dem Checkin natürlich längst an anderen Themen arbeitet. Die Qualität dessen, was der Kunde letztlich erhält, ist einfach unterirdisch. Nicht mehr stolz auf sein Werk sein zu können, das finde ich persönlich extrem frustrierend.

[@BBirke1337]

Sowas kenn ich als Kinderkrankheiten, ist zum Glück vorbei. Refinements des gesamten Teams gibt es nicht mehr, nur noch die, die sich damit beschäftigen. Tests werden gemacht und kosten viel Zeit, sind aber für die Qualität essentiell. Dank Docker kann man auch sowas wie Datenbanken, externe Webserver usw. leichter integrieren. Ich bin mal bei der Neueinführung von Scrum Leuten auf den Schlips getreten, als ich gesagt hab, dass wir soviel Zeit mit Meetings "verplempert" hätten. Vielerorts hätte sowas wohl ernste Konsequenzen gehabt, aber hier nicht, und die agile Entwicklung hat sich verbessert.

[@rolfwuerth2461]

"der agil-industrielle Komplex" - sehr schön formuliert 😁

[@SofaKartoffelSchorsch]

Ich denke ist wie beim consulting, es gibt gute und schlechte, der Unterschied ist vor allem ob man dauerhaft Mehrwert beim Kunden schaffen will oder die Kuh melken will bis sie zum Schlachter geht... (wie in jedem anderen Business auch) Der Optimist in mir hofft ja, dass es mehr gute als schlechte gibt aber ich kann es nicht quantifizeren.

[@wunder1385]

The agile industrial complex and it's consequences have been a disaster for the human race

[@freemanch.6720]

Schön dass das jetzt einen Namen hat 😂

[@JavierGomez-lv5mq]

​@@wunder1385 indeed, one problem is that you can only see and understand that, if you are willing to think about it, which people CLEARLY are not!

[@tinoengel363]

Danke für dieses Video. Ich glaube auch, dass Agil aufgrund der notwendigen Rahmenbedingungen nicht so einfach gelebt werden kann. Hier geht es auch um Freiräume (für Fehler), Vertrauen und Eigenverantwortung. Das fehlt jedoch in sehr vielen Unternehmen.

[@thenativeweb]

Ja, das trifft es sehr gut. Danke 😊

[@neutralias]

Ja, genau das ist das Problem. Es wird vergessen, dass die Kultur ein fundamentaler Faktor ist.

[@lassmalgehen]

Ein Inpout aus einem anderen Bereich. Ich bin Sozialberaterin und wir arbeiten immer mehr agil. In kleinen Projekten, Scrum Meeting und Storyboard. Es wird immer mehr und funktioniert. Ich denke es funktioniert mehr, weil wir gewohnt sind frei zu arbeiten.

[@andreasschmalzl1752]

​@@lassmalgehenJa.

[@minimal3734]

Unser Konzern wurde vor 4 Jahren auf "agil" umgestellt. Seitdem sind wir nur noch Soldaten, die stumpfsinnig Aufträge abarbeiten. Früher wurde den Mitarbeitern vertraut. Sie hatten die Freiheit, selbst zu denken und in jedem Moment das jeweils Richtige zu tun. Nun ist alle Intelligenz, Flexibilität und Verantwortungsbereitschaft ausgetrieben worden.

[@mariobader2152]

Also ich arbeite seit bald 30 Jahren an der Schnittstelle zu Infrastruktur und Softwareentwicklung, ich will es mal so sagen die Erstellung von Software war immer flexibel, musste Sie auch sein. In meiner subjektiven Wahrnehmung wurde immer von der BWL- und Marketingseite solche Schlagworte benutzt, um irgendetwas zu verkaufen ...... ! Die eigentlichen Entwickler oder Systemarchitekten waren immer bzw. sind flexibel (agil 🙂) auch ohne irgendwelche Pseudozertifikate.

[@SvenAmend]

So ist es. Die Umsetzung wird gerne "agil" gehalten. Jegliche konkreten Planungen, Kalkulationen, Vertragswesen etc. sind allein schon aus Haftungs-/Gewährleistungsgründen selten wirklich agil und eher sehr statisch.

[@-Jakob-]

Ein bisschen Balance schadet nie. Viele Entwickler tendieren gerne dazu, über längere (zu lange) Strecken abzutauchen. Dazu muss man Methoden haben, diese immer wieder nah an die Oberfläche zu steuern, wo sich so seltsame Geschöpfe wie Anforderungen, Timelines, Kosten, QS, Sichtbarkeiten, Abhängigkeiten, Finanzierungen, Marketingstrategien tummeln. Genauso muss man auch (Micro-)Controller und Vermarkter ab und an dazu bringen, mehr Bodeneffekte zu nutzen, sonst tendieren diese nach Wolkenkuckucksheim (oder Nirvana). Die Frage ist halt, wer bringt all diese Balance gut hin, da müssen die einzelnen Kompetenzbereiche an einem Strang ziehen: eine Herhausforderung.

[@Rippafratta]

So isses. Hört heute noch jemand vom 360-Grad-Ansatz? Das war so grottendämliches, durchschaubares Marketing-Gewäsch, dass es mir den letzten Schub gegeben hat für meine Entscheidung, mein Angestelltenverhältnis zu verlassen.

[@Rippafratta]

@@-Jakob-Ja, vernünftige Firmen (egal in welcher Branche der Kreativität) machen daher seit jeher (lange vor irgendwelchen Buzzwords) eine kurze Frühbesprechung. Die reicht für gewöhnlich, den Überblick zu behalten und da und dort zu steuern.

[@andreas7944]

So ganz unterschreiben kann ich das nicht. Früher hat man ein Lastenheft gehabt und das auch hart verhandelt. Abgeliefert wurde es dann auch exakt so, wie es aufgeschrieben wurde. Denn man hat damals nach Festpreis gearbeitet. Das war definitiv nicht flexibel. Der Übergang in Richtung moralischer Festpreis und Agilität war schon deutlich spürbar.

[@marcello3159]

Meine Eindrücke: Agilität wurde (i.d.R. von Fachfremden) als Buzzword angewendet und als Allheilmittel verstanden ohne dass die Entscheider Agilität als Ganzes verstanden haben. Wenn ich mir angucke, wer allein mit dem Begriff um sich geworfen hat, wundert es mich nicht, dass das Topic "verbrannt" ist, weil es die unrealistische und zweckentfremdete Erwartungshaltungen nicht erfüllen konnte. Eine weitere Beobachtung meinerseits: Es wird versucht, Agilität mit der Brechstange auf alles anzuwenden - selbst Linienprozesse. Und wenn sich nach und nach herausstellt, dass es nicht passt, dann wurde es Fingerpointing in Richtung "Agilität ist Mist" statt sich selbstkritisch damit auseinanderzusetzen, dass man versucht hat, mit einem Hammer eine Schraube einzudrehen.

[@alexanderweigand6758]

Mag sein. Ich war aber noch nie von Agilität begeistert und wundere mich da nicht wenn der Begriff verbrannt wird. Wenn es um Speziallösungen für einen Kunden geht dann ist es wichtig dass der Kunde ein genaues Lastenheft erstellen kann. Das Problem. Der Kunde hat keine Ahnung was Software kann und was nicht. Hier kann es helfen wenn es beim Kunden eine IT Koordinationsabteilung gibt die sowohl versteht was die andere Abteilung benötigt als auch ob/wie Software das liefern kann. Ist natürlich auch nichts was garantiert funktioniert. Schlechte Manager bekommen auch so etwas kaputt. Ob jetzt der Gruppenleiter der keine Ahnung hat aber meint bei allen Arbeiten seiner Untergebenen irgendwie mitreden zu müssen. Oder der Typ von ganz oben im Management der auf der Messe diese tolle Software gesehen hat die jetzt "gesetzt ist". Dann sehen sich "die unten" das an und finden es .... Dann ein wir müssen es installieren, aber nicht nutzen. Wie müssen unsere eigene Software entwickeln (lassen). Was das ganz hohe Tier dann natürlich nicht gut findet wenn er das irgendwann herausfindet. Ich gebe Millionen aus für die optimale Software und die wollen für 50 oder 100k€ etwas eigenes entwickeln (lassen). Das muss ich verhindern. Keine Ahnung wie diese Entwicklung weiter ging. Ich vermute die fehlenden Features der gesetzten Lösung werden dann irgendwann für einige Millionen mehr als Erweiterung gekauft.

[@jorgw.6151]

Für Embedded Systeme ist Agilität ungeeignet. Die Systeme laufen Monate bis Jahre am Stück und dürfen nur extrem wenige Fehler haben. Die Hektik, die Agilität in die Entwicklung bringt, führt zu einer schlechten Softwarequalität. Die wird dann versucht über automatisierte Tests zu erhöhen aber das hat ja noch nie funktionert, da sich die Fehler an die Tests anpassen und sie so umgehen. Das ist das Gesetz der Evolution.

[@Nickrii]

Wenn Agilität zu Hektik führt, ist es nicht agil, sondern der getarnte Versuch, den Druck zu erhöhen, um noch mehr Output in kürzerer Zeit aus den Mitarbeitern zu pressen. Agilität soll nämlich das genaue Gegenteil bewirken: positiv darauf reagieren zu können, wenn mal etwas nicht so läuft wie gedacht.

[@flitzebogen0815]

Ich habe leider auch genau die gleiche Erfahrung im Embedded Bereich gemacht. Agil ist häufig ein anderes Wort für, wir machen alles nur noch auf Zuruf und machen uns keine Gedanken. Alles wird mit der heißen Nadel gestrickt. Für mich ist Agil ein sch... Buzzword für alles schnell schnell und möglichst billig. Der Entwickler ist dann derjenige der das ganze unter hohem Druck zusammen zimmern darf, obwohl er von vornherein schon weiß, dass das alles nach hinten losgeht.

[@michaelme4028]

Besonders wichtig ist eine gute Fehlerkultur. Niemand sollte Scheu haben, mögliche Fehler einzugestehen und niemand sollte sich für Fehler rechtfertigen müssen. Fehler passieren und man sollte stressfrei damit umgehen. Automatisierte Tests können helfen, Fehler frühzeitig zu erkennen, eine Garantie für Fehlerfreiheit gibt es jedoch nicht. Man kann auch spezielle Tests durchführen, wie Z. B. Performance Tests, um Verschlechterungen frühzeitig zu erkennen. Denn auch wenn Software generell funktioniert, kann es sein, dass es bei Lastspitzen, etc. zu erheblichen Problemen kommt. Auch Ressourcenlecks können zu massiven Problemen führen, auch wenn diese bei einfachen Tests nicht auffallen, sondern erst im Dauereinsatz zu Problemen führen. Continuous Delivery und Deployment automatisiert lästige Arbeit, damit Entwickler sich auf das konzentrieren können, was am meisten Spaß macht, nämlich produktives Arbeiten.

[@jorgw.6151]

@@Nickrii Bei uns war das so. Die Agilität war nur ein Deckmäntelchen für die geplante Totalüberwachung aus der Geschäftsführung. Letztendlich haben die nichts verstanden und meinten man könnte die Regeln der Agilität für die Mechanikentwicklung auf die Software anwenden. Ich wurde tatsächlich ernsthaft beauftragt die Softwareteilaufgaben in 3 Schwierigkeitsstufen einzuteilen und dafür feste Bearbeitungszeiten (von Stunden ;-) bis max. 1 Woche) anzugeben. Zeit zu gehen. 🙂

[@BeX32210]

Natürlich kann man Embedded-Entwicklung auch agil machen, und das auch nicht schlecht. Ob man es tun sollte ist eine andere Frage. Nach Lehrbuch ist „agile Entwicklung“ in erster Linie für komplexe und explorative Projekte geeignet. Bei klassischer Embedded-Entwicklung sollte aber von Anfang an ein Lastenheft vorliegen und das Herunterschreiben der Anforderungen ist dann nur noch Fleißarbeit. So kannst du dann auch Tests entwickeln und sogar damit Test-Driven mit CI/CD und HIL entwickeln um schnelles Feedback zu bekommen.

[@Joamonica]

Wow. So ein gutes, kompetentes Video habe ich in YT schon länger nicht gesehen! Fliessender Vortrag, Materie total im Griff, schlüssige Argumentation, kein Blabla, keine Äääähmm-orgie, fantastisch. Danke sehr.

[@TheLightAhead]

Nach meiner über 20-jährigen Erfahrung als Prozess-Berater (ich schreibe jetzt trotz Zertifikats extra nicht Scrum Master) ist die mit Abstand(!) größte Hürde zur erfolgreichen Umsetzung agiler Methoden (egal ob Scrum, Kanban oder XP) der Widerwille in Führungsebenen, die auch in den Unternehmensstrukturen notwendigen Änderungen zu gestatten und zu unterstützen. Auf operativer Ebene ist bspw. der Konflikt zwischen agiler und klassischer Planung (Ressourcen/Termin/Budget) aufgrund des Beharrungsvermögens von Führungskräften mittlerer Ebene fast unüberbrückbar. Und an dieser Stelle hilft es dann auch sehr schnell nicht mehr, wenn in den Teams Scrum nach Lehrbuch umgesetzt wird. Ich hatte persönlich übrigens meine ersten ausgesprochen guten Erfahrungen mit Agilität bereits Mitte der 90er mit XP. Und ebenso halte ich Kanban (in Verbindung mit XP-Ansätzen) für wesentlich effektiver und vor allem agiler im eigentlichen Sinne, als es Scrum sein kann. Aber das ist nur meine persönliche Ansicht dazu und hat vielleicht auch damit zu tun, dass unter dem immer populärer werdenden DevOps-Ansatz Kanban sehr viel besser funktioniert als Scrum.

[@tribonian3875]

Stimme als Entwickler zum Punkt Kanban vollkommen zu. Damit kann man gut arbeiten.

[@nonlinearsound-001]

Ich kann die Effektivität von Kanban auch nur bestätigen. Nicht nur in meiner aktuell täglichen Projektstrukturierung in der Leitung der IT des Unternehmens sondern all meiner persönlichen Softwareentwicklungsprojekte. Klappt wirklich gut weil einfach und übersichtlich.

[@nonlinearsound-001]

Bezüglich Wasserkopf: In einem aktuellen E-Commerce Projekt ist der Vertrieb faktisch der Product Manager und dies ist klar zu merken. Keine Struktur in der Produktentwicklung, keine langfristige Strategie und Zielfindung sowie Features, die ohne Umwege direkt auf Kundenwunsch in den Backlog gedrückt werden. So kann’s natürlich nichts werden mit einer agilen Entwicklung.

[@TheLightAhead]

@@nonlinearsound-001 Ich beklage nicht den "Wasserkopf" (wenngleich ich diesen auch nicht negieren will), sondern den Unwillen oder das Unvermögen von Führungskräften, sich auf das Mindset einzulassen, das in agilen Modellen verlangt wird. Unvermögen findet sich vor allem dort, wo sich Personen befinden, die sich auf ein "Das hat früher doch auch und meist besser funktioniert!" zurückziehen, während Unwillen vor allem dort anzutreffen ist, wenn sich jemand durch einen möglichen Machtverlust bedroht fühlt. Und es gibt natürlich auch die Kombination aus beidem. Was ich in zwanzig Jahren noch nicht erlebt habe: Dass eine Führungskraft sich mit voller innerer Überzeugung auf einen Hierarchieabbau durch Agilität eingelassen hätte - inklusive der damit einhergehenden eigenen Entmachtung.

[@tom1stein2]

Für alle, die es noch nicht kapiert haben: Auch das V-Modell sagt nicht, dass es nur einmal durchlaufen werden DARF. Es enthält sogar die Aufforderung für Schleifen: Stellt ein Test fest, dass etwas falsch ist, kann das auch an einer falschen (z.B. widersprüchlichen) Anforderung liegen, und der muss vorne im V korrigiert werden. Der eigentliche Fehler vom V-Modell ist, dass diese Schleife nicht als Schleife benannt wird. - Klappt man die rechte Hälfte des V nach unten, kommt man zum Wasserfall-Modell, und muss dort feststellen, dass es auch dort Schleifen wieder zurück geben muss. Und wer Software im Sicherheits-Bereich entwickelt, darf agil logischerweise nur innerhalb eines Release-Zyklus sein - am Ende muss eine (vorher!) definierte Funktion mit einem dokumentierten Umfang entstehen, alle agilen Zwischenschritte dienen nur Zwischentests, also Wegen zum Ziel.

[@w1darr]

Für alle, sie noch wissen, wie Sprache funktioniert: Das ursprüngliche Wasserfallmodell ist nicht das, worauf sich der Begriff Wasserfallmodell heute bezieht. So funktioniert Sprache- Dinge ändern sich, Bedeutungen wandeln sich.

[@Telfast92]

Ich arbeite in einem großen deutschen Konzern als Senior Developer. Bei uns sind die "agilen" Prozesse nur im Namen agil... Extrem viele Meetings, starre Prozesse und drei Monatspläne, bei denen kein Informatiker wirklich mitbestimmen darf. In meinem Team arbeiten mehr Leute ohne technischen Hintergrund als Informatiker. Oft verstehen die Leute gar nichts von Softwareentwicklung machen aber Vorgaben und berufen ein Meeting nach dem nächsten ein.

[@m.k.3370]

Ist doch wenig überraschend. Konzerne sind meistens Aktiengesellschaften. Da ist also die Investorenseite relativ klar gesetzlich reguliert. Ebenso, dass es einen Vorstand und einen Aufsichtsrat benötigt. Dieses wiederum bringt gewisse Rahmen im Reporting über Quartalsveröffentlichungen mit sich. Dann dürfte der Konzern im Kern noch einer Stablinienorganisation folgen. Da ist dann natürlich die Frage, ob und wo eine Organisationseinheit (Bereich / Abteilung, Team, etc.) agil arbeiten kann oder nicht? Ggf. hat man dann noch eine Personalvertretung, die ebenfalls einen gewichtigen Blick auf Organisationsentscheidungen wirft. Besonders wenn es später über transparente Steuerung, Leistungsmessung, etc. geht. Oder letztlich wird sich aus einem Toolset bedient. Und natürlich äußern Menschen Wünsche. Ich verstehe auch nichts vom Bürobau, habe jedoch Vorstellungen, die ich mit den Architekten bespreche. Er hört sich das an und ich bin offen für seine Erklärungen. Diejenigen, die das Bürogebäude errichten, sind jedoch noch überhaupt nicht eingebunden. Wozu auch? Auf der anderen Seite haben wir den Beschluss und Budget für die Errichtung eines neuen Bürogebäudes.

[@andreas7944]

Ab einer gewissen Größe sollte man sich auch anders koordinieren. Viele setzen dabei auf SAFe. Das fängt die ganzen wilden Meetings ein und bündelt diese und macht Abhängigkeiten sichtbar. Eine nette Sache. Dadurch hast du auch einen Plan, bis wann jeder seine Themen erledigt haben muss.

[@DuRoehre90210]

Kommt mir irgendwie bekannt vor. Auf jeden Dev/Op/Integrator kommt mindestens ein "Projektmanager/-koordinator/-XYZ-Teil-Verantwortlicher". Dieser Wasserkopf koordiniert sich dann selbst hin und her, malt illustre Zeitpläne in zig Meetings, und den Entwicklern wird erst am Ende deren Erwartungshaltung mitgeteilt, aber schön mit Zeitbudgets und Bullshit-Versionsnummern und Milestone-Phantasienamen (die man ja mit soooo vieeel Fleiß doch ausgearbeitet hat, das ist doch das wichtigste, blah, blah). Und wehe, es kommt irgendwo eine Störung dazwischen, und die aufwendig ausgearbeiteten Zeitpläne fallen um, dann werden auf einmal nochmal soo viele Meetings nötig, und am liebsten holt man sich noch die Entwickler in die Bullshit-Meetings rein, damit sie dort ihre Zeit mit Erklärungen verplempern, statt die eigentliche Arbeit zu machen.

[@DuRoehre90210]

@@andreas7944 Meinst du das ernst? Nach meiner Erfahrung ist SAFe nur alter Wein in neuen Schläuchen. Dieser Wein wird jetzt über viele verschiedenen Schläuchen aufgeteilt, und jedem Schlauch gibt man illustre Namen, damit auch jeder aus der frühen Bullshit-Brigade sich irgendwo einen passenden Schlauch finden kann. Und dann klebt man überall noch den Suffix "ART" dran, und dann tut man so, als hätte man jetzt ein tolles neues Prozessgerüst gebaut.

[@minimal3734]

Der Software-Konzern, in dem ich seit 16 Jahren arbeite, wurde vor 4 Jahren "agil". Seitdem sind wir Soldaten, die stumpfsinnig Tickets abarbeiten. Intelligenz, Flexibilität und Verantwortungsbereitschaft wurden abgeschafft. Die persönliche Leistung ist seit der Einführung der "agilen" Prozesse stark zurückgegangen. Außer Mittelmaß ist nichts mehr drin. Zum Glück konnte ich in den 12 Jahren bevor wir "agil" wurden das Fundament errichten, von dem wir jetzt zehren.

[@jigglewiggle7878]

Vielen, vielen Dank für dieses Video. Ich habe es lachend und weinend, mit Gänsehaut geschaut. Ich erkenne ganz stark meinen Arbeitgeber bzw. mein altes Team. Ich bin neuen Arbeitsmethoden grundsätzlich immer offen gegenüber, aber sie sollen mich möglichst unsichtbar begleiten und leiten und sich nicht mit unzähligen Meetings in der Vordergrund drängen, so dass ich mich auf meine Arbeit nicht mehr fokussieren kann. Das führte in der Vergangenheit bei mir zu starkem Frust.

[@thenativeweb]

Ja, das kann ich verstehen - und das mit dem einen lachenden und einen weinenden Auge leider auch.

[@husbabbl]

Danke für das Video! Für mich ein wesentlicher Faktor für das Verbranntsein von "agil" ist, dass die Einführung von "Agile" in Grossunternehmen Top-Down betrieben wurde. Teure, praxisferne Berater haben mit den Entscheidern zusammen ein Regime aus Riesen-PIs-Plannings, teamübergreifend synchronisierten Sprints und Shaming-Retros erstellt ("Erklär bitte allen 200 Mann, warum du keinen Daumen-Hoch zeigst. Warum bist du immer so negativ? Sei anders.") Die Leute haben keinen Bock mehr auf sowas.

[@hugosbalder6139]

Ich denke das trifft den Nagel auf den Kopf. Ich habe erlebt das Scrum funktioniert. Man muss nur pragmatisch von der reinen Lehre abweichen wenn erforderlich...............

[@Alois_from_Vienna_in_Austria]

Ein großes Problem ist, dass Agilität nicht nur für die Softwareentwicklung genutzt wird, sondern sich in alle möglichen Bereiche bis hin zum Hardwarebetrieb (oder Dienstleistungsbranchen) eingeschlichen hat. Dort passt es gar nicht hin aber die Methoden werden halt irgendwie angewendet. Außerdem wurde Agilität vom Prozessmodel zum Organisationsaufbaumodel für Unternehmen. Dem Management wurde versprochen, dass man dadurch schneller und billiger wird und Manager, die das Ziel haben Kosten zu senken, haben Agilität als Methode dafür entdeckt, um z.B. Führungskräfte (und Mitarbeiter) einzusparen. Fachliche Führung macht z.B. der Product Owner, der aber genauso "nur" ein Fachexperte wie früher ist, dafür spart man sich einen Teamleiter und die Mitarbeiter führen sich selber.

[@Kupferhans]

"Mitarbeiter führen sich selber"... das hab ich immer als die angenehmste Arbeitsweise erlebt. Es genügt, wenn man ein paar sehr gute/erfahrene Mitarbeiter hat, die Unerfahreneren als Vorbild und Mentor dienen. Wichtige Entscheidungen können gemeinsam diskutiert und umgesetzt werden. Die jüngeren Mitarbeiter entwickeln eine intrinsische Motivation und entwickeln sich weiter. Die Älteren müssen offen bleiben und verstricken sich weniger in starre Denkmuster. Als unangenehm hab ich hingegen Teamleiter empfunden, die qua ihres Amtes zwanghaft ihre Meinung durchsetzen müssen. Etliche Softwareprodukte leiden noch heute unter den Fehlentscheidungen, die vor Jahrzehnten von solchen Leuten getroffen wurden.

[@ayngush.]

Scrum mit seinen Regelwerk ist eigentlich das komplette Gegenteil von dem, was mit "agil" im Sinne des agilen Manifest mal gemeint war. Agil soll es sein sich nicht starr an Pläne und Vorgaben zu halten, sondern auf die Bedürfnisse und Veränderungen beim "Kunden" (Umfeld) einzugehen. Man könnte das ganze agile Manifest meiner Meinung nach auch einfach mit folgendem Satz abkürzen: "Agil ist es, wenn Entwickler einfach ohne Hindernisse ihren Job erledigen können, wollen und dürfen." Da passt ein Regelwerk, welches dir tägliche Meetings, damit auch wieder feste "Arbeitszeiten", starre Sprint-Korsets, feste Aufgaben für vordefinierte Iterationen, uvm. vorgibt irgendwie nicht so recht ins Bild.

[@ayngush.]

@@c.n.5476 Als nach meinem Wissensstand gehört das Anforderungsmanagement immer noch zum Entwicklungsprozess dazu. Es ist also Teil des Jobs. Ich sehe da nichts falsches in meinen Aussagen.

[@RalfGlaschke]

Danke für den Beitrag. Bei uns wurde vor einigen Jahren für ein Projekt Scrum eingeführt und ich habe mich immer gefragt was dass eigentlich verbessern soll. Die inkrementelle Arbeitsweise in Softwareprojekten, bei mir hauptsächlich Automatisierungsprojekte, wurde schon seit Jahren gepflegt und ein Review bzw. Anforderungsmanagemant ist im speziellen Fall des Maschinenbaus inhärent.., keiner baut eine Maschine die nicht das macht was sie soll. Aus Entwicklersicht ergabt sich einfach nur ein zusätzlicher Formalismus, verbunden mit zusätzlichen Besprechungen und irgendwelchen hübschen Fibonaccizahlen.😜

[@christophhuber7071]

Das Hauptproblem ist IMO dass fast niemand weiss, was "agile" im Sinne des Manifestos eigentlich bedeutet. Insbesondere die Berater nicht, die "agile" Prozesse in Unternehmen einführen. So wird dann aus "Individuals and interactions over processes and tools" ein Prozess, der unbedingt eingehalten werden muss, egal wie er sich auf die Teamentwickler und deren Interaktionen auswirkt. Und aus "Customer collaboration over contract negotiation" wird dann ein Sprint Board, welches umbedingt umgesetzt werden muss, egal ob es gerade Sinn macht oder nicht.

[@paulsalomon9522]

Was mich an Agil stört ist, dass es so unagil ist. Ich würde als Entwickler gerne an einem Thema arbeiten bis es fertig ist, oder zu einem gewissen Teil fertig ist. Stattdessen muss das Thema in x Tickets zerteilt werden und dann muss diskutiert werden, ob die Beschreibung richtig ist, ob die Akzeptanz Kriterien richtig sind, wie viele Story Punkte das sind, in welchen Sprint die einzelnen Tickets rein kommen. Und wenn man anfängt fällt auf, dass noch etwas weiteres zu tun ist, dafür muss aber erstmal eine neues Ticket geschrieben werden, das kann dann nicht in den aktuellen Sprint und auch nicht in den nächsten, weil die sind ja voll. Dann kann ich nicht weiter am Thema arbeiten, weil es dafür keine Tickets mehr im Sprint sind und muss ein anderen Thema anfangen. Nächsten Sprint schnappt sich jemand anderes das Ticket zum Thema und arbeitet in eine andere Richtung usw..

[@Massenhaft1]

Es gibt auch Menschen die deine Entwicklerzeit bezahlen und planen. Ich kann nachvollziehen, dass das Business ihre Budgets geplant sehen möchte. Das ein Sprint nicht umstrukturiert werden kann ist natürlich nicht gut. Wer die Aufgabe nicht in Schritte zerlegen kann, kann auch keine Planung erstellen. Das die Planung "unscharf" und Risiken enthält sollte auch jedem klar sein, wenn aber die "Risiken" in jedem Ticket in etwa gleich groß sind, dann kann man auch wieder über Termine sprechen.

[@dagorgonzoladotco]

Wir haben Tickets "Thema ABC Recherche" und "Thema ABC Spezifikation" eingeführt. Da wird noch gar nix programmiert. Das hat extrem geholfen.

[@francopannacottta3751]

Das ist ja auch wieder kein Agiles Arbeiten. In bestimmten Kontexten können auch Regeln gebrochen werden. Wenn das Team bemerkt "hmm, wir halten usn nicht wirklich dran bzw. klappt das nicht so gut in der relaität" muss dieser Einwand, den du hier gerade formulierst und wahrscheinlich auch empirisch darstellen kannst, eingearbeitet werden, damit man nicht gezwungen ist, den Prozess ständig zu brechen. Agilität bedeutet ja sich an umstände anpassen zu können. Deswegen ist SCRUM auch nur aus der Vogelperspektive und lässt eine menge freiraum im direkten doing.

[@marcotroster8247]

Wenn du merkst, dass was nicht passt, sollte der Sprint gecancelt werden, mal abgesehen davon dass die Software immer releasebar sein sollte statt nur am Sprintende. Aber ganz ehrlich, mach doch einfach die Aufgabe, die du als Vorbereitung brauchst. Ist doch ultra der Käse, das nicht zu machen. Man muss den Value maximieren, indem man an den relevantesten Sachen arbeitet. Wenns nicht relevant ist, dann fahr in Urlaub. Bei Agilität geht's darum rauszufinden was man machen muss. Man muss die Sachen ausprobieren, obs so klappt, wie man es sich vorgestellt hat. Und wenns nicht klappt, muss man adaptieren. Das ist so banal, dass mans eigentlich gar nicht sagen muss.

[@minimal3734]

Der Software-Konzern, in dem ich seit 16 Jahren arbeite, wurde vor 4 Jahren "agil". Seitdem sind wir Soldaten, die stumpfsinnig Tickets abarbeiten. Intelligenz, Flexibilität und Verantwortungsbereitschaft wurden abgeschafft. Die persönliche Leistung ist seit der Einführung der "agilen" Prozesse stark zurückgegangen. Außer Mittelmaß ist nichts mehr drin. Zum Glück konnte ich in den 12 Jahren bevor wir "agil" wurden das Fundament errichten, von dem wir jetzt zehren.

[@xcoder1122]

Im Prinzip lässt sich Scrum auf die Frage reduzieren "Wie können wir den Entwicklern vorgaukeln, dass jetzt alles agil ist, dass sie jetzt die Kontrolle über den Entwicklungsprozess haben, um ihnen am Ende für alles, was schief läuft, die Schuld in die Schuhe schieben zu können und sie durch Druck zu härterer Arbeit und freiwilligen Überstunden zu bewegen, ohne dass das Management auch nur einen Hauch von Kontrolle und Aufsicht gegenüber dem bisherigen Modell aufgeben muss?" und die Antwort lautet "Scrum". Das Grundproblem war schon immer, dass die Art und Weise, wie Betriebswirte Software entwickeln wollen, völlig inkompatibel damit ist, wie Software tatsächlich entwickelt wird und was Entwickler sich wünschen würden, um diesen Prozess noch viel besser zu gestalten. Entwickler wollen gute Software rechtzeitig abliefern und Entwickler können das auch, dazu brauchen sie niemanden, der ihnen von oben herab sagt, wie sie ihren Job machen sollen, aber selbst noch keine 100 Zeilen Code in seinem Leben geschrieben hat. Software entwickeln ist eben nicht wie Brötchen backen oder Bratpfannen herstellen. Wie oft sagt mein Chef: "Also, das Feature, das ist doch bestimmt ganz einfach umzusetzen", nein, ist es nicht. Es wäre vielleicht einfach, wenn man ein vernünftiges Grundgerüst hätte, aber das gibt es nicht. Und warum nicht? Weil da unter Zeitdruck irgendwas zusammengeschustert wurde und man gesagt hat "es muss nicht schön sein, Hauptsache es wird fertig" und deswegen ist das Feature jetzt extrem aufwendig und es müssen zig Codeteile angefasst werden, der ganze Programmfluss muss geändert werden und es werden sich zig neue Bugs einschleichen, die erst mal keiner findet, weil für automatische Tests auch keine Zeit war. Da hieß es "das machen wir später" und das war vor 6 Jahren und auf dieses "später" warten wir heute noch. Die Idee hinter der agilen Entwicklung ist, dass es keine starren Entwicklungsprozesse und keine starren Anforderungen gibt, sondern dass man die Entwickler einfach arbeiten lässt, so wie sie arbeiten wollen. Das Management gibt vor, was entwickelt werden soll, was das Produkt idealerweise können soll und vergibt gegebenenfalls Prioritäten und hat von da an kaum noch etwas direkt mit der Entwicklung zu tun. Die Entwickler machen jeden Tag ihre Arbeit und liefern regelmäßig ein testbares Produkt ab, das sich das Management anschauen kann und wenn es damit zufrieden ist, kann es das Produkt freigeben. Wenn es nicht zufrieden ist, dann kann es natürlich Wünsche äußern, Änderungen vorschlagen oder Prioritäten verschieben und die Entwickler werden ihr Bestes tun, um all das in die Entwicklung einfließen zu lassen. Die Entwickler können sich auch an das Management wenden, wenn sie Fragen haben. Wichtig ist, dass es kein starres Ziel gibt, sondern dass alles immer im Fluss ist, denn was man wirklich will, merkt man oft erst mitten im Projekt bzw. merkt man erst, wenn man das bekommt, was man bestellt hat und dann merkt, dass man das eigentlich gar nicht will. Und dann muss man flexibel genug sein, die Ziele zu ändern. D.h. die Entwickler müssen auch den Code so flexibel gestalten, dass es eben kein Problem ist, wenn man auf einmal 50% der ursprünglichen Planung über den Haufen wirft, weil man erst jetzt merkt, dass man eigentlich in eine ganz andere Richtung gehen will. Außerdem entscheidet das Management, wann die Software fertig ist. Entweder ist das nach einer bestimmten Zeit, dann ist aber offen, was die Software bis dahin alles kann, oder es ist, wenn ein bestimmter Funktionsumfang erreicht ist, dann ist aber offen, wie lange das dauert. Beides geht nicht, man kann nicht erwarten, dass nach einer bestimmten Zeit ein bestimmter Funktionsumfang erreicht ist, das ist reines Wunschdenken. Warum also wollen die Unternehmen das nicht? Weil sie Angst vor Kontrollverlust haben, weil sie ihren Entwicklern nicht trauen, weil sie in der Illusion leben, dass das Management in der Vergangenheit einen wichtigen und produktiven Beitrag zur Entwicklung geleistet hat und vor allem, weil man dann nur noch ein sehr schlankes Management bräuchte und 2 von 3 Managern ihren Hut nehmen müssten, da sie einfach nicht mehr gebraucht werden, weil die Entwickler sich jetzt selbst managen.

[@bjoernwuest7483]

Na ja, es stimmt schon, dass Kunden (Nutzer) gerne sagen wie die Software zu entwickeln / anzupassen ist. Andererseits gibt es aber auch unzählige Entwickler die gerne sagen was Software eigentlich tun muss, um dem Kunden (Nutzer) zu helfen. Und noch etwas: insbesondere bei der "agilen Anpassung von Standardsoftware" erlebe ich immer wieder, dass man bei Adam und Eva anfängt. Beispiel das Aufsetzen eines Kontenrahmens. Da gehen 8 Wochen Workshop mit 40 Personen ins Land, am Ende gibt es ein 1.200-Seiten-Dokument das keiner ließt - auch der Autor nicht - und es ist noch immer kein einziges Konto in der Software eingerichtet... Dabei hat in der "Beraterauswahl" noch jeder von sich behauptet das schon mindestens 70x gemacht zu haben. Ja, wo ist es dann, warum muss man da von vorne anfangen?

[@xcoder1122]

@@bjoernwuest7483 Es ist natürlich ein Unterschied, ob man Software für einen bekannten Kunden entwickelt oder für mehrere unbekannte Kunden. Im ersten Fall kommt ein Kunde und bestellt ein konkretes Produkt und wird auch konkrete Vorstellungen haben, wie das Produkt auszusehen und zu funktionieren hat. Hier kann man natürlich dem Kunden immer mal wieder den aktuellen Stand zeigen und ihm gegebenenfalls auch etwas vorschlagen, wie z.B. "Also ich würde da diese Info reinschreiben und dann hier einen Button platzieren", vielleicht sagt der Kunde dann "Stimmt, das ist eine gute Idee, daran habe ich gar nicht gedacht". In diesem Fall arbeiten die Entwickler direkt mit dem Kunden zusammen. Das Management regelt nur die finanziellen und vertraglichen Dinge mit dem Kunden. Also was kann der Kunde von den Entwicklern erwarten, wie viel Entwicklungskosten werden letztendlich gedeckt, was kann das Unternehmen leisten und was will das Unternehmen leisten. Wenn man aber für mehrere unbekannte Kunden entwickelt, also z.B. eine Smartphone-App, die dann über einen AppStore vertrieben wird, dann hat man während der initialen Entwicklung keinen direkten Kontakt zu, finalen Kunden. Man kennt ihn also nicht und weiß auch nicht, was er will oder braucht. In dem Fall ist das Management der Kunde, weil die quasi diese Software in Auftrag gegeben haben, um sie verkaufen zu können. Die Entwickler verkaufen ja nicht das Produkt, sondern das Unternehmen verkauft es und das Unternehmen wird vom Management geführt. Hier entscheidet also das Management, wie das Produkt auszusehen hat und tritt an die Stelle eines externen Kunden. Wenn die Entwickler der Meinung sind, dass die Software schlecht geplant ist, weil sie z.B. aus Erfahrung wissen, dass die Kunden etwas nicht verstehen werden oder ein bestimmtes Feature garantiert vermissen werden, dann mögen sie sogar Recht haben, aber dann müssen sie das Management davon überzeugen. Wenn das Management aber schlechte Software will, dann soll es auch schlechte Software bekommen. Wenn ich einen Maler beauftrage, eine Wand schokobraun zu streichen, und er sagt: "Das sieht bestimmt nicht gut aus, macht den Raum viel zu dunkel und beißt sich mit den anderen Farben", ich aber genau das will, dann wird er es entweder so machen, oder ich suche mir einen anderen Maler, der es so macht. Es ist nicht mein Problem als Entwickler, wenn das Produkt floppt, wenn es nur deshalb floppt, weil das Management es schlecht geplant hat. Wichtig ist, dass das Produkt nicht schlecht entwickelt ist. Das heißt, auch wenn es scheiße aussieht, auch wenn es unbenutzbar ist, der Code muss trotzdem gut sein, er muss trotzdem einfach zu warten sein, er muss einfach erweiterbar sein, er muss getestet sein, er muss weitgehend bugfrei sein. Denn wenn dann das Management kommt und sagt: "Die Kunden hassen die App. Wir hätten es lieber so ... und so ... machen", dann kannst du als Entwickler sagen "Macht nichts, wir können das jederzeit so umbauen. Dauert so zwischen 4 und 8 Wochen, schätze ich", weil der Code gut ist, weil er flexibel ist und weil es Tests gibt, die sofort erkennen, wenn man durch den Umbau etwas kaputt gemacht hat. Außerdem hat man dann Feedback von den Kunden und weiß ganz konkret, was die gerne anders hätten oder was sie vermissen und das kann man dann auch problemlos nachliefern. Das alles geht aber nur, wenn man nicht auf die Schnelle etwas zusammengeschustert hat, was gerade mal mit Spucke und Tesa zusammengehalten wird und nur bei jedem zweiten Start der Anwendung halbwegs fehlerfrei funktioniert. Denn sonst ist so ein Umbau schnell teurer als eine Neuentwicklung. Und das bedeutet agil: Nicht in dem Irrglauben zu leben, dass man eine Software vorher perfekt auf Papier planen kann, alles in ein Pflichtenheft schreiben kann und dann garantiert ein tolles Produkt bekommt, denn die Realität ist, dass das beste Pflichtenheft der Welt immer noch massive Lücken aufweist, weil zig Randfälle gar nicht bedacht wurden und an einigen Stellen massiv von dem abweicht, was der Kunde eigentlich will bzw. was er eigentlich braucht.

[@MrRobsn89]

Das Problem ist auch, das wir immer weiter und höher hinaus wollen, statt mit dem zu arbeiten was da ist. Immer mehr Anforderungen, mehr Konkurrenz, mehr Kunden, mehr mehr mehr, alles muss mehr sein. Wundert mich also alles nicht. Leute müssen eben auch Ihr Brot verdienen.

[@xcoder1122]

@@MrRobsn89 Der Hauptgrund, warum die meisten Entwickler nicht mit dem existierenden Code arbeiten wollen, ist doch eigentlich, dass der existierende Code einfach Kacke ist. Und warum ist er so kacke? Weil immer so getan wird, als würde es Zeit sparen, Code nicht schön zu schreiben. Aber jede Studie, die jemals zu diesem Thema gemacht wurde, widerlegt diese Behauptung. Denn Zeit, die man am Anfang einspart, weil man es nicht schön macht, für die muss man später im Projekt 3-5 mal draufzahlen, so dass man unterm Strich überhaupt keine Zeit gespart, sondern in Summe nur Zeit verloren hat. Wer von Anfang an und konsequent schönen Code schreibt, der hat relativ konstante Entwicklungszeiten (also O(1)), wer hingegen immer nur alles dreckig zusammen hackt, dessen Entwicklungszeiten wachsen quadratisch (also O(n^2)) und wir alle wissen, dass letzteres auf Dauer nicht gut gehen kann. Uncle Bob hat mal in einem Vortrag (den gibt es auch auf KZbin) Zahlen aus solchen Studien veröffentlicht und da haben die Teams, die schönen Code geschrieben haben, die anderen Teams im Laufe der Zeit immer überholt und waren am Ende alle deutlich schneller. Es sieht nur am Anfang so aus, dass sie langsamer sind, weil sie am Anfang eben nicht so schnell neue Features liefern können, weil eine schöne Struktur aufzubauen eben Zeit kostet, sich aber am Ende massiv auszahlt. Und dann kommt oft das Argument: "Warum willst du das selbst schreiben, anstatt eine fertige Library zu benutzen?" Weil ich oft nur ein paar kleine Funktionen aus der Library brauche, die ich in 30 Minuten selbst schreiben kann und die dann genau so funktionieren, wie ich es brauche, statt mich mit irgendeinem minderwertigen Interface herumzuschlagen, das am Ende nicht alle Anforderungen abdeckt und um das ich Wrapper schreiben muss und bis das alles so funktioniert, wie ich es will, habe ich am Ende auch zwei Stunden verschwendet, aber jetzt habe ich das Projekt unnötig um eine weitere Abhängigkeit aufgebläht. Und wenn deren Entwicklung dann eingestellt wird oder plötzlich nicht mehr kompatibel zur Anwendung ist und man nicht bei der alten Version bleiben kann, weil die vielleicht auf aktuellen Systemen nicht mehr läuft oder es keine Version der Library für eine neue Plattform/Architektur gibt, dann verbringt man schnell 1-2 Wochen damit, den Mist jetzt irgendwie zu reparieren und ein Problem zu lösen, das nie entstanden wäre, wenn ich die hundert Zeilen einfach selbst geschrieben hätte. Ich habe schon Projekte an Abhängigkeitshöllen scheitern sehen, nur weil jemand dachte, es sei besser, 50 externe Abhängigkeiten einzubinden, als einfach ein paar Zeilen Code selbst zu schreiben. Jeder Windows-User aus den 90ern und frühen Nullerjahren kennt noch die "DLL-Hölle" und die damit verbundenen gigantischen Probleme. Warum sollte man sich eine solche Hölle in eigenen Softwareprojekten schaffen wollen? Mir ist schon klar, dass man TLS nicht mal eben schnell implementieren kann, natürlich greift man dafür auf OpenSSL, LibreSSL, Mbed TLS oder ähnliches zurück. Aber darüber reden wir hier nicht. Wir reden hier über Dinge wie Node.js Projekte, die zu 95% nur aus externen npm Paketen bestehen und dann löscht ein Entwickler sein Paket und hunderttausende Applikationen gehen vor die Hunde. Und warum? Wegen 20 Zeilen Code, die selbst ein schlechter Programmierer in weniger als 10 Minuten selbst hätte schreiben und testen können! Wirklich agile Projekte sind laut Studien schneller fertig als nicht agile, und wenn sie fertig sind, haben sie obendrein mehr Features und weniger Bugs. Ergo würde man mit denen schneller seine Brötchen verdienen und man würde auch mehr Brötchen verdienen. Aber man muss der Sache eine echte Chance geben und nicht einfach unterstellen, dass es nicht funktionieren kann, denn diese Unterstellung basiert auf nichts außer Aberglauben und Unwissenheit. Es gibt keine objektiven Fakten, die gegen agile Entwicklung sprechen, es gibt nur subjektive Meinungen und Mythen, die dagegen sprechen. Und leider fallen selbst Entwickler auf diese Mythen herein und verbreiten selbst diese falschen subjektiven Meinungen.

[@DuRoehre90210]

@@xcoder1122 Ui, ui, das sehe ich mit einem lachenden und mit einem weinenden Auge. Zum Problem der Initialkosten: es ist nicht nur die Entwicklung, ist auch das Grundgerüst. Ich arbeite z.B. gerade in einem Projekt, welches ursprünglich von einer ganz tollen Berater-Firma aufgesetzt wurde, weil diese das Thema angeblich so toll beherrschen. Praktisch haben sie Schrott abgeliefert, diverse Konventionen nicht eingehalten, im Setup des SCM ein paar grundlegende Empfehlungen nicht eingehalten haben, ihren Quark aber überall hartkodiert haben. Ergebnis: die Infrastruktur fällt ein paar Jahre später komplett um, IT wird langsam, und man wundert sich, was hier los ist, denn am Anfang sah doch alles so rosig aus. Ich war wenig überascht, eben ein Freelancer/Ext.Firma - Produkt. Aber zu "der Sache eine echte Chance geben" - sorry, Scrum ist einfach unangenehmer Sch..reck, geht mir tierisch auf den Keks. Und nein, in den meisten Fällen sind es ja die Entwickler selbst, die (sobald sie in die PO oder Scrum-Master-Rolle versetzt werden), dafür sorgen, dass jedes Daily zum Verhör und jedes Refinement zur Zwangs-Kaffeesatzleserei (oder aber wieder Verhör) wird. Wozu brauchen wir diese Spielchen? Die Scrum-Priester argumentieren gern damit, dass dann jeder Zugang zur Information und ein Mitspracherecht hat. In der Realität sind die Themen oft so divers, dass 80-90 der anwesenden Sch..gal ist, was da entschieden wird. Und wenn man das Thema zu gut kennt (und andere für doof hält) oder wenn man keinen Plan hat (und zu hoch schätzt), dann wird man mit einer "abweichenden Meinung" (also zu hohe oder zu geringe Schätzung) sofort in die Erklärungsnot gedrängt. Dann muss man sich als (vermeintlich) doof oder (vermeintlich) überheblich outen. Also sorry, diese sozialen Tendenzen in Scrum finde ich einfach KAGE.

[@SebastianTitze-cu9ll]

So hervorragend die Idee von agiler Software oder Produktentwicklung ist, aus Systemtheoretischer Sicht ist es eine Suboptimierung und funktioniert halt nur bedingt. Soll aus meiner Sicht nicht heißen, dass agil tot ist, aber es fängt erst an zu scheinen, wenn das komplette System, in dem Fall Organisation, sich ändert und nicht nur die Softwareentwicklung. Crossfunktional ist an der Stelle nicht genug. Die Teams müssen auch aus dem Zentrum der Organisation in deren Perepherie mit direktem Kontakt zum Markt. In einem solchen Kontext, ist agil dann aber definitiv eine Option Komplexität zu begegnen.

[@MaXMustermann-fw2vo]

Scrum funktioniert in der Theorie wahrscheinlich wenn alle Voraussetzungen stimmen. Dann muss ein Team (PO, BA/ITEM und Entwickler) auch an EINEM Produkt/Projekt arbeiten. Empirisch ist dies nicht der Fall. Schön zu merken, wenn kein spezifisches Sprintziel gefunden werden kann und statt dessen irgendwas Generelles formuliert wird. Oder es wird nicht ein, sondern n-Sprintziele definiert, weil man halt n Produkte im Sprint bearbeitet. Warum ist das mMn so? Weil Entscheidungsträger glauben, fehlende "Manpower" mit einer anderen Methodik ausgleichen zu können. Den ganzen Overhead an Meetings wird man auch nicht los, diese bekommen halt nur andere Namen. Damit eine Methodik wie Scrum funktioniert, muss ein Team auch Befugnisse haben und nicht nur Pflichten. Es wird erwartet sich auf den Sprint zu "commiten" hat aber im Wesentlichen keinen Einfluss auf die notwendigen Rahmenbedingungen. Wer vernunftbegabte Mitarbeiter hat oder sich wünscht, der sollte sich nicht wundern, dass es nicht besser läuft nur weil man eine andere Methodik wählt um Defizite struktureller Art auszugleichen.

[@helmstan6538]

Vielen Dank für dieses Video und für die Machart: Klare Sprache, keine peinlichen Stock Videos und keine nervtötenden Soundeffekte. Einfach gut!

[@flashnfantasy]

Mein Problem mit "agil" ist, das es als Gegenentwurf zum V-Modell verstanden wird. Ich würde viel lieber mit einem agilen V-Modell arbeiten. Ich würde zu gerne die Strukturen vom V-Modell behalten, aber nicht alles im voraus planen müssen (was übrigens auch das V-Modell garnicht fordert), und die Planung auf der Basis des V-Modells sehr dynamisch halten. Scrum, so wie ich es momentan kenne ist einfach nur ein großes unzusammenhängendes Blendwerk. Wir planen Sprints auf wilden Schätzungen, und keiner weiß, wie weit wir in unseren Projekten wirklich sind. Die Burn-Down-Charts sind völlig aus der Luft gegriffen, und wir Programmier müssen uns ständig rechtfertigen, warum wir bei der Entwicklung so sehr daneben liegen und warum wir soviele Sachen bei der Planung, die ja nur sehr oberflächlich ist, übersehen. Scrum ist Planwirtschaft, die auf keinen Plan aufbaut.

[@kazuhah1743]

Das eigentliche Problem (zumindest im corporate Umfeld) ist ein soziales. Und zwar fördern die Backlog-getriebenen Prozesse ein feature-driven development. Dadurch kommt der klassische Product*manager* in die Machtposition des Product*owners*, auch wenn er von Software-Entwicklung an sich keine Ahnung hat (weil er es nicht kann und nie getan hat). [Zur Erinnerung: das Aufgabengebiet des klassischen Product*managers* besteht in der Kommunikation mit Kunden/Prospects und Einkippen von Featurerequests in den Backlog.] Die jetzt fremdgesteuerten Entwickler haben nur noch die Sprintplanung und Statusreports als Stellschraube, um sich Zeit für die wachsende technical debt zu nehmen. Und der Product*owner* hat natürlich seine Lieblingsentwickler/architekten, die ihm die Welt schönreden.

[@troi951]

Ich weiß bis heute nicht wirklich wie ein "perfektes" Scrum aussieht oder eine Annäherung daran. In der Firma, wo wirklich Scrum stattfand, wurden 3 Scrum-Master in 5 Jahren verheizt. Der erste, war selber ehemaliger Entwickler und hat umgeschult, er hat uns dann, in Summe mit 10 Stunden an Meetings pro Woche gequält von 40 Arbeitsstunden, also rund 25%. Wie viele Diskussionen wir im Planning Poker verschwendet haben, allein die Definition jedes Mal durch zu gehen, warum wir nicht Zeit schätzen sondern Komplexität. Schlimmer war aber, dass man keine Erkenntnis aus dem Schätzen abgeleitet hat. Also was bedeutet es, wenn wir ein Ticket/Story/Task mit 5 Story bewertet haben und das innerhalb des Sprints dennoch nicht geschafft haben!? Dafür wäre eigentlich die Retro geeignet aber außer Ziele definieren und dann nicht überprüfen ob die zum nächsten Mal überhaupt eingehalten wurden, war es auch reine Zeitverschwendung. Mir stellt sich sowieso die Frage ob Scrum überhaupt geeignet ist, für größere Firmen. Denn bei uns war es permanent ein Problem, dass in vielen Tickets auch andere IT-Abteilungen involviert waren und wir abhängig von denen waren. Wenn wir beispielsweise etwas mit der SAP-Abteilung koordinieren mussten, konnte das Ticket dafür in der Komplexität 2 Punkte haben aber zog sich dann dennoch über mehrere Sprints, weil die SAP-Abteilung andere Ziele in der Zeit hatten. Scrum wie wir es leben wollten, gab auch vor, dass jeder alles können und wissen muss, was der andere im Team hauptsächlich erledigt. Das halte ich, lediglich meine Meinung, für ein Ding der Unmöglichkeit. Die ganzen Chefs wollen alle nur noch Eierlegene-Wollmilchsäue, zum Fullstackwissen gesellt sich dann noch "Devopskram" dazu. So viel Zeit kann ich zumindest nicht aufbringen, neben meiner Arbeitszeit um das "alles" zu verinnerlichen. Evtl. Funktioniert Scrum, in einer Firma die an einem einzigen Produkt feilen, wo der Admin, der Firewall-Experte bis hin zum Frontendentwickler alle dasselbe Ziel verfolgen. Aber das ist lediglich meine bescheidene Meinung.

[@medical-informatics]

Bravo! Ja, sehe ich auch so. Bei uns in der Forschung ist es noch schlimmer, da quasi jeder Wissenschaftler ein 1-Mann/Frau Scrum machen müsste, da keiner wirklich zusammenarbeitet und dennoch einige Externe deine "Product owner" sind. #digitalisierung am A!

[@MarcelRiegler]

Meiner Erfahrung nach läuft es meist darauf hinaus, dass das Management sich kostenlose Effizienzsteigerungen wünscht, diese aber nicht bekommt. Kostenlos deswegen, weil das Management sich NIE NIE NIE an die agile Methode anpasst. Beim allerersten Problemchen wird doch wieder mit Stunden und Deadlines, und "mach mal kurz" gearbeitet. Niemand hat die Eier dem Kunden Nein zu sagen. Ich glaube manchmal, man muss sein Rückgrat abgeben sobald man seine erste Business Krawatte kauft...

[@Max-gu5so]

Ich arbeite jetzt seit fast 15 Jahren in der Industrieautomation. Ich garantiere, dass so gut wie keinem der Begriff etwas sagte. Letztens hat unser neuer Chef was davon erzählt, und meinte das das nur heiße Luft ist. Nach dem was er erzählt hat und dem was ich mir dazu angelesen habe bin ich für mich zu dem Schluss gekommen, dass es irgendwie in einigen Bereichen doch genau das ist, was wir mehr und mehr machen. Nur finden die Meetings halt an der Kaffeemaschine statt. Es hat sich mit der Zeit und dem Wachstum der Abteilung halt einfach so ergeben. Sind 80 Leute, davon 40 auf dem Büro.

[@LaposMovies]

Wir waren in vielen Teams ziemlich agile. Aber die "internen" Kunden waren da einfach, zum Großteil, nicht mit der agilen Idee an zu "Überzeugen" . Da kommt nur bis wann ist das fertig (und was kostet das). Die bekommen halt heute auch intern soviel druck , da sind die nicht bereit das dann später "aus zu handeln" , auch weil bei ihnen schlicht die Ressourcen fehlen , heut zu Tage, um hier einen PO und Co. für das Projekt frei zu stellen. ... und Projekte die von sich sagen das sie Agile sind sind heute einfach meist Mini Wasserfälle hintereinander. Weil auch hier der Projektleiter ja in "Phasen" gesteuert wird. Das Problem ist nicht Agile , sondern das die Rahmenbedienungen drum herum einfach nicht mehr da sind. Die Kunden wollen schon gar keinen PO abstellen. Oder es ist ein PO der wie ein PL arbeitet ... usw. Das obere Management hat Scrum/Agile gehört und dass das Risiken und Kosten reduziert. Das man dafür aber auch das Mindset braucht ... das wurde nicht verstanden ... Selbst bei den Teams wo nämlich Srum eine "weile" sehr gut funktioniert hat, hat man für eine "Planungssicherheit" geopfert.

[@andreasschmalzl1752]

Mein sehr junger Projektleiter in der Schweiz meinte: "Wir benutzen Scrum, deshalb sind wir agil." Er hat mich, damals 58 mit 25 Jahren Betufserfahrung, nach 7 Wochen raus geschmissen. War gut für meinen Blutdruck.

[@SvenAmend]

Das ist mir klar. Solche jungen Blender haben häufig nicht viel auf dem Kasten gedchweige denn wirklich was zu sagen. Die fallen frpher oder später irgendwo selbst auf die Nase.

[@borstenpinsel]

Wir benutzen Kanban und weil das ja agil ist, sind wir automatisch erfolgreicher. Wir entwickeln im übrigen nichts

[@hugochavez6170]

Lass mich mal raten: Der junge Projektleiter hatte viele 1en im Zeugnis aber keine 1000 Zeilen Programmcode im Leben geschrieben und dürfte wegen seines Zeignisses und eventuell seines Zertifikats als Scrum Master arbeiten. 😂

[@andreasschmalzl1752]

@@hugochavez6170 Er war nicht mal Scrummaster. Der Scrummaster hat ihm auch mehrfach versucht zu erklären, dass sein Vorgehen völliger Blödsinn ist. Was für eine Ausbildung der junge Mann hat, habe ich allerdings nie erfahren. Er war halt 100% beratungsresistent. Ich vermute ja, da der erfahrene Projektleiter abgezogen wurde und die Chefs das Projekt ohnehin nicht haben wollten, dass deshalb der junge Mann gewählt wurde um das Projekt planmäßig gegen die Wand zu fahren. Sind halt Schwizer.

[@walterlotte4215]

@@hugochavez6170 Warum sollten Projektmanager Code geschrieben haben? Das ist kein Teil der Anforderung. Es hat auch weniger mit dem Projektleiter zu tun, als mit der Vorgabe der Firmenleitung. Ich habe bisher nur in Firmen gearbeitet wo das je nach Bedarf mehr oder weniger genau umgesetzt wird. Zu meinem Glück - meistens wurden nur wenige Elemente rausgepickt. Diese nutzlose Daily musste ich fast nie über mich ergehen lassen.

[@serialkiller504]

Warum gibts in den Kommentaren keinen Hinweis auf Softwarearchitektur und Technical Debt? Wenn ich bei kleinen Änderungen die Hälfte der Tests zum scheitern bringe, weil der Spagetticode zu groß geworden ist, dann wirds auch nicht mehr mit Agil. Schlechte Softwarequalität frisst jede Effizienz. Softwarequalität als Ziel des Agile Manifest und Testkonzepte wie TDD ist leider komplett unter die Räder gekommen.

[@insertrndnamehere]

100%

[@thosteg]

welche Tests?

[@kalebrosenberg8294]

Neben den Problemen die im Video erwähnt wurden fehlt meiner Meinung noch ein wichtiger Punkt: Scrum ist auch deshalb so beliebt bei Unternehmen weil PO/PMs ins Team gesetzt werden können, die Einblick und Einfluss auf die Teams haben. Unter den ganzen tollen Buzzwords steckt dann ganz schnell wieder Top-Down Management Mentalität und ambitionierte aber fachfremde BWLer die sich vor allem profilieren und Erfolge vorlegen wollen.

[@volkerscholl5831]

Der Irrglaube ist, dass es eine Methodik gäbe, die für alles passt. XP eignet sich eben nur für sehr autarke Software ohne große Abhängigkeiten zu anderen und auch nur in einer entsprechenden technischen Umgebung. Scrum kann wieder kleinere Teams auch in Zusammenarbeit mit anderen Teams zu einem Gesamtprogramm gut steuern. Aber der Feind aller agilen SW Entwicklung ist die Komplexität. Hier merkt man sehr schnell, dass agile Strukturen eben nicht ausreichen, um Anpassungen über verschiedene Programme hinweg gut zu steuern. Hier werden dann wieder neue Strukturen wie PI Planning etc geschaffen, die auch wieder erheblichen Overload erzeugen, und das dann teilweise ohne wirklich effizient komplexe Themen wirklich zu steuern. Der intelligente Mix von kleinen agilen Teams, die fachliche Anforderungen schnell in Zusammenarbeit mit den Kunden / Fachbereichen umsetzen und eben Projekten, die Anwendungsübergreifende Themen koordinieren und planen ist erforderlich. Ich bin seit 1980 in der IT. Agil hieß früher closed shop und wurde ohne irgendein Manifest gemacht, dann kamen immer größer und komplexere Projekte und jetzt agile Methoden. Wie immer in der IT schlägt jetzt das Pendel wieder in eine andere Richtung aus. Man darf nur nicht den Fehler machen, die nächste Sau die durch die IT getrieben wird dann für die eierlegende Wollmilchsau zu sehen, sondern Entwicklung und Projektprozesse für die eigene Organisation anzupassen und agil und schnell im Fixen von Fehlern und Entwickeln von fachlichen Anforderungen in einer Anwendung sein, aber auch Anwendungsübergreifende Projektstrukturen zu ermöglichen, die komplexere Themen sauber umsetzen. SW Entwicklung ist eben nicht nur neue SW auf der grünen Wiese zu erstelle, sondern bewährte Anwendungen in komplexen und heterogenen Umfeldern effizient weiter zu entwickeln.

[@valeridause]

Sie haben Recht. Jedoch wollen die Menschen und die Manager einfache Erklärungen. Eben schwarz und weiß. Sie haben angeblich sogar nicht so viel Zeit, ähnlichen eie Ihren Kommentar zu lesen. Und da kommen die Evangelisten von allen Agile Methoden auf ihre Kosten..

[@T.he.fishonthefly-fl8pc]

Das alte Lied vom Hammer und vom Nagel, in Großunternehmen braucht es flexible Frameworks die unterschiedliche (agile) Ansätze unterstützen basierend auf den Zielen und dem Scope, Project, Program, Produkt (Lebenszyklus) etc. Finde das Video sehr gut gemacht. Thanks for sharing! Ohne Clickbait hätte ich nicht geklickt ;-)

[@andreaskuhnel3872]

Ich habe bisher aus zwei Firmen agile SW Entwicklung miterlebt, und beide waren sehr ineffizient. Was früher im klassischen Modell mit fixen Projektmitarbeitern von 10 Leuten geleistet wurde, werden mit dem agilen Modell 30 Leute benötigt. Das 'agile' neigt sehr leicht zur Überadministierung.

[@neutralias]

Meine Erfahrung: Agilität scheitert oft deshalb, weil Agilität selbst agil gelebt werden muss. Ich habe Scrum immer skeptisch gegenüber gestanden und meine Projektteams ermutig die Methode selbst agil zu sehen und das agile Prinzip zum Maßstab zu machen. Die methodischen Frameworks werden zu oft dogmatisiert und zu wenig hinterfragt. Dazu trägt, wie Du sagst, die Kommerzialisierung bei, die natürlich ein Interesse daran hat, Agilität als schwarze Magie und kompliziert darzustellen. Dazu kommt die immer weiter um sich greifende Risikoscheu in Unternehmen - Verantwortung ist unmodern. Hast Du eigentlich schon ein Video über den Zertifizierungsfetisch bzw. die Aussagekraft von Zertifikaten gemacht?

[@schmitzbeats6102]

"Die methodischen Frameworks werden zu oft dogmatisiert und zu wenig hinterfragt." AMEN! Ich nenne das Cargo Cult (nach R. Feynman) man ahmt mechanisch etwas nach ohne den eigentlichen Zweck zu verfolgen.

[@squirrelinteractive]

Ich habe Firmen die in Ihrem Profil irgendwas mit "Agil" stehen hatten konsequent ignoriert. Das ist mir einfach zu stressig und zu blöd. Ich entwickle in Ruhe und bin in einem Betrieb in dem ich genau diese Ruhe habe und auch genug Zeit, ich habe keinen extremen Termindruck.

[@doublejack1617]

Agilität wurde so lange „gemanaged“ bis sie mittlerweile in Regulierung erstarrt ist.

[@alicewonderland9767]

Dynamisches, zielgerichtetes Arbeiten sollte selbstverständlich sein. Formal „agile working“ hat bei uns vor allem viel unproduktive Nervosität gebracht. Deckt sich mit Feedback aus anderen Grossfirmen. In 5 Jahren kommt wieder ein neuer Hype. Problem ist, dass die Konzepte reihenweise mit viel Enthusiasmus kopiert werden, bevor überhaupt klar ist, wie diese in der Realität ankommen und wo sie allenfalls Sinn machen. Liegt es an der mangelnden Kreativität, eigene Konzepte zu generieren?

[@KleinmeisterPang]

ganz ehrlich in den letzten 5 Jahren habe ich noch nicht ein Projekt gesehen wo Scrum korrekt angewendet wurde. Das Problem ist das Leute sich einfach nicht anpassen wollen, auch der inbegriffene Kontrollverlust und Übergang zum Vertrauen auf das Entwicklungsteam gelingt meiner Erfahrung nach fast nie. In 99% aller dailys in denen ich war war es immer: Ich habe dies gemacht und heute mache ich das & status ist das... Anstatt das korrekt zu machen.

[@hanspeterbestandig2054]

Brillant analysiert! Ich habe leider alle erwähnte Varianten erlebt. Aber auch (leider nur) einmal, bei dem es prächtig funktionierte. Es war mit die erfolgreichste und freudebringendste Phase meines Berufslebens. Wir waren ein sagenhaft effektives Team. Es kann funktionieren!

[@thenativeweb]

Auf jeden Fall - es *kann* definitiv funktionieren. Aber eben nur, wenn das Management die Zügel locker lässt und sich das Team selbst finden und organisieren kann. Denn darum geht's: Erwachsene wie Erwachsene und nicht wie Kleinkinder zu behandeln. Und danke für das Lob 😊

[@hanspeterbestandig2054]

@@thenativeweb Exakt! Genau so war es! Es brauchte einige Sprints, aber dann lief es prima! Und wenn Einer mal Probleme hatte, sprang oft ein Anderer mit ein. So haben wir nach 3 Sprints immer alle geschafft. Wichtig auch: Unser Teamleiter (Selbst erfahren in Sachen Scrum) überließ UNS das Commitment und so fanden wir - das Team - zu uns und unserer Leistung! Es ist, wie Du es sagst! 👍👏

[@hugosbalder6139]

Kann das nur bestätigen, habe das bei einem großen Vergleichsportal erlebt, dort hat es funktioniert. Die Führung muss das wollen, mit allen Konsequenzen. Und der Scrum-Master muss Erfahrung und die Eier haben gegenüber der Führung auch mal Nein zu sagen.

[@pixelhusten]

Das Problem, an Agile sehe, dass es innerhalb von Unternehmen, zu etwas viel Größerem aufgebauscht wird, dabei aber das Wesentliche vergessen wird. Wenn ich in der Woche, zig Meetings mitmachen muss, werden meine Tickets / Stories halt auch nicht schneller geschlossen. Zum Teil hat man das Gefühl, dass Scrum Master und POs dazu neige die Prozesse zu überoptimieren zu wollen. Man denkt sich, man sorgt dafür, dass die Prozesse einfacher werden, aber im Grunde wird es komplizierter gemacht. Im Grund ist es aber Ego getrieben, weil die POs halt sehen wollen, dass Storys schnell geschlossen werden. Die ganze Planung bringt auch wenig, wenn in einen aktiven Sprint ständig neue Dinge hineinrutschen, die kurzfristig gemacht werden müssen, die man fertigstellt und die nach sechs Monaten immer noch in Feature Branches herumgammeln (war am Ende halt doch nicht so wichtig). Des Weiteren ist es auch eine Frage, wie man Agile umsetzt. Ist ein Unternehmen bei der Umsetzung einfach dogmatisch, geht das in die Hose. Es funktioniert auch nicht in einem internationalen Unternehmen ein Regelwerk für alle Mitarbeiter zu erstellen, da jedes Team unterschiedlich arbeitet, andere Ansprüche hat etc. pp. Und so mancher Mitarbeiter bekommt auch schnell den Verdacht, dass die ganzen Regeln dazu dienen ihn irgendwann zu blamen. Deshalb ist es wichtig, Agile nicht als Dogma zu betrachten. Wer das macht, sorgt nur für Frust bei den Mitarbeitern. Die Regeln, die man erstellt, sollte man regelmäßig überprüfen und anpassen, kein "Das haben wir immer so gemacht" oder "das bleibt so." Es ist wichtig, dass jedes Team auch eigene Anpassungen an das Regelwerk benötigt. Und zu guter Letzt, released fertige Software und keinen unfertigen Kram. Den jeder Entwickler will auch irgendwie Stolz darauf sein, was er gemacht hat.

[@devstories-iv1mw]

Ich stimme dir vollkommen zu. Die Zertifikatsindustrie im Scrum-Bereich ist wirklich ein Thema für sich. Viele Leute weigern sich zu akzeptieren, dass Scrum nicht nur ein "lightweight wrapper" ist. Es gibt auch eine ganze Beratungs- und Softwareindustrie, die davon profitiert, dass Menschen Scrum "the right way" implementieren. Auf der anderen Seite bin ich der Meinung, dass das größte Problem in der IT heutzutage die Anzahl der nicht-technischen Personen ist, die in technische Entscheidungsprozesse oder Führungsrollen involviert sind. Die Scrum-Industrie fördert dies ebenfalls, und es scheint irgendwie nur in der IT normal zu sein.

[@rethardotv5874]

Viele Firmen und Projekte sind wahrscheinlich auch nicht dazu geeignet agil zu arbeiten. Ich arbeite gerade an einem Projekt in dem viel Unsicherheit ist, weil wir viel Research machen müssen und wir dementsprechend überwiegend auf Sicht fahren. Hier fahren wir mit scrum wirklich gut, es ist aber auch ein Paradebeispiel dafür. Wenn man aber ein Projekt hat in dem das Ziel von Anfang an feststeht und der Projektleiter weiß was gemacht werden muss kann man auch einfach klassisch entwickeln.

[@foppel]

Immer wieder wiederholen: Scrum und Agile sind KEIN Projektmanagement Werkzeug! sobald es zum Projektmanagement tool wird um diese 'Entwickler' kontrollieren zu können, ist es kein Scrum/Agile/Kanban mehr.. punkt

[@cgessner2004]

Sorry, da hat wer was völlig falsch verstanden. Scrum Agile ist eine Methode. Welche Werkzeuge dafür eingesetzt werden, ist egal.

[@foppel]

@@cgessner2004 Stimmt da hat jemand was völlig falsch verstanden sonnst hätte er erkannt das ich genau das sage - das das Problem entsteht sobald man es als PM-Werkzeug einsetzt

[@Volker.Berlin]

Die ganzen agilen Formalien wie Scrum, Extreme Programming, etc sind doch nur ein ganz kleiner Teil der Softwareentwicklung bei den es um Kunden Projekte geht. Also Auftragsarbeiten. Es gibt doch so viel mehr Softwareentwicklung, wie Open Source, Browser, OS, Standardsoftware, Embedded-Software. Diese brauchen ganze andere Abläufe des Agilen. Diesen Beispielen fehlt oft der typische Kunde der mitwirkt. Es so lächerlich, das diese agilen Formalien sich so wichtig nehmen.

[@k3daevin]

Manche nehmen Scrum als ihre Core Domain wahr 😓

[@Nerd_Republic]

We couldn't agree more! Danke für disen tollen Beitrag. Wir reden uns da auch oft den Mund fusselig. Es fühlt sich so an, als wenn Agilität für alles Verantwortlich ist. Vielleicht ist da ein kleiner "Shake-Out" auch mal gut.

[@Nickrii]

Danke für das gute Video. Gerade zum Schluss sprichst Du einen Punkt an, der mir schon mehrfach übel aufgestoßen ist: die mit Scrum oftmals verbundene Dogmatik. Jetzt schwappt die agile Welle rüber in die Hardware- und Mechatronik-Entwicklung und viele Manager fragen sich, warum Scrum bei Ihnen nicht funktioniert, obwohl sie sich sklavisch an die Prozesse halten. Übereifrige PO, die dank Zertifizierung die Weisheit mit dem Löffel gefressen zu haben scheinen, tragen oft noch ihren Teil dazu bei. Häufig fallen Aussagen wie „Wenn irgendwas davon nicht nach Scrum-Lehrbuch umgesetzt wird, ist das aber nicht mehr Scrum.“ - als ob das schlimm wäre. Dabei lautet schon das „erste Gebot“ der Agilität, dass Individuen und deren Interaktion wichtiger sind als die Prozesse und Tools. Die agilen Prozesse müssen also zu allererst für das Team funktionieren. Welchen Namen man dem Kind dann gibt, ist erstmal egal.

[@JakomoLeopardy]

Als agile SW-Entwicklung aufkam, haben wir alle darüber gelacht, weil es nicht wirklich neues wahr. Als die Projekte so gemacht wurden, haben wir gelacht, weil nicht viel neues reinkam, außer mehr "unproduktives Gelaber" und schlechtere Software Die Projekte verkauften sich besser, weil noobs darauf abfeierten, liefen aber schlechter. Natürlich brachte es auch kleine positive Aspekte Nach rund 50 Jahren an Computern (bin also Älter) sage ich: - Für Datenbanken Zuhause etc. ist die Flexibilität geil - Wäre ich "IT-Projekteinkäufer "eines Kunden würde ich Phrasen und Projektvorschläge der Agilität etc. ablehnen und auf gute Doku sehr viel Wert legen.

[@prozessbegleitung]

Ich werde immer skeptisch, wenn Developer im Scrum Team keine XP Praktiken anwenden. Nur Scrum schafft vielleicht Transparenz, aber ohne XP werden die Dev-Teams nicht unbedingt bessere Softwarequalität liefern. Damit Devs XP Praktiken umsetzen können, brauchen sie aber auch ein Umfeld, in dem das gewünscht ist. Sobald Pairing, Code Reviews und Tests schreiben keine hohe Prio haben oder Devs da keine Bock drauf haben, wird es halt schwierig. Von Scrum Teams in denen keine UXler vorhanden sind, POs nichts zu sagen haben oder PO Proxis sind und mehr Manager als Devs arbeiten, will ich erst garnicht anfangen. Da hilft keine Methode der Welt mehr weiter 😂 Ich arbeite in einem Unternehmen wo Teams ein Umfeld haben, in denen sie die Agilen Benefits ausspielen können. Sie liefern belastbare Forecasts, allgemein existiert eine hohe Teamzufriedenheit und die Teams liefern regelmäßig neuen Wert. Der Kunde fungiert als PO und arbeitet täglich mit dem Team zusammen. Und das erlebe ich bei uns in mehreren unabhängig arbeitenden Teams - es handelt sich also nicht nur um Zufall in einem Team.

[@DerHouy]

UXler sind aus dem ganzen Scrum-Prozess was StoryPoints usw. anbelangt raus (ist ja schließlich eine kreative Ecke), PO ist gleichzeitig Scrum-Master und UXler und definiert die Anforderungen, zusätzlich ein UXler, was sagst Du dazu?

[@saschaganser9671]

Agile kommt ja als Antwort auf das Waterfall Modell, wo man Top Down ewig vor sich hin entwickelt hat, dann aber festgestellt hat, dass das was man Entwickelt hat den Anforderungen nicht gerecht wird. Darum wollte man Interativ arbeiten, wollte auch die Anforderungen überprüfen und abgleichen, und v.a. bottom up ermöglichen. Das Agile Manifest ist ja bewusst so allgemein gehalten. Leider hat man das ganze dann Bürokratisiert und mit administrativen Themen aufgeladen, was oft zu entsprechenden Resultaten führt. Am Ende haben einige Leute geschickt diese Methode verkauft, ohne nachweisen zu müssen das sie besser ist. Und dann ist die Frage wie und wofür man sie einsetzt.

[@tommmlij]

Der agil-industrielle Komplex.... Das ist so wahr! Da kaufen Firmen bei Consulting-Häusern einen Haufen Leute, Coaches, Scrum Masters, POs, whatever ein, bekommen dabei genau Null Entwicklungskompetenz und diese Leute versuchen dann mit wenigen Devs loszuarbeiten. Dann wundern sich alle, dass das failed und versuchen permanent den Prozess zu verbessern.... Die Devs werden dabei von Meeting zu Meeting geschleift und quasi tot-gegrinded. Danke für das Video!

[@thenativeweb]

Gerne - und sehr passend dazu: kzbin.info/www/bejne/fYO9gn-ZZt2epdE

[@DuRoehre90210]

Du hast DevOps vergessen! Da wird viel altes einfach neu aufgegossen und dann als Synergie aller Welten als eine neue Welt verkauft.

[@motzky]

Product OWNER ownen oft überhaupt kein Produkt, da fängt der Fisch zum stinken an. SAFE wird über alle gestülpt, aber Teams haben überhaupt kein Produkt und Markt, sondern werden klassisch nach Projekttagen finanziert.

[@samuelmathes8151]

Aus meiner Sicht bedeutet Agilität, dass ein Team Verantwortung übernimmt: Für die Software an sich, für die Abstimmung mit den Stakeholdern, Planung der Sprints, Retros, etc. Die Erfahrung zeigt leider, dass in Unternehmen viele ihre Verantwortung nicht dem Team überlassen wollen und andererseits viele Entwickler die Verantwortung auch nicht haben wollen (ich bin zufrieden, wenn mir jemand sagt, was ich tun soll). Das führt dann auch dazu, dass Agilität scheitert. Das liegt aber nicht an dem agilen Ansatz an für sich. Nach wie vor halte ich den agilen Ansatz - sofern richtig umgesetzt - für den richtigen.

[@RealWorldMusicTheory]

Sehr gute Erklärung mit viel Einsicht und Erfahrung. Danke. Das sollte vielen helfen, ihre vielleicht bestehenden Probleme mit Agilität zu reflektieren.

[@hugosbalder6139]

Ich bin überrascht über die Kommentare hier. Agiles Entwickeln funktioniert. Man muss es aber auch ernst nehmen. Die Ressourcen im Produktmanagement und der Entwicklung (Architekt, Qualitätsmanager) müssen vorhanden und kompetent sein. Die Produktmanager müssen ihr Produkt und die Prozesse wirklich verstehen und die Grenzen der Entwicklung. Und der Architekt muss alle zusammenbringen und unterstützen. Ob agiles Entwickeln für alle Projekte Sinn macht steht auf einem anderen Blatt. Und die Entscheider müssen die Ressourcen bereitstellen die ein agiles Team benötigt. Wenn die Entscheider nichts taugen, dann kann Scrum nichts dafür.....................

[@Octavian82]

Meines Erachtens hat Scrum kaum etwas mit Agilität zu tun. Agilität bedeutet doch rollenübergreifend gemeinsam ein Produkt zu erarbeiteten und frühes Feedback zu erhalten und einzuarbeiten. In welcher täglichen Arbeitsstruktur oder welche Art von Projektmanagement dazu gewählt wird kann je nach Kontext und Kultur ganz unterschiedlich aussehen.

[@borstenpinsel]

Scrum schon. Das was 99% der Firmen als agil/scrum bezeichnen, hat so viel damit zu tun wie ein Chicken McNugget mit einem Wiener Schnitzel😅

[@YTLaLi]

Werden eigentlich Flugzeuge, Brücken und Häuser nach agilen Methoden gebaut, oder nur Sachen, bei denen nicht wirklich was passieren kann?

[@helidrones]

Ich weiß schon gar nicht mehr, wer über die Kommerzialisierung agiler Methoden ein vernichtendes Video veröffentlicht hat, es war in jedem Fall einer der Verfasser des Agile Manifesto. Einer seiner Sätze geistert mir seitdem immer mal wieder im Kopf herum: „Agile is not a noun!“

[@yt7042]

Nicht meine Thema heute, als Einzelkämpfer. Ich wünsche "trotzdem" eine schöne Woche!

[@thenativeweb]

Danke schön, das wünsche ich Dir auch 😊

[@i-am-the-slime]

Wieso nicht? Wie organisierst du dich? Wie entscheidest Du, was du machst und in welcher Reihenfolge?

[@QueryTuner]

@@thenativeweb Habt ihr einen Link zu dem Thema "Eine Studie im Juni zeigte alarmierende Ergebnisse: "268% Higher Failure Rates for Agile Software Projects"." ?

[@yt7042]

@@i-am-the-slime Ich bin als "Dienstleister" größtenteils im Tagesgeschäft und meine Entscheidungen sind sehr dynamisch und an die jeweilige Situation angepasst. Ich kläre jeden (potentiellen) AG über meine Arbeitsweise auf und lehne Aufträge auch ab wenn es nicht passt. Ansonsten organisiere ich mich über GitHub Projects wenn es unübersichtlich wird. Der AG ist maximal read only dabei. Kanban finde ich persönlich gut wenn es einfach gehalten wird. Da ich keine sehr großen Projekte mache muss die Projektverwaltung klein gehalten werden, da diese schwer abrechenbar ist.

[@tldw8354]

@@i-am-the-slime Ich bin auch Einzelkämpfer. Aber ich verstehe nicht ganz, worauf du hinaus willst. Die Antwort: mit gesundem Menschenverstand - wäre glaube ich nicht das, was du hier erwartest. Aber was genau willst du dann wissen?

[@dontswitch8951]

Das größte Problem ist aus meiner Sicht nicht die agile Entwicklung, sondern DevOps. Die Annahme, dass etwas auf Produktion funktioniert und man sich nicht darum kümmern muss (das ist die Realität hinter DevOps), ist einfach Unsinn. Wer einen stabilen Service haben will braucht ein Betriebsteam. Dieses bildet dann auch ein Quality Gate um sicherzustellen, dass es wirklich funktioniert bzw. ein Rollback erfolgt.

[@iblarson2556]

Sehr interessant und mal was Kritisches! Tatsächlich bin ich viel mit 1h-Dailys und 3-Monats-Sprints u.a. in Berührung gekommen. Ich durfte viel gutes aus SCRUM / SAfe etc. lernen und mitnehmen z.B. dass die Leute, die die Arbeit erledigen müssen, die sein sollten, die sie auch planen. Niemand sonst. Der PO sagt, was er haben will, das Team sagt, was es schaffen kann. Und dabei helfe ich ihnen. Richtig gelebt und vorgelebt (und das ist die wahre Arbeit dahinter) bringt das Agile haufenweise Verbesserungen, sowohl für den Kunden und auch für die Teams. Das alles durfte ich selbst erleben. Daher würde ich sagen, dass das Agile Vorgehen weniger ein Prozess ist, sondern vielmehr eine Einstellung (neudeutsch Mindset) ist. Aber, wie gesagt, darin liegt der wahre Aufwand, solche Team aufzubauen und zum Laufen zu bekommen. Ich hatte das Glück, dass mir dies mehrmals gelungen ist.

[@1879heikkisorsa]

Gibt's ein Video oder Artikel zu eurer Interpretation von Kanban + XP?

[@thenativeweb]

Am 25. September ist es soweit: kzbin.infosORcUbCOnBw

[@mariel4871]

Sehr guter Beitrag! Hab schon in Fake, sowie dark aber auch sehr guten agilen teams gearbeitet. Es macht echt Spaß und fühlt sich sinnvoll an, wenn es gut funktioniert. Falls nicht ist es sehr frustrierend!

[@der-lotse]

Agilität ist nicht tot. War sie nie. Softwareprojekte wurden auch noch nie, nicht agil entwickelt. Aber: Die Mehrheit der Stakeholder/POs etc. und ja auch die Mehrheit der Entwickler verstehen das inkrementelle Arbeiten nicht. Verstehen Selbstorganisation nicht. Verstehen Continuous Delivery nicht. Sie verstehen das Konzept nicht, den Fehler Im Grunde hat bereits jeder Wasserfallprokektmanager agile gearbeitet, der ordnentlich Puffer eingerechnet hat und Platz für Restrukturierung gelassen hat, sobald neue Informationen existieren. Und dieselben Typen, die das damals nicht gepeilt haben, die machen aus Agile heute eben das selbe. Dailies werden zu Statusmeetings, Refinements 5 mal die Woche. Druck wenn der Sprint nicht fertig wird. Aber bei Tests wird geschludert und die vollständige Automatisierung der Deploymentprozesse als zweirangig ewig runterpriorisiert. Dann funktioniert es genausowenig wie das alte Wasserfall und weil die Meisten genau diese Nichtsnutze sind, kommen sie zu dem Schluss: Agile funktioniert genausowenig, wie das alte Wasserfall.

[@tommypauker2600]

Scrum ist ein interessanter Ansatz, aber es entbindet die Verantwortlichen nicht von grundlegenden Projektmanagement-Tugenden wie Anforderungs-Management, Risiko-Management, Personalführung (ermutigen und auch mal ermahnen). Wenn in der Retrospektive nicht offen diskutiert wird und keine Konsequenzen daraus erwachsen, kann man sich das ganze auch sparen. Es gibt auch Projekte, da muss so viel vorgegeben werden, dass Scrum keinen Sinn macht. Nach dem Motto: "Überlegt Euch mal alle was schönes und ich sage dann am Ende, wie es tatsächlich gemacht werden soll."

[@ai-stratege]

Wenn man Agilität in ein starres, dogmatisches Framework setzt, ist es dann überhaupt noch agil?

[@i-am-the-slime]

Schön wär's. Die Realität, die ich kenne lautet: "Bloß nicht dogmatisch ein Framework befolgen, damit wir alle Meetings, auf die wir keinen Bock haben, streichen können". Es kotzt mich an.

[@Chris-14all]

Ist das dann nicht SAFe ? Also: scaled agile Framework ? Diese Zertifikate sind übrigens nur 12 Monate gültig, sogar auf unterster Mitarbeiter Ebene! Ach, und dann noch den AgileReleaseTrain..... Und am Ende wird mit dem Kunden ein Zieltermin vereinbart, der weit vor allen hochgerechneten Terminen ist. Dann müsste man die ganze PI Planung nochmal machen, aber darauf hat keiner Bock - und die Zeitverschwendung für diese Planung, mein Gott. Früher haben die Experten vertretend für ein Team das mitgemacht. Heute sitzt jeder Arsch 2-3 volle Tage in den Planungen....

[@thomaslaun7360]

Fake Agile ist genau das, was der erste Punkt im agilen Manifesto kritisiert: Die Formalia sind wichtiger als der Inhalt. Als ehemaliger PO sehe ich Scrum in der Zwischenzeit aber auch kritisch: Diese ständigen Committments und die enge zeitliche Taktung erzeugen einen riesigen Druck auf die Entwickler. Da hast du mal ein paar schlechte Tage und schon musst du dich ständig dafür rechtfertigen hinten dran zu sein. Mein Team hat das zu Recht immer abgelehnt.

[@borstenpinsel]

Eben nicht rechtfertigen. Aber in der klassischen Managementwelt gibt es halt nur rechtfertigen. Daher scheitert Agilität schon im Ansatz.

[@svr5423]

Wenn man Stories, Acceptance Criteria etc. gut definiert, hat man wenig Stress. Aber man bekommt einfach nichts tatsächlich gemacht. Zwischen dysfunktionaler Workstation und Enterprise Landschaft, stundenlangen Meetings, Dailies und 'du musst genau 8h am Tag abrechnen' bleiben oft nur wenige zusammenhängende Zeitblöcke in denen man tatsächlich produktiv sein kann.

[@tribonian3875]

Die Häkchenmacher wollen halt ihr "fertig" oder "erledigt" setzen. Und von denen gibt es immer mehr.

[@sigmundkreuzer9655]

Die meisten sind nicht agil. Sie machen agile Rituale und Microdeadlines aka Sprints.

[@TheLightAhead]

Das Thema "Microdeadlines" ist tatsächlich ein Problem. Man kann sogar soweit gehen zu sagen, das zumindest bei Scrum der Sprint regelmäßig zum "Microwasserfall" wird. Das ist beispielsweise ein Grund, warum ich Kanban viel besser finde als Scrum: Kein Microwasserfall möglich.

[@DemokratieErwacht]

Stimmt! Der Funktionsumfang ist fix, der Endtermin ist fix, dann kann dazwischen nur ein Wasserfall mit beliebig vielen Kaskaden liegen

[@sigmundkreuzer9655]

@@DemokratieErwacht Beim Funktionsumfang haben alle Beteiligten nur eine sehr Grobe, um nicht zusagen Naive vorstellung. Keiner kennt die Prozesse im Unternehmen. Die ganzen Details kommen erst unterwegs raus oder schlimmstenfalls nach dem erfolgreichen Test und Rollout. Dann wird auf die dummen Softwarentwickler geschimpft, die das nicht vorausgesehen haben und überstunden machen müssen, um den mist der passiert ist wieder geradezubiegen.

[@Massenhaft1]

@@DemokratieErwacht Kann man so sehen. Die Sprints sind ja normalerweise recht kurz. Ich finde unsere zwei Wochen sehr angenehm. Es geht dir niemand auf die Nerven und du kannst deine Dinge abarbeiten. Nachdem klar wurde, dass die Dailies nur Status-Meetings sind haben wir sie abgeschafft. Das Team kommuniziert bei Problemen sowieso.

[@cfo3049]

Ok, ich muss mal Danke sagen für die Aufklärung, als jemand der sich jetzt seit 3 Jahren mit der Softwareentwicklung beschäftigt, aber noch in einem anderen Beruf arbeitet. Jetzt weiß ich, unter welchen Umständen ich auf keinen Fall arbeiten möchte. Ich kannte bisher nur die Crunch Geschichte im Gaming Sektor, die ich auch seit dem Wissen davon ausgeschlossen habe. Scrum und Extreme Programming sind jetzt Teil dessen.

[@anion21]

Interessantes Video! Also ich hab schon sehr lange immer mal wieder harsche Kritik an Agilität gehört. Ich selbst habe in dem Team, in dem ich bis vor kurzem war, ausgesprochen gute Erfahrungen mit Scrum und Agilität gemacht. Ich sage nicht, dass Agilität der Weisheit letzter Schluss ist, aber es kann funktionieren, es kann sehr produktiv sein. Ich denke, das Problem ist wie du auch sagst, dass Agilität oft falsch verstanden und/oder falsch umgesetzt wird. Agilität beginnt im Kopf, man sollte das intrinsisch wollen. Und man kann z. B. auch nicht effektiv agil arbeiten, wenn die Stakeholder usw. alle zu "unagil" sind. Das konfliktet sich dann und dann ist es halt auch tatsächlich schwer, in diesem Umfeld Agilität sinnvoll/nützlich umzusetzen. Und die Agilitäts-Kritiker fühlen sich dann meiner Erfahrung nach bestätigt und lassen manchmal auch gar nicht mehr darüber mit sich reden... (Es gibt beliebig viele Beispiele dafür z. B. in den Kommentaren von Scrum-Artikeln bei heise, wo Leute es besser wissen, weil sie ihre Sachen ja schon seit 30 Jahren nicht-agil und angeblich viel besser machen.)

[@tobiasurban8065]

Gibt es Belege, dass es so etwas wie Dark Agil als Pattern wirklich gibt oder ist das anektdotisch (von enttäuschen Mitarbeitern geäußert)?

[@chrisoak4916]

Was sind die Alterntiven?

[@thenativeweb]

Wie im Video gesagt - nicht stumpf einem vorgegebenen Prozess folgen, schon gar nicht einem, der danach ausgewählt wurde, "weil alle ihn machen". Sondern sich einen aussuchen, der zur eigenen Situation passt, und den nach Bedarf, und mit Weitsicht und Erfahrung adaptieren.

[@st0ox]

Was mich persönlich eigentlich am meisten an Scrum in meinen Jobs gestört hat, ist das zwar Backend und Frontend im besten Fall gut verzahnt miteinander arbeiten und in den selben Sprints sitzen aber im Backend braucht man einfach eine längere Sprintlänge als im Frontend.

[@thenativeweb]

"[…] aber im Backend braucht man einfach eine längere Sprintlänge als im Frontend." Lustig - das ist bei uns genau andersrum 🤣 So unterschiedlich können die Welten sein.

[@st0ox]

@@thenativeweb absolut, dass kann komplett unterschiedlich sein. War jetzt auch nicht generell gemeint, sondern wirklich auf meinen Job. Wir haben halt wirklich ein komplexes Backend, weil es die gesamte Hardware einer komplexen Maschine abbilden muss und die Kommunikation mit diversen anderen Systemen, aber auf der anderen Seite gibt es auf der Welt nicht viele von diesen Maschinen, daher ist die Anzahl der User der Software sehr gering und die Ux/Ui kann daher weniger gut designt sein, weil man davon ausgehen kann, dass der User mindestens 3 Monate eingearbeitet wird. Zudem wird die Maschine in der Bedienung sowieso nie idiotensicher sein. Ich mein ich fänd einen ordentlichen Einrichtungsmanger wirklich cool, der einem dann durch die über 1000 settings führt, aber da der Service User, der solche Einrichtungen macht, selber 3+ Jahre Erfahrung mit der Software hat und durch sowas als Power User eher behindert wird, ist es wirklich schwierig zu rechtfertigen wieso man viel Zeit in die Ux/Ui stecken sollte. Aber keine Sorge, super hässlich und oldschool ist die Ui auch nicht, das meiste generieren wir halt automatisch, dadurch sieht aber vieles auch echt generisch aus. Aber die meisten Change-Request sind dadurch Ui technisch schnell umgesetzt, aber im Backend kann dies sehr große Refactorings verursachen.

[@marmeladenopa3069]

Grüße in meine Heimatstadt aus der Schweiz. Habe um die Ecke von der Lokhalle gewohnt, war am Wochenende zu Besuch. Hat sich echt viel verändert. Mal ne Frage außerhalb des Themas. Was für ein technisches Setup verwendest du für die Audioaufnahmen? Nutzt du auch so eine Art digitalen Ticker für die Texte? Würde mich über Feedback und Tipps dazu freuen. Gerade das Ding auf deiner Brust macht mich neugierig.

[@thenativeweb]

Tja, die Welt ist manchmal echt klein ☺️ Das „Ding“ ist ein kabelloses Mikrofon, genauer gesagt, das DJI Mic. Das ist über Funk an ein iPhone 14 Pro angeschlossen, mit dem wir filmen.

[@marmeladenopa3069]

@@thenativeweb Mega, danke dir für deinen Tipp. Wünsche dir ein super Start in die Woche :).

[@flexiblebirdchannel]

Ich habe den exakten Doppelblindstudienvergleich: ein und dieselbe Software, ein mal nach Lastenheft von 2 Leuten funktionsfähig (in C) entwickelt in 2 Jahren (4MJ) inkl. Doku, dann dieselbe Software nach Scrum von 6 Programmierern und 4 Supporten (Doku, Deployment, Orga) in 10 Jahren (60-100MJ) in C++. Also wirklich dieselbe Software, schnittstellenkompatibel, funktionskompatibel, mit dem Anspruch entstanden 20 x schneller zu werden, in der Realität schaffte sie nicht mal Faktor 2, war aber 20 mal so speicherintensiv. Und zumindest 2 Entwickler dabei waren sogar höherqualifiziert als am Anfang. Exakte Kompatibilität konnte bis heute nicht erreicht werden, aber good enough. Scrum ist die Hölle, trotz Schulung und Zertifikat.

[@Ralf947]

Das würde meine These stützen nach der Scrum Inovation, Kreativität und Qualität kaputt macht. Weil alles in Stories geplant sein soll und man nicht einfach die Arbeit machen kann die gerade anfällt und man gerade feststellt das man eine Funktion doch besser gerade noch mal auf links dreht und es ganz anders implementiert und es einfach jetzt sofort macht. Ich stelle mir immer vor wie es wohl wäre wenn so Dichter und Denker und Komponisten agil ihre Arbeit machen müssten 🤣 Hr. Beethoven, Planen sie doch mal die Komposition der Klaviersonate 14 im Backlog, machen sie Stories DODs vergeben Storypunkte und wir machen Dailys und schauen alle 14 Tage im Review was sie an Mehrwert zugefügt haben. Was würde da wohl bei raus kommen. Meine Prognose ist es würde die Kreativität vernichten. Für mich ist dieses Scrum (zumindest so wie ich es bisher erleben musste) eher ein Managerspielzeug um aus kreativer Arbeit Fließbandarbeit zu machen.

[@TimG-5230]

Das hört sich für mich aber nicht unbedingt nach einem Scrum-Problem an. Denn meistens hat man so einen Vergleich ja gar nicht weil es nicht wirtschaftlich ist ein und die selbe Software zwei Mal zu entwickeln. D.h. das beschriebene hört sich für mich nach einer Neuentwicklung einer bestehenden Software an die historisch entstanden ist und nun irgendwelche Anforderungen nicht mehr erfüllen kann (siehe Performance-Anforderungen am Ende). Da ist dann also jemand in der Nähe der Entwicklung auf die Idee gekommen „Wir brauchen unbedingt einen Re-Write“. Solche Re-Write Projekte habe ich bisher selten gut gehen sehen. Da braucht man m.E. Kein Scrum für um die zu vermurksen.

[@rabiatorthegreat6163]

Da stellt sich als erstes die Frage, wo der Faktor 20 genau her kommen soll. 20x schneller ist schon eine Hausnummer, bei der die Flaschenhälse bekannt sein sollten, bevor man eine solche Leistungssteigerung verspricht. Und wenn die Flaschenhälse erst mal erkannt sind, reicht vielleicht sogar eine Überarbeitung des betreffenden Programmteils. Hypothetisches und einfaches Beispiel: Irgendwo wurde dummerweise Bubblesort statt Quicksort verwendet, und die Zahl der zu sortierenden Datensätze ist über die Zeit stark angestiegen. Jetzt fängt die quadratische Komplexität an, weh zu tun. Aber vielleicht läßt sich der Sortieralgorithmus einfach austauschen, bestenfalls mit einer Änderung in nur einer .cpp Datei.

[@flexiblebirdchannel]

@@rabiatorthegreat6163 Ja, man kann wunderbar spekulieren wenn es nur so wenig Info gibt. Der Faktor 20 kam, weil die Truppe den Job haben wollte, und das dumme Management drauf reingefallen ist. Dank agiler Anforderungsreduktion kann man dann weiter Geld verbrennen.

[@arctanx4745]

Wenn ich Agil höre, schrillen bei mir mittlerweile die Alarmglocken. Was ich da bei Kunden und im eigenen Unternehmen schon gesehen hab ist schon teilweise skurril. Agile PCB Hardwareentwicklung z.B. oder auch Festpreisprojekte (HW+SW) mit Projektplanung > 1Jahr mit Scum umgesetzt... Aber Hauptsache im Prospekt steht AGILE

[@ottomaier7127]

Ich hoffe, dass du Recht hast mit dem "immer mehr in Frage gestellt"... 👍

[@thenativeweb]

Zumindest man selbst kann damit ja anfangen und versuchen, das auch im eigenen Umfeld zu propagieren 😉

[@ottomaier7127]

@@thenativeweb Die wollen das alle nicht hören und du stellst dich in's Abseits, bist nachher der Böse. Habe ich oft probiert und dann irgendwann aufgegeben. Wenn sie's so wollen, es ist nicht an mir das zu verhindern. Ich weise einmal auf irgendwelche nicht passenden Dinge hin, mehr kann und will ich nicht tun. Manchmal hilft's, öfters leider nicht.

[@pi4630]

Vielen lieben Dank für das Video! Als ehemaliger JEE Backend Entwickler, der am liebsten wieder programmieren würde, kann ich nur bestätigen: Die agilen Frameworks setzen IMHO eine organisatorische Veränderung voraus, bzw. ziehen sie mit sich, aber das birgt oft Unwillen in den oberen Etagen. Das Agile soll halt die Produktion von Software bändigen, mehr nicht.

[@4Mensi]

Sehr gut auf den Punkt gebracht. Oft sehe ich aucg, dass Scrum angepasst wird aber die Idee von Scrum noch gar nicht verstanden wurde (SP in Stunden, direkte Zuweisung von Stories vor dem Sprint, Sprint wird laufend angepasst usw.). Bevor man etwas ändert, sollte man Scrum auch mal richtig durchführen und agile Methotik leben. Und wichtig agil ist nicht gleich "man kann machen und ändern wie man Lust und Laune hat"

[@axymoulm]

Hat sich diese Methode denn tatsächlich „Jahre lang hoher Beliebtheit erfreut“, oder könnte es auch so gewesen sein, dass nur keiner, der darunter litt, sich traute, was zu sagen? Dort, wo ich gearbeitet habe, waren jedenfalls die meisten Leute eher Ja-Sager und haben Missstände lieber hingenommen, als sie anzusprechen - aus Angst vor negativen Konsequenzen. Das ist eine soziale Dynamik, die man nicht unterschätzen sollte. Ich selbst habe auch erst den Mund aufgemacht, als ich schon ahnte, dass meine Tage gezählt sind. Und erst dann haben auch andere Leute geäußert, dass 2 Meetings pro Woche (=rund 3-4 Stunden Verlust an produktiver Zeit) - vorsichtig augedrückt - von begrenztem Nutzen sind. Und wie ich in den Kommentaren gelesen habe, kann ich mich mit dem hier genannten Volumen an Meeting noch glücklich schätzen.

[@nannanganggang]

Interessantes Video und bestimmte Punkte erkenne ich wieder. Unser PO tritt tatsächlich mehr als Projektleiter auf und unser Scrum Master schaut einfach zu. Bestimmte Teammitglieder sind schon genervt von den Sprints und fühlen sich unter Druck gesetzt. Ich habe mich jetzt etwas fortgebildet bzgl Agilität und insbesondere Scrum und bin hier doch sehr erschrocken wie schlecht unser Team eigentlich funktioniert.

[@airlag]

Das Eingehen auf sich verändernde Kundenwünsche und Bedürfnisse ist ein ganz großes Problem wenn man ein begrenztes Projekt-Budget hat, und ist noch problematischer wenn man für Festpreis mit Endabnahme des Produktes arbeitet.

[@thenativeweb]

Das kommt darauf an, wie man es verkauft - grundsätzlich ist das nicht mal bei Fixpreis ein Problem, wenn man klar kommuniziert, dass man gerne zusätzlich noch X umsetzen kann, man dafür aber Y und Z streichen muss, oder es teurer wird bzw länger dauert.

[@felixlutte727]

Richtig, schade nur, dass meist schon bei der Angebotserstellung unklar ist, was „genau“ Angeboten ist. Dabei hab ich Sätze wie: „Das muss doch aber in einem normalen Webshop drin sein“ und „war doch von Anfang an klar, dass wir das brauchen“ schon viel zu häufig gehört. Meist endet es im Streit darüber, welche Funktionalität von Anfang an bestellt war und was als Sonderwunsch gilt :(

[@michaelme4028]

Grundsätzlich sollte dem Kunden klar sein, was er will und was er bestellt und dann auch bekommt. Bei der agilen Umsetzung sollte der Kunde involviert sein und Tickets sinnvoll priorisiert werden, damit frühzeitig ein minimales Produkt entsteht, das der Kunde schon mal testen kann, damit schon frühzeitig Feedback rein kommt, egal ob für Bugs oder Feature Requests. Continuous Delivery ist dafür ideal, denn der Kunde kann der Software beim Wachsen zusehen, wie bei einer Pflanze. Wenn der Kunde beim Wasserfall Modell das Produkt erst in die Hand bekommt, wenn es fertig ist, ist es das meistens nicht und die Nachbesserungen nehmen dann agile Züge an, aber mit dem Unterschied, dass der Kunde unzufrieden ist, weil das Produkt zur Deadline nicht die zugesagten Eigenschaften hatte. Man kommt bei agiler Umsetzung also nicht darum herum, die Anforderungen an das Produkt zu definieren, der Kunde hat aber einen besseren Überblick und mehr Möglichkeiten, auf die Entwicklung Einfluss zu nehmen und wird am Ende zufriedener sein. Für den Entwickler ist die Feedback Schleife kurz und es wird weniger am Bedarf vorbei für die Mülltonne entwickelt, was weniger Frust bedeutet und effizienter ist und am Ende weniger Stress bedeutet, weil weniger Zeit vor Deadlines verbrannt wird. Die vorher definierten Anforderungen helfen dabei, bei Änderungen fair zu entscheiden, ob ein Mehraufwand entsteht, der zusätzlich bezahlt werden muss. Somit ist es auch kein Problem, auf sich ändernde Kundenwünsche einzugehen.

[@motzky]

​@@michaelme4028Hatte in fast 35 Jahren IT ein einiges Wasserfall-Projekt, wo alles voran spezifiziert und exakt nach Vorgaben mit Pseudocode und Mockups der Dialoge implementiert wurde. Das Projekt war mit 6 Monaten in Tine, Budget und Quality. Alle anderen Projekte, lange vor Scrum und Agile, wurde iterativ erarbeitet bzw. in Stufen. Auch dort wurde in Lenkungsausschüssen repriorisiert. Der Kunde konnte auf die Ausbaustufen Einfluss nehmen und korrigieren. Wenn Scrum und SAFE trotz zahlreicher Schulungen und Zertifizierungen defacto nicht die erhofften Ergebnisse erzielt, dann ist die Methode eventuell doch nicht das Allheilmittel.

[@gzoechi]

Wenn man nachfragt kommt man immer zum gleichen Ergebnis. Die Leute machen etwas das nicht im entferntesten irgendetwas mit Agile zu tun hat, außer Alibi-Handlungen wie Daily Stand-ups, aber ein Vorgesetzter nennt es trotzdem Agile. Deshalb heist es Agile ist "böse" weil es nicht funktioniert.

[@Durayne]

Für mich war Daily eher die Daily Rechtfertigung, ob man denn gearbeitet hat. Fand ich besonders Schlimm weil, als ich in einem solchen Team war, zwar an Software gearbeitet hatte, aber mehrere parallele Aufgaben hatte. Beziehungsweise einfach Erfahrungen mit vielen Systemen im Betrieb hatte und so für ettliche Dinge der Ansprechpartner war. Durch die ganzen Kontextswitches ging natürlich aber die Produktivität für das Projekt runter. Haben meine Teammember zwar glücklicherweise gesehen, für mich hat sichs trotzdem immer misstig angefühlt. Lustig war immer als ich aus dem Urlaub zurückgekommen bin und in der Zeit andere aus dem Team meine Zusatzrollen übernehmen mussten. Dann hieß es immer : "Endlich bist du zurück" ... Leute waren heilfroh dass jemand wieder den ganzen extra kram gemacht hat. haha

[@DuRoehre90210]

Die Leute haben ja oft genug "baseload", also irgendwelche Infrastruktur-Themen oder Aufgaben, die spontan aufpoppen und auch spontan gelöst werden, und sei es nur den Kollegen bei einem Debugging-Problem o.ä. helfen. Oder wenn man sich in irgendein neues Thema nebenbei einarbeiten muss (Training!), was nicht schon Wochen vorher voraussehbar war. Die sind dann froh, wenn sie den ganzen von oben verordneten Agile-Zirkus-Mist irgendwie befriedigen und ansonsten IN RUHE arbeiten können.

[@TvonSch]

7:51 ja, weil Eigenverantwortung und Disziplin für Agilität wichtig ist! Das Team muss dafür geeignet sein.

[@Ready-To-Learn]

Wichtiges Video, denn es gibt einen guten Hinweis auf das Eigentliche Problem hinter all dem Begriffsgewusel: Führungslosigkeit kann durch keine Methode behoben werden. Und Ihr macht es richtig… So wie man niemals alle Menschen im Team mit der gleichen Methode führen kann, kann man auch niemals eine Organisations-Methode aus dem Lehrbuch abschreiben und umsetzen. Ein ordentlich geführtes Team findet gemeinsam den Modus in dem es gut und gerne arbeitet. Und das gilt nicht nur für Softwareentwicklung.

[@drsteffenstrange]

Sehr geil auf den Punkt gebracht!

[@Hofer2304]

Was können die Kunden zum Gelingen eines Projekts beitragen? Wer haftet bei fehlgeschlagenen Projekten? Der Kunde, weil er unerfüllbare Anforderungen gestellt hat, oder das Softwareunternehmen, weil es den Kunden nicht gewarnt hat oder dem Kunden unnötige Features aufgeschwatzt hat?

[@horstkampfgarten5768]

Also bei uns läuft es mit Agilität und Sprints prima. Was wäre denn die Alternative? Zurück zum Wasserfall?

[@-Jakob-]

Wenn ihr die Methoden und Werkzeuge mit gesunden Menschenverstand wählt, Talente und Vorlieben fördert, gute Führungskräfte in den Kompetenzbereichen habt, ist es eigentlich egal, wie ihr es macht, es wird prima sein.

[@andreasschmidt2293]

Ich arbeite jeden Tag agil. Das Problem ist, dass mich ständig jemand mit irgendwelchen Projektmanagement-Frameworks und frisch erlernten Methoden davon abhalten will und wir gar keine Softwareentwickler sind.

[@MarcRudolph]

Tolles Video! Passt! Aber "siehe Video in der Info-Card" - Welche Info Card? Ich sehe keine - Die Verweise fänd' ich aber trotzdem spannend.

[@christianmontagx8461]

Es bedarf eines starken Projektmanagements, dass jeglichen Unfug aus der Chefetage vom Programmierteam fern hält aber zeitgleich auch das Entwicklerteam fordert. Wir haben z.B. gemerkt als der Herr im langen Urlaub war, dass sich vermeintlich "einfachere" Systematiken wieder einschlichen, die eigentlich Gift sind (keep/drop/take wurde abgestellt und das Standup wurde nicht mehr regelmäßig durchgeführt). Entsprechend ist die Performance in den Keller gegangen.

[@CafeMuyCaliente]

Ich habe auch schon erlebt, dass Sprints verschieden gedehnt wurden, um keine Story Points in spätere Sprints zu verlagern. Die Vorgehensweise, die Feinkonzeption in fester Reihenfolge durchzuführen, erinnert stark an das Wasserfallmodell. Daher konnte man es auch als "Water Scrum" bezeichnen.

[@michaelmueller9635]

Ich denke, es ist wichtig zu verstehen, wie Agilität (so wie man es heute versteht) entstanden ist. Und hier war es schlicht ein Gegenentwurf zum klassischen Top-Down-Modell. Und somit zum damaligen Standard. Viele Forderungen von Agilität kommen auch heute seltsam bis selbstverständlich daher. Aber im Kontext der damaligen, schlechten Erfahrungen mit Top-Down waren es durchaus sehr logische Konsequenzen/Forderungen. Jetzt ist es aber so, dass Agilität der Standard ist. Und sich somit Agilität anderen Ansprüchen/Erwartungen als zu seiner Entstehung gerecht werden muss. Quasi 180 Grad vertauschte Rolle der Agilität von heute zu damals in der Selbstauffassung. Das Grundproblem von Softwareprojekten ist Organisation und Hierarchie (bzw. symmetrische und asymmetrische Beziehungsverhältnisse). Wenn man klare Hierarchien hat, ist es vielleicht ungerecht, aber klar, wer Entscheidungen trifft und Verantwortung trägt. Das Problem ist, dass es aber ebenso Konflikte, Entscheidungen und (Nicht-)Verantwortung gibt, wenn man nicht im Top-Down Modell arbeitet. Und oft wird dann in der Praxis Agilität "Anarchie auf Augenhöhe" gleichgesetzt (auch wenn das sicher nicht der Sinn und Anspruch von Agilität ist) und artet in einer Art "Cagefight 2er Personen/Parteien und Publikum mit Popcorn" aus. Je nachdem, welche Gruppendynamik das dann schafft, wollen viele dann zu 'einfachen Strukturen' als Default zurückfallen (inklusive einer lustigen Vergangenheitsverklärung "früher war alles besser ...da waren die Gummistiefel aus Holz"). Solange man nicht am falschen Ende von Willkür und Autorität sitzt, finden das viele sehr verlockend und glauben, davon sogar profitieren zu können.

[@robertbehrendt8685]

Die Gründung eines zusätzlichen Debattierclubs hat noch keine Firma effizienter gemacht und das Labeln von bestimmten Prozessen macht diese nicht besser. Mein Freund, Leiter der Fertigungsplanung eines Konsumgüterherstellers hat jahrzehntelang agil gearbeitet, bis zu dem Moment als Scrum in Kombination mit großen Debattierclubs eingeführt wurde, in denen Widerspruch und offene Kommunikation nicht gewünscht waren. Wenn alle entscheiden, ist keiner verantwortlich. Millionenverluste im oberen zweistelligen Bereich sind das Ergebnis des Missmanagements, an dem ausnahmsweise kein deutscher Politiker beteiligt ist.

[@DualerHeld]

Wir haben seit kurzem eine neue Agentur. Agil waren wir schon vorher unterwegs, jetzt machen wir reines Scrum mit all seinen Problemen. Somit sind wir auch langsamer geworden und die Business-Leute wundern sich, dass selbst 5min-Kleinigkeiten nicht mehr schnell umgesetzt werden können, weil das erst kompliziert in einem Sprint mit vorherigem Refinement etc. eingeplant werden muss. D.h. ich spreche jetzt bei diesen Sachen länger um eine mögliche Umsetzung und warte, anstatt einfach mal kurz das Problem zu lösen.

[@NK-rm7kc]

Ich habe „agile“ nicht in der trivialen Softwareentwicklung, sondern in der Hardwareentwicklung eingesetzt: Meine Erfahrung ist durchwachsen. Zum einen löst „agile“ weder klassische Projektmgmt-Probleme wie die Abwesenheit von Time, Cost, Quality. Zum anderen erhöhte es bei uns lediglich die Kommunikationsfrequenz…das war zwar nicht negativ, hatte aber etwas von micromanagement. Schlußendlich war das zeitkritische Projekt erfolgreich, aber weder lag das an „agile“, noch hatte es etwas nachhaltiges. Sprich, es war ein kurzfristiger Erfolg, der das Team durch die ständige over-time ausgelaugt hat…und so wollte niemand weitermachen.

[@NK-rm7kc]

Ps. Super Video! Und geniale Kommentare hier! Love it.

[@krccmsitp2884]

Ohne das Video (bisher) gesehen zu haben: Was ist die Lösung/Antwort?

[@thenativeweb]

Na, ich denke, dafür musst Du das Video schon angucken … 😉