Bullshitbingo Teammeeting Scrum

Aber es funktioniert doch!
Bin mir sicher, dass Boing das komplett umgesetzt hat. Nicht nur bei der 
737 MAX, sondern auch beim Starliner:
https://www.msn.com/en-us/news/technology/nasa-faults-boeing-for-critical-software-defects-in-starliner/ar-BBZLxkm
Also zumindest konnte man einen Bug beheben, als der Starliner schon im 
Weltall war.
Gut, die Sache dass die Uhrzeit unerheblich (mehrere Stunden; 6?) 
daneben war ist immer noch so. Aber im Weltall gibt es ja auch keine 
Zeitzonen. Also unerheblich! Kommt dann im nächsten Release. Morgen.

Unglaublich schrieb:
> Gerade wieder eine Stunde Sprint / Meeting hinter mir. Fast hätte ich
> das Bullshitbingo gewonnen. Soll wohl sowas wie Scrum sein / werden.

René H. schrieb:
> Ich hatte mein Sprint Planning Meeting gestern und kann Dir nur
> beipflichten. Aber glaub mir, es geht noch schlimmer: SAFe :-)

Wie wird Scrum eigentlich gelebt? Bekommen das die Entwickler von oben 
vorgegeben und müssen so arbeiten oder einigen sich die Abteilungen 
intern darauf das mal zu versuchen? Dachte Scrum sei ein moderner und 
agiler Stil wobei jeder selbstorganisiert und freier arbeiten kann und 
soll.

Man hört aber immer die Entwickler heulen dass das alles so zäh und 
ineffizient sei. Dann kann man es doch Abteilungsintern wieder 
abschaffen.
Oder hört man wie meistens nur den geringen Teil der Entwickler schreien 
und der größere Teil ist damit erfolgreich?

Kai schrieb:
> Wie wird Scrum eigentlich gelebt? Bekommen das die Entwickler von oben
> vorgegeben und müssen so arbeiten oder einigen sich die Abteilungen
> intern darauf das mal zu versuchen? Dachte Scrum sei ein moderner und
> agiler Stil wobei jeder selbstorganisiert und freier arbeiten kann und
> soll.

Hier sitzen nur junge dynamische Mitarbeiter, alle max. 35 Jahre alt und 
viele erst ein paar Jahre aus der Uni. Manche auch noch Werksstudenten.

Die finden das alle total geil und leben das. Die wollen das und bringen 
das aktiv voran.

Ich stehe nur gelangweilt daneben und überlege mir, wann ich wiedermal 
den Rasen mähen muss.

Fehlt mir da ein Gen? Ich bin nicht älter als die. Das ist ja nicht nur 
die Arbeitsweise (Scrum etc.), sondern alles wird in höchst 
unübersichtlichen Tools verpackt, die auch noch mal mega viel Zeit 
fressen. Da ist man (mit einem kleinen Produkt) noch in der Entwicklung 
und verpackt das alles in Release und Sub Releases bla bla bla... wenn 
ich zusammenzähle werden hier ca. 10 verschiedene Tools nur zur 
Organisation verwendet, welche gar nichts mit der Entwicklung an sich zu 
tun haben.

Da wäre mir sogar eine Exceltabelle lieber, als das...

Unglaublich schrieb:
> Da wäre mir sogar eine Exceltabelle lieber, als das...

Oh ja bitte mehr Excel Tabellen, am besten mit 1000 Makros welche sich 
Daten aus 10 verschiedenen Dateien holen! Alles undokumentiert!

Und den Leute schön antrainieren aufs "Makro aktivieren" Knöpfchen zu 
drücken!

arbeitsloserArbeitsloser schrieb:
> Oh ja bitte mehr Excel Tabellen, am besten mit 1000 Makros welche sich
> Daten aus 10 verschiedenen Dateien holen! Alles undokumentiert!
>
> Und den Leute schön antrainieren aufs "Makro aktivieren" Knöpfchen zu
> drücken!

Ist schon in Ordnung mit professionellen Tools zu arbeiten. Aber dieser 
Zustand hier ist für mich nicht mehr lange tragbar.

Naja, wenns sich um ein Prj. mit ein paar Mannstunden handelt, ist der 
Overhead nicht gerechtfertigt.
Im Gesamtkontext sehr sinnvoll, weil meist gar nicht so wirklich klar 
ist, was entwickelt werden soll.

Im Prinzip ist Scrum reines Kommunikationsmanagement. Agil ist hip.

Richtig angewandt, ist dies bei großen Projekten eig. das kleinere Übel. 
Denn wieviel Zeit geht für Projektplanung im Detail drauf und wie oft 
wird dann doch alles wieder umgeschmissen?

Unglaublich schrieb:
> Hier sitzen nur junge dynamische Mitarbeiter, alle max. 35 Jahre alt und
> viele erst ein paar Jahre aus der Uni. Manche auch noch Werksstudenten.

Jung, dynamisch, erfolglos...

> Fehlt mir da ein Gen?
Nein, Du bist nur intelligenter, als die Lemmingmasse.

soso schrieb:
> Im Prinzip ist Scrum reines Kommunikationsmanagement. Agil ist hip.
>
> Richtig angewandt, ist dies bei großen Projekten eig. das kleinere Übel.
> Denn wieviel Zeit geht für Projektplanung im Detail drauf und wie oft
> wird dann doch alles wieder umgeschmissen?

Das sehe ich überhaupt nicht so.

Ich bin jetzt seit ca. 20 Jahren in der Softwareentwicklung und fand es 
noch nie so unproduktiv und frustrierend wie seit der Einführung von 
SCRUM.

Für mich ist inzwischen klar, dass SCRUM bzw. die agile Arbeitsweise 
hauptsächlich einer gewissen Gruppe von Anforderern dient - nämlich 
denen, die es damals schon nicht drauf hatten, ihre Anforderungen klar 
zu definieren und immer schon dagegen waren, dass Projektbudget für 
Dokumentation und Analyse verbraucht wird.

Und die Entwickler, die heute neu dazukommen, haben Analyse und 
"Systementwicklung" ebenfalls absolut nicht drauf. Die können garnix 
anderes mehr, als aus dem Kopf in Konsole zu programmieren und im ewigen 
Hin- und Her mit dem Anforderer ultralangsam ans Ziel kommen.

Erfolgversprechender als ein Wasserfallmodell?
Ja klar - wenn man nix kann, auf jeden Fall. Denn sonst kommt man mit 
dem Wasserfallmodell erst gar nicht so weit, dass die Programmierer mal 
aktiv werden.

Das einzig tolle daran:
Ich kann jetzt ca. 1/3 meiner wöchentlichen Arbeitszeit in Meetings, 
Dailys, Telefonkonferenzen und JIRA-Pflege verbringen. Sitze also im 
Grunde nur rum und kassiere dafür genauso viel Geld, wie für eine 
vernünftige Systemanalyse.


Absolut lächerlich.

Meine persönliche Konsequenz:
Ich distanziere mich weiter von meiner Arbeit und schraube meinen 
eigenen Anspruch runter. Das Produkt hat hier eindeutig an Bedeutung 
verloren... wichtiger ist, dass alle vom PO an aufwärts ihre Häkchen 
machen können und bunte Bilder sehen.

"Guck mal - die neue Software!!!
Sie hilft uns zwar nicht weiter aber sie ist fertig."

Kai schrieb:
> Oder hört man wie meistens nur den geringen Teil der Entwickler schreien
> und der größere Teil ist damit erfolgreich?

Ich bin auch kein großer Fan davon, ich hätte auch lieber Requirements 
die ich abhaken kann und dann zufrieden bin.

Dennoch, wenn man einigermaßen weiß, was man tun muss, damit das Projekt 
ein Erfolg wird, ist es am Ende egal.

Dann präsentiere ich meine Fortschritte eben Scrum-kompatibel in 2 
Wochen großen Häppchen.

Dann sind die Scrummaster zufrieden, dass ich selbst einen 
längerfristigen Plan verfolge muss der nicht wissen.

endwiggler schrieb:
> Dann sind die Scrummaster zufrieden, dass ich selbst einen
> längerfristigen Plan verfolge muss der nicht wissen.

Uhuh, ganz ganz schlechte Teammoralbildung. Vielleicht solltet ihr mal 
häufiger zusammen in der Kantine Mittagessen gehen oder abends noch in 
der Firma am Kicker fachsimpeln.

Unglaublich schrieb:
> endwiggler schrieb:
>> Dann sind die Scrummaster zufrieden, dass ich selbst einen
>> längerfristigen Plan verfolge muss der nicht wissen.
>
> Uhuh, ganz ganz schlechte Teammoralbildung

Nö, mein (Entwickler-)Team ist ja eingeweiht. Der Scrummaster gehört nur 
nicht dazu, zu diesem Team.

Unglaublich schrieb:
> einfach mal am Anfang einer Entwicklung einen Anforderungskatalog
> erstellen können

Ist doch durch Srum abgedeckt. Leider hat alles in Scrum beschissene, 
irreführende, "moderne" Bezeichnungen und es werden haufenweise 
Nebelkerzen geworfen. Bullshitbingo  ist schon das richtige Wort dafür. 
So findet sich der Anforderungskatalog in Form des "Backlogs" (zusammen 
mit ein paar anderen Dingen).

Noch beschissener ist die Terminologie wenn es darum geht die 
Anforderungen zu präzisieren und aktuelle Änderungen einzuarbeiten. 
Backlog Grooming und Refinement. Als ob es zum Hundefriseur geht :-(

Dass zum Backlog Grooming und Refinement gar nicht das ganze Team 
antreten muss wird gerne übersehen und so werden Teams Woche für Woche 
mit sinnlosen Monologen über Backlog-Items gequält. Erst dann fühlt sich 
der Product Owner groß, stark und mächtig. "Jetzt müssen sie mir alle 
mal zuhören, jetzt red i".

Product Owner ist noch so ein beschissener Scrum Term. Dem Product Owner 
gehört gar nicht das Produkt. Er ist nur Herr über den 
Anforderungskatalog, hat den gefälligst ranzubringen, aktuell zu halten, 
die Anforderungen zu priorisieren und dem Team Rede und Antwort zu 
stehen wenn Anforderungen unklar sind.

Statt dessen wird Product Owner gerne als Ehrentitel an einen Manager 
vergeben der von der Technik (und damit den Anforderungen) keine Ahnung 
hat und seinen Arsch nicht hoch bekommt.

> - dann könnte man sich diesen modernen Unsinn sparen
> und jeder weiß, was realistisch zu tun ist.

> Da braucht man wirklich bald einen Scrummaster,

Jedes Team "braucht" einen Scrummaster. Kleine Teams notfalls in 
Teilzeit oder als Doppelfunktion Entwickler / Scrummaster.

> um ein kleines Team zu
> managen....

Der Scrummaster managed nicht das Team. Vereinfacht gesagt, er schützt 
den Prozess. Er hat keine Vorgesetztenfunktion sondern steht im Dienst 
des Teams.

Unglaublich schrieb:
> Unfassbar, was da für Zeit und Energie bei drauf geht. Man hätte auch
> einfach mal am Anfang einer Entwicklung einen Anforderungskatalog
> erstellen können

Was meinst du, warum Software seit der Erfindung und zunehmenden 
Verbreitung von Scrum und anderen agilen Methoden so viel schlechter 
geworden ist.

Gestern durfte ich jemandem helfen, dessen Thunderbird nach dem Update 
vom 28.1. keinen 'Senden' Knopf mehr hat. Im 'Neue Nachricht erstellen' 
Fenster gibt es gar nichts mehr, kein Menü, keine Knöpfe, nur 
Adresszeile und Textfeld.

Immerhin ergab eine Suche im Web die Lösung: Alt drücken. Dummerweise 
gibt es das Problem schon mindestens seit 2013, immer wieder, aber man 
ist bei Mozilla zu blöd es zu beheben.

Daß bei dem Update die Knöpfe wie 'Antworten' auf der Nachrichtenliste 
vom Kopfbereich in die Vorschau gewechselt sind, muss auch an einem 
Entwiggler mit kleinem Hirn aber quadratmetergrossem Bildschirm liegen. 
Auf normalen Bildschirmen kann man sich gar keine Vorschu anzeigen 
lassen, so verschwenderisch geht Thunderbird mit dem Bildschirmplatz um. 
Dumm nur, daß auf die Art der Knopf beim Update auch verschwunden ist. 
Immerhin kann man ihn dort in die noch weiter oben liegende Button-Bar 
konfigurieren.

Es ist weitgehend egal wo du hinguckst: Überall wird Software 
schlechter. Selbst mein Auto hat Bugs, durch die es den Funkschlüssel 
'vergisst', was die Markenwerkstatt durch einen 1900 EUR teuren Wechsel 
de Funkempfängers beheben will, weil sie nicht weiss, wie man das 
Vergessen rückgängig macht, sondern glaubt die Hardware wäre defekt.

Das ganze Leben ist umständlich und kompliziert. Vor allem eins - 
anstengend.

Meistens wird man mit Arbeit zugemüllt und hat keinen Einblick oder kein 
Interesse für die Tätigkeit des PL zB, der dafür sorgt, dass das Projekt 
zusammengehalten wird.

Noch ein zusätzlicher Prozess, na Danke. Dennoch. Würde sagen unter dem 
Strich ist dies eine Verbessserung, vor allem von der Kommunikation.

Die meisten, die sich hier auslassen über Scrum haben vor 10 Jahren 
darüber geschimpft, dass die Leute nicht miteinander reden und/oder die 
wichtigen Informationen nicht durchdringen.

Ein Backlog ersetzt im Übrigen nicht das Pflichtenheft und auch nicht 
die Dokumentation des  Projekts.

Unglaublich schrieb:
> Gerade wieder eine Stunde Sprint / Meeting hinter mir. Fast hätte
> ich das Bullshitbingo gewonnen. Soll wohl sowas wie Scrum sein / werden.
>
> Unfassbar, was da für Zeit und Energie bei drauf geht. Man hätte auch
> einfach mal am Anfang einer Entwicklung einen Anforderungskatalog
> erstellen können - dann könnte man sich diesen modernen Unsinn sparen
> und jeder weiß, was realistisch zu tun ist.
> Da braucht man wirklich bald einen Scrummaster, um ein kleines Team zu
> managen....

Ein Scrum meeting sollte < 15 min dauern

René H. schrieb:
> Ich hatte mein Sprint Planning Meeting gestern und kann Dir nur
> beipflichten. Aber glaub mir, es geht noch schlimmer: SAFe :-)
>
> https://www.scaledagileframework.com/
>
> Grüsse,
> René

Wow!
"Epic Owners"
"Learn-Agile Mindset"
"Agile-Release-Train"

Ich werde Epic owner!

Niemand hat euch gezwungen, einen solchen Beruf auszuüben.

Name: schrieb:
> Ich werde Epic owner!

Ist das gleiche wie bei AISLER 
(Beitrag "Ask me anything, Fertigung bei AISLER"). Lauter 
buzzwords, bunt und hauptsächlich Luft.

Wenn es Klärungsbedarf gibt, frag ich halt einen Kollegen und zwar 
zeitnah und nicht erst Freitags. Und wenn es was zu erklären gibt, dann 
erklär ich es ihm und nicht denen die nichts damit zu tun haben und 
nichts damit anfangen können.
Und wenn es Alle was angeht, dann genügt ein "Setzen wir uns zusammen".

Wenn das jetzt in einem festen Zeitraster besser sein soll, dann ist mir 
klar, warum die Montagsbesprechnungen hier so völlig sinnlos waren und 
ich mich durch häufiges gähnen und Aufforderung zur Kürze selbst 
rausgekick hab. War ja eh nichts für mich dabei. Mir geht's einfach am 
Arsch vortbei wie die Buchhaltung SAP bedienen soll oder Netzwerkkabel 
beim Kunden X unbedingt grau sein müssen.

Aber Schneeflocken brauchen wohl eine Anleitung wie sie mit Kollegen 
umgehen sollen. "Kollegial" und "Zusammenarbeit" sind wohl völlig neue 
und unverständliche Begriffe für die.

Kindergarten!

Hahaha,
da bin ich ja froh, dass mein langjähriger Kollege und ich nicht die 
Einzigen sind, die sich über Sinn und Unsinn dieser 'modernen' 
Prozesstools amüsieren.

Wir sitzen jeden Tag 45min und quatschen darüber welche JIRA-Story ich 
gestern bearbeitet habe, welche heute drankommt und evtl. noch was ich 
dann morgen mache.
Ich bete meine Story also runter (wobei ich mir ziemlich sicher bin, 
dass - wenn sie denn noch zuhören - die meisten überhaupt nichts mit der 
Nummer und der Kurzbezeichnung anfangen können) und mache dann die Augen 
wieder zu .... ;)
Scrum wird wie üblich von Unwissenden oben aufgezwungen, Scrum Master 
ist bei uns einer aus dem 'Entwicklerteam'.
Technisch inhaltlich soll nichts besprochen werden, nur der Fortschritt 
des Projekts und die grünen Häckchen für die Vorgesetzten sind wichtig.
Aktuelle, technische Probleme hinterher in P2P-Gespräch geklärt ... nein 
besprochen werden.

Ich sehe das wie einer meiner Vorredner - wenn sich die Firma so einen 
Blödsinn leisten kann ... dann soll sie das.
Die Konsequenz ist, dass ich nicht mehr mitdenke, nur noch stumpfsinning 
meine Punkte abarbeite und danach nach Hause gehe und mich mit letzter 
Kraft jeden Tag neu auf die Arbeit schleppe.

Vor 25 Jahren haben wir mit wenigen Leute Riesen-Projekte gestemmt oder 
zu zweit die komplette Steuergeräte-SW entwickelt (incl. 
Hardwareabsprache) ... wir machten HW, SW, System und wussten, dass das 
eine nicht ohne das andere laufen kann und kannte die ganze 
Funktionalität aus dem Kopf, weil das unser 'Kind' war.
Heute ist alles in einzelne Abteilungen aufgesplittet, weil ASPICE das 
verlangt und niemand fühlt sich verantwortlich.
30 Leute bekommen in 4 Jahren nicht die Arbeit (ok, damals gabs kein 
AUTOSAR und solchen Quatsch) hin, die wir damals in einem Jahr zu zweit 
gemacht haben.

Und welche Pfosten finden diesen 'modernen' Weg gut :
Die, die nach zig Jahren C-Programmierung Zeiger nicht benutzen, weil 
sie die nie richtig verstanden haben und auch privat nicht eine Minute 
programmieren oder gar mal irgendeine Hardware-Entwicklung gemacht 
haben.
Aber sagen wir müssen sofort alle Kraftwerke und den privaten 
Autoverkehr abschaffen und all solchen Schwachsinn ohne den Kopf vorher 
einzuschalten.

Noch Fragen ???
Schöne neue Welt (Aldous Huxley) lässt grüßen ... weiter so  X(

Nick M. schrieb:
> Aber Schneeflocken brauchen wohl eine Anleitung wie sie mit Kollegen
> umgehen sollen. "Kollegial" und "Zusammenarbeit" sind wohl völlig neue
> und unverständliche Begriffe für die.
>
> Kindergarten!

Zustimmung in den meisten Punkten.

Außer in einem:
Ich mach den Affenzirkus in den Firmen jetzt seit 25 Jahren mit, und 
gemeckert über die Jungen Leute wurde schon immer gleich viel. Wer 
behauptet, in seiner Firma wäre das besser, lügt. Dazu war ich schon in 
zu vielen Firmen, um das noch glauben zu können ;-)

Wir waren damals halt "die no future Generation", und "aus denen wird eh 
nie was".  Lieblingsspruch: "Nimm die Hände aus den Hosentaschen, sonst 
wachsen sie fest".

Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am 
Handy rumwischen.

Geändert hat sich tatsächlich fast gar nichts. Fakt ist, dass sich Leute 
kurz nach oder in der Pubertät für Arbeit nur selten begeistern können.

Name: schrieb:
> Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am
> Handy rumwischen.

Ja und nein. Ich versteh dich schon. Aber es gibt Leute die man mal 
schwach anreden kann ohne dass sie in Tränen ausbrechen. Sondern kurz 
nachdenken, lächeln und dann drauf reagieren. Zurücklächeln und damit 
ist das dann erledigt. Und das kenn ich auch so aus meiner "Jugend".

Achim H. schrieb:
> Du arbeitest also in mindestens drei (großen) Teams gleichzeitig:

Es ist ein Team an 2,5 Standorten ....
Eines der Scrums dauert alleine 30min ....

Unglaublich schrieb:
> Ich stehe nur gelangweilt daneben und überlege mir, wann ich wiedermal
> den Rasen mähen muss.
>
> Fehlt mir da ein Gen?

Nein, dir fehlt überhaupt nichts, geht mir genau so.

Ich wünschte Scrum würde bei uns "abgeschafft" werden. Ich weiß gar 
nicht warum man sich täglich 15min hinstellen muss und über das redet, 
was sowieso klar ist.

Ich mein wir sitzen alle im selben Raum und quatschen den ganzen Tag 
über die kack Software. Okay, ich gebe zu der PL weiß es nicht, aber 
muss der alles wissen?

Er steht trotzdem da und hört sich alles an. lol. Der PL!!! Man sieht 
deutlich welche Prioritäten er scheinbar hat. Egal. Ich stehe so da und 
erzähle meist mein JIRA-Ticket so, dass es ja keine Nachfragen gibt oder 
mir noch Hilfe angeboten wird.

"Ich bearbeite gerade JIRA-Ticket ABC, es geht um XYZ, ich werde 
voraussichtlich Freitag fertig und schnappe mir dann JIRA-Ticket DEF."

Schön unter dem Radar bleiben. Wie zu DDR-Zeiten Leute. ;-)

Matthias Döpke schrieb:
> Vor 25 Jahren haben wir mit wenigen Leute Riesen-Projekte gestemmt oder
> zu zweit die komplette Steuergeräte-SW entwickelt (incl.
> Hardwareabsprache) ... wir machten HW, SW, System und wussten, dass das
> eine nicht ohne das andere laufen kann und kannte die ganze
> Funktionalität aus dem Kopf, weil das unser 'Kind' war.
> Heute ist alles in einzelne Abteilungen aufgesplittet, weil ASPICE das
> verlangt und niemand fühlt sich verantwortlich.
> 30 Leute bekommen in 4 Jahren nicht die Arbeit (ok, damals gabs kein
> AUTOSAR und solchen Quatsch) hin, die wir damals in einem Jahr zu zweit
> gemacht haben.

Jaja frueher war alles besser.... NICHT! Ich kenne niemanden, der wieder 
gerne in den 90ern leben will. Da muss man schon von gestern sein. Mit 
so jemanden kann man auch nicht gut zusammenarbeiten, egal ob mit oder 
ohne Scrum.

PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger 
gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten 
und Wissen weiterzugeben. Nur armselige Wuerstchen behalten alles fuer 
sich und laestern dann in Online Foren.

BonusGekoppeltAnGewinn schrieb:
> PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger
> gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten
> und Wissen weiterzugeben.
Nein feuert die Person die solche Honks eingestellt hat.

> Nur armselige Wuerstchen behalten alles fuer
> sich und laestern dann in Online Foren.
Das sind Grundlagen, man keine Zeit denen das Laufen beizubringen, das 
lernt man in der Ausbildung/Studium. Wer solche Pfeifen einstellt gehört 
sofort gefeuert.

Jira ist der Vorhof der Hölle!

René H. schrieb:
> Wenn ich meine Tasks nicht in der "Estimated Time" abhandle werden
> Fragen gestellt.

Deshalb sollte man auch immer kräftig over-estimaten. Auch so eine 
Bewältigungsstrategie bei Diagnose Scrum

Joachim B. schrieb:
> Das Geld musste nur etwas mehr als reichen, solange ich damit gut lebte
> war es für mich OK. Nachteil reich bin ich nicht geworden, aber macht
> reich glücklich?

Nein, alleine nicht, aber man muss sich aufgrund seiner Passion trotzdem 
nicht ausbeuten lassen. Ich bin für gutes Geld für gute Arbeit (die auch 
Spaß machen darf), ich finde, das ist kein Widerspruch.

Jan H. schrieb:
> In der Realität konnte ich aber leider noch kein einziges echtes
> Scrum-Projekt beobachten. Denn die Methodik ist ja recht streng
> vorgegeben. Stattdessen werden meist die dysfunktionalen Prozesse
> umetikettiert

Oje, das Geschwafel eines Scrum-Fanboys.

So wie das Geschwafel eines Sozialismus-Funktionärs.

Merke: ein Verfahren, was nicht zur realen Welt passt, hat in der realen 
Welt nichts verloren. Das gehört höchstens in Märchenbücher.

René H. schrieb:
> Jan H. schrieb:
> Erbsenzählermethodik
>
> Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks
> nicht in der "Estimated Time" abhandle werden Fragen gestellt.

Estimated time einfach höher ansetzen.

René H. schrieb:
> Tja, das wird dann durch das Team angezweifelt: "Low Performer".
>
> Hmmmm....

Muss schon ein Scheiß team sein... Von meinem Team kommt höchstens dann 
beim Scrum planning Einspruch, wenn ich mich zu übernehmen drohe.

Auf einen gestressten Kollegen der das Verhältnis von eingeplanten zu 
erledigten User Stories ruiniert hat nämlich keiner Bock.

Das der Scrum master niemals selbst einschätzen kann wie groß ein 
einzelner Task ist ist jedem klar.

Daher immer niedrig ansetzen, bisschen Fachchinesisch hilft um die 
Aufgaben jede für sich wie eine praktisch unmögliche Aufgabe wirken zu 
lassen. Dann während des Sprints noch extra Aufgaben einbuchen, das 
macht Eindruck und man kriegt die Dinge die wirklich getan werden müssen 
am product owner vorbeigeschmuggelt.

BonusGekoppeltAnGewinn schrieb:
> Jaja frueher war alles besser.... NICHT! Ich kenne niemanden, der wieder
> gerne in den 90ern leben will. Da muss man schon von gestern sein. Mit
> so jemanden kann man auch nicht gut zusammenarbeiten, egal ob mit oder
> ohne Scrum.
>
> PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger
> gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten
> und Wissen weiterzugeben. Nur armselige Wuerstchen behalten alles fuer
> sich und laestern dann in Online Foren.

Vielen Dank für die lieben Worte ... ein netter Zeitgenosse :)

Ich nehme gerne Dinge an die Innovation und echte Vorteile bringen ... 
ich programmiere heute auch nicht mehr in Assembler ;)

Die Frischlinge sind leider keine, sondern teilweise (fast) mein Alter. 
Sie haben aber weder Ahnung von Software, noch Hardware ... meinen aber 
Prozesse und moderne Tools lösen alle Probleme von selbst.
Sie implementieren Code, ich teste den und gebe den wegen Fehlern 
zurück. Dann kommen solche Leute und möchten von mir möglich exakt 
wissen, wo sie was ändern müssen.
Hat nichts mit dem Thema zu tun ... aber komischerweise sind genau 
solche Pfeiffen die, die auf solchen modernen, unbrauchbaren Mist stehen 
und ganz toll finden (z.B. modellbasierte Entwicklung - ohne zu 
verstehen was die Blöcke im Hintergrund überhaupt genau tun).
Das sind auch die Mitarbeiter die als erste bei jeder Gelegenheit der 
Arbeit fernbleiben ...
Ich helfe gerne und gebe mein Wissen weiter, aber es gibt Menschen die 
sind einfach unbelehrbar ... ;)

Matthias Döpke schrieb:
> Noch Fragen ???

Eher nicht. Aber ich verstehe Dich vollkommen. Mein Beileid. AG Wechsel?

Name: schrieb:
> Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am
> Handy rumwischen.

Nette Geschichte: letzten Winter laufe ich hier durch die Stadt. Kaum 
Fußgänger unterwegs. Ich sehe so 40m vor mir einen Schulbub 
(Grundschule) auf mich zukommen. Gehweg war an der Stelle so 3-3,5m 
breit. Mitten auf dem Weg stand ein temporäres Strassenschild (die unten 
mit diesen Platten beschwert sind). Der Bub geht auf mich zu, guckt 
dabei nur auf sein Handy. Ich schaue nach unten, nach einigen Sekunden 
wieder nach vorne. Er sitzt hinter dem Schild auf dem Hosenboden, 
rappelt sich langsam auf und greift mit der rechten Hand an die Stirn. 
Ich musste acht geben, dass ich nicht losgelacht habe. Meine Eltern 
hätten gesagt: "Pass uff wo 'de hi'latschst!"

Tilo R. schrieb:
> Ihr seid das Scrum-Team - ihr könnt die Spielregeln ändern!

Typischer Bullshit.

In Realität wird dem Ganzen ein Manager oder eine andere Aufsichtsperson 
übergestülpt, die natürlich seine Existenz rechtfertigen muss, an seiner 
Karriere arbeitet und sich wichtig macht. So wild herumlaufende 
Programmierer ganz ohne Aufsicht können die meisten Firmen nicht ab.

Soll es in Scrum nicht geben? Ja, FML.
Ist nicht die Schuld von Scrum? Ja, FML.

Eine Methode, die nicht robust genug ist so etwas auszuhalten, und Scrum 
hält es nicht aus, ist nun mal scheiße.

> Grüne Häkchen für Vorgesetzte muss es im Sprint nicht geben. Die helfen
> nicht bei der Entwicklung.

Doch, die muss es geben, wenn der Chef sagt es muss sie geben.

> Wenn ein Vorgesetzter während des Sprints
> quengelt - schickt ihn zum Scrum-Master oder PO.

Ha, ha, ha. Der Begriff "abhängiger Beschäftigter" sagt dir was?

> Wofür gibt es diesen
> Proxy?

Damit zwei Leute mehr schönen Ehrentitel haben und von einer Karriere 
träumen können.

> Klar kann der Scrum-Master auch einen Burndown-Chart malen und grüne
> Häkchen reporten. Das ist aber keine Aufgabe fürs Daily, das kann er
> ganz allein machen.

Dann müsste er ja mal selber arbeiten und denken. Ist doch viel 
einfacher dass das Team "mal schnell" unter Aufsicht des Scrummasters 
malt und Häckchen macht. Das spart dem Scrummaster noch dazu den Aufwand 
die Ergebnisse separat im Team zu kommunizieren. War ja jeder dabei und 
"involved".

Unglaublich schrieb:
> endwiggler schrieb:
>> Dann sind die Scrummaster zufrieden, dass ich selbst einen
>> längerfristigen Plan verfolge muss der nicht wissen.
>
> Uhuh, ganz ganz schlechte Teammoralbildung. Vielleicht solltet ihr mal
> häufiger zusammen in der Kantine Mittagessen gehen oder abends noch in
> der Firma am Kicker fachsimpeln.

Genau, Abends am Kicker. Warum nicht gleich auf die Familie scheißen und 
direkt neben, oder besser, in die Firma einziehen.

Sys schrieb:


Das sollte SysIngMue heißen.

René H. schrieb:
> Jan H. schrieb:
>> Erbsenzählermethodik
>
> Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks
> nicht in der "Estimated Time" abhandle werden Fragen gestellt.

Und? Dann beantwortest du die Frage eben. Oder fehlen dir die Cojones, 
um zu sagen "ich hab mein Arbeitspensum leider nicht fertig gekriegt 
wegen XYZ"?
Genau dieses Feedback ist der Sinn der Retrospektive, um mit der Zeit 
die Abschätzungen zu verbessern.
Und stell dir vor, das hat auch nix mit Scrum zu tun, derartiges 
Feedback macht auch ohne Scrum Sinn. Woher soll der Vorgesetzte oder der 
Rest des Teams denn sonst wissen, dass es irgendwo hakt?

René H. schrieb:
> Tja, das wird dann durch das Team angezweifelt: "Low Performer".

Tja, wenn du dich durch sowas fertig machen lässt... Wahrscheinlich 
verschweigst du auch immer schön, wenn du hinter dem Zeitplan bist, und 
kompensierst das dann durch kräftig Überstunden, denn der Projektleiter 
darf ja auf keinen Fall mitkriegen dass der Zeitplan zu eng war? Sehr 
gut, denn dann wird er ihn beim nächsten mal gleich noch enger 
gestalten, denn es hat ja funktioniert.

Michael Gugelhupf schrieb:
> Tilo R. schrieb:
>> Ihr seid das Scrum-Team - ihr könnt die Spielregeln ändern!
>
> Typischer Bullshit.
>
> In Realität wird dem Ganzen ein Manager oder eine andere Aufsichtsperson
> übergestülpt, die natürlich seine Existenz rechtfertigen muss, an seiner
> Karriere arbeitet und sich wichtig macht. So wild herumlaufende
> Programmierer ganz ohne Aufsicht können die meisten Firmen nicht ab.
>
> Soll es in Scrum nicht geben? Ja, FML.
> Ist nicht die Schuld von Scrum? Ja, FML.

"Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut, 
deswegen ist Scrum kacke!!1elf"

Sounds legit.

René H. schrieb:
> Joachim B. schrieb:
>> Hugo H. schrieb:
>>> (O.K. ich tue gerne, wofür ich bezahlt werde)
>
> Unrecht hat Hugo aber nicht. Ich programmiere seit ich 12 bin. Es ist
> eine Leidenschaft und deshalb mache ich das auch heute noch gerne (fragt
> nicht wie lange das her ist :-)).
> Es sind die Umstände die einem das madig machen, nicht nicht die Sache.
>
> Darauf war ich ehrlich gesagt nicht vorbereitet. Jetzt ist es halt so.
> Ich zieh das noch ein paar Jahre durch bis ich es mir leisten kann in
> Rente zu gehen (oder ausgemustert werde, was wahrscheinlicher ist).

Entwickler die Entwicklen mit Basteln verwechseln ist die Spezies, die 
in Firmen den größten Schaden anrichten. Das sind zwei völlig 
verschiedene Dinge.

Da kommt meist nichts dabei raus.

Das sind dann die "tollen" "Programme" für die es keine Doku gibt, 
keinen Projektplan, keine Tests und die massig Bugs enthalten. Weil 
"Programmieren ja soviel Spass macht", lässt man den "lästigen Beikram" 
weg oder die Kollegen machen. Dass Softwareentwicklung mit Programmieren 
wenig zu tun hat, wissen solche Bastler oft nicht.

Bin Hardwerker, aber auch hier gibts diese Spezies.
Auch ich bastle in der Freizeit an Elektronik rum. Die Tätigkeit hat mit 
Hardwareentwickeln nur wenig gemeinsam.
Wenn doch: Herzliches Beileid für die Kollegen :-(

vn nn schrieb:
> "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut,
> deswegen ist Scrum kacke!!1elf"

Nein, Scrum ist kacke, weil Scrum nicht robust ist und in einer nicht 
100% idealen Umgebung sofort zusammenbricht.

> Sounds legit.

Wie alt bist du? 12?

Scrum wurde von China oder den USA erfunden um uns
endgültig zu ruinieren. Mein Arbeitgeber hat es auch
eingeführt, seitdem kommt nixhts mehr raus .....

Name: schrieb:
> Das sind dann die "tollen" "Programme" für die es keine Doku gibt,
> keinen Projektplan, keine Tests

Klingt wie die allseits bei Kunden und Chefs beliebten schnell 
erstellten Prototypen.

Es kann gar nicht schnell genug gehen.

Und meistens bliebt es dann beim Provisorium, denn für alles andere ist 
ja kein Geld da, läuft a, irgendwie.

Es ist nicht der basteldnde Entwickler, der so geil darauf ist.


Und gerdae Scrum manifestiert diese (Fehl-)Entwicklung: im ersten Sprint 
den Prototypen und dann kontinuierlich 'verbessern'.

Stichwort "Agiles Theater"!

MaWin schrieb:
> Und meistens bliebt es dann beim Provisorium, denn für alles andere ist
> ja kein Geld da, läuft a, irgendwie.

Bei den Scrumprojekten werden dann solange die Anforderungen runter-
geschraubt bis ein "minimal verkaufsfähiges Produkt" entsteht.
Hab ich alles schon erlebt.

Herrlich, dass auch viele andere so denken, wie ich :)

Udo S. schrieb:
> Eins unserer Scrum Teams bastelst schon seit eineinhalb Jahren an so
> einem "minimal viable system" herum, das der Nachfolger eines von 4

Ich kenne das !

Da sollte etwas ersetzt werden, im Endeffekt konnte das neue
nicht einen Bruchteil des Altsystems. Damit fahren die Burschen
dann auch noch zu einem Keykunden, der hat sie zum Glück raus-
geschmissen.

Aber immerhin ist das ganze mit agilen Methoden entwickelt.

Bei meinem Arbeitgeber läuft das nur noch so. Nichts kommt mehr
raus.....

Udo S. schrieb:
> hbl schrieb:
>> "minimal verkaufsfähiges Produkt"
>
> Nennt sich "minimum viable product"

Nein, minimum marketable product. Minimum viable product ist das 
mindeste was man dem Kunden für eine erst evaluation in die hand drücken 
kann um festzustellen ob es in die richtige Richtung geht.

Michael B. schrieb:
> aber inzwischen wurden alle
> Anforderungen gestrichen, man ist froh wenn er dasselbe kann und nicht
> langsamer läuft), der damals (vor 2000) in 2 Jahren von 2 Leuten ohne
> Scrum realisiert wurde und sich seit dem gut verkauft.

Ich hab geschafft und du bist nix Mentalität. Immer die gleiche Leier.
Echt amüsant die Diskussion zu verfolgen, wobei etliche Klischees 
erfüllt werden.

Jungs, setzen 6;-9

soso schrieb:
> Ich hab geschafft und du bist nix Mentalität.

Und ?

So ist die Welt.

Einige können es, und Andere können eben nix.

Deine Mentalität ist:

"Wenn man es nur hart genug anstrengt,
gibt es Nichts, was man nicht erreichen könnte ?

Bullshit, passend zum Bingo.

soso schrieb:
> Ich hab geschafft und du bist nix Mentalität.

Es gibt überall bessere und schlechtere Leute.
Sicherlich auch bessere als man selbst ....

Aber wenn gerade Leute die noch nicht einmal herkömmlich vernünftig 
arbeiten können, meinen mit neuen Techniken und Tools könne man fehlende 
Kenntnisse (manchmal sogar Basics) und Fähigkeiten wettmachen, irren sie 
gewaltig.

Wenn man Scrum wenigstens sinnvoll anwenden würde, aber damit nur Zeit 
totzuschlagen und Motivation von Mitarbeitern zusätzlich zu rauben, 
macht keinen Sinn.
Oft sind es halt nicht die Leute die gut führen und vernüftig und 
zielstrebig arbeiten die so etwas einführen oder/und leiten, sondern 
genau die anderen.

Darum ging es in diesem Blog ... und offenbar stimmen die meisten der 
Poster in der Meinung überein - was natürlich nicht repräsentativ ist ;)

hbl schrieb:
> endgültig zu ruinieren. Mein Arbeitgeber hat es auch
> eingeführt, seitdem kommt nixhts mehr raus .....

Scrum-Guru:"Ja dann macht ihr es nicht richtig!!! Ich kenn mich aus!"

Ist das selbe Geschwätz wie beim "Kein Wahrer Schotte":
https://de.wikipedia.org/wiki/Kein_wahrer_Schotte

Ich war mal kurz in einer kleine Firma, da gab es mehr 
Projektentwickler/leiter, Scrum-Master, Product-Owner, 
Schwaller-Priest,...  als reine Entwickler. Drei Entwickler, ein Student 
der seine Abschlussarbeit dort machte, ein Azubi und eine Teilzeitfrau 
die ich nie gesehen habe, die hat glaube ich Design oder sowas gemacht, 
GUIs aufgemöbelt, Icons gemalt.

Von den Dampfplauderern gab es mind. 12. Z.t. waren mehre owner des 
selben products. Der Eine von denen (der war zertifizierter Scrotum 
Master) konnte gut den Chef beschwatzen, dass noch mehr solche Kasper 
gebraucht würden und der nach und nach seine ganzen Kumpels dadurch in 
dem Laden installiert hat.

Ich war dort nicht mal ein Monat. Einer dieser Schwätzer ist ja schon 
schlimm aber wenn die du die im Rudel den ganzen Tag um dich rum hast, 
da drehste durch. Das ist wie im Kindergarten, malen nach Zahlen, 
Software entwickeln mit Scrum.

Sprint, daily, product owner, user story, backoffice,... immer wenn ich 
diese Begriffe höre zucke ich sofort zusammen und muss an diese Firma 
denken.

Dick Boutsos schrieb:
> Von den Dampfplauderern gab es mind. 12. Z.t. waren mehre owner des
> selben products. Der Eine von denen (der war zertifizierter Scrotum
> Master) konnte gut den Chef beschwatzen, dass noch mehr solche Kasper
> gebraucht würden und der nach und nach seine ganzen Kumpels dadurch in
> dem Laden installiert hat

Das ist heutzutage leider üblich geworden! Waren früher die 
Fertigungsleute die Arbeitshuren die man ausbeuten musste sind es heute 
die Programmierer!
Diese sogenannte Networking ist eine massive Seuche für die, die noch 
etwas leisten und für den Betrieb sowieso! Fakt ist, mit Bullshitbingo, 
Networking und viel Geschwafel geht es die Erfolgsleiter nach oben! Wer 
nicht mitspielt hat schon verloren! Oben angekommen ist der Erfolg der 
Firma bzw. der Arbeitsweise egal, geht man halt woanders hin!
Dieser Wahnsinn hat system! Zack ist die nächste Firma am Abgrund!
Leider nicht so schnell, daß es sich rumspricht, aber dennoch real!
Die größten Posauner mit der niedrigsten Kompetenz in den wichtigsten 
Belangen zeigen, wo es lang geht!
Leider habe ich wohl ein Zuviel an Kompetenz, und zuwenig Dummschwätz... 
deshalb komm ich übers Brötchenbacken auch nicht hinaus!

Tilo R. schrieb:
> Oder was macht man da, wenn zu einem späteren Zeitpunkt noch
> Requirements dazukommen?

Eine neue Rechnung an den Auftraggeber schreiben, was sonst ?

René H. schrieb:

> Neue Requirements bedeuten in jedem Modell dass selbe.
> Änderungen. Das kann Agile nicht besser und nicht
> schlechter auffangen als andere Modelle.

Vielleicht solltest Du mal mit Deiner alten Tradition
brechen und DOCH mal einen Blick in ein Buch werfen.
Das "Agile Manifest" würde sich eignen.

Udo S. schrieb:

> Der Hinweis auf Religionen in dem Wikipedia Artikel
> passt gut. Ich glaube SCRUM ist so ein bischen was
> wie eine Religion für manche.

Ich fühle mich eher an den Marxismus erinnert... oder
nehmen wir besser Cholesterin, das ist (scheinbar!)
nicht so politisch: Ancel Keys hat seinerzeit eine
Korrelation zwischen Cholesterinspiegel und Herz-
infarktrate gefunden und dieses Ergebnis publiziert.

Prompt kamen die Marktschreier und behaupteten:
"Cholesterin löst Herzinfarkte aus!" Millionen Menschen
quälten sich mit cholesterinarmer Ernährung, obwohl die
Chemiker WISSEN , dass der Cholesterinspiegel nur
minimal von dem mit der Nahrung aufgenommenen Cholesterin
abhängt -- das meiste produziert der Körper selbst.

Cholesterinsenker sind ein RIESIGER Markt, damit werden
jedes Jahr Milliarden gescheffelt. Dumm nur, dass bisher
niemand wirklich zuverlässig weiss, wovon der körper-
eigene Cholesterinspiegel abhängt und was ein Eingriff
von außen bewirkt. (Es gab beispielsweise Studien, die
einen Zusammenhang zwischen zu niedrigen Cholesterin-
spiegel und Demenz nahelegen.) Trotzdem werden fleissig
Cholesterinsenker verschrieben...

Und das Schlimmste: Außer ein paar akademischen Gehirn-
wichsern interessiert sich NIEMAND dafür, was Keys
wirklich geschrieben hat -- denn gerade, wenn er sich
geirrt hat, sollte man ihm nur das als Irrtum anlasten,
was er tatsächlich behauptet hat, und nicht das, was
ihm von seinen unkundigen Jüngern angedichtet wurde...

Johannes F. schrieb:

> Ist klar, dass sich die Anforderungen ändern, sei es
> weil das Projekt innovativ ist, so das der Kunde/die
> Nutzer erst beim Testen wirklich merken was sie
> (anders) wollen oder so lang läuft, dass klar ist,
> dass die Rahmenbedingungen sich ändern (irgendwas
> Konzernweites, Projekt über Jahre. Da ist klar, das
> zwischendurch sich 48 juristische Rahmenbedingungen
> ändern, 12 Firmen integriert und abgestoßen werden
> und das "irgendwie" die Anforderungen beeinflusst),
> dann kann agil sinnvoll sein.

Du sprichst hier nebenbei aus, was ungefähr 90% der
Kritiker hier in A,S&B ihr Leben lang ein Geheimnis
bleiben wird: Es ist ein intrinsisches Merkmal eines
Projektes, dass am Anfang ein Wissensdefizit vorliegt.
Genau das Wissensdefizit ist es, was ein Projekt zum
Projekt macht -- wüsste man am Anfang schon alles,
wäre es ein einfacher Auftrag.

Dick Boutsos schrieb:
> Von den Dampfplauderern gab es mind. 12. Z.t. waren mehre owner des
> selben products. Der Eine von denen (der war zertifizierter Scrotum
> Master) konnte gut den Chef beschwatzen, dass noch mehr solche Kasper
> gebraucht würden und der nach und nach seine ganzen Kumpels dadurch in
> dem Laden installiert hat.

Das ist aber kein SCRUM-Problem. Solche Schwätzer haben wir hier auch. 
Nennt sich "Innovationsabteilung".

Deren "geniale Ideen" dürfen normale Entwickler nicht kritisieren oder 
kommentieren, denn Cheffe hat sich dort als Teamleiter dort installiert 
und fasst Kritik entsprechend als persönlichen Angriff auf. Er liebt 
Selfies vor Patantanträgen, die öffentlich aushängen. Keine einzige der 
"Innovationen" jemals zu einem Produkt geführt. Seit 5 Jahren nur teures 
Scheitern, oft an der Physik. Wenn nich daran, dann daran, dass deren 
Schmarrn viel zu teuer ist.

Die haben 5(!) Jahre lang keine, aber auch gar keine einzieg Idee 
irgenwie in ein Produkt überführen können. Nichts. Da wird nichts davon 
verkauft. 0,000€ verdient, Millionen ausgegeben. Inzwischen dürfen sie 
glücklicherweise kein Geld mehr ausgeben, oder sonstige Ressourcen 
nutzen. Irgendwer hat also was gemerkt. Langsam wird man dort sichtlich 
nervös.
Ich fürchte schlimmes, den Cheffe wird die Leute vermutlich in die 
Entwicklung drücken, und wir müssen die mitziehen. Darum wälze ich schon 
Stellenazeigen.

--> Die Schwätzerseuche ist ein größeres Problem in der Wirtschaft, als 
der Wandel in der Fahrzeugindustrie je sein könnte...
--> Für heutige Chefs zählt oft nur Geschwätz. Leistung ist irrelevant. 
Traurig.

Jan H. schrieb:

> Johannes F. schrieb:
>> Habe ich ein Projekt, wo die Anforderungen wirklich
>> bekannt sind (z.B. Programmierung der Steuerung einer
>> "konventionellen" Waschmaschine), ist was agiles
>> einfach dämlich.
>
> Warum? Wenn du das agile Manifest liest ist die
> Änderung von Anforderungen nur ein kleinerer Teil
> der Idee.

... aber m.E. der entscheidende.


> Wenn die anderen Rahmenbedingungen passen kann Scrum
> auch bei Projekten mit vollständig bekannten
> Anforderungen sinnvoll sein. Vielleicht möchte sie
> Hardwareentwicklung ja eine lauffähige Zwischenversion
> haben um das Schleudern oder EMV zu testen.

Ich würde zwischen "iterativ" und "agil" unterscheiden.
Iteratives Vorgehen ist praktisch immer sinnvoll (siehe
Winston W. Royce: "Do it twice"). Dass Agilität bei
vollständig bekannten Anforderungen sinnvoll sein soll,
erschließt sich mir erstmal nicht.

Kann mal endlich jemand diesen unredlichen Thread löschen? Hier wird 
aktiv Werbung gegen Scrum gemacht, was ich nicht in Ordnung finde. 
Immerhin hat sich diese agile Arbeitsmethode weltweit mit großen Erfolg 
durchgesetzt. Ewig gestrige Schwätzer sollen sich halt ein anderes 
Tätigungsfeld suchen.

Ich gehe doch mal stark davon aus, dass auch die Forumleitung im Stile 
von Scrum organisiert ist. Wurde die Löschung schon im Backlog vermerkt?

Bitte zu machen und löschen, danke.

Scrummaster schrieb:
> Kann mal endlich jemand diesen unredlichen Thread löschen? Hier wird
> aktiv Werbung gegen Scrum gemacht, was ich nicht in Ordnung finde.
> Immerhin hat sich diese agile Arbeitsmethode weltweit mit großen Erfolg
> durchgesetzt. Ewig gestrige Schwätzer sollen sich halt ein anderes
> Tätigungsfeld suchen.

Krieg, Landmienen, Folter und Krankheit haben sich auch weltweit 
durchgesetzt und sind erfolgreich...

Scrummaster schrieb:
> Ich gehe doch mal stark davon aus, dass auch die Forumleitung im Stile
> von Scrum organisiert ist. Wurde die Löschung schon im Backlog vermerkt?

Siehe oben...Was mir gerade klar wird, der Tenor ist:

René H. schrieb:
> Das ist kein Klagen, dass ist eine Kritik an der Methode und wie sie
> verwendet wird!

vn nn schrieb:
> um mit der Zeit die Abschätzungen zu verbessern

Während mwn beum Hausbau weiss,  wie lange es dauert Stein auf Stein zu 
stellen, ist eine Fehlersuche eben eine Suche.
Gib mir deine Abschätzung wie lange du brauchst, die Nadel im Heuhaufen 
zu finden.

vn nn schrieb:
> "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut,
> deswegen ist Scrum kacke!!1elf"

Ewiges wiederholen macht den Satz nicht richtiger. Wenn du nur richtig 
tief religiös bist, wird Gott dich von Krwbs, Vorona und Dummheit 
heilen, bete mehr.

Udo S. schrieb:
> Und eben die Tatsache das SCRUm massiv dazu genutzt wird Druck
> aufzubauen um mehr Leistung aus den Leuten zu quetschen
Ob mit oder ohne SCRUM:
Wenn Dein Kollege den Job sauber in der Hälfte der Zeit schafft, dann 
sollte Dir das zu denken geben.
Aber meist sind es doch nur die Dummschwätzer, denen ihr Code nach einer 
statt drei Wochen Arbeit beim ersten Start um die Ohren fliegt. Von 
denen muss man sich nicht drängen lassen.

Wir sind in einem Projekt auch agil unterwegs. In meinem SW-Subteam 
leben wir das nicht mehr wirklich, da es doppelte Arbeit ist. 
Detaillierte Planungen und Regelmeetings im Team und mit anderen 
Parteien werden weiterhin benötigt, um Prozessforderungen (intern und 
von den Kunden) zu erfüllen.

Ich habe in zwei aufeinanderfolgenden Demos (3 Wochen dazwischen) mal 
den Versuch gemacht, genau die gleichen Ergebnisse zu präsentieren (auf 
Grund anderer Themen war tatsächlich auch kein Fortschritt da, aber das 
habe ich verschwiegen).
Das wurde von den Product Ownern aber nicht bemerkt - beim zweiten mal 
wurde ich sogar noch für den Fortschritt gelobt ^^

Agiler schrieb:
> Das wurde von den Product Ownern aber nicht bemerkt - beim zweiten mal
> wurde ich sogar noch für den Fortschritt gelobt ^^

Genau dazu habe ich mal eine Frage:

SCRUM ist ja mit der Zielsetzung angetreten, möglichst früh Ergebnisse 
beim Kunden abzuliefern. Sprints sind ja auch nicht dazu da, schneller 
zu arbeiten, sondern kleinere Ergebnisse möglichst früh dem Kunden 
vorzulegen, damit der zeitnah eingreifen und lenken kann.

Aber wie sieht das in der Realität aus? Sind die Verantwortlichen beim 
Kunden wirklich so realitätsnah und wissen, was gebraucht wird? Oder 
sind das auch nur Frackträger, deren Terminplan noch die nötigen Lücken 
für die Besprechungen aufweist.

Kurz: Wird der Kunde beim Einfangen seiner eigenen Anforderungen durch 
SCRUM real erfolgreicher?

Udo S. schrieb:

> Egon D. schrieb:
>> Ich fühle mich eher an den Marxismus erinnert... oder
>> nehmen wir besser Cholesterin, das ist (scheinbar!)
>> nicht so politisch:
>
> Dein Beispiel passt ganz gut. SCRUM als Idee ist ja nicht
> das Problem, im Endeffekt unterscheidet es sich nicht so
> viel von guten Projekten die ich erlebt habe bevor hier
> irgendwer SCRUm kannte.

Ja, klar, aber...


> Mich nervt nur das starre Konzept das drüber gestülpt
> wird, was dazu führt dass zumindest ein Teil der Leute
> Scheuklappen aufsetzt.

...das "starre Konzept" ist ein intrinsisches Problem,
das jeder agilen Methodik -- und jeder Projektmethodik
überhaupt -- innewohnt: Man versucht, das, was gute Leute
intuitiv können und richtig machen, explizit als Regelsatz
zu formulieren.

Wenn jetzt ein Anfänger diese Regeln liest, ohne den
Erfahrungshintergrund dazu zu kennen, kommt natürlich
Mist heraus, weil er sich an formalen Details aufhängt
und das Prinzip dahinter nicht versteht.

Dazu kommt noch, dass die Erfinder der Agilität m.E.
die Interessenkonflikte zwischen Management, Projekt-
leitung und Indianern ziemlich blauäugig behandeln.


> Wenn ich sehe dass ein Team hier 3 Tage munter
> weiterentwickelt, obwohl klar ist daß sich eine
> wesentliche Anforderung geändert hat, weil man ja
> "mitten im Sprint" ist, und da keine Änderungen
> erlaubt sind, dann frage ich mich wohin das Hirn
> verschwunden ist.

Naja, das sehe ich nicht ganz so. Ist ein weites
Feld.


> Und eben die Tatsache das SCRUm massiv dazu genutzt
> wird Druck aufzubauen um mehr Leistung aus den Leuten
> zu quetschen und die Verantwortung bei Problemen von
> oben nach unten zu schieben.

Richtig -- das ist der eigentlich ärgerliche Punkt. Die
agile Gilde muss sich den Vorwurf gefallen lassen, dass
sie dieses Problemfeld unterschätzt hat.

René H. schrieb:

> Egon D. schrieb:
>> René H. schrieb:
>>
>>> Neue Requirements bedeuten in jedem Modell dass selbe.
>>> Änderungen. Das kann Agile nicht besser und nicht
>>> schlechter auffangen als andere Modelle.
>>
>> Vielleicht solltest Du mal mit Deiner alten Tradition
>> brechen und DOCH mal einen Blick in ein Buch werfen.
>> Das "Agile Manifest" würde sich eignen.
>
> Ha! Du wirst es nicht glauben, ich bin sogar zertifizierter
> Scrum Master.

In der Tat: Das glaube ich wirklich nicht! :)

Der praktische Unterschied zwischen einem einfach nur
iterativen Vorgehen und einer agilen Vorgehensweise ist
ja GERADE der, dass die schrittweise Annäherung AUCH
die Anforderungen einschließt und also den Kunden
einbezieht.

Die agile Methodenwelt ist ja eine Reaktion auf die
Erfahrungstatsache, dass späte Änderungen eben NICHT
vollständig vermeidbar sind -- also versucht man, den
Spieß umzudrehen: Wenn Änderungen ohnehin nicht vermeidbar
sind, dann richten wir all unsere Arbeitsabläufe darauf
aus, dass wenigstens die Kosten für diese Änderung
möglichst niedrig bleiben.

Dass das als Einladung zum Missbrauch aufgefasst werden
kann, hatten die Vordenker der Agilität wohl nicht aus-
reichend auf dem Schirm...

Udo S. schrieb:
> Mich nervt nur das starre Konzept das drüber gestülpt wird, was dazu
> führt dass zumindest ein Teil der Leute Scheuklappen aufsetzt.
> Wenn ich sehe dass ein Team hier 3 Tage munter weiterentwickelt, obwohl
> klar ist daß sich eine wesentliche Anforderung geändert hat, weil man ja
> "mitten im Sprint" ist, und da keine Änderungen erlaubt sind, dann frage
> ich mich wohin das Hirn verschwunden ist.

Die Frage ist völlig berechtigt. Hirnmangel oder Lesemangel. Man kann 
einen Sprint auch mittendrin einfach abbrechen. Formal können das zwei 
Spieler:

1) Der PO bricht den Sprint ab weil das Ziel des Sprint obsolet ist.

2) Der Scrummaster bricht im Namen des Teams den Sprint ab weil das Team 
von irgendwas die Schnauze voll hat.

Die dritte Variante ist nicht offiziell:

3) Das Team bricht den Sprint unter Umgehung des Scrummasters ab weil es 
von irgendwas und dem Scrummaster die Schnauze voll hat.

Natürlich wird das alles in der Praxis nicht gemacht. 1) bedeutet der PO 
muss verstehen was seine Rolle ist und Verantwortung übernehmen, nicht 
zuletzt für die Zusatzkosten und die verschwendete Arbeit die der 
Abbruch und die radikale Änderung der Anforderung mit sich bringt. Statt 
dessen mogelt sich der PO lieber durch um beim Chef nicht blöd 
dazustehen.

2) und 3) entspricht einem kleinen Streik, einer Arbeitsverweigerung. 
Dann bricht das ganze Kartenhaus um das Scrumteam zusammen, von wegen 
selbstorganisierend und alle Freiheiten. Dann werden Leute auf höheren 
Hierarchieebenen richtig böse. Wer zahlt bestimmt die Musik und das ist 
letzten Endes nicht das Scrumteam.

So bricht Scrum dann mal wieder in der harten Realität des Arbeitslebens 
zusammen.

Nebenbei bemerkt, der hier herum turnende zertifizierte(!) Scrummaster 
hätte Antwort 1) und 2) sofort geben müssen. Das sollte er auf der 
Schule für kleine Scrummaster gelernt haben.

Ach ja, Agile und Scrum.

Das Interessante ist, das bei meinem ehemaligen AG (Ausland, 20 
hochqualifizierte Tech-"Bros", 2 Produktmanager, die selber 
Vollblutingenieure waren) völlig ohne Kotzen und relativ effizient 
funktioniert. Wenig Verwaltungsoverhead, konzentriertes Arbeiten. "Agile 
Light" funktioniert ganz gut.

Nun habe ich hier im Team (1 Dutzend) einen Agile-"Coach" und einen 
nicht-technischen PM sowie PO. 120% Scrum. Alle 2 Wochen: 4x2h 
Scrum-"Zeremonien" und 1x1h Inter-Team-"Review", dazu jede andere Woche 
2x2h "Refinement" und 5x0.5h "Daily" sowieso.

Da wird dann sinnlos an Tickets rumgeschnitzt nach dem Motto "1 
Arbeitspaket von 12h lässt sich in 3 Arbeitspakete zu 4h unterteilen, 
die von verschiedenen Leuten bearbeitet werden, lasst uns das jetzt 
kleinlabern und dann von Leuten, die keine Ahnung haben und nicht am 
Thema interessiert sind, schätzen lassen".

Bis heute haben die nicht verstanden, dass ein wertschöpfender 
Entwicklungstask von 6h bei Unterteilung in 2x3h mindestens 8h dauert 
und dass somit prinzipiell mit Schnipseltickets alles länger dauert als 
die Summe der "Storypunkte" vermuten ließe.

Und dann wundern sie sich, wenn die Monate ins Land gehen.

Egon D. schrieb:
>> Und eben die Tatsache das SCRUm massiv dazu genutzt
>> wird Druck aufzubauen um mehr Leistung aus den Leuten
>> zu quetschen und die Verantwortung bei Problemen von
>> oben nach unten zu schieben.
>
> Richtig -- das ist der eigentlich ärgerliche Punkt. Die
> agile Gilde muss sich den Vorwurf gefallen lassen, dass
> sie dieses Problemfeld unterschätzt hat.

Läuft doch alles nach Plan. Agile wurde zuerst dem Management verkauft 
und dann unter die Leute gebracht.

Framulestigo schrieb:
> SCRUM ist ja mit der Zielsetzung angetreten, möglichst früh Ergebnisse
> beim Kunden abzuliefern. Sprints sind ja auch nicht dazu da, schneller
> zu arbeiten, sondern kleinere Ergebnisse möglichst früh dem Kunden
> vorzulegen, damit der zeitnah eingreifen und lenken kann.
>
> Aber wie sieht das in der Realität aus?

Meiner Erfahrung nach sehr sehr mau. Es mag in anderen Firmen, in 
anderen Branchen Kunden geben die das Spiel mitmachen. Der Kunde will 
sich doch gar nicht ständig mit der Softwareentwicklung befassen. Wollte 
er das würde er die Software selber entwickeln, nicht kaufen.

Wer soll denn jede Woche vom Kunden aus die letzten Entwicklungen 
begutachten (Demo)? Ein teurer Manager? Der hat doch keine Ahnung. Der 
weniger teure Spezialist, der dann jede Woche einen Tag ausfällt? Der 
Praktikant, der billig ist aber nicht weiß was benötigt wird?

> Sind die Verantwortlichen beim
> Kunden wirklich so realitätsnah und wissen, was gebraucht wird?

Wer weiß was gebraucht wird hat häufig nicht die Verantwortung. 
Entscheidungen behält sich das Management vor, besonders solche, die 
Geld kosten.

> Oder
> sind das auch nur Frackträger, deren Terminplan noch die nötigen Lücken
> für die Besprechungen aufweist.

Nein, weil der Kunde nicht gar nicht erst kommt. Egal ob Manager, 
Spezialist oder Praktikant.

> Kurz: Wird der Kunde beim Einfangen seiner eigenen Anforderungen durch
> SCRUM real erfolgreicher?

Wenn er mitspielen würde vielleicht.

Was funktioniert ist eine Art gemeinsame Entwicklung. Das ist ein altes 
Konzept noch aus XP-Zeiten, der On-Site Customer. Scrum hat sowieso die 
Hälfte von XP (schlecht) kopiert.

Der Kunde stellt für die Entwicklung einen Mitarbeiter (Spezialisten) 
ab, der Teil des Entwickler-Teams wird. Es muss aber wirklich ein 
Spezialist sein, nicht der Praktikant.

Wenn das Interesse der beteiligten Firmen groß genug ist, z.B. ein 
gemeinsames Produkt zu dem die Software gehört, dann funktioniert das. 
Ansonsten scheitert auch das.

Bin vom Entwickler zum Product Owner "aufgestiegen" und grundsätzlich 
funktioniert es ganz gut bei uns. In den Sprints arbeiten die Entwickler 
eigenständig ihre Tasks ab.
Daily Standups gibt und gab es bei uns sowieso schon immer, da wir eine 
aktive "Kaffeekultur" haben...

Grundsätzlich bin ich als PO für die technische Entwicklung voll 
verantwortlich. Ich behalte den Überblick, kenne die Architektur und 
bereite das Backlog vor. Die Kommunikation mit dem Kunden und 
Anforderungen übernimmt zu 2/3 der Produkt Manager, der mich dann bei 
Bedarf mitnimmt.

Es gibt bei uns alleridngs aus Prozessgründen auch Projektmanager, die 
kümmern sich allerdings nicht um technische Details der Entwicklung, 
sondern um die Planung der Auslieferungen, Inbetriebnahmen, 
Vertragsdetails... von denen kommt dann als Rückmeldung zum PM und PO, 
dass Kunde X eine Anlage zum Zeitpunkt Y bekommt und diese Features 
(bzw. diese Version) von der Software dort eingesetzt werden soll.

Ich denke es gibt ein paar "Fallen", in die traditionelle 
Projektmanager, die Mikromanagement bis ins kleinste Detail 
perfektioniert haben, treten und damit dann Scrum aktiv zerstören (ist 
dann aber Quatsch, dass Scrum dann nicht robust genug ist -> jeder 
Prozess kann aktiv zerstört und umgangen werden)

- Das Team muss selbstorganisiert sein: Ich als PO "assigne" nicht 
direkt Tasks bzw. nur in Ausnahmefällen (dringender Bug). In den 
Planning Meetings kommt vom Team die Rückmeldung, wer was macht, wenn 
ich das Backlog für den Sprint zeige. Bei uns hat sich das sowieso schon 
eingespielt, da die Entwickler natürlich Spezialisierungen haben und der 
eine oder andere immer Tasks in diese Richtung macht.
- Überplanung der Backlog-Items: Ich schreibe in die Backlog-Items, was 
ich am Ende "in der Hand haben will". Den Lösungsweg muss der Entwickler 
bringen. Im klassischen PM kommt der Lösungsweg oft "von oben" und der 
Entwickler muss es dann auf die Spezifikation genau umsetzen. Das geht 
gegen den Gedanken von Scrum.
- Nach jedem Sprint muss die Software/Hardware ein Stück weiter sein: 
Das Backlog für einen Sprint muss so aufbereitet sein, dass nach dem 
Sprint die Software "ein wenig mehr" an Funktionalität hat, als davor. 
Das ist die Aufgabe vom PO, das sicher zu stellen.

Wenn diese drei Merkmale nicht erfüllt sind, dann kann man wohl wirklich 
von "bullshit-bingo" sprechen...

PO schrieb:
> Grundsätzlich bin ich als PO für die technische Entwicklung voll
> verantwortlich. Ich behalte den Überblick, kenne die Architektur und
> bereite das Backlog vor.

Wenn das gegeben ist, und Du als PO das wie den Entwicklern überlassen 
kannst, dann ist das schon ideal. Da würde auch andere Verfahren laufen.


Schlimm ist, wenn der PO nur Manager ist ohne fachlichen Durchblick 
("ihr seid die Fachleute"). Leider ist das oft so, dass PO und Co der 
Karriereweg für jene ist, die in der Entwicklung scheitern.

Udo S. schrieb:

> Wenn eure Projektmanager "Mikromanagement" betrieben haben,
> dann sollten sie sich eine andere Aufgabe suchen.

Genau.
Und wer nicht mit einer vollständigen Kenntnis des C-Standards
geboren wird, soll Bäcker werden -- und nicht Programmierer.
Schulen, Universitäten, Ausbildung wird sowieso überschätzt.
Kein Mensch mus je irgendwas lernen -- entweder er kann es,
oder es hat sowieso keinen Sinn.


> [...]
> Und das funktioniert völlig ohne starres SCRUM Korsett.

Das bedeutet nur, dass Eure Führungskräfte gut und fähig
sind -- und nicht, dass SCRUM generell schlecht ist.

Alle Vorgehensmodelle und Methodiken sind sowieso nur ein
Versuch, die Dinge explizit zu formulieren und lehrbar zu
machen, die gute Leute intuitiv richtig machen.

Das ist im Ansatz erstmal nicht falsch.

Scrum funktioniert eben nicht überall und zwanghaft alles in das 
Framework reinzupressen macht einfach keinen Sinn. Leider wird Scrum 
häufig zum Mikromanagement missbraucht und dient häufig dazu, dass man 
eine Art Fabrikarbeit etabliert, die Entwickler zu Implementierern 
degradiert. Besonders bei großen Konzernen ist das oft der Fall, weil 
man dort alles möglichst in kleine übertragbare Aufgaben verpacken will.

Wenn man aber vernünftig "agile" arbeitet, funktioniert es auch recht 
gut. Nur meistens nicht so wirklich mit Scrum. Man braucht aber auch die 
richtigen Leute dafür. Der lernresistene 9to5 Arbeiter ist denkbar 
ungeeignet für richtiges "Agile". Jemand, der gegen alles neue kämpft 
und destruktiv ist kann eben nichts sinnvolles beitragen. Die Idee 
dahinter ist ja eigentlich, dass man Hierachien abbaut und nicht alles 
vorkaut.

Scrum ist so ein Mittelding, irgendwie braucht man die ganzen 
Wasserköpfe noch (oder sogar mehr) und irgendwie kann man damit werben 
agil zu arbeiten. Wasserköpfe behalten ihre unnötigen Jobs und 
Entwickler bekommen das Gefühl agil zu sein, nur bringen tut es effektiv 
halt nix.

Egon D. schrieb:
> Alle Vorgehensmodelle und Methodiken sind sowieso nur ein
> Versuch, die Dinge explizit zu formulieren und lehrbar zu
> machen, die gute Leute intuitiv richtig machen.

Sehe ich ganz genauso !!! ;)

Bei uns testet der Kunde tätsächlich die einzelnen Releases .. d.h. 
nicht der Kunde selbst - die haben oft keine Ahnung von der Materie.
Das machen Subauftragnehmer wie üblich heute - 
Entwicklungsdienstleister.
Abartig in welche Richtung das heute läuft ...

Aber die Dienstleister testen dann Releases die Wochen zurückliegen, da 
sie wohl mit der Arbeit ned hinterher kommen oder was immer.

Die Folge :
Wir müssen dann Schwächen in Releases suchen, die schon längst 
überarbeitet wurden und folglich verlieren wir eine Menge Zeit, um alte 
Hardware- und Softwarestände wieder einzurichten und dann dort Fehler zu 
suchen und zu korrigieren ... obwohl mit denen gar nicht mehr gearbeitet 
wird, da sie nur ein Zwischenstand waren.
Die neue Hard-/Software arbeitet möglicherweise schon anders, so dass 
die Probleme dort gar nicht auftreten würden.

Wir haben früher ebenfalls abschnittsweise entwickelt und die 
entsprechenden Abschnitte getestet.
Ich denke mal es erklärt sich von selbst, dass ein engagierter 
Entwickler seinen Kram selbst auf Herz und Nieren testet und so viel 
Ehre hat ein 'sauberes' Produkt abzuliefern.

Und früher ohne Prozesse haben wir Kundenwünsche in wenigen Stunden 
umgesetzt getestet und 2 Tage später hatte der Kunde das auf dem 
Steuergerät zum Testen und war sehr zufrieden.

Heute bei all den modernen Prozessen mit viel mehr Leuten, aber Scrum, 
Controll-Board und all dem Blödsinn dauert es Wochen bis wir überhaupt 
Anstalten machen Fehler oder Änderungen zu bearbeiten, der Kunde ist 
ärgerlich und wir unmotiviert ...
 :D

MaWin schrieb:
> vn nn schrieb:
>> um mit der Zeit die Abschätzungen zu verbessern
>
> Während mwn beum Hausbau weiss,  wie lange es dauert Stein auf Stein zu
> stellen, ist eine Fehlersuche eben eine Suche.
> Gib mir deine Abschätzung wie lange du brauchst, die Nadel im Heuhaufen
> zu finden.

Nein? Doch! Oh!
Genau deswegen wird einem normalerweise keiner den Kopf abreißen, wenn 
man als Softwareentwickler mal seine Zeiteinschätzung nachträglich 
korrigieren muss. Egal ob mit Scrum, oder ohne.
Oder willst du damit sagen, dass dein Chef nicht wissen will, wie lang 
du voraussichtlich für XYZ brauchen wirst? Was seid ihr denn für eine 
Bastelbude?

MaWin schrieb:
> vn nn schrieb:
>> "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut,
>> deswegen ist Scrum kacke!!1elf"
>
> Ewiges wiederholen macht den Satz nicht richtiger. Wenn du nur richtig
> tief religiös bist, wird Gott dich von Krwbs, Vorona und Dummheit
> heilen, bete mehr.

Dein Posting macht leider absolut keinen Sinn. Überraschung, wer hätte 
das gedacht...

Udo S. schrieb:
> Und eben die Tatsache das SCRUm massiv dazu genutzt wird Druck
> aufzubauen um mehr Leistung aus den Leuten zu quetschen und die
> Verantwortung bei Problemen von oben nach unten zu schieben.

Ob dein Chef ein Arsch ist oder nicht, wird sich wohl durch die 
Verwendung von Scrum (oder sonst irgendeinem Prozess) nicht ändern. 
Entweder er ist einer, dann wird er immer einen Weg finden, Druck 
aufzubauen, oder er ist eben keiner.

vn nn schrieb:
> Egal ob mit Scrum, oder ohne.
> Oder willst du damit sagen, dass dein Chef nicht wissen will, wie lang
> du voraussichtlich für XYZ brauchen wirst? Was seid ihr denn für eine
> Bastelbude?

Jedes Projekt hat Dinge, die abschätzbar sind (weil sie schon oft 
gemacht wurden) und Dinge, die nicht abschätzbar sind,  z.B. manchmal 
Fehlersuche. Da kann man dann gerne verschiedene Wege skizzieren und 
denen verschiedene Zeiten (Aufwände, Prioritäten, Leute) zuordnen, aber 
es dauert halt so lange, wie es dauert. Bis hin zur Aufgabe des ganzen 
Projektes wenn man den sporadischen Absturz nicht findet oder patchen 
kann.

A. S. schrieb:
> vn nn schrieb:
>> Egal ob mit Scrum, oder ohne.
>> Oder willst du damit sagen, dass dein Chef nicht wissen will, wie lang
>> du voraussichtlich für XYZ brauchen wirst? Was seid ihr denn für eine
>> Bastelbude?
>
> Jedes Projekt hat Dinge, die abschätzbar sind (weil sie schon oft
> gemacht wurden) und Dinge, die nicht abschätzbar sind,  z.B. manchmal
> Fehlersuche. Da kann man dann gerne verschiedene Wege skizzieren und
> denen verschiedene Zeiten (Aufwände, Prioritäten, Leute) zuordnen, aber
> es dauert halt so lange, wie es dauert. Bis hin zur Aufgabe des ganzen
> Projektes wenn man den sporadischen Absturz nicht findet oder patchen
> kann.

Genau das ist es, was ich die ganze Zeit sage. Und in jedem Projekt ist 
es üblich, seinen Vorgesetzten über sowas im Bilde zu halten.
Außer
a) Bastelbude, er will es gar nicht wissen
b) keine Eier dem Chef zu sagen dass man hinter dem Zeitplan ist.
c) cholerischer Vorgesetzter wirfst jeden beim geringsten Fehlschlag 
raus.

In allen drei Fällen hilft nur ein Jobwechsel, bei a) und c) zu einer 
Firma wo nicht gebastelt wird und es eine ordentliche Fehlerkultur gibt, 
bei b) in eine Branche wo man keine Eier braucht.

BTW, wenn es "sporadische, unauffindbare Abstürze" gibt, die ein ganzes 
Projekt zum scheitern bringen, läuft auch was falsch...

Kanban

Matthias Döpke schrieb:
> Egon D. schrieb:
>> Alle Vorgehensmodelle und Methodiken sind sowieso nur ein
>> Versuch, die Dinge explizit zu formulieren und lehrbar zu
>> machen, die gute Leute intuitiv richtig machen.
>
> Sehe ich ganz genauso !!! ;)

+1!

Die neueste Quintessenz: Die Tools funktionieren gar nicht richtig. Man 
packt seine Dokumentationen und Workflow in Tools, die ihre Daten in 
Clouds parken. Werden die morgen abgeschaltet, dann wars das. Dann auch 
außerhalb Meetings endlose Kommentare und Diskussionen, wie man was auf 
dem Backlog anlegt, ob das noch in den Sprint passt, dass "du dafür ja 
nur noch x Tage Zeit hast".

Zusätzlich muss jetzt ein Devop eingestellt werden, der sich in - 
zugegebenermaßen in Teilzeit - um das Netzwerk, um E-mail Accounts etc. 
kümmert. Bei einer 8 mann Bude. Weil da keiner für diese belanglosen 
Dinge Zeit hat oder es nicht tun darf? Pervers.

Ich schreibe jetzt Bewerbungen...

Unglaublich schrieb:
> Zusätzlich muss jetzt ein Devop eingestellt werden, der sich in -
> zugegebenermaßen in Teilzeit - um das Netzwerk, um E-mail Accounts etc.
> kümmert.

DAS ist kein Devop, das ist ein Sysadmin.
Devops ist, wenn das gleiche Team Aministration und Entwicklung macht 
(um die Zielkonflikte zwischen Betrieb und Entwicklung zu reduzieren).
Das mit den Bewerbungen klingt allerdings gut, so viel "Bullshit-Bingo" 
und wenig "echtes Umsetzen" da anklingt.

Die Managementmethode Scrum wird heute mit agiler Unternehmensführung 
gleichgesetzt, also einer Art Ideologie des richtigen Führens, in der 
Menschen freier, selbstbestimmter und zufriedener sind.  Wenn man aber 
nach der hintergründigen Wahrheit sucht, dann stößt man schnell darauf, 
was dieses Scrum wirklich ist: eine Managementmethode zur 
Effizienzsteigerung in bester tayloristischer Tradition. Dort wird keine 
Transformation geboren, sondern kleine Projektchen werden effizient 
abgewickelt. Alles andere ist ein attraktiver Anstrich.

Da es in der Zeit vor SCRUM mit 40% Fehlquote bei der Projektentwicklung 
reine Lotterie war, ob man denn als Kunde das bekommt, was man meint, 
bestellt zu haben, kann ich in dem Gedanken "Effizienzsteigerung" keinen 
Fehler finden.

Framulestigo schrieb:
> Da es in der Zeit vor SCRUM mit 40% Fehlquote bei der
> Projektentwicklung
> reine Lotterie war, ob man denn als Kunde das bekommt, was man meint,
> bestellt zu haben, kann ich in dem Gedanken "Effizienzsteigerung" keinen
> Fehler finden.

Das wird heute dadurch kompensiert, dass SCRUM Projekte 10mal so lange 
dauern wie damals und im Endeffekt das vielfache von vergeigten 
Entwicklungen, die man ggf. mal neu startet, kosten.

In Zeiten von Corona werden jetzt die fehlenden Teammitglieder, die im 
Homeoffice zu Hause hocken, per Videoschalte in die täglichen Meetings 
zugeschaltet. Unfassbar..

Was bei uns so auffällt... Wo man früher im Wasserfall Servicetöpfe 
hatte bei uns hatte und kleine Dinge immer Mal "einfach so" mitgemacht 
hat, also meist technische Sachen, kommt heute immer nur "müssen wir 
dann Mal mit ins Sprint planning mitnehmen". Da hat der fachlich 
zentrierte Productowner natürlich kein Bock auf technische Themen.. also 
geht das drumherum so langsam aber sicher den Berg herunter. Und man 
lähmt sich wo es nur geht. Man versteckt sich förmlich hinter scrum...

Rainer Zufall schrieb:
> Da hat der fachlich zentrierte Productowner natürlich kein Bock auf
> technische Themen..

Dann müsst ihr es ihm beibringen, dass sich das sonst langfristig rächt. 
Dann werden solche Themen auch höher priorisiert.

Jo... sollte man meinen.... aber die Leute blicken es halt nicht. Ist 
halt wie so eine Aktiengesellschaft. Hauptsache schnelle Rendite - mit 
den langfristigen Problemen können sich dann die nächsten rumschlagen...

Es gibt sogar ein festgelegtes Budget von 20% je Sprint was in Technik 
investiert werden muss. Wird halt nur permanent übersteuert, oder es 
wird irgendein Crap als "das ist doch wohl Technik!" definiert.... man 
schiesst sich halt gerne selber ins Knie.... mir egal. Ich nehme es zum 
Glück nur von außen wahr.

Rainer Zufall schrieb:
> festgelegtes Budget von 20% je Sprint was in Technik investiert werden muss

?
Beispiel?

A. S. schrieb:
> ?
> Beispiel

- Update Framework Version
- Optimierungen grundsätzlicher Natur
- einführen neuer Dinge wie zentralisiertes Logging, verbessern 
Monitoring
- erneuern von Dingen wie Authentifizierungsverfahren, 
Laufzeitmonitoring
- Upgrade von Betriebsmodell Application Server auf virtueller Maschine 
vs. Betrieb im Cluster
Usw. Usw. Halt so Dinge neben fachlichen usecases die für den Kunden 
keine direkte Sichtbarkeit haben....

Vor allem muss ich mir immer den Scheiss der anderen Mitglieder ahören, 
der mich überhaupt nicht interessiert und ich auch gar nichts mit 
anfangen kann und der für meine Arbeit auch vollkommen unwichtig ist. 
Aber man soll ja bei Scrum die Mitarbeiter lustig untereinander tauschen 
können, da muss der Raketentechniker auch schon mal eine Uhr 
zusammenbauen ????

Robert K. schrieb:
> Erforderlich sind klare Vorgaben, was zu einem bestimmten Zeitpunkt
> fertig sein soll, denn nur so kannst du abschätzen ob du im Zeitplan
> bist.

Was willst du denn machen, wenn der Kunde selber nicht weiß, was er 
will, braucht und bezahlen kann?

Ich meine: Wer leidet denn nicht darunter wenn alle drei Wochen der 
Vertriebler dazwischenquäkt, daß das ab jetzt alles anders gemacht 
werden muß weil er dem Kunden das so versprochen hat?

Unglaublich schrieb:
> Vor allem muss ich mir immer den Scheiss der anderen Mitglieder
> ahören, der mich überhaupt nicht interessiert und ich auch gar nichts
> mit anfangen kann und der für meine Arbeit auch vollkommen unwichtig
> ist. Aber man soll ja bei Scrum die Mitarbeiter lustig untereinander
> tauschen können, da muss der Raketentechniker auch schon mal eine Uhr
> zusammenbauen ????

Das hängt von der Homogenität des Teams ab, ob das funktioniert. Der 
Gedanke bei Scrum geht wohl tatsächlich in die Richtung, dass jeder im 
Team alles kann, und die Leute im Team ohne Probleme beliebig 
untereinander austauschbar sind. Ich würde aber auch behaupten, dass das 
in der Praxis wohl häufig so nicht funktionieren kann.

Wenn es für dich vollkommen unwichtig ist, was die anderen Kollegen so 
täglich machen, ist das ein deutliches Zeichen dafür, dass ihr einen 
falschen, nicht für Eure Bedürfnisse passenden Prozess lebt (bzw. leben 
müsst, da von oben vorgegeben).

Qwertz schrieb:
> Ich würde aber auch behaupten, dass das
> in der Praxis wohl häufig so nicht funktionieren kann.

Was durchaus funktioniert, ist, daß jemand, der NICHT im Designprozess 
drinsteckt, wertvolle Denkanstöße liefern kann.
Ich jedenfalls finde prinzipiell nichts Schlechtes daran, anderen meine 
Designentscheidungen zu erklären oder "Warum hast du das so 
gemacht"-Fragen zu beantworten.
Und manchmal sieht jemand anderes ja doch etwas, an das man selber noch 
gar nicht gedacht hat.

Und andersrum finde ich die Probleme anderer oft deutlich einfacher (und 
interessanter) als die meine eigenen. Übrigens ein wichtiger Grund für 
mich, mich in Foren herumzutreiben.

Übrigens völlig unabhängig davon, ob man nach Scrum arbeitet oder nicht. 
Ich habe diese Arbeitsweise immer noch nicht kennengelernt und keine 
Ahnung wie das wirklich zugeht.


Qwertz schrieb:
> Wenn es für dich vollkommen unwichtig ist, was die anderen Kollegen so
> täglich machen, ist das ein deutliches Zeichen dafür, dass ihr einen
> falschen, nicht für Eure Bedürfnisse passenden Prozess lebt (bzw. leben
> müsst, da von oben vorgegeben).

Oder das jemand einfach nicht in ein Team mit zwei oder mehr Mann 
reinpasst. ;)

Wühlhase schrieb:
> Was durchaus funktioniert, ist, daß jemand, der NICHT im Designprozess
> drinsteckt, wertvolle Denkanstöße liefern kann.
> Ich jedenfalls finde prinzipiell nichts Schlechtes daran, anderen meine
> Designentscheidungen zu erklären oder "Warum hast du das so
> gemacht"-Fragen zu beantworten.

Das erfordert aber, dass der Tippgeber etwas davon versteht. Aber wie 
soll ein Elektroniker in der grossen Runde ein Programm hinterfragen? 
Das könnten die Softwareker doch nicht einmal untereinander: Wenn ich 
sehe, wie wenig die Softwareentwicklung an Konzepten macht, sind die gar 
nicht in der Lage ad hoc in einem meeting irgend etwas zu beantworten. 
Das ist vollkommen oberflächlich.

Ich kenne die Runden aus Erfahrung und sehe, was bei rumkommt. Viel 
oberflächlich schnell dahin gesagtes.

M. W. schrieb:
> Wenn ich
> sehe, wie wenig die Softwareentwicklung an Konzepten macht, sind die gar
> nicht in der Lage ad hoc in einem meeting irgend etwas zu beantworten

"Eng ist die Welt, und das Gehirn ist weit. Leicht beieinander wohnen 
die Gedanken, doch hart im Raume stoßen sich die Sachen" [Schiller]

das mit den Konzepten wird regelmäßig überbewertet: Klar, wenn ich eine 
abgeschlossene Funktionalität habe (die Funktion sin() z.B.), dann mache 
ich in 10% der Zeit die Beschreibung der Schnittstelle inklusive Tests 
und Doku, und lasse den Programmierer dann machen. Das gleiche gilt für 
viele Web-Anwendungen, HALs oder Treiber. Deshalb setzt man dort zum 
Codieren auch Programmierer ein.

Wenn ich jedoch wirklich etwas neues schaffe, für ein neues Produkt neue 
Features, dann sind Konzepte maximal ein Plan nach Sunzi: "Der Beste 
Plan versagt beim ersten Feindkontakt". Oder modern: Vergiss den Plan, 
Planung ist alles.

Ein echtes SW-Projekt, wo nicht nur Programmierer dransitzen, ist wie 
das Einräumen eines Geschirrspülers oder das Einrichten eines Lagers: 
Ja, man stellt sich das so oder so vor, und am Anfang macht man auch wie 
geplant, doch dann kommen halt Teile in der falschen Größe oder im 
falschen Verhältnis und das hätte man ja alles kommen sehen müssen.

Nein hätte man nicht.

Am Ende räumt man immer mehr wieder um, gruppiert was heute sinnvoll ist 
und wirft einige der besten Ideen über Board, weil sie sich nicht 
bewähren. Und spätestens beim dritten Projekt geht das umso besser, je 
weniger man schon in Beton gegossen hat. Wände, die man schon "für die 
Ewigkeit gebaut und getestet" eingebaut hat, reißt man ungern ein und 
behilft sich lieber mit dubiosen Workarounds.

Das, und genau das ist der Grund für agile Programmierung, egal ob 2 
erfahrene Entwickler in XP mit Verachtung als Prutscher durch Kollegen 
und Chefs, als Scrum oder als ungeliebter Chef, der "immer wieder mit 
Änderungen" kommt.