Was haltet Ihr von Scrum?

[Matti]

Hallo zusammen, was haltet ihr von Scrum?

Hier mal meine Gedanken: Positiv sind die täglichen Status-Meetings, weil damit rechtzeitig erkannt werden kann wenn Entwickler blockiert sind oder sich selbst festgefahren haben. Abgesehen davon gibt es bei Scrum aber viele Probleme: Erstens versuchen die Entwickler möglichst viele Story-Points zu schaffen, um Lob vom Chef zu kassieren, was aber oft schädlich für die Qualität ist. Zweitens ist Scrum nicht agil, weil das spontane hinzufügen von Tasks zu einem Sprint entweder gar nicht zugelassen ist oder viel organisatorischen Aufwand nach sich zieht. Drittens gibt es oft Aufgaben, bei denen Forschung, Recherche oder Experimente notwendig sind und deren Aufwand deshalb nicht abgeschätzt werden kann. Wenn so eine Aufgabe dann länger dauert, gibt es Stress bei den Entwicklern und Frust bei den Managern, was mit einem flexibleren Planungssystem vermeidbar wäre. Viertens kosten die Sprintplanungen unnötig Zeit und funktionieren wegen Punkt 3 sowieso oft nicht. Und fünftens sollte man Feedback nicht bis zum Retrospective aufheben, sondern in den täglichen Meetings ansprechen.

[nalye]

Scrum ist wie ITIL: man muss es auf seine Firma anpassen. Einfach sagen "Wir machen jetzt Scrum/agilen Shit" ist genau das Gegenteil.

Auch ist Scrum fuer Devs nicht so sonderlich verkehrt, fuer beispielsweise einen Support oder Ops eher nicht, da der Sprint schlecht planbar ist.

[Gohan]

Scrum ist ja nicht in Stein gemeißelt. Und auch Recherche und Probieren sollte eine Aufgabe während des Sprints und mit Story-Punkten belegt sein.

Qualitäts-Mangel ist selber Schuld, nur um Punkte abzuarbeiten. Dagegen hilft z.B. eine Definition of Done, die z.B. Unit- und Integrationstests einfordert. Ist zwar keine Garantie, aber bei uns sorgt das für guten Code.

Die DoD ist bei uns auch sehr streng, wir haben harte Regeln im CI-Prozess was Code-Formatierung, Benennung, Komplexität und Testabdeckung betrifft. Vorher wird kein PR akzeptiert und kein Ticket auf Done geschoben.

Sind wir vor dem Sprint-Ende fertig, werden Tickets noch nachgeschoben. Und unsere Sprints sind kurz, nach jedem wird neu priorisiert. Was soll daran nicht Agil sein?

[Monger]

Es gibt diverse Videos, unter anderem von den Gründern des agilen Manifests, warum Scrum ne scheiß Idee ist. Scrum ist etwas was gerne an Firmen verkauft wird die Prozesse lieben, aber gerne "agile" wären.

Ich hab das zwei Jahre lang mitgemacht. Fand das eigentlich super. Aber auch nach Ewigkeiten wurden die vielen Meetings nicht effektiver, der Erfahrungsaustausch nicht besser.

Es gibt viele Missverständnisse über Agile. Scrum ist vielleicht der größte.

[Matti]

Kurze Sprints erhöhen die Agilität aber auch den Planungsaufwand, weil man Tasks mehr unterteilen muß. Und Qualität ist mehr als Testabdeckung und Coding-Style. Es ist vor allem, dass man intuitiv benutzbare Interfaces designed, wofür man eben etwas Bedenkzeit braucht. Wenn man sie sich nicht nimmt, kommt oft Müll heraus (wie ich selbst schon oft gesehen habe).

[Monger]

Scrum ist ja nicht in Stein gemeißelt.
Doch. Scrum ist eine eingetragene Marke. Nichts darf sich Scrum nennen, was nicht Scrum ist. Es gibt auch kein "Scrum-like", da ist die Scrum-Organisation streng. Wenn du was ähnliches, aber nicht gleiches machen willst, gib ihm nen anderen Namen. Das dient u.a. dazu, die Label wie "Scrum-certified" nicht zu verwässern.

[Marscel]

Ist Ok: Nicht weil Scrum Scrum ist, sondern weil es im Grunde ein etabliertes Verständnis mitbringt für eig. alles, was man in den meisten Fällen als Entwicklungsteam braucht.

Erstens versuchen die Entwickler möglichst viele Story-Points zu schaffen, um Lob vom Chef zu kassieren, was aber oft schädlich für die Qualität ist.

Ich weiß gerade nicht, wen man hier eher austauschen sollte, wenn das der Fall ist: Die Entwickler oder den Chef? Am besten beide.

Zweitens ist Scrum nicht agil, weil das spontane hinzufügen von Tasks zu einem Sprint entweder gar nicht zugelassen ist oder viel organisatorischen Aufwand nach sich zieht.

Das ist ein Problem der Kultisten, nicht der Pragmatiker. Mit organisatorisch weiß ich zwar nicht, was du meinst, aber wir stellen die Tasks zusammen und nehem uns die vor. Wenn wider erwarten etwas durch äußere Faktoren z. B. etwas komplett hängen bleibt, übermäßig schnell erledigt ist oder unerwartet und unaufschiebar wird, kommt was aus dem Backlog reingezogen oder kriegt ein entsprechendes Label.

Drittens gibt es oft Aufgaben, bei denen Forschung, Recherche oder Experimente notwendig sind und deren Aufwand deshalb nicht abgeschätzt werden kann. Wenn so eine Aufgabe dann länger dauert, gibt es Stress bei den Entwicklern und Frust bei den Managern, was mit einem flexibleren Planungssystem vermeidbar wäre.

Kannst du wg. Unsicherheit hochwerten oder in Tasks kleinbrechen, je nach Wissenstand und Erwartungswert. Hab ich zumindest noch nie als Problem erlebt, ist vielleicht auch eine Routinesache.

Viertens kosten die Sprintplanungen unnötig Zeit ...

Welche Planung kostet denn jetzt keine Zeit? Und was ist daran konkrekt unnötig? Jemand sagt, was jetzt als nächstes Prio hat, dann diskutieren ein paar, wie viel realistisch davon rein passt, und dann schiebt jemand das zusammen.

Und fünftens sollte man Feedback nicht bis zum Retrospective aufheben, sondern in den täglichen Meetings ansprechen.

Klar, aber in einer Retro soll man ja auch in erster Linie breiter sammeln und über Maßnahmen nachdenken.

Doch. Scrum ist eine eingetragene Marke. Nichts darf sich Scrum nennen, was nicht Scrum ist. Es gibt auch kein "Scrum-like", da ist die Scrum-Organisation streng. Wenn du was ähnliches, aber nicht gleiches machen willst, gib ihm nen anderen Namen. Das dient u.a. dazu, die Label wie "Scrum-certified" nicht zu verwässern.

Sollen die Kultisten doch die Polizei in unser Büro rufen.

Wie schon gesagt, wenn dir jemand den Begriff Scrum nennt, wissen die meisten, worum es geht: Keine ausufernden Scopes, Boards, Planung, Schätzung, Dailies, Retro, sowas eben. Dass wir nicht certified sind und nichts irreführendes unter dem Namen auf die Homepage schreiben sollten: klar. Wenn hier ein Bewerber kommt oder jemand aus Neugier fragt, wie das läuft: Verstanden.

Und zu:

Es ist vor allem, dass man intuitiv benutzbare Interfaces designed, wofür man eben etwas Bedenkzeit braucht. Wenn man sie sich nicht nimmt, kommt oft Müll heraus (wie ich selbst schon oft gesehen habe).

Ich bin zwar schon zum Glück seit langer Zeit aus (Web-)Frontends raus und will nicht pauschalisieren, z. B. wenn du eine Agentur bist, aber: Interfaces in ihren Standardkomponenten sollten doch im besten Fall gestreamlined etabliert werden, Themes, Componenten, Stylesheets. Zweitens: Wenn es sich dabei wirklich um Sachen handelt, die nicht nur intern bedeutsam sind: Sowas sollte man doch hinreichend von einem jew. Owner/Manager/Designer schon für den Task als Entwurf reinkriegen? Plötzlich hast du eine Erwartung, eine Anforderung und kannst viel schneller schätzen bzw. diskutieren, was davon teuer wird, weil z. B. neu oder experimentell.

[Monger]

So eine Eigenart von Scrum ist es, dass es Planung von Implementierung via dem Backlog trennt. Das kann naturgemäß nicht schnell sein. Die beworbene Selbstbefähigung von Teams ist damit auch in enge Grenzen gefasst.

Es gibt ein kleines, aber sehr feines Buch von Jan Bosch, wo er das so zusammenfasst:lerne erst, dein Business zu verstehen. Dann wähle dafür eine geeignete Architektur. Wähle dann eine Organisation die diese Architektur trägt, und dann einen Prozess der deine Organisation stützt. Nicht umgekehrt.
Wenn dein Business so funktioniert, dass die Anforderungen relativ einfach Happen für Happen kommen, und gut isoliert einfach nur umgesetzt werden müssen, dann ist Scrum o.ä. okay. Wenn du etwas hast, wo Anforderungen erst relativ aufwendig ermittelt werden müssen, und es einen engen Feedbackprozess zwischen Kunden und Entwickler braucht, dann sind andere Modelle besser.

Aber glaube niemandem, der dir Scrum (oder agile) verkaufen möchte. Und glaube auch niemandem, der auf einen Schlag in der Firma nen Prozesswechsel vornehmen möchte.

[#44]

Zweitens ist Scrum nicht agil, weil das spontane hinzufügen von Tasks zu einem Sprint entweder gar nicht zugelassen ist oder viel organisatorischen Aufwand nach sich zieht.
Und fünftens sollte man Feedback nicht bis zum Retrospective aufheben, sondern in den täglichen Meetings ansprechen.
Agile bedeutet nicht plan- und kopflos. Nicht 2 Wochen warten zu können ist für mich ein Zeichen, dass commitment oder Beteiligung vom PO fehlt. (Unplanbares wie Support sollte mmn. nicht agile abgebildet werden.)

Es ist vor allem, dass man intuitiv benutzbare Interfaces designed, wofür man eben etwas Bedenkzeit braucht. Wenn man sie sich nicht nimmt, kommt oft Müll heraus (wie ich selbst schon oft gesehen habe).
Im ersten Wurf 100% zu wollen ist nicht agile. Agile ist Iteration. Wer nicht iteriert ist nicht agile.


Es ist relativ egal, welchen Prozess man nun nimmt, wenn man agile nicht verstanden hat. Die Vorteile wird man nicht ernten können, wenn man sie nicht mal erkennt oder sie gar ablehnt.
(Liest sich zwar so, ist aber keine Kritik am TS - meine Organisation arbeitet ja auch so... :usad:)

Achja: Pur agile taugt ja auch gar nicht für alle vorstellbaren Fälle...

[Monger]

Agile bedeutet nicht plan- und kopflos. Nicht 2 Wochen warten zu können ist für mich ein Zeichen, dass commitment oder Beteiligung vom PO fehlt. (Unplanbares wie Support sollte mmn. nicht agile abgebildet werden.)

Das sehen Extreme Programmer übrigens ganz anders. Da hat der PO gefälligst mitzuarbeiten, und nicht alle zwei Wochen mal was übern Zaun zu werfen.
Selbst Code Reviews sind böse, weil die Feedbackschleife zu lang ist. Das Review wird dann durchs Pair Programming ersetzt.

Bei Continuous Integration Leuten sind auch Pull Requests böse, weil das unnötige Hand-off Kosten produziert. Einchecken, live gehen, own your mistakes.

Das sind alles definitiv Dinge die nicht bei allen Produktarten funktionieren. Aber wer Scrum für schnell und flexibel hält, sollte sich mal noch ein paar andere Denkschulen anschauen.

[#44]

Das sehen Extreme Programmer übrigens ganz anders. Da hat der PO gefälligst mitzuarbeiten, und nicht alle zwei Wochen mal was übern Zaun zu werfen.
Worauf ich hinaus möchte, ist das Hands-Off Mindset, dass mir bei vielen POs begegnet ist.
Dass POs oft denken sie müssten nur Satzhülsen ins Backlog kippen und der Rest wird von agile erledigt.
Dass agile oft nur als Werkzeug gesehen wird, mit dem man von außen Entwicklungsteams steuert, nicht als Entwicklungsprozess, an dem alle Stakeholder beteiligt sein müssen.

Sprints sind ja am Ende auch ein Werkzeug dafür, den PO festzunageln - weil diese sonst öfter denn nie meinen, dass agile bedeutet, sie könnten jederzeit eine Kehrtwende machen, ohne dass das Auswirkungen auf das Resultat hätte.
Mit einem hart definierten Sprint samt Prozess ist da sofort klar wie viel Zeit sowas vernichtet.

Das ist mmn. auch worum sich viele agile Prozesse tatsächlich kümmern - fach- (oder auch welt)fremde Führungskräfte im Zaum halten, die nicht verstehen was ihre Macht anrichten kann.
(Gibt natürlich auch Entwickler, die mit einem hohen Grad an Eigenveranwortlichkeit nicht zurechtkommen. Auch denen wird Struktur geboten.)

Mit Stakeholdern die agile verstanden haben und es nicht nur als magischen Feenstaub für Prozesse sehen kann man auch sehr viel mehr Flexibilität im Prozess erlauben. Da kann man dann tatsächlich agil arbeiten.

Ansonsten muss agile eben, wie jeder andere Prozess auch, den professionellen Kindergarten im Zaum halten...

[Monger]

Das ist mmn. auch worum sich viele agile Prozesse tatsächlich kümmern - fach- (oder auch welt)fremde Führungskräfte im Zaum halten, die nicht verstehen was ihre Macht anrichten kann.
Leider zu wahr ;D

[Matti]

Bisher habe ich Sprints immer als Mittel zur Kontrolle der Produktivität der Entwickler verachtet. Dass Sprints die Entwickler auch vor konfusen POs schützen ist ein guter Punkt. Allerdings handhabe ich das anders: In meiner privaten Task-Liste habe ich eine "Bullshit" Checkbox für Aufgaben, die irgendwelche Chefs wollen aber die das Projekt nicht vorwärts bringen. An allen "Bullshit" Tasks zusammen arbeite ich pro Tag maximal 25% der Arbeitszeit.

[Monger]

https://twitter.com/Carnage4Life/status/1624696396271202304?t=a0GqO0_NACY1gDlrHK459Q&s=19

Allen Holub hält Backlogs für das Symptom eines krankhaften Prozesses. Obasanjo hält dagegen, dass man ja irgendwo dokumentieren muss warum etwas ne schlechte Idee ist ;D

Auf Arbeit sind wir von solchen Gedankengängen meilenweit entfernt. Unser avisiertes Ziel ist, alle drei Monate releasebereit zu sein. Von dem Ziel sind wir noch weit weg. Unsere Kunden sind allerdings auch solche, die Software ausschließlich über DVD/USB Stick installieren bzw. aktualisieren.

[Marscel]

So eine Eigenart von Scrum ist es, dass es Planung von Implementierung via dem Backlog trennt.

Wenn man eine kleine Welle von dieser-Sprint-nächster-Sprint aufrecht hält, gibts da praktisch mEn kaum Probleme; wo was zu tun ist, ist was zu tun. Und dass man eines der Meetings nutzt, damit nochmal alle Entwickler kurz abgeholt werden, was wichtiges ergänzen oder sagen, was ggf. ein Problem: Ist doch super. Alles Sachen, die nach hinten raus das Risiko senken.

Selbst Code Reviews sind böse, weil die Feedbackschleife zu lang ist. Das Review wird dann durchs Pair Programming ersetzt.

Bei Continuous Integration Leuten sind auch Pull Requests böse, weil das unnötige Hand-off Kosten produziert. Einchecken, live gehen, own your mistakes.

In welchen Branchen wird denn sowas akzeptiert? Und wie hoch ist der Burnout-Anteil da?

[Ganon]

Ich denke das größte Problem von Scrum ist, dass eine ziemlich große Lücke zwischen "Wie macht man Scrum" und "Wie machen WIR Scrum" klafft.

Ein Board, ein paar Tickets und eine Deadline für einen Entwickler ist halt für sich alleine kein Scrum. Falsch ausgeführt, ist es einfach nur ein krasser Entwickler-Verschleiß. Besonders wenn man wirklich darauf abfährt jeden Sprint zu schaffen und es quasi als Tragödie angesehen wird, wenn es mal nicht klappt. Weil klar: Am Ticket hängt eine geplante Zeit, an dieser Zeit hängt Geld und an diesem Geld hängt eine Rechnung. Wurde die Leistung aber (zu dem Zeitpunkt) nicht erbracht, gibt's auch kein Geld.

Das stresst Entwickler, senkt Code-Qualität massiv und erzeugt schwer wartbare Systeme.

[noid]

Schlechte Qualität erzeugt weder Scrum, noch Wasserfall. Sondern heftiges Vernachlässigen der Testumgebungen und CICD.
"Wir bauen Prototypen und verkaufen sie" ist in allen Ansätzen möglich. Scrum ist gut, wenn man starke Charakter an den passenden Stellen hat. Hier kann man richtig gut das Team formen auch Wissen teilen.

[Shink]

Ich mache seit 15 Jahren Scrum, aber auch Kanban und Nexus.
Praktisch an Scrum ist, dass vieles vorgegeben ist (z.B. Rollen, Termine). Damit erspart man sich, selber was auszudenken und wenn Kunde oder Entwickler sagt, er hat keinen Bock, alle 2 Wochen darüber zu reden, was man gut gemacht hat und was man besser machen hätte können oder den Stakeholdern seine erledigten Tasks zu zeigen: Tja, ist leider so, steht im heiligen Buch.

Kanban ist natürlich viel besser geeignet für Ops oder Support. Entwicklung damit geht auch super, aber so etwas wie Retro, Daily, Review etc muss man sich selber ausdenken. Die Scrum-Termine passen nicht.

Kurze Sprints erhöhen die Agilität aber auch den Planungsaufwand, weil man Tasks mehr unterteilen muß.
Es gibt quasi eine ideale Sprintlänge abhängig von Team, Fachbereich und Softwareprodukt. Kurze Sprints führen zu öfterer Planung, aber die sollte dann natürlich entsprechend kürzer sein. Das funktioniert auch.

Scrum ist etwas was gerne an Firmen verkauft wird die Prozesse lieben, aber gerne "agile" wären.

Ich hab das zwei Jahre lang mitgemacht. Fand das eigentlich super. Aber auch nach Ewigkeiten wurden die vielen Meetings nicht effektiver, der Erfahrungsaustausch nicht besser.
Ja, ist ziemliche Geldmacherei und fällt unter "irgendwas müssen Manager/Coaches ja vorgeben". Wobei man für diverse Zertifizierungen halt einen dokumentierten Softwareentwicklungsprozess braucht. Da ist es super, wenn man entsprechende dokumentierte Prozesse in der Hinterhand hat.

Schlechte Qualität erzeugt weder Scrum, noch Wasserfall.
Natürlich nicht. Der Einfluss des Prozesses ist massiv überbewertet im Vergleich zur Kompetenz des Fachbereichs, der Entwickler, die Entwicklungsleistung...

Ach ja: Bin nicht sicher, was ich da jetzt ankreuzen soll.
Für manche Probleme und Teams ist Scrum "gut".
Bestehende Software erweitern z.B.
Ich kenne eine Firma, die verwendet das im Protesenbau.
Ich kenne eine Person, die damit seine Scheidung abgewickelt hat - einmal von seiner Frau und einmal von unserer Firma.

Ich weiß aber auch, dass es für viele Themen suboptimal ist. Z.B. SW-Entwicklung mit großen Teams. Multiprojektmanagement. Softwareprojekte, bei denen verschiedene Fachbereiche ein gemeinsames Projekt aus dem Boden stampfen.

[Ganon]

Sondern heftiges Vernachlässigen der Testumgebungen und CICD.

Jetzt unabhängig vom Entwicklungsmodell: Das ist auch nur ein Teilbereich von Qualität. Ein Code kann alle Tests bestehen und auch funktionieren. Das sagt am Ende aber nichts über die Codequalität, Wartbarkeit, Erweiterbarkeit etc. aus. Das merkst du meistens aber erst hinterher, wenn sich im Verlauf des Projekts oder allgemein im Betrieb das Teil als Wartungshölle entpuppt.

[noid]

Jetzt unabhängig vom Entwicklungsmodell: Das ist auch nur ein Teilbereich von Qualität. Ein Code kann alle Tests bestehen und auch funktionieren. Das sagt am Ende aber nichts über die Codequalität, Wartbarkeit, Erweiterbarkeit etc. aus. Das merkst du meistens aber erst hinterher, wenn sich im Verlauf des Projekts oder allgemein im Betrieb das Teil als Wartungshölle entpuppt.

Auch das würde als Teil des Tests betrachten.

[Ganon]

Auch das würde als Teil des Tests betrachten.

Und wer soll das bewerten? Und wie soll das Verfahren sein, wenn der Test negativ ist? Etwas funktionierendes wegwerfen und alles neu schreiben?

[Marscel]

Das find ich noch vergleichbar easy: Je fetter bis verrückter man z. B. Unittests aufziehen muss, nur um etwa einen Aspekt des Code zu verifizieren, desto schlechter, unterstell ich mal mit meiner Erfahrung bisher, ist die Codequalität.

Umgekehrt zieht sich das hoch, weil aufgebrochene, besser testbarere Sachen die Erweiterbarkeit verbessern.

[Asaraki]

Hach das liest sich hier wie so ziemlich jedes Dinner/Feierabendbier unter Entwicklern ^^
Jetzt jeder noch ein Bier und bald wird darüber geredet wiieeeee viel schöner alles war früher….

Gut so, weitermachen und cheers :D

Und wer soll das bewerten? Und wie soll das Verfahren sein, wenn der Test negativ ist? Etwas funktionierendes wegwerfen und alles neu schreiben?
Nennt sich NFT. Also nicht das unnütze Zeugs von Heute, aber wird scheinbar von vielen Buden ähnlich nützlich bewertet...

Wird nicht quantifiziert wie viel das Fehlen dessen kostet, sonst wär das längst überall mandatory.

[Shink]

Hach das liest sich hier wie so ziemlich jedes Dinner/Feierabendbier unter Entwicklern ^^
Jetzt jeder noch ein Bier und bald wird darüber geredet wiieeeee viel schöner alles war früher….
+1

Qualität ist ohnehin ein... wenig aussagekräftiger begriff.
https://en.wikipedia.org/wiki/FitNesse fand ich super - als Konzept und auch als Tool. Damals.

Ich sollte langsam Frühpension andenken.

[Marscel]

Qualität ist ohnehin ein... wenig aussagekräftiger begriff.

Hä?

Es gibt seit zig Jahren das Konzept von technical debt.

Ich beziffer dir jetzt, was es in unserem alten Setup kostete, ein lahmes Feature einzubauen: drei Leute auf knapp 12 Monate. Bei jedem Schritt vorwärts fallen drei Sachen runter, die muss man finden und fixen und fühlt sich wie Archäologe. Die Qualitätsignoranz und fehlende Leadership der Jahre kostet also irgendwann Hundertausende zusätzlich und dein Kunden und Nutzer glauben auch nicht mehr groß daran, dass du der Aufgabe gewachsen bist.

Fast forward, das System wurde vor objektiven Maßnahmen neugebaut und qualitätsgesichert geführt: Ähnlicher Feature-Request jetzt: ein Entwickler auf ein bis zwei Sprints? Betriebskosten: Bruchteil, vielleicht ein Fünftel. Personalaufwand: kleiner.

[Shink]

Hä?
Ich wollte nur sagen, dass der Begriff "Qualität" nichts aussagt.
Matti hat geschrieben, er versteht darunter "intuitiv benutzbare Interfaces".
Eine offizielle Definition dafür ist "Übereinstimmung der Umsetzung mit den User Stories". Das würde implizieren, dass der Kunde immer weiß, was langfristig am besten für ihn ist. Ich bin nicht überzeugt.
Ich hab auch schon mal etwas bescheuertes gelesen ala "Qualität = Anzahl der Customer Findings pro LOC/Story Point/Function Point".
Technical Debts drücken nicht aus, ob die Anwendung tut, was der Anwender braucht. Da kann viel mehr Geld, Zeit und Personalaufwand verloren gehen.
Kann dem Entwickler wurscht sein, weil er eventuell sogar zu mehr Geld kommt. (Tut er übrigens auch, wenn die Architektur schlecht ist.)

Ja, Usability, Codequalität und QA sind wichtig, automatisierte Integrationstests auch aber ob man zur Summe dann "Qualität" sagen darf, bin ich nicht überzeugt.

[Monger]

Nach fast 15 Jahren Arbeit direkt in QA und später nahe QA bin ich davon auch nicht mehr überzeugt. Effizienz wird überschätzt, Effektivität unterschätzt. Es nützt dem Kunden wenig, wenn die Software selbst exotische Randfälle meistert, und das in einer schicken und intuitiven Weise, aber nicht das was der Kunde wirklich braucht. Es wird viel zu viel an Zeug mit zweifelhaftem Nutzen rumgeeiert. Und dann ist goldplating eigentlich schade.

[Matti]

Mal eine Frage an die Leute, die gestimmt haben für "Scrum ist überwiegend gut, sollte aber nicht in Reinform angewendet werden": Welche Methoden sollten angewendet werden und welche nicht?

[BoM]

Scrum ist doch nur ein Sammelsurium an Werkzeuge wie man ein Team/Projekt koordinieren kann. Es löst keine Probleme, sondern macht sie im besten Falle transparent.

Gute Scrum Master oder agile Coaches gibt es leider viel zu selten. Eine ehemalige Projektleitungsperson, die nie entwickelt hat, soll plötzlich ein Entwicklungsteam coachen? :freak: (vergleiche Fussballtrainer, der noch nie Fussballgespielt hat ;D)

Jedes Devteam ist top, wenn sie eine gescheite ci/cd pipeline haben und sie sich auf ihre automatisierten Tests verlassen kann wenn was deployed wird. Aber ob man dafür Scrum braucht? Eher nein, sondern nur gescheiter/gesunder Entwicklerverstand. Scrum hilft dem Miteinander im Team.

Eines der nützlichen tools sind die Retrospektiven. wenn man die ergebnisse einer retro ernst nimmt und sich dadurch wirklich verbessert, dann hat man schon viel gewonnen.

Edit: wer ernsthaft Qualität haben will, sollte sich mit der ISO 25010 vertraut machen und die Aspekte in die DoR/DoD oder im Refinement bei jeder Story hinterfragen oder whatever packen (am besten Blaupausen fürs Storywriting verwenden) :P

[RMC]

Ich bin schon seit über 15 Jahren Softwareentwickler und nutze Agile Software Development in vielen Formen sicher schon seit einem großen Teil dieser Zeit. Ich hab schon viel gesehen, sowohl extrem gute als auch weniger gute Techniken und Teams, die diese einsetzen.

Ehrlich gesagt ist die Frage nicht ob, sondern wie. Entwicklung ohne agile Methoden möchte ich nicht mehr machen. Die besten Arbeitsbedingungen habe ich in einem Team das weiß wie es Techniken, Tools und Mindsets aus der agilen Software möglichst effizient für seine Zwecke nutzt und diese ständig verbessert.

[Aquaschaf]

Hallo zusammen, was haltet ihr von Scrum?

Hier mal meine Gedanken: Positiv sind die täglichen Status-Meetings, weil damit rechtzeitig erkannt werden kann wenn Entwickler blockiert sind oder sich selbst festgefahren haben. Abgesehen davon gibt es bei Scrum aber viele Probleme: Erstens versuchen die Entwickler möglichst viele Story-Points zu schaffen, um Lob vom Chef zu kassieren, was aber oft schädlich für die Qualität ist. Zweitens ist Scrum nicht agil, weil das spontane hinzufügen von Tasks zu einem Sprint entweder gar nicht zugelassen ist oder viel organisatorischen Aufwand nach sich zieht. Drittens gibt es oft Aufgaben, bei denen Forschung, Recherche oder Experimente notwendig sind und deren Aufwand deshalb nicht abgeschätzt werden kann. Wenn so eine Aufgabe dann länger dauert, gibt es Stress bei den Entwicklern und Frust bei den Managern, was mit einem flexibleren Planungssystem vermeidbar wäre. Viertens kosten die Sprintplanungen unnötig Zeit und funktionieren wegen Punkt 3 sowieso oft nicht. Und fünftens sollte man Feedback nicht bis zum Retrospective aufheben, sondern in den täglichen Meetings ansprechen.

Wie man mit Story Points und/oder Sprint Commitments umgeht ist eine kulturelle Sache. Bug-Tickets und Aufgaben die keinen direkten "business value" haben kann man z.B. immer mit 0 Story Points bewerten. Damit regelt sich die Velocity dann selbst - wenn zu schlampig gearbeitet wird, dann müssen später Bugs gefixt werden und mehr Tech Debt aufgeräumt werden, was dann die Velocity des Teams wieder nach unten korrigiert. Mangelndes Qualitätsbewusstsein im Team, und/oder zu großer Druck von außen sind eher die Ursache, als der Prozess.

"Agil" ist relativ - der Vergleich sind da eher Arbeitsprozesse bei denen es Planungen und Releases auf Quartalsebene, oder in noch größeren Abständen gibt. Die Sprints sind ein Kompromiss dazwischen die Leute in Ruhe arbeiten zu lassen und Pläne hinreichend oft anpassen zu können. Wiederum ist hier entscheidend wie man es lebt. Wenn alles abgeblockt wird was innerhalb eines Sprints an den Aufgaben geändert wird läuft was falsch. Wenn am Ende jeden Sprints mehr als die Hälfte der Tickets erst nachträglich aufgenommen wurde aber auch.

Für Recherche-Aufgaben oder ähnliches kann man sich z.B. statt einer Schätzung auf eine Time Box einigen.

Stress und Frust hängen an der Arbeitskultur. In vielen Kontexten ist irgendeine Form von Schätzung gefragt. Es sollte bloß allen klar sein dass Schätzungen nie besonders genau sind, und dass sie auch kein Versprechen darstellen wann etwas fertig sein wird. Story Points sind ja schon ein Trick um unter anderem etwas Druck rauszunehmen, weil die Skala bewusst grob ist, und es keine explizite Zeitschätzung darstellt.

Sprint-Plannings erfordern einen halbwegs passablen Product Owner der in der Lage ist Anforderungen zu formulieren und der das Projekt bzw. Produkt kennt. Wenn diese Person ihre Hausaufgaben nicht macht, dann ist das kein schönes Meeting. Ansonsten ist es aber effektiv darin dem Team einen Überblick darüber zu geben was ansteht und Feedback darüber zu sammeln (schlecht definierte Stories können ja auch abgewiesen werden beispielsweise). Und wenn man nur explorative Aufgaben hat, dann müsste man darüber nachdenken die Schätzungen vielleicht ganz wegzulassen. Solche Teams gibt es aber nur selten.

Klar, Feedback sollte man nicht nur für Retrospektiven aufheben. Es gibt aber immer mal wieder Punkte die einem erst im Laufe der Zeit auffallen, oder die man im gesamten Team besprechen möchte, oder bei denen ein Moderator hilfreich ist. Hier ist es auch wieder relativ zu sehen, man ist gezwungen regelmäßig zu reflektieren, und die Hemmschwelle ist niedriger als ad hoc festzustellen dass man ein Thema besprechen muss. Ist eine Umgebung sehr stabil kommt es natürlich vor dass man irgendwann weniger Themen hat, dann kann man eventuell die Frequenz etwas verringern. Und die "Gefahr" besteht auch an den Punkt zu gelangen an dem alle ernsthaften Probleme außerhalb des Einflussbereichs des Teams liegen; dann kann eine Retrospektive eher nach unten ziehen.


Insgesamt denke ich ist Scrum immer noch ein valider Startpunkt um iterativ oder "agil" zu arbeiten.
- Es "by the book" zu tun widerspricht natürlich irgendwie dem agilen Manifest, aber Scrum "by the book" ist um Welten besser als gar kein definierter Prozess.
- Wenn ein Team unerfahren ist hilft es auch es erstmal genau zu nehmen, damit der Prozess nicht so umdefiniert wird das er am Ende gar nicht mehr agil ist.
- In Unternehmen die noch nicht agil arbeiten findet man mit Scrum Akzeptanz weil der Prozess so verbreitet und etabliert ist.

[Monger]

https://twitter.com/svpino/status/1695806027256475777?t=Ii2sglCehCD0wdDQw2EIQw&s=08

Falls Twitter mal wieder dicht macht hier rauskopiert:

Scrum is a cancer.

I've been writing software for 25 years, and nothing renders a software team useless like Scrum does.

Some anecdotes:

1. They tried to convince me that Poker is a planning tool, not a game.

2. If you want to be more efficient, you must add process, not remove it. They had us attending the "ceremonies," a fancy name for a buttload of meetings: stand-ups, groomings, planning, retrospectives, and Scrum of Scrums. We spent more time talking than doing.

3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.

4. We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.

5. I had to use t-shirt sizes to estimate software.

6. We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points."

7. Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.

8. Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously.

9. We paid people who told us whether we were "burning down points" fast enough. Weren't story points about complexity instead of time? Never mind.

I believe in Agile, but this ain't agile.

We brought professional Scrum trainers. We paid people from our team to get certified. We tried Scrum this way and that other way. We spent years doing it.

The result was always the same: It didn't work.

Scrum is a cancer that will eat your development team. Scrum is not for developers; it's another tool for managers to feel they are in control.

But the best about Scrum are those who look you in the eye and tell you: "If it doesn't work for you, you are doing it wrong. Scrum is anything that works for your team."

Sure it is.

----
Scrum is like communism.

It fails everywhere, every time, but they tell you “you aren’t doing it right.”

[Demirug]

Nach mehren gescheiterten Versuchen hängt bei mir im Büro jetzt ein "Scrum Done!" Poster um jeden daran zu erinnern.

[Aquaschaf]

https://twitter.com/svpino/status/1695806027256475777?t=Ii2sglCehCD0wdDQw2EIQw&s=08

Falls Twitter mal wieder dicht macht hier rauskopiert:

Die meisten Sachen die er aufzählt sind nicht einmal Teil des Scrum-Framework sondern wären genauso mit Kanban, was er als Alternative vorschlägt, möglich. Ich lese eher Frustration über dysfunktionale Teams oder Organisationen da heraus.

Wer bei Scrum zu viel Zeit in Meetings verbraucht würde es auch bei Kanban tun; das einzige was man sich an Zeit spart ist sich auf ein Sprint Commitment zu einigen. Mehr als 1-3 Stunden + Standups pro Woche sollten die Meetings nicht dauern. Anderes deutet darauf dass entweder das Team nicht in der Lage ist sich einig zu werden, zu groß ist, oder die Anforderungen zu unklar sind.

Ich finde Kanban auch in der Regel besser, aber es erfordert eigentlich noch mehr Disziplin damit die Dinge die er aufzählt nicht passieren.

[Exxtreme]

https://ronjeffries.com/articles/016-09ff/defense/

;)


Aber ja, wenn man Scrum für Projektmanagement nutzt dann werden andere Frameworks da auch nicht besser sein. Scrum scheint da aber offener für Missbrauch zu sein.

[Aquaschaf]

Vielleicht ist das auch Selection Bias. Scrum wird als Einstieg in agile Prozesse verkauft, und ist immer noch der am häufigsten verwendete "agile" Prozess. Insofern gibt es da auch die meisten Negativbeispiele.

[nairune]

Läuft bei uns, etwas angepasst.
Das Zitat oben ist ein Witz, oder? So doof kann man nicht sein?

[Monger]

Vielleicht ist das auch Selection Bias. Scrum wird als Einstieg in agile Prozesse verkauft, und ist immer noch der am häufigsten verwendete "agile" Prozess. Insofern gibt es da auch die meisten Negativbeispiele.
a-BOSpxYJ9M
So einer der zentralen Sätze immerhin von einem der Urväter des agilen Manifests: traue niemandem der dir "agile" zu verkaufen versucht.

[][immy]

https://twitter.com/svpino/status/1695806027256475777?t=Ii2sglCehCD0wdDQw2EIQw&s=08

Falls Twitter mal wieder dicht macht hier rauskopiert:

Jep, scrum ist das moderne Schlangenöl. Wenn es nicht funktioniert macht man es falsch, wenn es funktioniert soll es richtig sein. Klingt so ein wenig nach Begründungen von Wunderheilern.
Grundsätzlich, Teile davon gehen sicher in die richtige Richtung, aber es als den Prozess zu verkaufen ist einfach nur falsch.
Ich sag nur unvorhersehbare Probleme... Schätzungen werden als Zeitmaßstab genutzt (Punkte pro Sprint sind nichts anderes als eine Zeiteinheit) und es wird mehr über Dinge geredet als umgesetzt.
Am ende kommt fast immer unfertige Software raus die man so nicht einsetzen kann.

Also grundsätzlich ist nicht schlecht:
Storys schätzen, aber bitte nur kurz über den Daumen. Lässt sich nicht einreden das irgendwer es genau wissen muss wie viel Aufwand am Ende dabei rum kommt, das funktioniert nicht.
Wenn zu komplex/groß versuchen die Story zu zerlegen (das geht aber nicht immer oder ist nicht immer sinnvoll). Für nichts wirklich anderes sollte die Schätzung sein.

Das sind allerdings Mechanismen die es auch vorher schon gab, ggfs nur nicht in als regelmäßiger Prozess.

Sprintlängen... ist Quatsch, weshalb wir letztlich unter anderem auch auf kanban umgestiegen sind. Eine Story ist schließlich erst dann fertig, wenn sie sinnvoll und einigermaßen bugfrei (soweit man es beurteilen kann) abgeschlossen ist.

Der Gedanke "fail fast" von scrum ist im Grunde auch nicht schlecht, aber auch nichts neues. Vorher hieß es quasi prototyping. Prototyping hat nur häufig den Nachteil daß es dann als vollständiger Produktbestandteil verkauft wird und nicht neu implementiert wird (mangels Zeit und Anweisung des Owners).

Retro ist auch so eine Sache. Ist im Grunde nur die regelmäßige Überprüfung was man hätte besser machen können und was man gut gemacht hat. Meist kommt bei rum das es Punkte sind die einen aufhalten, auf die man keinen Einfluss hat.

Ich habe zumindest bislang nichts gesehen wo srum zu einer Verbesserung geführt hätte. Es geht gefühlt deutlich langsamer vorran schon weil man durch Meetings ständig unterbrochen wurde und tatsächlich länger über so manche Punkte gesprochen hat, als die Umsetzung eigentlich gedauert hätte.

Letztlich war scr nichts anders als kleine Wasserfälle nur mit extrem viel Prozess drum herum. Das mag für manche funktionieren aber in der Produktentwicklung hab ich es noch nicht funktionierend gesehen. Die Trainer sprechen immer gerne davon das sie Firmen kennen wo es super funktioniert hat, aber fragt man mal nach haben es die meisten wieder abgeschafft weil es eben nicht funktioniert hat.


"Agile" & scrum sind heute einige dieser Buzzwords. Hauptsache man kann sie verwenden.


Nicht falsch verstehen ein bisschen Ordnung/Prozess schadet nicht, aber letztlich sind auch Entwickler nur Menschen und nicht jeder ist Prozess besessen. Aber was Bürokratie angeht, sind wir in Deutschland ja schon immer begeisterungsfähig gewesen ;)

[RMC]

[immy;13394198']
Nicht falsch verstehen ein bisschen Ordnung/Prozess schadet nicht, aber letztlich sind auch Entwickler nur Menschen

Prinzipiell ist es im Manifest auch so: People over Processes.

Was eigentlich nichts anderes heißen soll als "Macht die Dinge die euch helfen agiler zu sein statt Prozesse der Prozesse wegen zu führen".

---

Natürlich ist das nicht neu. Nichts davon ist wirklich eine Revolution. Die Basis von Scrum ist auch nur viele kleine Wasserfall-Modelle hintereinander (statt einem großen). Aber genau das einer der Punkte wieso es auch besser funktioniert als das was wir bisher hatten.

Die Frustration kommt daher, dass einfach viel zu viel Wirbel um angebliche Wunderlösungen stattfindet und jeder versucht sich als Trittbrettfahrer seinen "Erfolg" dem nächsten anzudrehen wie Wunder-Diäten auf dem Cover der Brigitte: 5kg abnehmen in nur 14 Tagen mit der neuen Scrum-Diät. Ich hab die Lösung für deine Probleme!

In Wahrheit ist jedes Projekt und jedes Team anders. Was in einem funktioniert, kann im nächsten furchtbar schief gehen. Darum gibt es keine ultimative Lösung, aber jeder versucht es so zu verkaufen und da ist viel Nährboden für Cargo-Cult und andere Phänomene, ausgehend vom mittleren Management das sich plötzlich wertlos fühlt und krampfhaft versucht noch im Spiel zu bleiben.

Was ich aber sagen kann ist: Meine Erfahrung mit agilen Methoden ist durchwegs positiv, vorallem wenn es darum geht viele sich ständig ändernde Anforderungen unter einen Hut zu bringen. Das war vor 20 Jahren noch völlig undenkbar, als Projekte über Jahre fix geplant waren und man quasi auf Zuruf gearbeitet hat. Sowas möchte ich nicht mehr.

Darum kann ich auch die Polemik um solche Twitter-Kommentare nur müde belächeln.

[Aquaschaf]

https://youtu.be/a-BOSpxYJ9M
So einer der zentralen Sätze immerhin von einem der Urväter des agilen Manifests: traue niemandem der dir "agile" zu verkaufen versucht.

Dem was er am Ende über Scrum sagt stimme ich auch voll zu. Und die "agile" Consulting- und Zertifizierungbrache ist größtenteils die Krätze.

[malibu_shake]

Hallo zusammen, was haltet ihr von Scrum?

Hier mal meine Gedanken: Positiv sind die täglichen Status-Meetings, weil damit rechtzeitig erkannt werden kann wenn Entwickler blockiert sind oder sich selbst festgefahren haben. Abgesehen davon gibt es bei Scrum aber viele Probleme: Erstens versuchen die Entwickler möglichst viele Story-Points zu schaffen, um Lob vom Chef zu kassieren, was aber oft schädlich für die Qualität ist. Zweitens ist Scrum nicht agil, weil das spontane hinzufügen von Tasks zu einem Sprint entweder gar nicht zugelassen ist oder viel organisatorischen Aufwand nach sich zieht. Drittens gibt es oft Aufgaben, bei denen Forschung, Recherche oder Experimente notwendig sind und deren Aufwand deshalb nicht abgeschätzt werden kann. Wenn so eine Aufgabe dann länger dauert, gibt es Stress bei den Entwicklern und Frust bei den Managern, was mit einem flexibleren Planungssystem vermeidbar wäre. Viertens kosten die Sprintplanungen unnötig Zeit und funktionieren wegen Punkt 3 sowieso oft nicht. Und fünftens sollte man Feedback nicht bis zum Retrospective aufheben, sondern in den täglichen Meetings ansprechen.

Erzähl doch mal wer welche Rolle bei euch hat, also wenn Du von Chef schreibst, wen meinst Du damit? Welche Rolle hast Du?

Und ich würde auf deine Punkte wie folgt antworten:

Motivation durch Story-Points:
Während einige Entwickler möglicherweise versucht sind, ihre Story-Points zu maximieren, liegt es am Scrum-Team, eine Kultur zu schaffen, in der Qualität über Quantität gestellt wird. Story-Points sollten als Mittel zur Aufwandsschätzung und nicht als Erfolgsmaßstab betrachtet werden.

Flexibilität von Scrum:
Das Framework von Scrum bietet tatsächlich Flexibilität. Während ein aktiver Sprint idealerweise nicht verändert werden sollte, kann das Backlog kontinuierlich angepasst werden, um auf Änderungen zu reagieren. Das Ziel ist, das Team vor ständigen Änderungen zu schützen, die die Produktivität beeinträchtigen könnten.

Schwierige Aufwandsschätzung:
Dies ist eine Herausforderung, die nicht nur bei Scrum, sondern bei vielen Projektmanagement-Methoden besteht. Das Schöne an Scrum ist, dass es mit der Zeit und Erfahrung des Teams tendenziell verbesserte Schätzungen ermöglicht. Zudem erlaubt Scrum "Spike"-Aufgaben, bei denen ein festgelegter Zeitraum für Forschung und Experimente reserviert wird.

Zeitaufwändige Sprintplanungen:
Die Sprintplanung ist notwendig, um sicherzustellen, dass das Team ein gemeinsames Verständnis für die anstehenden Arbeiten hat. Durch regelmäßige Retrospektiven kann das Team jedoch den Planungsprozess kontinuierlich verbessern und effizienter gestalten.

Feedback-Timing:
Tägliche Stand-ups sind hauptsächlich dazu gedacht, den Fortschritt zu überprüfen und Blocker zu identifizieren. Nichts hindert das Team jedoch daran, Feedback sofort zu geben, wenn es relevant und zeitkritisch ist. Die Retrospektive dient als zusätzlicher, formeller Mechanismus, um sicherzustellen, dass Feedback nicht übersehen wird.

VG

[Monger]

Motivation durch Story-Points:
Während einige Entwickler möglicherweise versucht sind, ihre Story-Points zu maximieren, liegt es am Scrum-Team, eine Kultur zu schaffen, in der Qualität über Quantität gestellt wird. Story-Points sollten als Mittel zur Aufwandsschätzung und nicht als Erfolgsmaßstab betrachtet werden.

Ich greif mal den Punkt explizit raus, weil er mich am meisten aufregt. Auch Robert C. Martin hat ja immer wieder argumentiert, dass Entwickler sich dagegen wehren müssen, schlechte Qualität rauszuhauen.

Nein! Qualität ist eine Entscheidung des Unternehmens, und muss von allen gemeinsam getroffen werden. Es gibt gute wirtschaftliche Gründe, weniger Geld für Qualität rauszuhauen. Wenn der Kunde für shit zahlt, soll er shit bekommen. Entwickler sind sich der Business-Umstände oft nicht ausreichend bewusst, und betreiben dann Goldplating, während Produktmanager oft die Leistungsfähigkeit der Entwicklungsabteilung sowohl unter- als auch überschätzen. Scrum zementiert die Trennung zwischen Kunde, Produktmanagement und Entwicklung, und das ist keine "falsche Anwendung des Prozesses", sondern das ist schlicht ein schlechter Prozess.

[malibu_shake]

Ich greif mal den Punkt explizit raus, weil er mich am meisten aufregt. Auch Robert C. Martin hat ja immer wieder argumentiert, dass Entwickler sich dagegen wehren müssen, schlechte Qualität rauszuhauen.

Nein! Qualität ist eine Entscheidung des Unternehmens, und muss von allen gemeinsam getroffen werden. Es gibt gute wirtschaftliche Gründe, weniger Geld für Qualität rauszuhauen. Wenn der Kunde für shit zahlt, soll er shit bekommen. Entwickler sind sich der Business-Umstände oft nicht ausreichend bewusst, und betreiben dann Goldplating, während Produktmanager oft die Leistungsfähigkeit der Entwicklungsabteilung sowohl unter- als auch überschätzen. Scrum zementiert die Trennung zwischen Kunde, Produktmanagement und Entwicklung, und das ist keine "falsche Anwendung des Prozesses", sondern das ist schlicht ein schlechter Prozess.


Klassische Anti Pattern den Du da konstruiert hast.

Das Entwicklungsteam folgt ohne Frage den Anweisungen des Product Owners. Ein wesentlicher Aspekt von Scrum ist jedoch, dass jedes Teammitglied den Product Owner hinterfragt, um sicherzustellen, dass die ausgewählten Aufgaben die sinnvollste Nutzung ihrer Zeit darstellen: "Ist das wirklich der beste Weg?". Scrum kann sein volles Potenzial nur entfalten, wenn alle Mitglieder die im Framework vorgesehenen Kontrollmechanismen nutzen. Es ist allzu einfach, sich auf eine bestimmte Lösung zu konzentrieren, statt das tatsächliche Problem des Kunden zu adressieren. Wenn das Entwicklungsteam blind den Vorschlägen des Product Owners folgt, wird der vom Team generierte Wert vermutlich nicht optimal sein. Deshalb ist es wünschenswert, engagierte Botschafter im Team zu haben, statt bloße Auftragserfüller.

[Monger]

Klassische Anti Pattern den Du da konstruiert hast.

Das Entwicklungsteam folgt ohne Frage den Anweisungen des Product Owners.
Damit ist es ne Einbahnstraße, mit dem PO als Gatekeeper. Das ist zwangsläufig keine Begegnung auf Augenhöhe.

[#44]

Damit ist es ne Einbahnstraße, mit dem PO als Gatekeeper. Das ist zwangsläufig keine Begegnung auf Augenhöhe.
Deshalb auch die Bezeichnung als Antipattern.

Der nicht zitierte Teil des Posts ist der eigentliche Inhalt.


Scrum verlangt nicht, dass der PO und der Kunde verschiedene Rollen sind. Scrum definiert keine exklusiven Kontaktpunkte zum Kunden. Scrum kennt keinen expliziten Kunden. In Scrum IST der PO der Kunde.

Die Trennung von PO und Kunde sind Unternehmen und PL, die etwas Neuem ihre gewohnten Muster überstülpen.

Ich habe schon so gearbeitet. Funktioniert gut. Aber der Kunde muss halt erst mal überzeugt sein, dass er Teil des Prozess ist und sein will. Bonus: Die moderierende Rolle des Scrum Masters wird plötzlich viel organischer.


Wenn es keinen singulär greifbaren Kunden gibt und ein Proxy her muss, haben auch andere Prozesse ein Problem an dieser Stelle.
Dieses Problem aufzulösen muss man aber nicht als integralen Teil eines Entwicklungsprozess (oder besser: Der Lenkung der technischen Umsetzung) sehen.

Die spannende Erkenntnis, die ich diese Woche hatte ist, dass wir Entwicklungsingenieuren implizit ganz selbstverständlich etwas auferlegen, was eigentlich eine eigene Disziplin ist: UX. Damit umgehen, dass man den Kunden nicht kennt.

Während wir alle so tun, als wäre das nicht der Fall.

Es wäre kein Wunder, dass diverse Prozesse nicht gut funktionieren, wenn niemandem klar ist, dass da ein ganzer Baustein fehlt.

[Monger]

Es wäre kein Wunder, dass diverse Prozesse nicht gut funktionieren, wenn niemandem klar ist, dass da ein ganzer Baustein fehlt.
Ich hab auch vor nem Jahr oder so nen Mini-Ausflug in UX gemacht, und kam zum selben Schluss. Der Fisch stinkt vom Kopf. Wenn man systematisch den Kunden erforschen würde, würde man weit weniger, dafür zielgerichteter planen, würde Anforderungen seltener wechseln, und könnte den Wert von dem was man tut viel besser beziffern.
Aber zu UX gehören Qualitäten, die man bei Ingenieuren eher nicht antrifft: aktives Zuhören, Einfühlungsvermögen, Moderationsfähigkeiten, gewissenhaftes Protokollieren, eine Portion Statistik...

Bei uns ist es definitiv so. Egal welcher Prozess darunter klebt, unsere Kommunikation zum Kunden ist unter aller Sau. Bis auf wenige Eingeweihte weiß niemand was wie und warum besprochen wurde, und dementsprechend wird im Nebel rumgeirrt. Dass man deswegen Entwickler und Tester zu "Prozessverbesserungen" nötigt, ist eigentlich eine Farce.

[malibu_shake]

Ich hab auch vor nem Jahr oder so nen Mini-Ausflug in UX gemacht, und kam zum selben Schluss. Der Fisch stinkt vom Kopf. Wenn man systematisch den Kunden erforschen würde, würde man weit weniger, dafür zielgerichteter planen, würde Anforderungen seltener wechseln, und könnte den Wert von dem was man tut viel besser beziffern.
Aber zu UX gehören Qualitäten, die man bei Ingenieuren eher nicht antrifft: aktives Zuhören, Einfühlungsvermögen, Moderationsfähigkeiten, gewissenhaftes Protokollieren, eine Portion Statistik...

Bei uns ist es definitiv so. Egal welcher Prozess darunter klebt, unsere Kommunikation zum Kunden ist unter aller Sau. Bis auf wenige Eingeweihte weiß niemand was wie und warum besprochen wurde, und dementsprechend wird im Nebel rumgeirrt. Dass man deswegen Entwickler und Tester zu "Prozessverbesserungen" nötigt, ist eigentlich eine Farce.


Für mich ist das mehr eine Frage der (Kommunikations)Kultur und weniger der agilen Methoden. Schade, dass Du negative Erfahrungen machst damit.

[myMind]

Bei uns ist es definitiv so. Egal welcher Prozess darunter klebt, unsere Kommunikation zum Kunden ist unter aller Sau. Bis auf wenige Eingeweihte weiß niemand was wie und warum besprochen wurde, und dementsprechend wird im Nebel rumgeirrt.
Wenn es gar keine Spezifikation in irgendeiner Form gibt, scheint es an den aller elementarsten Grundlagen des Softwareengineerings zu fehlen.

[Monger]

Wenn es gar keine Spezifikation in irgendeiner Form gibt, scheint es an den aller elementarsten Grundlagen des Softwareengineerings zu fehlen.
Das hab ich nicht gesagt. Wir haben sogar sehr viel davon. Aber nirgendwo steht, was der Kunde genau gesagt hat.

[myMind]

Das hab ich nicht gesagt. Wir haben sogar sehr viel davon. Aber nirgendwo steht, was der Kunde genau gesagt hat.
Wie werden denn die Spezifikationen/Epics/Stories/whatever erarbeitet? Das sollte in enger Abstimmung mit dem Kunden geschehen. Der Wasserfall-Weg wäre, dass gar nichts passiert, bevor unter der Spezifikation nicht die Unterschrift des Kunden drauf ist. Alle anderen Varianten (RUP, Scrum, ...) sind ja eigentlich nur zeitlich kleinere Zyklen, des selben Ablaufs.

[Monger]

Wie werden denn die Spezifikationen/Epics/Stories/whatever erarbeitet? Das sollte in enger Abstimmung mit dem Kunden geschehen.
Das ist wohl auch so, ändert aber nix daran dass fast niemand Zugang zu den Originalinterviews etc. hat. Es ist halt stille Post: der Kunde sagt es dem Regionalvertrieb, der Regionalvertrieb dem Produktmanager, der Produktmanager dem Projektleiter, der Projektleiter dem Entwickler, und der Entwickler dem QA Tester.

[malibu_shake]

Das hab ich nicht gesagt. Wir haben sogar sehr viel davon. Aber nirgendwo steht, was der Kunde genau gesagt hat.

Sind die Rollen alle besetzt bei euch?

Stakeholder
Product Owner
Scrum Master
Dev Team


Wer nimmt an was bei euch teil?

Sprint Planning

Dailys

Backlog Refinement

Sprint Demo/Review

Retrospective

[myMind]

Das ist wohl auch so, ändert aber nix daran dass fast niemand Zugang zu den Originalinterviews etc. hat. Es ist halt stille Post: der Kunde sagt es dem Regionalvertrieb, der Regionalvertrieb dem Produktmanager, der Produktmanager dem Projektleiter, der Projektleiter dem Entwickler, und der Entwickler dem QA Tester.
Die allermeisten die was mit Software zu tun haben werden vermutlich sofort dieses Bild im Kopf haben:
https://i.imgur.com/UooEY3x.png
Das Problem ist weithin bekannt, überall anzutreffen und steinalt.

Es ist genau so wie in dem Comic dargestellt, dass der mit der Vision am Anfang nur eine sehr sehr grobe Idee davon hat, wo man am Ende tatsächlich landet. Je eher man das akzeptiert und sich vernünftige Strategien überlegt, wie man damit umgeht, desto besser. Es gibt aber m.E. keine echte Lösung in dem Sinne.

Was würden die "Originalinterviews" überhaupt nützen? Wenn da mehrere Leute interviewed wurden, dann hatten schon die alle völlig andere Ideen im Kopf. Auf irgendwas muss man sich aber einigen. Entweder schriftlich (Spezifikation) oder man einigt sich auf ein Prototyping, bzw heute würde man MVP sagen. Dann kann man in eine möglichst kurze Feedbackschleife gehen.

Im täglichen Leben sind wir es gewohnt, das wir das Arbeitsergebnis gut abschätzen können. Mähe ich den Rasen, weiß ich schon vorher wie lange das dauert und ich weiß ziemlich genau wie das Ergebnis aussieht. Das würde ich von keiner einzigen größeren Unternehmensanwendung behaupten, an der ich jemals mitgearbeitet habe. Wenn man sich zeitlich zurückversetzt und sich überlegt, was man am Anfang eines Projekts gedacht hat und wie es dann am Ende aussieht, so liegen Welten dazwischen.

[malibu_shake]

Das ist wohl auch so, ändert aber nix daran dass fast niemand Zugang zu den Originalinterviews etc. hat. Es ist halt stille Post: der Kunde sagt es dem Regionalvertrieb, der Regionalvertrieb dem Produktmanager, der Produktmanager dem Projektleiter, der Projektleiter dem Entwickler, und der Entwickler dem QA Tester.

@monger bist Du noch da? Ich fand es total schön, wie Du Dich bisher hier geöffnet hast und würde es schade finden, wenn Du jetzt aus dem Gespräch aussteigst.

[Monger]

@monger bist Du noch da? Ich fand es total schön, wie Du Dich bisher hier geöffnet hast und würde es schade finden, wenn Du jetzt aus dem Gespräch aussteigst.
Sorry, ich brauche nicht noch einen Berater. Seit 10 Jahren sehe ich unterschiedliche agile Coaches durch die Firma pilgern. 8 davon hab ich die tatkräftig unterstützt, war selber Evangelist.
Das ist natürlich bei jeder Abteilung anders, aber bei uns ist mir die Erkenntnis gereift, dass weder das Problem noch die Lösung in der Entwicklungsabteilung liegen.

[malibu_shake]

Sorry, ich brauche nicht noch einen Berater. Seit 10 Jahren sehe ich unterschiedliche agile Coaches durch die Firma pilgern. 8 davon hab ich die tatkräftig unterstützt, war selber Evangelist.
Das ist natürlich bei jeder Abteilung anders, aber bei uns ist mir die Erkenntnis gereift, dass weder das Problem noch die Lösung in der Entwicklungsabteilung liegen.


Hi Monger, erstmal schön das Du Dich nochmal meldest. Ich bin kein agile Coach, ich bin CIO und verantwortlich für ziemlich viele MA und ich finde den Austausch spannend weil es eine Perspektive ist.

Um noch auf deinen letzten Satz hier einzugehen, die Frage ist nicht wo das Problem sitzt sondern viel mehr wo ist die Lösung? Was meinst Du?

VG

[Monger]

Um noch auf deinen letzten Satz hier einzugehen, die Frage ist nicht wo das Problem sitzt sondern viel mehr wo ist die Lösung? Was meinst Du?

VG
Ich kann nicht für andere Firmen sprechen. Bei uns ist mein Eindruck: man will sich waschen, aber nicht nass machen. Man lädt den Mitarbeitern immer mehr unterschiedliche Verantwortlicheiten auf (von Design über Build Pipelines übers Programmieren bis hin zum testen, am besten Full Stack), die MA profitieren aber null davon. Von Businessentscheidungen werden sie explizit ausgeklammert, es wird übern Zaun geworfen, und das muss gemacht werden. Basta.

So geht das nicht. Wenn man tatsächlich handlungsfähigere Teams haben will, muss man sie gut ausbilden, gut bezahlen, und weitreichendere Entscheidungsfreiheiten einräumen. Aber so weit geht die Liebe zur Agilität halt eben doch nicht. Weil, wer weiß wie sich die Firma dann verändern würde. Veränderung ist immer ein hohes Ziel, außer in der Führung.

[/dev/NULL]

Sehe ich hier auch (Großkonzern)

Alle machen auf Agile und Flightlevel und so.

(auch Detail)Entscheidungen trifft aber immer noch die Führung, nicht der ProductOwner (bzw wird der dann eiskalt überbügelt.

Dazu Outsourcing nach Indien und selbst objectiv einfachste Änderungen kosten "zwei Mannmonate"

Wir meeten uns nur noch und bekommen immer weniger gebacken. Aber Agile my Ass

[Asaraki]

Na passt doch, ganz agil jeglicher Effizienz ausgewichen ;)

[/dev/NULL]

Na passt doch, ganz agil jeglicher Effizienz ausgewichen ;)
Das ist leider viel zu richtig

[Asaraki]

I know… bin beim x-ten Kunden mit der x-ten Mutation von Agile, CI, Lean Sigma, 5 Diamonds oder wie das hiess…

Hab vor >10 Jahren den McKinseys und Co schon erklärt warum ihre Theorie nicht aufgeht, da sie nicht die praktischen Probleme löst.

Ich fürchte der Erfolg kommt daher, dass viele Teams vor Agile garkeinen Prozess hatten und dann ist natürlich auch der schlechteste Prozess meistens noch besser ^^

[nairune]

Oder man schiebt es schön auf Agile, während die Probleme hausgemacht sind und gar nichts damit zu tun haben.
Wenn man es vernünftig durchzieht, funktioniert es auch. Wenn man es nur zu einem Drittel umsetzt, halt nicht.

[Exxtreme]

Man sollte IMHO Agile und Scrum nicht gleichsetzen oder irgendwie äquivalent verwenden. Agile bedeutet lediglich, dass man viele kleine Schritte macht und für diese Schritte viel Feedback bekommt. Sodass man die Möglichkeit hat die Richtung zu ändern wenn man merkt, dass man gerade dabei ist einen Holzweg zuende zu gehen. Bei Scrum hat man ja noch einen kompletten Projektmanagement-Stack oben drauf gepappt.

Und das ist auch womöglich das Hauptproblem von Scrum.

[maximAL]

Ich hab mich auch durch den PSM 1 gequält um mich Scrum Master nennen zu dürfen.

Irgendwie kam mir das ganze immer wie ein Kult vor, bei dem der einzig wahre Weg gepriesen wird. Endloses herumreiten auf Definitionen und Formulierungen und dieser dämliche Multiple-Choice Test, der wenig mit Verständnis aber viel mit auswendig lernen zu tun hat.
Viele Dinge kommen mir als Senior Entwickler einfach zu absurd vor. Allein, dass jede Aufgabe irgendeinen Value für das Produkt bringen soll und damit Dinge wie Forschung, Refactoring und Infrastruktur gar nicht abbildbar sind ist albern.

Obwohl Scrum ja angeblich total flexibel ist und nur wenige Grundregeln hat, macht am Ende sowieso keiner Scrum, sondern nur Scrum-but. Allein das zeigt doch, dass das nicht funktioniert.

Bei uns wird auch nur Scrum-but gemacht. Der Abteilungsleiter ist gleichzeitig leitender Entwickler und PO, was soll da raus kommen? Jede Woche werden aufgaben geplant, bei denen man sich die Aufwände aus dem Hut schütteln muss. Aber alles über einer Stunde aufwand muss eingeplant und abgesprochen werden. Was dazu führt, dass häufig kleine Verbesserungen Monate lang im Backlog abgammeln, weil andere Sachen wichtiger sind. Viele Sachen, die ich sonst mal in der letzten Stunde machen würde, weil ich von der Hauptaufgabe die Nase voll hab, bleiben ewig liegen und nerven rum, weil ich ja erstmal um Erlaubnis fragen müsste.

[Monger]

Ich hab mich jetzt mit drei vier Kollegen zusammengesetzt, und mein Leid darüber geklagt, dass ich für jeden Commit ein vielfaches der Zeit aufs labern verbrate um den Prozess einzuhalten als das Entwickeln dauert.
Wir haben uns deshalb jetzt so geeinigt: Refactorings und Performanceverbesserungen gehen alle auf einem Ticket ungesehen durch. Wenn was schief geht, wird ohne Rückfrage zurückgerollt. Hintendran vielleicht mal über Fortschritte reden wäre nett.

[#44]

Ich hab mich auch durch den PSM 1 gequält um mich Scrum Master nennen zu dürfen.

Irgendwie kam mir das ganze immer wie ein Kult vor, bei dem der einzig wahre Weg gepriesen wird. Endloses herumreiten auf Definitionen und Formulierungen und dieser dämliche Multiple-Choice Test, der wenig mit Verständnis aber viel mit auswendig lernen zu tun hat.
Viele Dinge kommen mir als Senior Entwickler einfach zu absurd vor. Allein, dass jede Aufgabe irgendeinen Value für das Produkt bringen soll und damit Dinge wie Forschung, Refactoring und Infrastruktur gar nicht abbildbar sind ist albern.

Obwohl Scrum ja angeblich total flexibel ist und nur wenige Grundregeln hat, macht am Ende sowieso keiner Scrum, sondern nur Scrum-but. Allein das zeigt doch, dass das nicht funktioniert.

Bei uns wird auch nur Scrum-but gemacht. Der Abteilungsleiter ist gleichzeitig leitender Entwickler und PO, was soll da raus kommen? Jede Woche werden aufgaben geplant, bei denen man sich die Aufwände aus dem Hut schütteln muss. Aber alles über einer Stunde aufwand muss eingeplant und abgesprochen werden. Was dazu führt, dass häufig kleine Verbesserungen Monate lang im Backlog abgammeln, weil andere Sachen wichtiger sind. Viele Sachen, die ich sonst mal in der letzten Stunde machen würde, weil ich von der Hauptaufgabe die Nase voll hab, bleiben ewig liegen und nerven rum, weil ich ja erstmal um Erlaubnis fragen müsste.
Ich habe für mich irgendwann die Erkenntnis gewonnen, dass das zumindest Refactoring und Kleinkram mit in die Schätzung der Hauptaufgaben gehören.
Ich denke, dass das näher an dem ist, was Scrum wirklich will.

Das liegt am Ende auch an den Entwicklern - wenn wir bereit sind, zu behaupten die Arbeit ist fertig, während wir eigentlich noch gerne refactoren würden (oder gar der Meinung sind, es zwingend zu müssen!), ist das nicht die Schuld des bösen PO, der das ja nicht einplant. Es ist unser Versagen dabei, korrekt abzuschätzen (bzw. kommunizieren; das ist die Schätzung ja - eine Botschaft an den PO), wann die Aufgabe TATSÄCHLICH abgeschlossen ist. Und das ist sie halt nicht, wenn der erste Wurf funktioniert (oder man mal eine Runde grob aufgeräumt hat). Architektur liegt in unserer Hand. Nicht in der des PO. Und auch der Architekt kann nichts retten, wenn die Mannschaft nur all zu bereit ist, die Architektur für dem PO gefällige, niedrige Schätzungen zu opfern. Entsprechend sind wir dafür verantwortlich, dass sie passt. Und entsprechend müssen wir unsere Arbeit abschätzen. Und dann gehört es halt zur Entwicklung des neuen Features dazu, dass refactoring stattfindet um dieses architekturell sauber zu integrieren. Das ist keine separate Aufgabe. Der PO geht davon aus, dass es fertig ist, wenn wir sagen es ist fertig. Ihn (und uns!) zu belügen, dass das so wäre, sobald eine grundlegende technische Umsetzung erfolgt ist, ist ein Fehler der sich rächt.

Qualität kann nur dem Prozess entspringen und nicht etwa nachträglich dazu gebaut werden. Entsprechend muss man die Aufgaben behandeln.

Ja, das führt zu höheren Schätzungen. Ja das schmeckt dem PO nicht. Aber es ermöglicht überhaupt erst eine ehrliche Diskussion darüber, welche Kröten man bereit ist zu schlucken.
Aber wenn wir gute Architektur wollen, dann müssen wir dafür eintreten. Und nicht darauf hoffen, dass es schon irgendwer anders tun wird.

[RMC]

Der Großteil des mittleren Managements, das durch Agile Software Development im Prinzip zwecklos geworden ist, wedelt jetzt halt mit den Scrum Büchern (weil sie müssen) und wollen einfach nicht von ihren Prozessen, Methoden und Strukturen abweichen. Ohne dem können sie ja nicht existieren.

Und genau dann heißt es "Scrum funktioniert nicht". Na, wenn das alte Management jetzt meint dem nur einen neuen Namen geben zu müssen und weiterhin ihren Prozess-Overload durchdrücken will ohne dass sie begreifen worum es eigentlich geht, wird sich auch nix ändern. Dann ist es leicht mit dem Fingerzeig.

Ich hab viele Teams erlebt die mit Agile Software Development arbeiten (mal besser und mal schlechter) und es war nie gleich - und so gehört sich das auch. Jedes Team soll das machen was für sie am besten funktioniert. Mit der Betonung, dass die Ansagen aus dem Development-Team kommen müssen.

Wenn weiterhin die komplexen Prozesse und Strukturen von oben auf die Teams abgeladen werden von Leuten die keine einzige Minute in der Praxis damit zu tun haben, sodass alles kontraproduktiv wird, dann ist es ja die gleiche Scheiße wie vorher. So kanns auch nie funktionieren :crazy2:

[Exxtreme]

Gesehen bei ThePrimagen. X-D

fTaOdbUbFmI

Die Dichte an Sarkasmus ähnelt aber einem schwarzen Loch. Verträgt womöglich nicht jeder. ;D

[r3ptil3]

Modeerscheinung - schlussendlich wird auch hier nur das wiederverwendet und neu verpackt was vor Jahrzehnten schon mal in ähnlicher Weise zu Anwendung kam.

Sind halt Beraterfirmen, die ihre Stunden an grosse Unternehmen verkaufen wollen.
Ein grosser Konzern gibt mal die Marschrichtung durch und die kleineren ziehen dann nach.

Vorteile sind aber vorhanden.
Wenn davon 3-4% tatsächlich in den Alltag einfliesst, kann es als Erfolg angesehen werden. Alles andere ist unrealistisch.

[Shink]

Naja erinnert an den 1997er RUP (https://de.wikipedia.org/wiki/Rational_Unified_Process) aber genaugenommen ist Scrum auch ein Konzept aus den 90ern.
Was wirklich Neues fällt scheinbar auch keinem ein. Kanban für Softwareentwicklung streicht einiges des Overheads von Scrum. Das kann viel effizienter sein - oder nicht funktionieren, wenn die Leute nicht wissen, wie sie zusammen arbeiten sollten.

Bin gespannt, wie viele der Teams, die denken, sie machen Scrum, eher Kanban machen:
https://de.wikipedia.org/wiki/Kanban_(Entwicklung)#Unterschiede_zwischen_Kanban_und_Scrum

[RMC]

Bin gespannt, wie viele der Teams, die denken, sie machen Scrum, eher Kanban machen:
https://de.wikipedia.org/wiki/Kanban_(Entwicklung)#Unterschiede_zwischen_Kanban_und_Scrum

Nach der Liste hab ich aber noch kein Team eindeutig A oder B machen sehen. Daraus folgt eigentlich das was eh schon lange bekannt ist: Es gibt nicht "das eine" Scrum.

[Shink]

Nach der Liste hab ich aber noch kein Team eindeutig A oder B machen sehen.
Natürlich gibt's die Teams, die sich religiös daran halten - oder die Agile Coaches, die nur dafür da sind, dass das Team exakt so funktioniert.

[RMC]

Natürlich gibt's die Teams, die sich religiös daran halten - oder die Agile Coaches, die nur dafür da sind, dass das Team exakt so funktioniert.

Also ich hab religiöse Ansätze oder sture Agile Coaches so nicht erlebt bisher, mir kommt diese Schwarzweißmalerei sehr konstruiert und überzeichnet vor.

Vielleicht hab ich einfach Glück oder umgebe mich einfach gern mit professionellen Leuten.