Verbreitung von SCRUM

Reinhard S. schrieb:
> Mich würde interessieren, wo bei euch (und ob überhaupt) bereist
> SCRUM eingesetzt wurde, um Projekte zu managen.

Ist mittlerweile fast schon wieder ein alter Hut in der 
Software-Entwicklung, wurde bei uns schon vor über 5 Jahren eingeführt 
und hat sich bewährt.

Danke für Deine Fragen, Reinhard,

die Antworten interessieren mich auch.

Ich kann aus meinem Wissen und Können nur dies beisteuern:

1. Seit dem Taylorismus hat das Wissen und Können der Fachkräfte in 
ihrem Fach schneller und weiter zugenommen als das ihrer Manager in 
Sachen Management. Folge: a) Das Treffende am Dilbert-Comic. b) Der 
Vorschlag "ohne die dauernden Störmanöver unseres Deppen von Manager 
kämen wir viel schneller voran - und sein Gehalt kann gespart werden!"

2. Ungeklärt ist aber der Widerspruch zwischen Delegation / Übernahme 
der Verantwortung und der Forderung nach Gleichstellung aller im 
SCRUM-Team. Entsprechend unsicher ist die Praxis. Denn wer Verantwortung 
auf mehr als zwei Schultern verteilt, der erlebt, wie nachher immer der 
andere schuld gewesen sein soll.

3. Mir scheint, dem SCRUM-Master wird eine verlogene Aufgabe gestellt - 
einerseits soll er aus Sicht seines Teams eben keine 
Vorgesetztenfunktion haben, andererseits erwartet das Management 
Vorkalkulation, Zusagen und deren Einhaltung - spezifikationsgerecht, 
termingerecht und kostengerecht.
Dieser Widerspruch ist prinzipiell unlösbar. Irgendwer muss leiden.

Meine bevorzugte Arbeitsweise in der Vergangenheit bis heute ist diese:
"Niemand ist gut genug, einen anderen ohne dessen Zustimmung zu 
regieren." (Abraham Lincoln)
Würde PHB, Dilberts Boss, lernen, wie er diese Zustimmung gewinnt, müßte 
Dilbert nicht mehr wegen Burnout ausfallen. Ferner könnte PHB aus 
sämtliche Führungskompetenzen / Manipulationstechniken verzichten.
Dann könnte er Dilbert + Kollegen eine echte Hilfe sein, das zu tun, was 
diese wegen nicht dürfen oder auch nicht können.

Ciao
Wolfgang Horn

Reinhard S. schrieb:
> Vor allem würde mich interessieren, wo das System eingeführt
> oder angedacht - und dann wiede abgeschafft wurde.

Quasi jeder macht Scrum - oder was er dafür hält.

Die (katastrophalen) Ergebnisse siehst du z.B. bei eBay oder vielen 
Onlineangeboten von Zeitungen: Ständige Änderungen und immer 
funktioniert es nur halb, die Fassade wird ständig umgebaut, die Fehler 
hinten bleiben.

Die optimale (resourcen- und kosten-) Form der Softwareentwicklung 
(woanders auch) ist Wasserfall: Eine klare Aufgabenbeschreibung, 
erfahrene Umsetzung "schon 1000 mal gemacht", fertiges fehlerfreies 
Ergebnis (z.B. auch validiert durch kleinteilige Tests). Keine Arbeit 
wird doppelt gemacht, man ist sich von vorneherein über den Aufwand im 
Klaren.

Leider gibt es diese optimalen Bedingungen selten, daher kann es keine 
optimale Arbeit geben, Software ist immer teurer und schlechter als 
erhofft. Scrum ist der Weg, mit schlechten Vorgaben doch noch zurecht zu 
kommen. Meiner Erfahrung nach werden durch die nun entfallende 
Notwendigkeit klarer Gesamtvorgaben die Ergebnisse noch schlechter, der 
Informationsstand der Entwickler ist noch schlechter als früher.

Inzwischen ist es üblich, mit Programmen (und WebSeiten) zu kämpfen so 
daß sie doch noch irgendwie tun was man erreichen muss, an statt daß sie 
so arbeiten, wie man es von fehlerfreier und durchdachter Software 
erwarten würde.

Beispiel für ein real existierendes Softwareprodukt:
Realisierung nach Wasserfall, ausgehen von durchdachtem Pflichtenheft: 4 
Mannjahre.
Realisierung desselben Produktes durch eine andere Firma nach Scrum: 
bisher 80 Mannjahre, noch kein Ende in Sicht. Und das, obwohl hier das 
Endergebnis "ersetzt das alte Produkt" klar vorgegeben ist.

>Die optimale (resourcen- und kosten-) Form der Softwareentwicklung
>(woanders auch) ist Wasserfall:

Nein ist es nicht. Das wäre der Fall, wenn ein Entwicklungsprojekt 
vollständig planbar wäre. Das trifft aber maximal auf den Hausbau zu, 
wenn keine neuen Techniken verwendet werden und es auch sonst keine 
Unbekannten gibt.
Die meisten Softwareprojekte bewegen sich aber im Bereich des Neuen. 
Dort ist das Wasserfallmodell mit vollständiger Planbarkeit zwar der 
Traum jedes Managers, funktioniert aber in der Praxis nie. 
Wechselwirkungen und Zyklen gibt es dort immer, man kann die 
Spezifikation nicht am Anfang hin schreiben und dann abarbeiten.

Ich arbeite seit 5 Jahren in SCRUM-Projekten mit unterschiedlichem 
Erfolg.
Wenn jemand mit der Einstellung "Meine Kollegen sind meine Konkurrenten 
bei der nächsten Gehaltsverhandlung" im Team ist, dann kann das nicht 
klappen. Um solche Widersprüche zu lösen, ist eigentlich die 
Retrospektive gedacht, aber manchmal sitzen da nur harmoniesüchtige und 
reden nur Positives.

Es hat aber schon richtig gut funktioniert.

Es gibt sehr viele Tools für Scrum (also Methoden für die Retro usw.). 
Die Versuchung ist echt groß, mit diesen Tools rumzuspielen, anstatt die 
wirklichen Ursachen der Probleme anzugehen.

Kann man mit einem soliden kommt darauf an beantworten. Prozesse sind 
immer nur so gut wie sie von den beteiligten Personen verstanden und 
gelebt werden.
Habe sowohl schon gute als auch schlechte Ausprägungen gesehen.

SCRUM (schon fast generell agil) ist einfach eine andere Kultur und eine 
Kulturveränderung in etablierten Strukturen ist vor allem eines: 
schmerzhaft "teuer"

konkret sehe ich oft fehlende Grundlagen um SCRUM überhaupt einsetzen zu 
können:
* Auftraggeber kann nicht agil mitarbeiten
* Auftraggeber hat nicht die notwendige Vision und Fachexpertise
* Firmenkultur betrachtet "Scheitern" als lebenslanges Brandzeichen
* Firmenkultur bremst bei Entscheidungen, im Sinne von - streng 
hierarchisch, wenige Entscheidungsträger die noch weniger Zeit haben, 
wenig Vertrauen in die Mitarbeiter
* Firmenkultur kann selbst nicht agil, gerne wird mal ein Team mit Scrum 
losgeschickt, dabei aber vergessen, dass das Umfeld mitziehen muss
* das System an dem gearbeitet wird, kann nicht agil weiterentwickelt 
werden, im Sinne von - kleine Änderungen = große Ängste

wenn dann mal die groben Rahmenbedingungen stehen, tja dann sehe ich 
Scrum in Verbindung mit Lean und einer angemessenen Portion Kritik zu 
emergenten Architekturen als extrem kostensparenden 
Softwareentwicklungsprozess

Dumdi D. schrieb:
> Auftraggeber das gar nicht (da er nicht weiss was er eigentlich möchte)

Das ist überhaupt DAS Problem. Hört sich bekloppt an, kommt aber ständig 
vor. Man hat ein paar konkrete Punkte die geändert werden sollen aber 
später "noch viel mehr" aber was genau weiss man noch nicht.

TEAM = Toll Ein Anderer Machts

Mein persönliches Fazit aus der Praxis:

Eine Gruppe von Leuten, die gute SW entwickeln kann, sich vertraut und 
eine funktionierede Kommunikation aufgebaut hat, kann "klassisch" gute 
Software entwickeln. und kann das auch in einem Scrum Prozess.

Wenn man einfach Leute zusammenwürfelt, die nicht miteinander können, 
nützt auch scrum und agil nix.
Scrum ist spätestens da zuende, wo der Chef auf einzuhaltende Fristen 
pocht und der Kunde mit Konventionalstrafe oder Abbsprung droht.

Und SCRUM-Tools mögen vieleicht ein bischen nützlich sein, aber wenn ich 
mir die vielen Naivlinge anschaue die meinen man bräuchte nur das 
richtige Tool, dann klappts, dann weiss ich dass die Arbeit nie ausgehen 
wird.

Dumdi D. schrieb:
> Es stellt sich nur die Frage warum das alte Produkt ersetzt werden soll.

Es gab die Hoffnung, daß ein Rewrite zu einem schneller ablaufenden 
Programm führt. Phantasiezahlen wie "x20" oder gar "x1000" standen im 
Raum, nicht mal "x2" wird derzeit erreicht (inzwischen bringt die 
Hardware locker x20 auch beim alten), lediglich der Speicherbedarf ist 
"x20" geworden.

Hauptsächlich war es das üblich Geschwätz verirrter Modejünger 
"moderneres Aussehen" "moderne Technologien" "Abwerfen von Ballast" 
"bunter blinkender und XML konform".

MaWin schrieb:
> XML konform

Womit es schon mal bestimmt nicht schneller wird gegenüber proprietäten 
aber zum Problem passenden Datenstrukturen :-)

Reinhard S. schrieb:
> Mich würde interessieren, wo bei euch (und ob überhaupt) bereist SCRUM
> eingesetzt wurde, um Projekte zu managen.

Vor SCRUM:

Wir müssen einen weiten weg gehen.
Bevor wir loslaufen planen wir jeden meter und wie wir um mögliche 
Hindernisse herum kommen. Das was wir nach Abarbeitung des langen Planes 
erreicht haben muss das Ziel sein.

Mit SCRUM:
wir müssen einen weiten weg gehen.
Wir laufen einfach los und nach ein paar Metern schauen wir ob das Ziel 
näherrückt oder nicht. Dementsprachend halten wir die richtung bei oder 
nicht. Näherrückende Hindernisse umlaufen wir nicht, sondern melden 
diese dem SCRUM-Master. Der plant die nächsten Meter so das wir nicht 
frontal gegen das Hinderniss knallen. Damit kommen wir zwar dem Ziel 
nicht unbedingt näher aber immerhin treten wir nicht auf der stelle weil 
uns der Plan fehlt ...

hart aber weise schrieb:
> Vor SCRUM:
>
> Wir müssen einen weiten weg gehen.
> Bevor wir loslaufen planen wir jeden meter und wie wir um mögliche
> Hindernisse herum kommen.

In der Realität eher so: Wir machen eine Expedition in einen unbekannten 
Dschungel. Wir wissen nicht, was uns erwarten wird. Damit wir uns nicht 
verlaufen, setzen wir uns vorher zuhause 3 Monate an den Schreibtisch 
und malen ausführliche Landkarten.

Tom schrieb:
> Damit wir uns nicht
> verlaufen, setzen wir uns vorher zuhause 3 Monate an den Schreibtisch
> und malen ausführliche Landkarten.

Man könnte natürlich vorher ein Flugzeug oder Satellit bemühen um die 
Landschaft zumindest grob vorzuerkunden. Das wäre der klassische Ansatz.

Die Scrum Ameisenmethode ist auch nicht der letzten Weisheit Schluß.
Im Prizip macht Scrum das was eine gut eingspielte Gruppe mit 
funktionierender Kommunikation so oder so macht.
Nur ist es in Scrum streng schematisiert und ritualisiert, so daß man 
nicht den eigenen Verstand benutzen muss.
Halt der typisch amerikanische Checklistenansatz, mit dem auch 
Hilfsarbeiter klarkommen.

Der größte Fehler den man bei Scrum machen kann ist zu glauben, dass 
Scrum einfach ist. Ein paar wenige Aktivitäten, ein paar wenige 
Artefakte, was kann da schon schief gehen?

Scrum ist aufwändig, braucht Einsatz und ist besonders an den 
Schnittellen, wie zu Kunden, Lieferanten oder der eigenen Buchhaltung, 
schwer durchzuhalten. Da herrscht so eine Art Impedanzfehlanpassung.

Trotzdem, Scrum läuft, wenn alle am gleichen Strang ziehen, mitspielen 
und Verantwortung übernehmen. Ein fauler Apfel und die Geschichte sieht 
anders aus. Ganz schlimm wird es, wenn ein Team-Mitglied Scrum von innen 
sabotiert.

Der theoretische Lösungsansatz für so ein Problem, das Team-Miglied zu 
einem ex Team-Miglied zu machen funktioniert in deutschen Firmen nicht. 
So einfach wird man kein Team-Mitglied los. Tauschen mit anderen Teams 
geht selten. Dazu ist die Personaldecke zu dünn und die Personalplanung 
zu straff. Von US-Verhältnissen nicht zu reden. Dort entscheiden 
vielfach direkt Gruppenleiter über Einstellungen und Entlassungen in 
ihren Teams.

Im Grunde wird Scrum von zwei Gruppen totgeredet. Den Fanboys, die Scrum 
Heils- und Erweckungskräfte zuschreiben, die es nicht hat, und den 
Hassern, die immer wieder neue Ausreden erfinden, warum Scrum nicht 
funktionieren kann.

Das Wasserfall-Modell hingegen ist toll. Auf dem Papier. Es hat nur den 
großen Nachteil, dass es häufig nicht funktioniert, weil sich die 
Realität ums Verrecken nicht an das Modell anpassen möchte.

Ein Problem liegt auch darin das man meint man bräuchte nur SCRUM lernen 
um projecte zu managen. SCRUM Zertifikat als Lizenz zum Projekt leiten.

IMHO ganz großes Trugschluss:
Man wird nicht zum 3 SterneKoch nur wenn man den Küchengeräte umgehen 
kann.

Meines erachtens betrachten einige Absolventen die SCRUM-Zertifizierung 
als Abkürzung in die Leitungsetage. So wie Gutenberg und Co: wer den 
Titel hat ist Doktor, auch wenns völlig an Talent und Verständnis 
mangelt.

Dumdi D. schrieb:
> Jay schrieb:
>> Trotzdem, Scrum läuft, wenn alle am gleichen Strang ziehen, mitspielen
>> und Verantwortung übernehmen. Ein fauler Apfel und die Geschichte sieht
>> anders aus. Ganz schlimm wird es, wenn ein Team-Mitglied Scrum von innen
>> sabotiert
>
> Meiner Meinung nach kannst Du das Wort 'Scrum' in dem Ausschnitt durch
> jedes andere Wort ersetzen. Alles läuft, wenn alle am gleichen Strang
> ziehen, mitspielen und Verantwortung übernehmen.

Natürlich, aber ein Scrum-Fanboy muss ja in dem Kontext Scrum erwähnen.

Immer dran denken: Wenn 90% oder gar 99% der Projekte nicht 
funktionieren, darf es niemals an der reinen Theorie der Methode liegen, 
sondern immer an den Leuten.

Ist wie beim Sozialismus...

Jay schrieb:
> Trotzdem, Scrum läuft, wenn alle am gleichen Strang ziehen, mitspielen
> und Verantwortung übernehmen. Ein fauler Apfel und die Geschichte sieht
> anders aus. Ganz schlimm wird es, wenn ein Team-Mitglied Scrum von innen
> sabotiert.

Ja ja ein System, das nur funktioniert wenn alle innerer Elemente ideal 
sind ist ein "Scheiß" System, nämlich nicht fehlertolerant.
Ein gutes System funktioniert auch dann wenn es nichtideale Bauelemente 
hat.

Aber so schlecht will ich SCRUM und agile SW-Entwicklung gar nicht 
machen.
Aber es ist kein Zaubermittel. In unserer Firma läuft derzeit beides 
nebeneinander her, und ich kann bis jetzt kein Vorteil für SCRUM 
feststellen, nur ein Haufen Ausreden wenn die Zeitabschätzungen trotz 
SCRUM weit überschritten werden.

Dumdi D. schrieb:
> Jay schrieb:
>> Trotzdem, Scrum läuft, wenn alle am gleichen Strang ziehen, mitspielen
>> und Verantwortung übernehmen. Ein fauler Apfel und die Geschichte sieht
>> anders aus. Ganz schlimm wird es, wenn ein Team-Mitglied Scrum von innen
>> sabotiert
>
> Meiner Meinung nach kannst Du das Wort 'Scrum' in dem Ausschnitt durch
> jedes andere Wort ersetzen. Alles läuft, wenn alle am gleichen Strang
> ziehen, mitspielen und Verantwortung übernehmen.

bei Scrum ist es IMHO eher schwierig in die richtige Richtung zu ziehen 
da Ziele kurzfritig gesetzt werden (Sprints). So kann es bei Scrum 
schnell passieren das zwar alle am gleichen strang ziehen aber die 
entwicklungs im takt der Sprints hin und her irrt statt schnurrgerade 
auf die milestones zurast.

Oder fröhlich auf der Stelle tritt und vom Hundersten ins Tausendste 
inkrementiert.

Ach Leute, ihr habt ausführlich demonstriert, dass ihr an Erfahrungen 
nicht interessiert seit, sondern nur dogmatisch auf etwas rumzuhacken 
was ihr nicht versteht. Daher spare ich es mir mit euch zu diskutieren.

Jay schrieb:
> Ach Leute, ihr habt ausführlich demonstriert, dass ihr an Erfahrungen
> nicht interessiert seit, sondern nur dogmatisch auf etwas rumzuhacken
> was ihr nicht versteht.

Ich glaube eher du bist ein SCRUM Fanboy, hast aber noch nie im Leben 
ein reales Projekt mit Hilfe von SCRUM realisiert, mit einem Kunden der 
geliefert haben möchte und einem Chef der mit dem Projekt auch Geld 
verdienen will (und muss).

Ich habe hier in meiner Firma den Vergleich, mir persönlich wäre der 
sehr formale Prozess aber zu doof.

Mark B. schrieb:
> Aber: Gab es denn in der Geschichte der Softwareentwicklung jemals ein
> Projekt mit realen Kunden, wo das so funktioniert hat?

Ja, bei uns mehrere. Kleine Projekte, wo ein Kunde ein Problem hat, das 
schildert, gemeinsam ein Programmvorschlag zur Lösung erarbeitet wird (1 
Tag), das umgesetzt wird (2 Tage) dokumentiert wird (1 Tag), und der 
Kunde zufrieden mit der Lösung ist, also keine Nacharbeit. Das gab es 
dann für 4000 DM. Auch grössere Projekte, wo man das Pflichtenheft 
schreiben konnte, abgesegnet bekam, und in 1 Jahr umgesetzt hat, liefen 
erfolgreich, aber kleine Abweichungen "wir hätten gerne nach 3 Monaten 
einen Prototypen" verstiessen gegen das reine Wasserfallmodell (und 
kosteten den Kunden zigtausende, denn ohne so einen Schwachsinn hätte 
man anders effektiver programmiert). Das Produkt selbst wurde damit 
verkauft und eingesetzt, Fehler waren aber drin und mussten bei 
Entdeckung gefixt werden, das sollte ja bei reinem Wasserfall auch nicht 
sein. Und noch ein paar weitere. Ein Kunde, der mit Wischiwaschi kommt, 
und nicht mal ein Lastenheft liefern kann, fliegt gleich wieder raus.

Wichtig ist, daß der Kunde mit seinem Projekt zu den Erfahrungen des 
Teams passt. Wer bei Aufträgen einschlägt, deren Kernaufgaben er noch 
nie gemacht hat, bei denen er alles erst lernen muss, kann keinen 
Wasserfall anbieten. Wer so was so ähnlich schon dutzendmal gemacht hat 
"wieder eine Shopysystem, der Kunde ist mit Funktion und Aussehen des 
vorherigen Kunden zufrieden", wird nicht nur rasend schnell, auch dank 
Recykling von Code, sondern kann auch sehr genau sagen was es kostet und 
wie lange es dauert.

Die Einführung von SCRUM setzt immer voraus dass der Vorgesetzte denkt 
dass die Mitarbeiter Dölmchen drehen oder einfach schlafen. BWL-ler 
lieben die Illusion mit „agilen Prozessen“ einen Entsafter einzuführen 
der aus den Menschen noch mehr ausquetscht.

1. SCRUM macht überwiegend Sinn für jüngere Mitarbeiter die nicht wissen 
wie man miteinander kommuniziert. Den Älteren/Erfahrenen Kollegen geht 
das auf den Sack.
2. Wenn man eingespieltes und gut funktionierendes Team hat, ist SCRUM 
eher ein Nachteil weil hier ein unflexibles und autoritäres System 
eingeführt wird.
3. Durch SCRUM neigen viele nicht ganz bodenständige Menschen (Nerds 
sind in der Regel so) sich selbst auszubeuten und sich in Meetings mit 
kürzeren Fristen zu überbieten.
4. SCRUM ist ein fast religiöses System das auf gar keinem Fall 
kritisiert werden darf, erinnert stark an Scientology, z.B. „Tools for 
Life“ und ähnliche typisch amerikanische Bevormundung.
5. SCRUM deckt in der Regel auch interne  Strukturprobleme (Schwächen) 
des Unternehmens auf die aber kein BWL lösen wollen wird. Der Latein der 
BWL-ler endet exakt hier, schließlich ist SCRUM nur dafür gedacht etwas 
am Mitarbeiter zu „formen“.
6. Es ist viel billiger ein einfaches Tool einzusetzen wo Mitarbeiter 
eingeben was sie gemacht haben und wie lange, und kurze tägliche 
Gespräche abzuhalten. Stattdessen aber holen sich die Firmen teuere 
SCRUM-Berater und tagelange SCRUM-Schulungen wo außer den dämlichen 
denglischen Sprüchen kaum was Brauchbares erzählt wird.
7. SCRUM verschiebt einen Teil der Organisation (und Verantwortung) mit 
voller Absicht auf Mitarbeiterebene ohne dass dafür eine angemessene 
Entlohnung erhalten wird.
8. In enger Zusammenarbeit mit dem Kunden wo man flexibel reagieren 
muss, kaum anwendbar wenn man andauernd die Sprints ändern muss.

Du sprichts mir aus der Seele. Ich bin seit 1976 in der Entwicklung
tätig und muss diesen "MURCS" auch noch über mich ergehen lassen.

Tätgliche Scrum Floor Metings und dieser ganze denglische Scheiss.

Täte die Firma die Entwicklung mit einer ordentlichen 
Personalausstattung
betreiben bräuchte man diesen Mist nicht.

Die Kommentare hier decken sich mit meiner Erfahrung:

-) Scrum hat nicht viele Regeln, verlangt aber, dass diese eingehalten 
werden. Versteht man Scrum nicht und/oder setzt man es nur teilweise um, 
dann funktioniert es nicht. Sieht man gut hier in diesem Thread: da 
regen sich die Leute über Scrum auf mit Szenarien, die man bei Scrum 
gerade verhindern möchte.

-) Scrum ist nicht für alle Projekte geeignet. Für die hier genannten 
Projekte im Ausmaß von 4 Manntagen, oder wenn eh schon alles komplett 
spezifiziert ist (dann kann man es gleich den Indern geben), braucht man 
kein Scrum.

-) Scrum krempelt die Organisation stärker um als man denkt. Das klappt 
oft nicht.

In der Firma, in der ich arbeite, setzen wir ein Subset von Scrum ein. 
Das funktioniert nicht, ist aber auch logisch. Aber noch immer besser 
als zuvor, wo wir gar keine Methode hatten. Unsere Kunden sind mindere 
Qualität gewohnt, daher ist das leider kein Problem. "Richtige" 
Scrum-Teams funktionieren meiner Beobachtung nach aber echt gut.

In der Regel ist das so dass Unternehmensberater die Chefs dazu 
verführen diesen Blödsinn einzuführen weil sie ihm mehr Gewinn und 
weniger Arbeit (für ihn selbst) versprechen, da (wie schon vorgemerkt 
wurde) ein Teil der Organisation nach unten rutscht. Scrum und 
Flexibilität passen nicht zueinander. Den Höherpunkt der Perversität 
habe ich mal in einem Großkonzern erlebt, dort strömen morgen früh 
Mitarbeiter in die Meetingsräume rein, in jedem Raum ca. 50 man. Es gibt 
keine Stühle in diesem Raum, alle bleiben stehen für ca. 45min. In 
dieser Zeit wirft man sich gegenseitig so ein kuscheliges Bällchen zu, 
genannt Speechtoken, und erzählt was man gestern gemacht hat und was man 
heute vor hat. Noch peinlicher und kindischer geht es kaum.

progger schrieb:
> da
> regen sich die Leute über Scrum auf mit Szenarien, die man bei Scrum
> gerade verhindern möchte.

Präzisiere das mal bitte. Was nützt mir ein in der Theorie toller 
Prozess, der in der Praxis nicht funktionieren kann, weil es immer 
Randbedingungen wie ein Budget und ein Abgabetermin gibt.
Sorry aber das ist doch dann reine Augenwischerei, genau wie eine tolle 
Prinzipschaltung in Tieze Schenk, die aber nur funktioniert wenn die 
Bauteile max. 0,001% Toleranz haben.

Carl hat es prima zusammengefasst:

Carl D. schrieb:
> SCRUM formalisiert Dinge, die erfolgreiche Team von alleine richtig
> machen, bringt vielleicht ein paar Leute auf den Trichter und
> hinterlässt einige ratlos, die formal alles richtig gemacht haben, aber
> trotzdem versagen. Und es sorgt für viel Umsatz bei den
> Zertifikatsverteilern.

Was noch fehlt aber auch schon angesprochen wurde: SCUM ist ein schönes 
Bullshit Bingo Buzzword für BWLer und Vertriebler.

Es gibt in der Softwareentwicklung keinen Königsweg, sondern immer 
mehrere Varianten, welcher der Beste ist hängt vom Projekt, den 
Rahmenbedingungen und den Menschen ab, die daran mitwirken.

Ich finde von SCRUM wird häufig geredet. In Wirklichkeit steht was ganz 
anderes dahinter.
Selbst in Firmen die von fest definierten Aufträgen lebt wird intern 
gesagt man verwendet SCRUM(erlebe ich selbst gerade -.-).
Das kann nicht funktionieren.
Ich hab die Erfahrung gemacht es wird viel und oft gesagt: "Wir machen 
SCRUM", in Wirklichkeit ist es aber nicht so. Wenn ich ein Lastenheft 
habe dann wird es einfach schwierig einen wirklichen SCRUM-Prozess zu 
führen.
Das Problem ist vor allem das in DE viele Firmen einfach nicht agil 
sind, sich aber selbst so sehen. Außerdem ist die SW-Entwicklung, gerade 
in kleineren Industriefirmen, gespickt von Quereinsteigern die in der 
Regel keine Ahnung von agiler SW Entwicklung haben. Dann kommt es 
ziemlich schnell zu Missverständnissen was das überhaupt bedeutet, es 
wird mit Begriffen um sich geschmissen die hinten und vorne nicht 
stimmen und sich dann noch modern gefühlt.

SCRUM funktioniert dort wo ich eben keine starren Anforderungen habe und 
mich als Kunde laufend beteilige.

VW geht ja auch nicht zu Bosch und sagt: "Schauts mal wie es läuft, 30 
mille kriegts trotzdem.".
Die sagen ja auch:"Ich will eine Abgasabschalteinrichtung bis 31.1. für 
10 mille und wennst es nicht schaffst, Vertragssstrafe".

Hi,

ein aus meiner Sicht lesenswerter Artikel zu Scrum&Agile:

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

Kurzzusammenfassung: Es setzt die falschen Anreize, löst die falschen 
Probleme und macht Programmierung und Programmierer zu einem notwendigen 
vehikel. Es ist im Prinzip ein permanenter Kriesenmodus.

verwundet schrieb:
> Außerdem ist die SW-Entwicklung, gerade in kleineren Industriefirmen,
> gespickt von Quereinsteigern die in der Regel keine Ahnung von agiler SW
> Entwicklung haben.

Das ist leider genau das Problem,
Selber mitgemacht, in do nem kleinen KMU in der Industrie:
Auf 10 j. alter Legacysoftware ( in C geschrieben )
versucht, neue Komponenten mit Scrum zu entwickeln, die meisten 
Entwickler abgehaut, ich war einer der Erfahreneren damals mit ca. 2 
Dienstjahren bei der Firma.
Schlechte Qualität war der Kunde genauso gewöhnt.
Es gab nen Scrummaster wie sich das halt alles nennt, funktioniert hats 
im Endeffekt nicht.

Jeder hat halt für sich  seine Zettelchen und Tasks abgearbeitet, aber 
am Schluss hat alles schnittstellenübergreifend nicht funktioniert.

klausi schrieb:
> Jeder hat halt für sich  seine Zettelchen und Tasks abgearbeitet, aber
> am Schluss hat alles schnittstellenübergreifend nicht funktioniert.

Nicht funktionierende Kommunikation! Wenn jeder ein bischen über den 
Tellerrand geschaut und das ganze Problem im Blick gehabt hätte wäre das 
nicht passiert.
Klassisches Beispiel. dass der formale Prozess alleine keine Lösung ist.

Und wenn das Team gemeinsam über den Tellerrand schaut und konstruktiv 
miteinander redet, dann brauchst du den formalen Prozess nicht mehr.

Der Andere schrieb:
> Wenn jeder ein bischen über den
> Tellerrand geschaut und das ganze Problem im Blick gehabt hätte wäre das
> nicht passiert.

Ja wenn jeder den Gottgleichen IchStehÜberAllen Blick eines 5 
Sterne-Projektmanager hat managed sich jedes problem wie von alleine und 
zur universalen Zufriedenheit.

Aber wir sind nun man Menschen und keine Götter
und zerlegen deshalb Aufgaben zielführend in verdauungsgerechte Happen 
daran ändert auch kein SCRUM etwas.

Ecce homo schrieb:
> Der Andere schrieb:
>> Wenn jeder ein bischen über den
>> Tellerrand geschaut und das ganze Problem im Blick gehabt hätte wäre das
>> nicht passiert.
>
> Ja wenn jeder den Gottgleichen IchStehÜberAllen Blick eines 5
> Sterne-Projektmanager hat managed sich jedes problem wie von alleine und
> zur universalen Zufriedenheit.

Ich sage "ein bischen über den Tellerrand blicken"
Du interpretierst: "Gottgleichen IchStehÜberAllen Blick"

Welches Problem hast du? Verstehendes Lesen? Kann man lernen...

Lu R. schrieb:
> Der Prozess funktioniert, hat sich bewährt und ist gut, es fehlen nur
> die Leute. Aber statt Entwickler einzustellen werden Projektleiter
> geholt, der Overhead aufgeblasen und die Qualität herabgesetzt. Und
> gleichzeitig redet der Chef davon, dass wir unbedingt "agil" entwickeln
> müssen.

Genau das habe ich auch oft gesehen. Ich will noch genauer auf den Punkt 
eingehen wo dabei noch groß geschummelt wird. Ein Prinzip in Scrum ist 
dass man erst einen Sprint (ungestört!!!) beenden muss bevor die nächste 
Aufgabe angegangen werden darf. In der Praxis funktioniert das selten, 
es kommen immer Aufgaben dazu die "nebenbei" anfallen, selbst das 
Führungspersonal das Scrum eingeführt hat, hält sich selbst nicht dran 
und kommt immer wieder mit dem neuen Kramm. Dann heißt es aber, man 
solle einen Sprint einführen der ca. 70% der Auslanstung entspricht, 
dann kann man nebenbei noch Aufgaben machen.

In großen Firmen sehe ich immer BWL-ler die nur Scrum einführen können. 
Die sitzen nur da und suchen z.B. keine neue Marktanteile oder neue 
Möglichkeiten für die Firma. Sobald die Flaute kommt, rechnen sie um wie 
viele sie entlassen müssen. Darin sehen sie schon ihre Aufgabe erfüllt.

Der Andere schrieb:
> Ecce homo schrieb:
>> Der Andere schrieb:
>>> Wenn jeder ein bischen über den
>>> Tellerrand geschaut und das ganze Problem im Blick gehabt hätte wäre das
>>> nicht passiert.
>>
>> Ja wenn jeder den Gottgleichen IchStehÜberAllen Blick eines 5
>> Sterne-Projektmanager hat managed sich jedes problem wie von alleine und
>> zur universalen Zufriedenheit.
>
> Ich sage "ein bischen über den Tellerrand blicken"
> Du interpretierst: "Gottgleichen IchStehÜberAllen Blick"
>
> Welches Problem hast du? Verstehendes Lesen? Kann man lernen


Na dann hast Du ein problem mit "verständlichen Schreiben" den Du 
schreibst:

"das ganze Problem im Blick gehabt"

den genau das geht beim Projekten die nicht von einem einzelnen 
bearbeitet werden nicht mehr. Das ist die Aufgabe des PM der sich bei 
SCRUM gern mit der bemerkung "Schaut über den tellerand" aus der 
verantwortung schleicht.

Im im Bild zu bleiben Mit den Blick über den tellerrand erblickt man nur 
den Tellarand des anderen aber nicht das Problem in Gänze.

Das kann nur der PM der nicht zu 110% vom Tagesgeschäft aufgefressen 
wird wie der Coder in seinem Cubicle.

Ecce homo schrieb:
> Das kann nur der PM der nicht zu 110% vom Tagesgeschäft aufgefressen
> wird wie der Coder in seinem Cubicle.

Gehts nur mit Buzzwords? Und mir willst du nicht verständliches 
Schreiben vorwerfen? ROFL!

Im Gegensatz zu dir bin ich schon über 20 Jahre im Geschäft und habe 
genau solche funktionierende Projekte gesehen, genauso wie Projekte die 
trotz oder wegen Wasserfall oder agilem Ansatz die vor die Wand gingen.

Ecce homo schrieb:
> Das ist die Aufgabe des PM.
Der PM behält den kompletten Überblick. Aber wenn du an einer 
Schnittstelle rumwurstelst ohne den anderen, der für die Gegenseite 
verantwortlich ist,  gefragt zu haben ob es so passt, dann bist du der 
typische Scheuklappenprogrammierer, der die Hände in den Himmel streckt 
und ruft "Ich wars nicht" wenn das Projekt gegen die Wand gefahren ist.

Der Andere schrieb:
> Ecce homo schrieb:
>> Das kann nur der PM der nicht zu 110% vom Tagesgeschäft aufgefressen
>> wird wie der Coder in seinem Cubicle.
>
> Gehts nur mit Buzzwords? Und mir willst du nicht verständliches
> Schreiben vorwerfen? ROFL!

Du weisst nicht was Buzzwords sind, in den zitierten Text findet sich 
kein Einziges.

Das Kommunikation nicht die Lösung sondern nur Mittel zum Zweck sind 
scheint dir auch nicht geläufig. Was das prinzip Divide et impera im 
Team bedeudet hast Du offensichtlich auch nicht kapiert - Hinweis Über 
den Tellerrand schauen und dabei kommunizieren ist kein "impera" - also 
Beherrschung (des problems).

Der Andere schrieb:
> Im Gegensatz zu dir bin ich schon über 20 Jahre im Geschäft und habe
> genau solche funktionierende Projekte gesehen, genauso wie Projekte die
> trotz oder wegen Wasserfall oder agilem Ansatz die vor die Wand gingen.

Der gegensatz zwischen uns besteht nicht in der berufserfahrung  gleich) 
sondern eher im Verantwortungsbewusstein und im Umgang mit 
Bauernschlauen Weisheiten (übern Tellerrand ...)

MfG,

Ecce homo schrieb:
> Der gegensatz zwischen uns besteht nicht in der berufserfahrung  gleich)
> sondern eher im Verantwortungsbewusstein

Der Unterschied besteht wohl eher darin, dass du BWLer bist und noch nie 
entwickelt hast.
Ich beende die Diskussion hier ist völlig sinnlos geworden.

Mark B. schrieb:
> progger schrieb:
>> -) Scrum ist nicht für alle Projekte geeignet. Für die hier genannten
>> Projekte im Ausmaß von 4 Manntagen, oder wenn eh schon alles komplett
>> spezifiziert ist (dann kann man es gleich den Indern geben)
>
> Ich habe noch nie ein SW-Projekt gesehen, in dem wirklich alles komplett
> spezifiziert war. Gibt es sowas?

Ja, und zwar bei Projekten, wo es gar nicht anders geht, weil sie 
komplett nach Indien outgesourced werden.

Wir verwenden prinzipiell Scrum, jedoch wird das in seit einiger Zeit 
ein wenig vernachlässigt.
Der hohe Zeitdruck im Projekt, die chronische Unterbesetzung und der 
ständige Richtungswechsel vom Management machen es aktuell (und in den 
letzten 6 Monaten) recht schwierig, Prioritäten zu setzen.
Die Tasks, die jeder bearbeitet, sind mittlerweile viel zu groß und bis 
auf das tägliche Meeting ist nicht mehr viel von Scrum zu erkennen.
Aber 2016 wird alles besser ;-)

Konrad schrieb:
> Ja, und zwar bei Projekten, wo es gar nicht anders geht, weil sie
> komplett nach Indien outgesourced werden.

Warum sollte man beim outsourcen nach Indien irgendetwas spezifizieren ? 
Die machen doch sowieso alles wie sie gerade lustig sind. Selbst wenn du 
ordentliches Englisch schreibst, wird es kulturell bedingt dort nicht 
gelesen aber ständig betont daß sie alles verstehen und hochrangige 
Experten alles detailgenau umsetzen und es kommt ein ganze anderes 
Produkt zurück. BTDT.

Inder kannst du knicken, Ex-UdSSR ist deutlich besser.

Jan H. schrieb:
> ei einem agilen Prozess beides zu fixieren, und dann dem Kunden alle
> Änderungen gestatten, weil agil, geht natürlich in die Hose.

Ja klar!
Kommt mir bekannt vor!
Am liebsten alles dem Kunden gestatten, Anforderungen über Bord 
schmeißen, wir sind ja agil. Kein Problem.

Die Verkäufer haben verkauft, wir Entwickler sind die blöden.

Bei uns war es am Schluss gar kein Scrum mehr.

Es wurden einfach Zettelchen auf ne Wand geklebt und dann wenn wer 
fertig wurde hat der den Zettel auf fertig gehängt. Oder es wurden 
welche Zettel (Tasks) vergessen ;-)

Am Schluss wars einfach eine mehr oder weniger vollständige Todo Liste 
:-)

michl42 schrieb:
> Hi,
>
> ein aus meiner Sicht lesenswerter Artikel zu Scrum&Agile:
>
> 
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

Das war gut!

Können wir den Thread schließen und sagen, Scrum ist ein unnützes 
neumodisches K*ck Zeug, womit irgendwelche Bwler damit rumwerfen und es 
nur für Juniorentwickler entworfen wurde, um damit sinnloses 
Micromanagement zu betreiben?

Hi,

das wollte ich damit nicht sagen.
Für eine Krisensituation ist es ok.

Für eine Standard-Situation ist es aus den aufgeführten Gründen nicht 
mein Fall.

klausi schrieb:
> Können wir den Thread schließen und sagen, Scrum ist ein unnützes
> neumodisches K*ck Zeug,
> womit irgendwelche Bwler damit rumwerfen und es

Nö, damit beschuldigst du die Falschen. Nach meiner Erfahrung sind es 
aufstrebende Ingenieure und Informatiker die per reverse MURCS versuchen 
die Karrierleiter nach oben zu fallen.

> nur für Juniorentwickler entworfen wurde, um damit sinnloses
> Micromanagement zu betreiben?

Das kommt der Wahrheit schon näher

MfG,

Das ist nicht nur für Projekte. bei meinem oem wird das als firmen 
politik inklusive führung so eingeführt. Ihr könnt euch vorstellen, was 
das bedeutet, wenn die ganze Organisation so ist.
Vielleicht muss ich doch nach anderen jobs woanders schauen..

Was ist eigentlich aus Iso 9001 und Six Sigma geworden?

> Da gibts ja noch Kanban, Kaizen, Lean und wie sie alle heißen....

Just-in-time nicht zu vergessen.

Ich finde das cool:

SCRUM <-> MURCS ;-)

klausi schrieb im Beitrag #4347180:

> Da gibts ja noch Kanban, Kaizen, Lean und wie sie alle heißen....

Oder im Sichherheitskritischen Bereich:
DO-178, V-Modell XT; mit Schwerpunkt auf den gesamten SW-life cycle IEEE 
12207 ...

Sichherheit ensteht eben nur wenn alles aufeinanderpasst.

Der Ansatz von SCRUM widerspricht dem zum Teil. "Wir wissen nicht was 
der Kunde will also zeigen wir ihm jede Woche was wir so gemacht haben 
und er kann dann sagen was ihm daran gefällt." So was funktioniert bei 
Wischi Waschi
Oberflächen und macht da auch bei Kunden mit geringer (visueller) 
Vorstellungskraft Sinn.

IMHO kommt bei SCRUM die Team-Aufstellung, Einarbeitung und "Schaffen 
des Environments"-Phase zu kurz bzw. wird komplett ignoriert. Deshalb 
scheitern ja auchso viele zusammengewürfelte ANÜ-Teams vom 
Dienstleister.

MfG,

Andreas E. schrieb:

>  und da hatte ein Kunde die Begriffe agil und Sprint falsch
> verstanden.

IMHO ist das die schlechteste und dümmste Ausrede bei der 
Projekt-Retrospective: " Der Kunde hat SCRUM falsch verstanden "

Warum hat man dann SCRUM angeboten bzw. durchgezogen wenn SCRUM und die 
Vorstellungen des Kunden nicht zusammenpassen? Klar SCRUM verleitet dazu 
utopische Vorstellung des kunden über kurze Lieferfristen ernst zu 
nehmen, weil SCRUM ja auf vielen inkrementellen Lieferungen aufbaut: 
Nach jedem Sprint kann man was präsentieren und den Kunden beruhigen. 
Die Zeit bis zur Abschlußlieferung wird aber dadurch auch nicht mehr, 
über Qualität kann zu schweigen.

MfG,

Andreas E. schrieb:
> Ich glaube, aus vielen Aussagen hier eine gewisse Unzufriedenheit mit
> der eigenen Situation heraus klingen zu hören. Ist es denn wirklich so
> schlimm?

Und was soll falsch sein an der Unzufriedenheit? Jeder postet seine 
Erfahrung dazu, ich glaube nicht dass SCRUM automatisch gute Laune 
verursacht, dafür wurde es schließlich nicht erfunden.

PS: Übrigens ist bei SCRUM kein menschlicher Faktor drin. Kein einziger.

Andreas E. schrieb:

> Mir ist nur das Maß der Unzufriedenheit aufgefallen,
> und das ist imho ziemlich hoch. Überraschend für mich,
> denn aus meiner täglichen Arbeit kenne ich das anders.

Ach naja, die Erklärung ist, glaube ich, nicht kompliziert:

1)
Wir sind hier in "Ausbildung, Studium & Beruf". Hier muss
aus Prinzip ALLES in Grund und Boden diffamiert werden.

2)
Offensichtlich wird von diversen Führungskräften viel
Schotter unter der Flagge "SCRUM" verkauft, der mit dem
ursprünglichen Geist der Methode wenig bis nichts gemeinsam
hat.
Wenn z.B. eine von SCRUM Betroffene klagt, dass "das
Vorbereiten der täglichen Präsentation unheimlich viel
Zeit kostet", dann fragt man sich schon ernsthaft, welches
Märchenbuch deren Chefs gelesen haben. Wo im agilen
Manifest steht etwas von täglichen Präsentationen?

> Meine besten Projekte waren agil und mehr oder weniger
> scrum, sie lebten von der Flexibilität, vom Team und
> den einzelnen Menschen, die - so unterschiedlich sie
> auch waren - im Team mehr wert waren als die Summe
> der Einzelnen. Dass für einige vorher ein Erkenntnisprozess
> notwendig war, ist klar, aber ohne dieses Wir-Gefühl
> kann keine agile Methode funktionieren.

Ja. Ich denke, der Schlüssel liegt in der Erkenntnis,
dass agile Methoden weder für alle Aufgabenstellungen
noch für alle Teams gleichermaßen geeignet sind.

> [...] sonst wird gemockt dass die Schwarte kracht,
> und der Aufwand steigt ins Unermessliche.

Das ist wohl kein Privileg agiler Methoden. Nimm mal
an einem halbfertigen Wasserfall-Projekt eine halbwegs
tiefgreifende Änderung vor und beobachte den Aufwand...

Ach so, nochmal was anderes: Was sagst Du zu der Kritik,
SCRUM sei abzulehnen, weil es sich lediglich um einen
permanenten Krisenmodus handele?

Andreas E. schrieb:
> Das wollte ich auch gar nicht ausdrücken. Mir ist nur das Maß der
> Unzufriedenheit aufgefallen, und das ist imho ziemlich hoch.
> Überraschend für mich, denn aus meiner täglichen Arbeit kenne ich das
> anders.

Du verwechselst hier etwas. Die Postings über Scrum sagen gar nichts 
über Zufriedenheit/Unzufriedenheit allgemein. Es kann sein dass man im 
Allgemeinen zufrieden ist aber Scrum Scheisse findet weil man sich davon 
gestört fühlt. Ich finde nicht dass es sich widerspricht.

Und zum Thema "agil", was soll das eigentlich sein? Jedes Projekt was in 
guter Zusammenarbeit und unter Zeitdruck läuft, läuft agil. Man tut so 
als hätte man vorher geschlafen und jetzt höchst offiziell ganz "agil" 
und superschnell ist. So etwas kann doch nur ein BWL-ler glauben. Ohne 
den Quatsch mit Rechtfertigungen was man getan hat, Floor-Meetings und 
Zettelchen hatte man vorher mehr Zeit für eigentliche Arbeit.

Gästchen schrieb:

> Und zum Thema "agil", was soll das eigentlich sein?

Moment. Verstehe ich das richtig: Du diskutierst über
agile Methoden, ohne zu wissen, was agile Methoden sind?

> Jedes Projekt was in guter Zusammenarbeit und unter
> Zeitdruck läuft, läuft agil.

Quark.

Einer der wesentlichen Pfeiler agiler Methoden ist das
iterative Vorgehen.

Um es einfach und bildhaft zu machen:

"iterativ (agil)" - Heranwachsen eines Kindes
"klassisch (Wasserfall)" - Montage eine Lokomotive

> Man tut so als hätte man vorher geschlafen und jetzt
> höchst offiziell ganz "agil" und superschnell ist.

Au Mann...

> So etwas kann doch nur ein BWL-ler glauben.

Also, wenn Deine Chefs (oder gar Du selbst?) nicht den
geringsten Schimmer haben, was die Kernidee agiler
Methoden ist, dann sollte man das nicht den agilen
Methoden anlasten...

Warum Scrum keine gute Idee ist, Projekt-Destruktor und 
Motivations-Killer ist:

1. Agilität? -> :-) der Mensch kann gar nicht agil sein, der Mensch ist 
keine Maschine, jede Person hat sein Charakter, unterschiedliche 
Erfahrungen,
Gefühle usw. usw. Der Mensch wird krank.....

2. Die meisten Scrum Projekte scheitert, weil:
Man produktions/fertiguns-Methodiken 1:1 übernommen hat, bei denen ja 
grundsätzlich Material/Grundlagen-Forschung, Produktionsplanung, 
Rohstoffe usw. usw. komplett entwickelt und fertig sind, per Knopfdruck 
passiert alles reibungslos("generell"). Aus dem Gründen die im 1. Punkt 
genannt sind kann der Mensch all das garnicht realisieren, Krankheit, 
keine kompletten Vorgehensweisen, falsche Implementierungen, Dokus sind 
evtl. vorhanden aber nur Theorie geschweige denn praktisch 1:1 
umsetzbar, große Abhängigkeiten die Zeitkosten verursachen.

3. Scrum wird vor allem vom bezogenem Management ausnahmslos missbraucht 
und zwar von allen und in allen Projekten, Druck auszuüben und zu 
kontrollieren.

4. Commitments werden ignoriert

usw.

usw..

usw...

zunächst mal Verzeihung, dass ich erst jetzt wieder zurückkehre. Das 
Thema bleibt spannend. Wir haben uns in den letzen 6 Monaten schwer 
getan, mit dem Thema etwas Sinnvoll an zufangen. Egal, was unterrichtet 
und erklärt wird, das Verhalten ist eigentlich immer gleich:

Jeder weiß eigentlich, was gemeint ist, kann aber konkret nichts an 
seiner Arbeitstechnik finden, die er anpassen oder ändern könnte, um dem 
mehr gerecht zu werden.

Will meinen, die meisten denken, sie arbeiten bereits nach optimierten 
Methoden.

Bis jetzt hat es noch nichts gebracht, außer Arbeitsunterbrechungen für 
die Scrum-Schulungen. :-)


Mehr Meinungen erbeten.

Ist halt das übliche Modependel in der IT. Zuerst hat man einfach 
drauflosentwickelt. Dann stellte man fest, daß das ins Chaos führt. 
Daraufhin hat man Prozesse eingeführt, um festzustellen, daß man dann 
nicht mehr flexibel ist und der Overhead wächst. Dann will man die 
Prozesse wieder reduzieren und bemerkt, wieso man sie noch gleich 
eingeführt hatte.

Kurzum: Der Wunsch, immer komplexere Projekte einfach und berechenbar zu 
haben, ist einfach neben der Spur. Aber eine ganze Berater-Industrie 
lebt davon, die Illusion der Wunscherfüllung in immer neuen, wenn auch 
leeren Verpackungen zu verkaufen.

Ich kenne übrigens sowohl prozeßlastige Arbeitsweisen wie auch eher lose 
strukturierte. Letzteres hieß im Wesentlichen, daß die Entwickler sich 
selber organisiert haben.

Witzigerweise war das Endergebnis genau andersrum, als man es glauben 
würde. Aus strukturierten Prozessen wurde Chaos, weil Dinge nicht 
rechtzeitig bedacht wurden und die Leute entweder nicht miteinander 
geredet haben oder keiner wirklich den Weitblick hatte, die Spec auch 
wirklich tauglich zu schreiben. Und dann waren die Prozesse im Weg, um 
die Versehen schnell wieder geradezuziehen.

Das eigentlich unorganisierte Chaos wurde dagegen gut, weil die 
Entwickler sich geeinigt haben, welcher Teilcode wem "gehörte", wodurch 
man immer erst um Erlaubnis fragen mußte, wenn man da ranwollte. Das kam 
eigentlich zunächst als Notbehelf gegen Mergekonflikte, wuchs sich dann 
aber effektiv bis zu Designreviews aus. Völlig ungesteuert vom 
Management wohlgemerkt, welches diese Entwicklung einfach nur mit 
wöchentlichen abteilungsweiten Frühstücks"meetings" unterstützt hat, das 
war Selbstorganisation. Nur, dazu braucht man halt auch die 
entsprechenden Leute.

D. I. schrieb:
> ann man mit einem soliden kommt darauf an beantworten. Prozesse sind
> immer nur so gut wie sie von den beteiligten Personen verstanden und
> gelebt werden.
> Habe sowohl schon gute als auch schlechte Ausprägungen gesehen.

Je mehr die Prozesse den MAs nutzen um so mehr werden diese genutzt und 
gelebt.

Agile Entwicklung ist durchaus weit verbreitet.
SCRUM ist eine Variante davon.

Meine Erfahrung ist, dass der Begriff "Agile Entwicklung" von Managern 
vielschichtiger Konzerne gerne missbraucht wird, um geregelte Prozesse 
zu umgehen und die Schuld für Versagen den Entwicklern am unteren Ende 
der Hierarchie zuzuschieben.

Wenn Zeit oder Geld knapp werden, verfällt man plötzlich in flexible 
"agile" Arbeitsweisen, wo man auf Projektleitung und Dokumentation 
verzichtet. Wenn dann außenstehende erste Sorgen äußern, weist man 
darauf hin, dass SCRUM doch eine bewährte Methode sei und wir machen 
jetzt SCRUM. Was allerdings eine glatte Lüge ist.

> Mir scheint, dem SCRUM-Master wird eine verlogene Aufgabe gestellt

Allerdings, leider habe ich das häufig so erlebt.

Womit ich allerdings sehr gute Erfahrung gemacht habe, ist die 
"Matrixorganisation", die bei Vodafone in der Technik eingeführt wurde.

Jeder Abteilungsleiter hatte für seine Abteilung spezifische Ziele für 
deren Erreichung er belohnt wurde. Und die hat er auf seine Mitarbeiter 
verteilt. Also hat sich jede Abteilung gewollt primär um die Erfüllung 
dieser Ziele gekümmert. Damit waren Zeit und Budget in der Regel auch 
schon ausgelastet.

Nun gab es technische Projekte, an denen Mitarbeiter zahlreiche 
Abteilungen zusammen arbeiten mussten. Da aber die eigenen Interessen 
Vorrang hatten, liefen diese Projekte immer schlecht. Und doch hat jeder 
genau das getan, was man von ihm verlangte. Wer sich zu tief in ein 
Projekt reinhängte, vernachlässigte zwangsläufig die Ziele seiner 
Abteilung und brachte damit seinen Vorgesetzten um seinen Bonus.

In der danach neuen Matrixorganisation verdoppelte man quasi die 
Führungskräfte. Die Abteilungsleiter unterschrieben Urlaubsanträge und 
die neuen technischen Projektleiter waren nur jeweils 1-2 Projekte 
zuständig. Zu hatten dazu Budget und Weisungsbefugnisse. Wenn mein 
Abteilungsleiter mich für irgendeine Aufgabe haben wollte, musste er 
sich mit dem Projektöleiter abstimmen. Bei Ressourcen-Konflikten mussten 
sich die Projektleiter untereinander abstimmen - was wöchentlich 
regelmäßig passierte.

Es gab damals viele starke Bedenken gegen diese Matrix-Organisation 
(auch von mir), aber letztendich hat sie sich bewährt.

Warum ich das schreibe: In einer Matrix Organisation kann der technische 
Projektleiter den SCRUM Master spielen, denn er hat die dazu nötigen 
Mittel.

>> Ich habe noch nie ein SW-Projekt gesehen, in dem wirklich alles komplett
>> spezifiziert war. Gibt es sowas?

> Ja, und zwar bei Projekten, wo es gar nicht anders geht, weil
> sie komplett nach Indien outgesourced werden.

Habe ich erlebt. Da wurde eine tabellarische Ansicht von Datensätzen 
skizziert, mit Buttons für Löschen und Ändern. Nur hatte man vergessen, 
zu erklären, dass der "Löschen" Button den Datensatz daneben löschen 
soll.

Die "Inder" Lieferten also ein Web-Interface mit Löschbutton, der keine 
Funktion hatte. War ja so bestellt.

Wenn das die einzige Macke dieser Art gewesen wären, könnte man ja noch 
drüber lachen. Aber leider lief es so, dass nach Ablieferung ein Team in 
DE noch weitere 2 Jahre an dem Programm arbeiten musste, um es überhaupt 
benutzbar zu machen. 2 Jahre Zeit und Geld über dem Ziel - ein Desaster!

Und als wir dann fertig waren, guckten wir in 20 Enttäuschte Gesichter 
bei den Anwendern, da sich die Prozesse im Unternehmen inzwischen 
geändert haben und das neue Programm ist nun (mangels Anpassung) gar 
nicht besser, als das alte.

> SCRUM kann für bestimmte Arten von Projekten gut geeignet sein. Wenn zum
> Beispiel der Kunde selbst nicht so genau weiß, was er eigentlich will,
> kann man ihm nach jedem Sprint eine Software ausliefern und seine
> Rückmeldungen in den nächsten Sprint einfließen lassen. Das setzt
> freilich voraus, dass der Kunde aktiv am Projekt mitarbeitet und
> regelmäßig entsprechende Rückmeldungen gibt.

Sehr gut, das müsste man in jede Ausgabe des Manager Magazins schreiben.

Reinhard S. schrieb:
> Mich würde interessieren, wo bei euch (und ob überhaupt) bereist SCRUM
> eingesetzt wurde, um Projekte zu managen.
Ich kennen keinen Laden mehr der das NICHT einsetzt, jede kleine 
Klitsche nutzt das inzwischen.

> Meinungen zu dem System sind wilkommen.
Hatten wir das nicht erst.


> Vor allem würde mich interessieren, wo das System eingeführt
> oder angedacht - und dann wiede abgeschafft wurde.
Ich kenne keinen Laden wo das wieder abgeschafft wurde. Vielleicht etwas 
in den Details ewtwas angepasst aber im Prinzip immer noch SCRUM.

Mir kommt es vor, als wäre SCRUM von und für Entwickler ausgedacht 
worden, aber die ganze Firma und der Kunde sollen mitspielen. Denn sonst 
funktioniert SCRUM nicht.

Nur: In welcher Welt bestimmen die Entwickler, wie es läuft?

In meiner nicht. Also beschränkt man sich bei der Anwendung von SCRUM 
auf den Bereich der Entwickler, und genau deswegen funktioniert es 
nicht.

Agile Entwicklung ist Ok, aber nach SCRUM Methode hatte ich leider noch 
kein Erfolgreiches Projekt miterleben dürfen.

Stefan U. schrieb:
> Mir kommt es vor, als wäre SCRUM von und für Entwickler ausgedacht
> worden

Nein, es ist vor allem so bliebt, um die Leistung der 
Programmiererschaft in betriebswirtschaftlichen Zahlen messen zu können, 
"Velocity" ist wichtig, die Richtung in die es geht eher nicht.

Stefan U. schrieb:
> Agile Entwicklung ist Ok

Nicht wirklich. Jede Änderung der Aufgabenstellung kann ggf. zur 
zunichtemachung aller bisherigen Arbeit führen, bedeutet also deutliche 
Mehrarbeit, verlängerte Projektlaufzeit, mehr Kosten, Arbeit für die 
Katz. Mit einer Entwicklung anzufangen, obwohl Kunden und Architekten 
nicht klar ist was das Projekt enthalten soll, ist halt voreilig. Agil 
ist nur nötig, wenn man es mit Leuten zu tun hat die nicht wissen was 
sie wollen oder können, (das hat man natürlich oft genug).

Mark B. schrieb:
> SCRUM kann für bestimmte Arten von Projekten gut geeignet sein. Wenn zum
> Beispiel der Kunde selbst nicht so genau weiß, was er eigentlich will,
> kann man ihm nach jedem Sprint eine Software ausliefern und seine
> Rückmeldungen in den nächsten Sprint einfließen lassen.

Jein. Wer regelmässig etwas vorzeigbares abliefern soll, baut keine 
Strukturen die einen guten Unterbau liefern, sondern baut schnell in die 
Höhe. Auch wenn ihm dann die Hilfsmittel fehlen, um den zeiten Turn 
daneben mit weniger Aufwand setzen zu können. Typischer Fall sind 
Dialoge oder Datenbanken: Da wird Dialog für Dialog gebaut, oder 
Datenbanktabelle für Datenbanktabelle, bloss mit den Hilfsmitteln die 
sowieso schon vorlagen also vom Softwarehersteller (ob Microsoft oder 
SAP, ..) , weil das ja vorzeigbarer Fortschritt ist, an statt erst mal 
Strukturen zu schaffen, die dann Dialoge und Datenbanktabellen im 
Idealfall automatisch generieren, zumidnest aber deren Daten automatisch 
hinein und hinaustransportieren. Weil dieser Unterbau ja für sich nicht 
lauffähig und vorzeigbar ist.

MaWin schrieb:
> Weil dieser Unterbau ja für sich nicht lauffähig und vorzeigbar ist.

Vor allem nicht vorzeigbar. Hauptsache man hat jede Woche etwas was man 
dem Chef, dem Vertriebler, dem Kunden oder sonstigen Personen für die 
ein Taschenmesser schon high tech ist "zeigen" kann.

> Agil ist nur nötig, wenn man es mit Leuten zu tun hat
> die nicht wissen was sie wollen

Ist das nicht fast immer der Fall? Deswegen meine ich ja, dass agile 
Entwicklung Ok ist. Denn wer nicht mit macht, sitzt draußen vor der 
Türe.

> Weil dieser Unterbau ja für sich nicht lauffähig und vorzeigbar ist.

Die wichtigen Personen interessieren sich ohnehin eher für Powerpoints, 
die super komplex und doch nachvollziehbar wirken. Ich sage nur SAP 
Hybris...

> Indem fähige Entwickler, die keine Vollnerds sind sondern die
> mit Menschen sprechen können :-) mit dem Kunden reden und ihm
> Vorschläge für seine Aufgabenstellung machen.

Ich bin immer dankbar, wenn es solche Menschen im Projekt gibt, die mir 
(kommunikationsmuffel, nerd, programmierer) den Rücken frei halten.

Jan H. schrieb:
> Leute wie Mawin glauben dann der Schrott wäre SCRUM.

Hallo Trottel.
Hättest du meine Beiträge gelesen

MaWin schrieb:
> Quasi jeder macht Scrum - oder was er dafür hält.

würdest fu meinen Namen hier nicht nennen.
Aber Trottel wie du sondern ja meist auch nur einen Sstz ab:
"Wenn Scrum schief geht, liegt es nur daran, dass ihr nicht 100% Scrum 
nach der reinrn Lehre gemacht habt - denn Scrum ist per Definition 
unfehlbar, nur die Mitarbeiter unfähig"

Das ist dann so wie mit dem Sozialismus dem du noch nachweinst...

Reinhard S. schrieb:
> Meinungen zu dem System sind
> wilkommen. Vor allem würde mich interessieren, wo das System eingeführt
> oder angedacht - und dann wiede abgeschafft wurde.

Hallo Reinhard,

in der Regel wird Scrum dort eingeführt (wenn man es überhaupt richtig 
aufsetzt) wo gleichwertige wiederkehrende Tätigkeiten anfallen, z.B. im 
Softwarebereich. Scrum macht eher Sinn für unerfahrene Mitarbeiter die 
richtige Kommunikation noch nicht drauf haben, Erfahrene brauchen Scrum 
nicht und ihre Arbeitsergebnisse sind sogar ohne Scrum besser da Scrum 
hier eher Grundlast ist. Bei enger Zusammenarbeit mit Kunden mit hoher 
Flexibilität ist Scrum nicht möglich, so viel muss gesagt werden.

Es gibt auch Härtefälle mit Scrum: oft fallen die Chefs auf das 
Versprechen der Unternehmensberater rein dass der Gewinn größer wird und 
dass sie und die Führungskräfte weniger arbeiten werden (die 
Organisation rutscht in Scrum nach unten ab) und Scrum wird als 
universelle neoliberale Wunderreligion verstanden die alle Probleme 
löst, und wird dort eingeführt wo sie nichts zu suchen hat. Scrum hat 
keinen menschlichen Faktor drin und sieht eher einen Akkord-Ablauf vor, 
auch jegliche Kritik für Scrum ist nicht zugelassen. (Diktat)

Fazit: bei Scrum wird typischerweise aus einer Mücke ein Elephant 
gemacht. Für effizientes Arbeiten mit nachvollziehbaren Tätigkeiten und 
angemessener Kommunikation reichen schon ein Paar einfache Tools, die 
Pseudoreligion der Basarwirtschaft ist hier kein Muss.

Liebe Mitarbeiter,

heute stellen wir unsere Entwicklung auf SCRUM, UML und NoSQL 
Datenbanken um. Sie werden alle drei Wochen geschult und danach werden 
wir das Vorbild für die Industrie 5.0 im internationalen Markt sein.

Die Kosten für die Schulungen werden Ihnen vom nächsten Leistungsbonus 
abgezogen - Wirtschaftliche Rahmenbedingungen zwingen uns leider zu 
diesem Schritt.

James, bitte fahren Sie den Jaguar vor und lassen sie den Schneider 
kommen, ich möchte heute Abend beim Meeting auf den Seychellen 
angemessen erscheinen. Ach und Frau Meier, stornieren Sie das Essen im 
Steigenberger, ich muss noch den Heli für die Benefizgala auswählen.

Nun denn, liebe Mitarbeiter: Frohes schaffen!

Jan H. schrieb:
>> "Wenn Scrum schief geht, liegt es nur daran, dass ihr nicht 100% Scrum
>> nach der reinrn Lehre gemacht habt - denn Scrum ist per Definition
>> unfehlbar, nur die Mitarbeiter unfähig"
>
> Nein, ich sage wenn man irgendetwas macht, SCRUM draufschreibt, und dann
> geht es in die Hose, dann ist nicht SCRUM schuld.
> Meiner Erfahrung nach machen nur die wenigsten, die es behaupten,
> wirklich SCRUM. Diejenigen, die es ordentlich durchziehen, fahren sehr
> gut damit.

Vielen Dank für die Bestätigung meiner Vermutung.

https://www.quora.com/In-a-nutshell-why-do-a-lot-of-developers-dislike-Agile/answer/Miles-English?srid=i5M8&share=1

Hier im Forum können die wesentlichen Probleme, die man mit Scrum 
Projekten (oder agil im Allgemeinen) so haben kann und die zu negativen 
Denken darüber führen, ziemlich genau beobachtet werden :).

Wir entwickeln embedded Projekte nach Scrum, und auch hier kann man 
relativ gut damit arbeiten.
Zu den Problemen, die meiner Meinung nach hier implizit geäußert wurden, 
und die zu einem eher negativen Meinung führen:

1) Scrum wird (von unwissendenden) gerne als Allheilmittel gesehen. Das 
ist es aber nicht. Auch eignet sich Scrum nicht für jedes Projekt 
(Projekte die ein festes Pflichten-/Lastenheft mit festen Zeitpunkten 
haben sind eher nicht geeignet). Da das hier  aber eher ein Forum für 
Ingenieure ist, ist tendentiell IMHO die falsche Zielgruppe betroffen 
(es soll möglichst viel planbar sein, deswegen auch 
Pflichten-/Lastenheft). Scrum ist ein Vorgehensmodell das, richtig 
angewendet, sehr zielstrebig funktioniert. Leider soll aber nicht der 
Kunde sagen können, ich will das xy bis zum 10.12. fertig ist. Das ist 
eher eine Entscheidung des Teams, was für viele Softwareprodukte 
überhaupt kein Problem ist (z.B. Officeprogramme: Feature xy gibts 
vielleicht in Release 1.2, wenns aber erst in 1.21 kommt ist das auch 
nicht schlimm), aber für typische Embeddedprodukte einfach nicht 
funktioniert.

2) Scrum wird gerne als "Unorganisiert" dargestellt, das einem Planung 
abnimmt. Meiner Meinung nach (ich habe sowohl positive als auch in 
Firmen negative Erfahrungen gemacht), ist es eher umgekehrt. Scrum 
braucht unglaublich viel Disziplin und Planung, aber nicht alles in 
einer Hand. Der Product Owner muss sich darum kümmern um mit dem Kunden 
auszumachen, welche Features er haben will (inkl. Priorisierung). Aber 
das Team entscheidet, bei welchem Sprint was mit reinkommt. D.h. der 
Kunde hat keinen direkten Einfluss darauf, was gemacht wird. Durch die 
kurzen Zyklen muss gleichzeitig das ganze Team sehr strukturiert 
arbeiten, weil schwere Fehler in max. 4 Wochen quasi nicht behebbar 
sind. Scrum verlangt viel Planung, aber diese ist in kürzen Abständen 
(eigentlich leichter planbar). Gleichzeitig braucht man auch einen 
groben Gesamtplan.

3) Gruppengröße. Kurz und Knapp. Ein Scrum Master + Product Owner ist 
Pflicht, dazu noch 4- 7 Entwickler. Mehr macht keinen Sinn. Hier wollen 
Firmen gerne sparen und machen größere Gruppen oder wollen sich den 
Scrum Master (der ja effektiv nicht direkt für die Firma was erbringt) 
sparen. Das ist Bullshit. Oder der Scrum Master ist ein Entwickler. Auch 
das ist nicht förderlich, sondern macht das Ding kaputt.

4) Managment: In größeren Firmen geben Vorgesetzte ungern Verantwortung 
nach unten ab. Geht da nämlich was schief, rollen Köpfe. Das ist ein 
weiteres Problem. Mangelndes Vertrauen, jeder will sich immer nur 
absichern (kommt auch schon mal innerhalb des Teams vor). Dann 
funktioniert sowas natürlich nicht. Leitende Angestellte mischen sich 
dann ein, erteilen "Befehle" (Feature xy muss noch rein, wenn das nicht 
passiert, dann gibts aufn Latz). Sowas ist scheiße und zeugt davon, dass 
derjenige von Scrum keine Ahnung hat. Dann braucht man sich nicht 
wundern wenn was schiefgeht.

5) Erfahrung: Bei meiner BA haben die Abteilungen auch nach "Scrum" 
gearbeitet. Natürlich nur so halb... Nach meiner Frage, wer den der 
Scrum Master ist: "Den brauchen wir nicht. Bei Problemen geh doch zu 
deinem Vorgesetzten". Genau das macht Scrum kaputt.

Stefan U. schrieb:
> Liebe Mitarbeiter,
>
> heute stellen wir unsere Entwicklung auf SCRUM, UML und NoSQL
> Datenbanken um. Sie werden alle drei Wochen geschult und danach werden
> wir das Vorbild für die Industrie 5.0 im internationalen Markt sein.

Hallo,

vielleicht als Tipp für einen angehenden "Scrummer": stelle sicher dass 
eure Sprints für 100% Auslastung ausgelegt werden. Wenn das nicht so 
ist, werdet ihr neben eure Sprints noch Nebenaufgaben erledigen müssen, 
wenn beispielsweise euer Gescrumme auf 70% Auslastung ausgelegt ist. So 
guckt manch ein "Scrummer" ganz schön erstaunt aus der Wäsche wenn er 
zum Sprint noch eine schöne Aufgabe bekommt. Schöner Trick, was?

Gruß.

Mark B. schrieb:
> ui schrieb:
>> Wir entwickeln embedded Projekte nach Scrum, und auch hier kann man
>> relativ gut damit arbeiten.
>
>> Das ist
>> eher eine Entscheidung des Teams, was für viele Softwareprodukte
>> überhaupt kein Problem ist (z.B. Officeprogramme: Feature xy gibts
>> vielleicht in Release 1.2, wenns aber erst in 1.21 kommt ist das auch
>> nicht schlimm), aber für typische Embeddedprodukte einfach nicht
>> funktioniert.
>
> Sehe ich da einen leichten Widerspruch? ;-)

Schon leicht. Da wir aber (als Team) von Anfang an die Dinge richtig 
geregelt haben (auch nach "oben" hin), funktioniert das bei uns (bis 
jetzt, ca. 9 Monate) richtig gut.

Ich krieg jeden Tag meherere solcher Mails.
Lösch ich einfach.

> Ich krieg jeden Tag meherere solcher Mails.

Was für Mails? Meinst du Werbung für SCRUM Seminare?

Reinhard S. schrieb:
> Mich würde interessieren, wo bei euch (und ob überhaupt) bereist SCRUM
> eingesetzt wurde, um Projekte zu managen. Meinungen zu dem System sind
> wilkommen. Vor allem würde mich interessieren, wo das System eingeführt
> oder angedacht - und dann wiede abgeschafft wurde.

SCRUM ist doch nur eine weiterer schwachsinniger Hype, von Consultants, 
Fachzeitschreiften, Buchverlagen und Softwareherstellern inszenizert, 
weil die ständig eine neue Sau durchs Dorf treiben müssen, um Geld zu 
verdienen.

Bei uns wurde SCRUM eingeführt und dann wieder abgeschafft, weil es 
nicht funktioniert hat. Später nach einem Projektleiterwechsel wurde es 
erneut eingeführt. Aber ich musste Gott sei Dank nicht mehr an diesen 
schwachsinnigen Meetings teilnehmen, wo sowieso immer nur dieselben 
zwei, drei Leute ihr Maul aufgerissen haben. Aber da ich nicht mehr 
teilnehme, weiß auch nicht, ob es diese Meetings überhaupt noch gibt 
oder ob das schon wieder abgeschafft wurde.

Wenn ich das so lese, kann ich nur sagen, dass jeder offenbar ein völlig 
anderes Bild von SCRUM hat und es überall unterschiedlich gelegt wird.

Und: Ich sehe, dass wieder viel bullshit bingo betrieben wird.

Neue Begriffe für alte Fakten in neuen Schläuchen!

Ich habe mich inzwischen näher damit befasst. Allerdings sehe Ich bei 
eigenen Erfahrungen und auch in der Literatur so richtig Neues nicht.

Gute Idee. Praktische Bücher, wenn es geht.

Keiner einen Vorschlag?

Bücher kann Ich Dir da keine empfehlen, wenngleich es etliche gibt, aber 
eine Latte an Erfahrungen mit dem Thema habe Ich, die Ich Dir gerne 
weitergebe:

SCRUM ist für mich nichts anderes, als dem unorganisierten Chaos in 
vielen Firmen einen Namen zu geben, damit es besser klingt. Die Methoden 
sind oft nicht wirklich "agil" oder gar "schnell", sondern es ist 
oftmals langsamer und weniger effektiv.

Von den ständigen und vor allem täglichen Abstimmungen halte Ich 
überhaupt nichts. Da stehen nur alle passiv in der Gegend herum und 
erzählen, was sie gerade gemacht haben und was sie tun wollen. Richtig 
in die Tiefe geht das nicht und nutzen tut es auch keinem wirklich, weil 
es nur der Aufgabendeklaration und -Verfolgung dient. Kaum einer hat 
wirklich Überblick, was der andere wirklich tut und kann ihm auch nicht 
helfen oder gar Tipps geben. Meist kommen nur kluge Kommentare und 
allseitiges Kopfnicken, was aber oberflächlich und oft falsch ist. Nur 
fundiertes Wissen über Details befähigt zur Stellungnahme. Alle anderen 
halten bei dem detaillierten Vorgehen besser die Klappe und kümmern sich 
um ihr Arbeitspaket. Sinn macht es im Grunde nur für den Projektleiter, 
damit er die Infos beitreiben kann, um die Koordination zu leisten, aber 
das könnte er auch anders tun. Viele "Scrum Master" machen es so, dass 
sie ganze Wände mit bunten Zetteln vollkleben, auf denen die Aufgaben 
und Stati notiert sind, damit es schön dynamisch aussieht. Ausser in den 
Meetings kuckt da aber keiner drauf, um Fortschritte an Projektaufgaben 
zu erkennen und sich darauf takten zu können, daher ist der Wert Null. 
Real meldet man das Ende eines Tasks dann doch, wenn er fertig ist, 
damit der andere es direkt erfährt und nicht erst am nächsten Tag im 
Meeting.

Vor allem ist es zeitlich sehr ineffektiv: Während einer redet, hören 
die anderen zu, können aber mit der Info nichts rechtes anfangen, weil 
sie die Details nicht kennen und von dem lediglichen Beschluss einer 
Aufgabenstarts nichts haben. Stattdessen unterhalten sie sich privat, 
schaukeln auf dem Stuhl herum, bis sie dann sind und überlegen sich bis 
dahin, wie sie am intelligentesten ihre Defizite an ihrem Vorankommen 
verstecken können und sich trotzdem toll präsentieren können, um 
eventuelle Rückfragen zu vermeiden. Kritisches Nachfragen zu Lösungen 
wird ohnehin abgewimmelt, teils zu Recht - teils zu unrecht.

Egal wie, am Ende wurschtelt doch wieder jeder vor sich hin und 
organisiert sich selber, weil irgendwas anders läuft, er es nicht 
geplant hat, nicht voraussehen können oder weil ihm was fehlt. Besser 
ist es, man organisiert die Arbeitspakete so, dass die Leute mal 3 Tage 
arbeiten können, ohne sich synchen zu müssen. Nur das ist effektiv. Dann 
kann jeder ungebremst durch SCRUM seine eigenen Planänderungen lokal 
durchziehen ohne andere mit abzubremsen.

SRUM ist daher mit der Art der Durchführung eine Methode, die ihrem 
eigenen Anspruch im Wege steht! Statt grobe short- und long-Task in 
"sprints" und "claims" zu organisieren und diese stündlich zu überwachen 
um ständig die Orga anzupassen, wäre es besser, die Tasks genauer zu 
beschreiben, diese länger aufzuziehen und eine Person gleichzeitig auf 3 
Tasks zu setzen, die sie mit den jeweiligen members lokal organisiert, 
um auf deren Schwankungen einzugehen.

Ich als Selbständiger habe dann auch nicht das Problem, ständig anwesend 
zu sein, um dann doch nichts vom Meeting zu haben, ausser irgendwo 
eingeplant zu werden, was dann doch nicht funktioniert, weil das team 
member überzieht, nicht anwesend ist und mir dann schnell was anderes 
zugewiesen wird, damit ich keinen Leerlauf habe. 30% der Zeit geht so 
fürs Planen drauf und fürs Umplanen und Ändern oder das Wegwerfen 
nutzloser Vorausarbeit oder Vorausdenken oder Absprachen eines Tasks, 
der schon einen Tag später wieder verworfen wird. Die Task selber sind 
dabei aber so überflächlich definiert, dass die formelle Darstellung am 
Tableau eher verwirrt und Chaos verursacht, z.T. zu Fehlschlussfolgerung 
führt.

Was hingegen nötig wäre, ist eine sinnvolle Aufteilung der Arbeit in 
kleine abgeschlossene Blöcke, die aber ausreichend lang sind umd dann 
selbständig und alleine ohne andere geleistet werden können, damit die 
Anzahl der Schnittstellen und Absprachen klein bleibt. Das eigentliche 
Ziel einer Projektleitung muss daher sein, das Projekt zu "entscummen", 
d.h. die Notwendigkeit der Absprachen zu reduzieren.

Innerhalb einer solchen long term Aufgabe muss sich dann jeder selber 
organisieren und sich ad hoc mit den anderen absprechen. Das geht aber 
nicht im daily scrum meeting. Das nimmt den Leuten nur Arbeitszeit weg 
und mindert die Leistung. Es blockiert auch die Terminoptionen für 
gegenseitige Absprachen untereinander.

Diese sind aber die wichtigen und sie müssen dann geführt werden, wenn 
sie anfallen. Wenn Ich aber sehe, wie oft die Leute (vor allem der PL 
und der TL) in den standardisierten meetings sitzen, hat kaum einer die 
Chance, irgendwas zu planen oder zu organisieren. Die rennen dann alle 
schnell zurück zum Arbeitspaket und machen dann dort weiter, wo es 
gerade geht und versuchen dabei krampfhaft den nächsten Termin zu 
schaffen. Je mehr Orga-meetings es gibt, desto weniger gut ist die Orga 
und desto unorganisierter ist das Projekt.

Am Ende hängt es nämlich einzig daran, wie effektiv die Einzelnen sich 
Ausserhalb des Meetings absprechen und das geht nicht so, dass man alle 
halbe Stunde quatscht!  Das geht nur so, dass man sich mal eine halbe 
Stunde zusammensetzt, ein Ziel dfiniert und dann die nächsten Tage 
gezielt drauf hingearbeitet wird.

Für die wirklich wichtigen Dinge gibt es nämlich schrifltiche Doku wie 
Lasten-, Pflichten- und Designhefte, in denen die Anforderungen 
hineingeschrieben werden und zwar bitte detailliert und richtig. So hat 
es dort nur oberflächliche und falsche Darstellungen, die einem nicht 
helfen. Weder bei der täglichen Arbeit noch bei deren Organisation. Die 
Themen Integration und IB, welche traditionell die Loops aufwerfen, 
fordern sowie ein bug tracking System, wo die Tester was reinspielen 
können. Das alles geht online, über Datenbanken und gleichzeitigen 
Zugriff!

Bin genau deiner Meinung. Und würde noch folgendes hinzufügen.

Selbständiger schrieb:
> SRUM ist daher mit der Art der Durchführung eine Methode, die ihrem
> eigenen Anspruch im Wege steht! Statt grobe short- und long-Task in
> "sprints" und "claims" zu organisieren und diese stündlich zu überwachen
> um ständig die Orga anzupassen, wäre es besser, die Tasks genauer zu
> beschreiben, diese länger aufzuziehen und eine Person gleichzeitig auf 3
> Tasks zu setzen, die sie mit den jeweiligen members lokal organisiert,
> um auf deren Schwankungen einzugehen.
>
> Was hingegen nötig wäre, ist eine sinnvolle Aufteilung der Arbeit in
> kleine abgeschlossene Blöcke, die aber ausreichend lang sind umd dann
> selbständig und alleine ohne andere geleistet werden können, damit die
> Anzahl der Schnittstellen und Absprachen klein bleibt. Das eigentliche
> Ziel einer Projektleitung muss daher sein, das Projekt zu "entscummen",
> d.h. die Notwendigkeit der Absprachen zu reduzieren.

Ich finde, dass Scrum lediglich die Inkompetenz bzw. Faulheit derjenigen 
kaschiert, die eigentlich für die Anforderungserstellung und die 
Definition der Aufgaben zuständig sind. Das betrifft sowohl den 
Auftraggeber als auch den Bearbeiter/Auftragnehmer. Anstatt sich mal 
länger hinzusetzen und zu überlegen, was man denn haben möchte, wird 
damit argumentiert, dass man es selber (also der Kunde selbst) nicht 
genau weiß und somit die Arbeit umgeht, sich mit dem System/Produkt/Ziel 
auseinanderzusetzen und zu sagen, xyz möchte ich haben.
So flattern nach jedem Treffen mit dem Auftraggeber/Kunde immer wieder 
neue Anforderungen/Features rein oder Änderungen, die man umsetzen soll. 
Diese sind dann aber wieder nicht genau definiert, weil man (Kunde und 
Auftragnehmer/Product Owner etc) seine Arbeit, also sich mal mit seinem 
System auseinaderzusetzen, nicht erledigt hat.

> Für die wirklich wichtigen Dinge gibt es nämlich schrifltiche Doku wie
> Lasten-, Pflichten- und Designhefte, in denen die Anforderungen
> hineingeschrieben werden und zwar bitte detailliert und richtig. So hat
> es dort nur oberflächliche und falsche Darstellungen, die einem nicht
> helfen. Weder bei der täglichen Arbeit noch bei deren Organisation.

Genau das is doch das Problem. Diejenigen, deren Aufgabe es ist, 
Anforderungen, Designs, Architekturen zu erstellen, machen ihre Aufgabe 
nicht richtig aus verschiedensten Gründen (Inkompetenz, Faulheit, keine 
Erfahrung etc). Aber auch der Kunde ist zu faul - anstatt zu sagen, was 
er denn haben möchte, lässt er den Auftragnehmer mal machen und schiebt 
dann seine Wünsche nach.

Nicht falsch verstehen: Es ist mir klar, dass man nciht von Anfang an 
eine komplette Spezifikation abgeben kann und dass es zu Änderungen 
kommt. Aber ich finde, dass es gerade wegen Scrum/agiler Entwicklung, 
dies immer mehr dazu führt, dass man sich immer weniger Gedanken über 
sein System/Produkt macht.

Ich habe mehrfach die Erfahrung gemacht, daß Agile Entwicklung zu guten 
Ergebnissen führen kann. Auch dann, wenn das Produkt erst während der 
Entwicklung definiert oder gar geändert wird.

Kompliziert wird es, wenn vor dem Beginn der Entwicklung schon der 
Zieltermin und Preis festgelegt werden, aber noch keiner so richtig 
weiß, was er eigentlich bauen soll.

Für die Entwickler ist es in solchen Fällen wichtig klar zu stellen, was 
man bis wann zu welchem Preis erledigen kann. Häufig hat man dann auch 
recht lange Listebn von Unsicherheiten, die man klar kommunizieren 
sollte. Denn wenn es am Ende länger dauert und teurer wird, sollte dem 
Auftraggeber klar sein, daß er es selbst Schuld ist.

Agile Entwicklung ist für mich das mehr oder weniger organisierte 
alltägliche Chaos. Oder wie ich zu sagen Pflege: Der ganz normale 
Wahnsinn. Nicht wirklich erquickend, aber man wird dafür bezahlt.

Scrum lehne ich in einigen Punkten ab. Die täglichen Meetings sind zu 
kruz, um Sinn zu ergeben und zu häufig um nicht von der Arbeits 
abzuhalten. Ein vernünftiger Projektleiter wird dann Meetings 
einberufen, wann sie angebracht sind. Die richtige Dauer und Häufigkeit 
will ich mir nicht von einem Buch vorgeben lassen. Ebensowenig die 
Anzahl der Tage pro Sprint.

Scrum ist mir viel zu starr. Zugleicht verlangt Scrum aber 100% 
Einhaltung der Regeln weil es sonst angeblich nicht funktioniert. Eine 
selbsterfüllende Prophezeiung.

Es erinnert mich an die viele Gesetze der Juden. Sie dienen 
hauptsächlich dem Zweck, den Menschen ihre Unvollkommenheit vor Augen zu 
führen. Nach dem Motto: Alle Juden sind unvollkommen, wiel sie Gesetze 
brechen.

Alle Scrum Projekte laufen schlecht, weil sie die Regeln mißachten.

Wirklich flexible Entwickler hängen sich nicht an so ein striktes 
Regelwerk. Und Flexibilität ist gefragt. Scrum ist nur ein Buzzword. Es 
reicht, ein Scrum Buch gelesen zu haben. Richtig anwenden kann man es 
danach zwar nicht, aber das erwartet auch niemand. Man soll ja auch gar 
nicht 100% Scrum machen.

Ich habe mich im vorigen Post unklar ausgedrückt:

Ich glaube daß Scrum absichtlich so starre und kaum einzuhaltende regeln 
festlegt, damit man sie nicht einhalten kann. So kann der Erfinder von 
Scrum sehr einfach sagen "Dein Projekt ist gescheitert, weil du die 
Regeln von Scrum nicht eingehalten hast". An Scrum selbst kann es nicht 
gelegen haben.

So wie das Judentum nicht Schuld an unvolkommenen Menschen sein will, 
zugleich jedoch Vorschriften macht, die kein mensch vollständig 
einhalten kann.

Das meinte ich mit dem Juden-Vergleich.

Vielleicht funktioniert Scrum auch nur in USA gut, wo die Leute kaum 
Fehltage haben und von 7 bis 7 die halbe Stunde täglich eher als Warm-up 
zu sehen ist.

Bei uns funktioniert SCRUM.

Stefan U. schrieb:
> Ich glaube daß Scrum absichtlich so starre und kaum einzuhaltende regeln
> festlegt, damit man sie nicht einhalten kann. So kann der Erfinder von
> Scrum sehr einfach sagen "Dein Projekt ist gescheitert, weil du die
> Regeln von Scrum nicht eingehalten hast". An Scrum selbst kann es nicht
> gelegen haben.

Genau das ist eben nicht der Sinn von SCRUM. Wenn du es so kennst, hast 
du es nicht verstanden, wenn du Leute kennst, die es so praktizieren, 
haben sie es ebenfalls nicht verstanden und machen es falsch.

Stefan U. schrieb:
> So wie das Judentum nicht Schuld an unvolkommenen Menschen sein will,
> zugleich jedoch Vorschriften macht, die kein mensch vollständig
> einhalten kann.

Was für ein dämlicher Vergleich. Viel dir wirklich nichts Besseres ein?

Achim S. schrieb:
> Vielleicht funktioniert Scrum auch nur in USA gut, wo die Leute
> kaum
> Fehltage haben und von 7 bis 7 die halbe Stunde täglich eher als Warm-up
> zu sehen ist.

Nö. Wenn man SCRUM richtig praktiziert, führt es eben zu einer 
entspannten Arbeitsumgebung. Verschiebungen sind durchaus erlaubt. Wir 
arbeiten mit mehr als 40 Leuten in 3 Teams an vielen Requirements, die 
auf die Sprints so verteilt werden, dass es eben nicht zu dieser 
Überbelastung kommt. Chaotisches Projektmanagement und Umsetzung der 
Anforderungen, wo am Ende erst auffällt, dass wichtige Dinge fehlen und 
zum Chaos und Panik führen, bleibt so aus.

Voraussetzung: Man hält sich an die Regeln, die SCRUM definiert. Und 
natürlich, dass man weiß, wovon man spricht, und eben nicht am Ende doch 
ein paar Begriffe mitbekommen hat, ohne zu verstehen, worum es geht.

Unsere Teams arbeiten ziemlich erfolgreich, die Fa. nimmt es auch in 
anderen Abteilungen an. Und ich bin weiß Gott kein Verfechter von 
solchen Dingen, nur muss ich als einfacher Entwickler nach vielen Jahren 
Berufserfahrungen in diversen Firmen doch anerkennen, dass es viele 
Projekte besser laufen lässt, als dort, wo es dies nicht gab. Meine 
anfängliche Skepsis und gewisse Vorurteile, die ich hatte, habe ich nach 
reichlicher Beobachtung doch zurückgefahren, und kann dem Ganzen einige 
gute Eigenschaften abgewinnen.
Dazu muss man allerdings sagen, dass die bei uns damit betrauten Leute 
dies auch mit Herzblut umsetzen und dies als kein "nice to have" 
betrachten.

Zu guter Letzt: die Stimmung unter den Leuten in diesen 3 Teams habe ich 
noch nie so gesehen: sie ist so gut, dass man gerne zur Arbeit geht.

So, und bevor hier mal wieder rumgetrollt wird: nein, ich verfolge keine 
kommerziellen Ziele, nur weil ich mal optimistischere Töne anschlage.

Wir haben im letzten Projekt ebenfalls SCRUM eingeführt und Ich muss 
sagen, Ich erlebe da zweierlei:

1) Viele sind enthusiastisch, weil sie ihre formellen Prozesse beiseite 
lassen können, die eh nie richtig gelebt wurden. Alle sind entspannt und 
haben endlich eine Begründung, so arbeiten zu können wie sie wollen. 
Quasi die Erlaubnis zum Spontanarbeiten.

2) Es wird versucht, irgendwie die formellen Prozesse von SCRUM 
einzuhalten und alle machen mit, versuchen aber trotzdem irgendwie zu 
arbeiten, wie sie es gewohnt sind. So richtig kapiert, was SCRUM sein 
soll, hat offenbar keiner.

Damit wurde der formelle Prozess ALT gegen einen neuen Prozess SCRUM 
ausgetauscht. Geändert hat sich aber garnichts. Die Probleme sind 
dieselben, die Lösungen auch und das eigentlich Wichtige, nämlich die 
Festlegung von gemeinsamen Zielen geschieht immer noch nicht in 
ausreichender Weise, weil dafür keiner Zeit hat. Er muss ja SCRUM 
machen, Reports schreiben und ins meeting.

Ich sehe in Scrum nichts anders, als eine feinere Planung mit kürzeren 
Laufzeiten. Ob die sinnvoll sind, hängt von der Aufgabe und Situation 
ab. Entscheidend ist, dass es klare Absprachen gibt an die man sich 
hält.

SCRUM verführt leider dazu, alles aus dem Stehgreif zu machen und 
weniger niederzulegen und verbindlich aufzuplanen.

Für die hemdsärmelige U30-Franktion sicher die richtige Arbeitstechnik.

> Für die hemdsärmelige U30-Franktion

Sei vorsichtig, was du von Dir gibst.

Scrum-Teilnehmer schrieb:
> Genau das ist eben nicht der Sinn von SCRUM. Wenn du es so kennst, hast
> du es nicht verstanden, wenn du Leute kennst, die es so praktizieren,
> haben sie es ebenfalls nicht verstanden und machen es falsch.

Wenn das so ist, kannst Du doch bestimmt die (schon laenger offene) 
Frage nach guter Literatur beantworten. Hilft die Diskussion zu 
versachlichen und verhindert das 10 Leute 15 verschiedene Sachen unter 
scrumm verstehen.

Scrum-Teilnehmer schrieb:
> Dazu muss man allerdings sagen, dass die bei uns damit betrauten Leute
> dies auch mit Herzblut umsetzen

Das ist genau der Schlüssel. Aber wenn die Leute mit Herzblut dabei 
wären, bräuchte man nicht unbedingt Scrum, welches meiner Meinung nach 
die Faulheit, Inkompetenz, Unerfahrenheit der Leute 
kaschiert/rechtfertigt und gerade auch verstärkt.
Denn ein Team, welches nach Prozess X erfolgreich entwickelt, wird auch 
nach Prozess Y erfolgreich entwickeln.

Cyblord -. schrieb:
> Was daran liegt dass Scrum bzw. die gesamte Agile Entwicklung kein
> Prozess sondern eine Art Geisteshaltung ist. Eine grundlegende
> Einstellung zum Thema SW-Entwicklung.

Und? Auch keine Literaturempfehlung, die das bestaetigen wuerde?

Wichtig finde ich, daß nicht einfach ein manager im laufenden Projekt 
sagt "So liebe Leute, hier ist das Buch über SCRUM, ab Montag machen wir 
das so". Denn die Methode setzt voraus, daß andere Abteilungen dabei mit 
machen.

Leider musste ich mehrfach erleben, daß Manager meineten, SCRUM sei eine 
Arbeitsmethode für die Softwareentwickler, aber alle anderen können 
drauen bleiben.

Chris F. schrieb:
> In großen Firmen

Richtig, den Konzernbeamten ist das alles zuwider. Die wollen gefälligst 
in Ruhe die Jahre bis zur Rente überstehen und nicht so neumodischen 
Schnickschnack lernen, geschweige denn auch noch seine Geisteshaltung 
ändern.

Damit Scrum funktioniert braucht man ziemlich homogene Teams. Die findet 
man halt im Konzernumfeld nicht.

Ich wollte deine Aussage ja nicht widerlegen, sondern eher untermauern. 
Das Problem an der Verwendung von Scrum ist, dass (gerade vom Management 
aus) immer alles Heil im Agilen gesucht wird. Dabei ist eher das 
Gegenteil der Fall. Wenn agil nicht richtig umgesetzt wird (oder werden 
kann), wird es eher zu ner Effizienz-Bremse.
Und in Konzernstrukturen rennen einfach zu viele Beamte (natürlich nicht 
nur) rum, sodass agil dort nicht funktionieren kann. Das was 
"Selbstständiger" oben beschreibt sind eben nicht die Schwachpunkte von 
Scrum, sondern die Fehlverwendung von Scrum. Wenn jemand vor mir auf der 
Autobahn schleicht ist in den meisten Fällen auch nicht das Auto Schuld, 
sondern der Fahrer.

Dumdidum schrieb:
> Wenn das so ist, kannst Du doch bestimmt die (schon laenger offene)
> Frage nach guter Literatur beantworten. Hilft die Diskussion zu
> versachlichen und verhindert das 10 Leute 15 verschiedene Sachen unter
> scrumm verstehen.
Ein lobenswürdiger Beitrag. Ich hatte die Frage tasächlich schon 
gestellt, aber die Antwort ist offen!

Chris F. schrieb:
> "Daily Scrum" und "Produkt-Backlog" klappt auch nur bei sehr ähnlich
> ausgebildeten Leuten die gleichberechtigt in einer Kleingruppe an einem
> gemeinsamen Thema arbeiten.
Das ist auch meine Beobachtung. Ich habe es schon gesehen, daß die halbe 
Abteilung im Halbkreis stand und jeder seine Ideen vortrug, am Ende 
gingen die 2 SW-Entwickler raus und haben sich nochmal extra 
zusammengesetzt  und alles wieder überworfen.

Mini-SCRUM!

djm schrieb:
> Ich wollte deine Aussage ja nicht widerlegen, sondern eher untermauern.
> Das Problem an der Verwendung von Scrum ist, dass (gerade vom Management
> aus) immer alles Heil im Agilen gesucht wird. Dabei ist eher das
> Gegenteil der Fall. Wenn agil nicht richtig umgesetzt wird (oder werden
> kann), wird es eher zu ner Effizienz-Bremse.

Dann würde Ich Dir hiermit bitten, einige Regeln aufzustellen, wie man 
das handhaben sollte und was man unterlassen sollte.

?

Reinhard S. schrieb:
> Dann würde Ich Dir hiermit bitten, einige Regeln aufzustellen, wie man
> das handhaben sollte und was man unterlassen sollte.

Warum soll ich da Regeln aufstellen? Das Vorgehen gemäß Scrum ist 
definiert. Da gibt's sogar deine heiß geliebte Literatur dazu.

Danach muss man leben. Und wenn dann zwei SW-Entwickler meinen, im 
Privaten alles über den Haufen werfen zu müssen, gibt's halt 
Klassenkeile. Das ist genau das was ich mit Geisteshaltung gemeint hab. 
Entweder ich will Scrum machen, dann klappt das auch. Oder ich hab da 
keinen Bock drauf, dann kann man es vergessen.

Und zum Thema Literatur:
http://www.scrumguides.org/

Scrum und scum liegen nicht ohne Grund sehr eng beinander.

SCRUM ist extreme Programming fuer arme, aber immer noch besser als 
Wasserfallmodelle, letzteres war urspruenglich ein Negativbeispiel wie 
man es NICHT machen sollte.

Wasserfall ist eben sehr unflexibel, kann man nur erfolgreich machen 
wenn man nicht innovativ ist und eben nicht auf Aenderungen regiert weil 
man seit Jahren dasselbe macht, viel Papier, wenn etwas falsch laeuft 
merkt man das viel zu spaet, passt eben super zum "OEM Modell", wie es 
oft in den "sterbenden Industrien" zu finden ist.

Selbst Auswuechse wie das V-Modell XT, ein verkapptes Wasserfall Modell, 
musste einen alternativen agilen Prozess einfuehren um nicht komplett 
unterzugehen.

Das scheint ein Kernpunkt in der SCRUM Lehre zu sein: "Wasserfall ist 
der Teufel". Und deswegen ist SCRUM auch garantiert 100% anders. Bloss 
nichts wie beim Wasserfall Modell machen, denn sonst müsste man ja 
eingestehen, daß dieses "feindliche" Modell auch positive Seiten hat.

Das Wasserfall Modell wird häufig von Auftraggebern verlangt. Es gibt 
dem Auftraggeber die Sicherheit, daß er zum Zieltermin im Rahmen der 
kalkulierten Kosten das erwartete Produkt erhält. Außerdem ist es so 
möglich, das Personal für QA und Betrieb erst später am Ende des 
Entwicklungsprozesses zu belegen.

So weit die Theorie. In der Praxis habe ich in jedem Projekt erlebt, daß 
während der Entwicklung wesentliche Änderungen angefordert werden (oder 
sich als Notwendig ergeben, weil der Plan fehlerhaft war). An diesem 
Punkt verhandelt man über Vereinfachungen, was man weg lassen kann oder 
später nach dem Zieltermin (gegen Aufpreis) nachliefern kann.

Hier soll man bitte nicht den Fehler machen, an der Dokumentation zu 
sparen! Wenn diese nicht von Anfang an VOR oder WÄHREND der Entwicklung 
erstellt wird, dann endet es sonst oft damit, die Dokumentation einfach 
weg zu lassen. Zugleich wird dann aber erwartet, daß man künftige 
Änderungen ohne Mehraufwand umsetzen kann und daß man die Funktionsweise 
des Produktes OHNE Dokumentation jederzeit vollständig mündlich erklären 
kann. Das ist jedoch nicht Möglich.

Ich halte es für äußerst hilfreich, wenn man während der 
Software-Entwicklung alle paar Wochen (aber nicht wöchentlich) den 
aktuellen Stand abliefert. So können die Benutzer das Produkt 
ausprobieren und Änderungswünsche äußern, die letztendlich der Qualität 
dienen. Man erkennt frühzeitig viele Fehler, noch bevor der 
Test/Abnahmeprozess beginnt. Wenn man schonmal etwas zum "anfassen" 
vorliegen hat, kommen meistens die besten Ideen.

Ich halte es auch für wichtig, dass ein technisch versierter 
Projektleiter oder Architekt (oder beide) die Verhandlungen mit dem 
Auftraggeber durchführen, damit sie den Entwicklern den Rücken frei 
halten. Es wäre ein Unding, wenn einzelne Entwickler mit dem 
Auftraggeber Details aushandeln müssten.

SCRUM geht einfach davon aus, daß alle Entwickler gleiches KnowHow und 
gleiche Talente haben. Jeder Entwickler müsste zugleich Programmierer, 
Tester, Dokumentierer, Händler und Betriebler sein. Das ist in der 
Praxis jedoch selten der Fall. Deswegen ist der Personalaufwand sehr 
viel größer, wenn man sich an die Regeln von SCRUM hält.

Bezüglich der Dokumentation möchte ich empfehlen, diese als Wiki 
anzulegen. Die Möglichkeit, alles kreuz und quer zu verlinken, erspart 
eine Menge Tipparbeit. Man sollte sich nicht mit einer starren 
Formatvorlage behindern. Wichtig ist doch, DASS alles irgendwo 
dokumentiert und durchsuchbar ist, nicht WIE. Ich habe in 25 Jahren noch 
keinen einzigen Kunden erlebt, der eine lockere Form reklamiert hatte.

Das heisst zum Beispiel, daß man keine endlos großen Diagramme von DB 
Strukturen aufmalt, sondern einfach die "create table" Statements in die 
Doku kopiert. Dazu noch ein paar Zeilen Text, was man sich dabei gedacht 
hat, falls das überhaupt nötig ist.

Normalerweise sollte sich der Programmcode selbst erklären. Ich muss bei 
der Funktion Customer.blockLoginUntil(Date) nicht erklären, was sie 
macht. Ich muss aber irgendwo zusammenhängend erklären, wann und warum 
wir Kunden blocken und wie man sie ent-blocken kann. Eben die 
Geschäftslogik, und die kann man in der Regel nicht 1:1 aus dem 
Quelltext heraus lesen. Dementsprechend sehe ich DoxyGen und JavaDoc als 
mittlerweilen fast überflüssiges* Hilfsmittel für die Programmierer an, 
jedoch nicht als Tool, die Dokumentation für die nicht-Programmierer zu 
erstellen.

* fast Überflüssig deswegen, weil jede IDE diese eingebetteten 
Dokumentationen irgendwie schön anzeigt, so daß man sie nicht mehr als 
HTML, PDF oder was auch immer separat vorhalten muss. Die eingebettete 
Doku ist natürlich weiterhin nötig. Und selbst da würde ich auf die 
Dokumentation von völlig offensichtlichen Funktionen und Parametern 
verzichten.

Stefan U. schrieb:
> SCRUM geht einfach davon aus, daß alle Entwickler gleiches KnowHow und
> gleiche Talente haben. Jeder Entwickler müsste zugleich Programmierer,
> Tester, Dokumentierer, Händler und Betriebler sein. Das ist in der
> Praxis jedoch selten der Fall. Deswegen ist der Personalaufwand sehr
> viel größer, wenn man sich an die Regeln von SCRUM hält.

Nein, davon geht Scrum eben nicht aus:

Development Teams are cross-functional, with all of the skills as a team 
necessary to create a product Increment;
Scrum recognizes no titles for Development Team members other than 
Developer, regardless of the work being performed by the person; there 
are no exceptions to this rule;

Warum sollte der Personalaufwand von Scrum dadurch höher sein als bei 
anderen Vorgehen? Ob ich jetzt im Wasserfall oder Scrum nen Betriebler 
oder Tester braucht, ändert nix an meinem Personalbedarf. Mit Scrum kann 
man tendenziell sogar mit geringeren PErsonalkosten arbeiten, da man die 
einzelnen Leute präziser "buchen" kann.

Wasserfall ist in der Theorie super und in der Praxis untauglich weil:

- Schätzungen am Anfang sowieso vollkommen fürn Arsch sind
- Die Kundenrückkopplungsschleife viel zu lange ist
- Entweder nicht alle Anforderungen von vornherein klar sind oder sie 
sich im Laufe ändern

Wir im Konzern in unserem Projekt fahren SCRUM (so gut es halt in den 
Strukturen geht) und meiner Beobachtung nach hängt vieles am Product 
Owner, ohne ein vernünftig priorisiertes Backlog (was im Wesentlichen 
den Anforderungen entspricht) ist das alles Scheiße. Egal ob SCRUM oder 
Wasserfall.
Wenn es aber ein vernünftiges Backlog gibt, dann läuft das wunderbar. 
Die Schätzungen für einzelne Pakete sind viel feingranularer und damit 
präziser. Der Kunde / Product Owner hat damit die Möglichkeit gut zu 
steuern, was er unbedingt haben möchte oder was nice-to-have is wenns 
noch ins Budget passt. Feedback kann frequenter eingeholt werden, nicht 
selten ist die erste Idee die man hatte ein Scheiß in der Praxis (kann 
man den Button nicht lieber so und so machen, weil ich habe 
festgestallt, dass ...).
Wenns normal läuft, kann man sagen, der Kunde kriegt das was ins 
vorgegebene Budget passt und hätte mit Wasserfall auch nicht mehr 
bekommen, das zeigt die Praxis.
Wir im Team und auch die anderen Teams im Projekt haben SCRUM an ihre 
Modalitäten angepasst (gesunder Menschenverstand!) und es funktioniert 
doch recht ordentlich. Dailies machen wir nicht daily, dafür häufiger 
Backlog Refinement, dadurch schrumpft das Planungsmeeting nur noch zu 
einem "was machen wir als nächstes, Herr Product Owner". Unser Team ist 
bunt gemischt, sowohl vom Alter (30-60), als auch vom Erfahrungsstand 
innerhalb des Projekts (manche sind schon Jahre dabei und haben 
entsprechendes Domänenwissen, manche erst ein paar Monate). Wie schon 
gesagt wurde, der Erfolg hängt auch im Wesentlichen davon ab, ob man 
einen sturen Stinkstiefel im Team hat (den es bei uns glücklicherweise 
nicht gibt) oder nicht, aber es ist dann Aufgabe der Führungskraft so 
jemand ordentlich zu polen. Aber meiner Beobachtung nach, sind die 
fähigsten Leute auch mit die, die offen für Neues sind und nicht nach 
Schema F immer wieder auf ihrem alten Scheiß beharren ohne dabei jedem 
Hype hinterherzulaufen oder sich für Weltenretter halten.

Wasserfall oder V-Modell hat seine Berechtigung. Nämlich genau da, wo 
von Anfang an feststeht, was am Ende rauskommen soll. Die 61508 
("SIL-Norm") verlangt es daher für sicherheitsgerichtete Funktionen. Zu 
Recht.
Denn a) kann man dafür nur bekannte Funktionalität verwenden (nichts 
neues, kreatives),
und b) ist die zu erfüllende Funktion am Anfang bekannt.

Für ein neues Produkt oder eine Weiterentwicklung ist Wasserfall 
natürlich Quatsch und war es auch schon immer. Scrum wurde erst 
notwendig, als die Manager ohne Programmierkenntnisse mitspielen wollten 
und auf Wasserfall, Ablaufdiagramme oder UML-Design ansprangen.

Dann könnte man sagen: SCRUM ist für die Forschung und V-MODELL für 
Auftragsentwicklungen?

Reinhard S. schrieb:
> Dann könnte man sagen: SCRUM ist für die Forschung und V-MODELL für
> Auftragsentwicklungen?

Unsinn.

Michael B. schrieb:
>> - Schätzungen am Anfang sowieso vollkommen fürn Arsch sind
>
> Welche Schätzung ? Kosten ? Gehört nicht ins Pflichten/Lastenheft.

In der echten Welt liegt jedem Projekt ein Budget zugrunde und das 
Pflichten/Lastenheft sollte dazu passen. Und ob es passt oder nicht, ist 
eine Schätzung am Anfang. Und die liegt oft genug meilenweit daneben.

Michael B. schrieb:
> Wozu braucht man die ? Wenn ich ein Zaungitter bestelle, möchte ich ein
> Zaungitter bekommen, und ich wähle vorher welche Farbe bzw. wie es
> aussehen soll. Dann will ich es nur noch geliefert bekommen. So ist das
> auch bei Software, die einen wirklichen Zweck erfüllen soll.

Da du offensichtlich nur mit Software mit der Komplexität eines 
Zaungitters zu tun hast, übersteigt die Realität wohl dein 
Auffassungsvermögen was Software betrifft. Und "was ein wirklicher 
Zweck" einer Software ist oder nicht, bestimmst auch nicht du alleine.

Michael B. schrieb:
> Wie schon geschrieben wurde: Dort, wo es wichtig ist, ist SCRUM sowieso
> unzulässig.

Was für ein Unsinn. Was ist denn "wichtig"? FuSi gibt es halt 
Vorschriften, aber ist nicht das einzig "wichtige".

Michael B. schrieb:
> Die Firmen, die es nutzen, wie eBay, Onlineportale und viele
> Tageszeitungen, haben normalerweise kaputte untaugliche Software. Schau
> mal, wie viele Sachen bei eBay im Argen liegen, z.B. Inkonsistenten
> zwischen WEB und Mobilangebot, Inkonsistenzen zwischen ständig
> geänderten Seiten vorne und den nicht mehr dazu passenden Seiten weiter
> hinten dort wo es ans Eingemachte geht.

Und als ausgewiesener Software- und Prozessexperte kannst du natürlich 
vollumfassend beurteilen, dass es am Entwicklungsprozess gelegen hat, 
...

Du solltest halt nur über Dinge labern von denen du was zu verstehen 
scheinst wie Elektroinstallationen.

Das Gefetzte zwischen Michael und der Person, die sich "Abr-adolf" nennt 
ist wieder mal ein schönes Beispiel, das bei den "Diskussionen" zwischen 
Entwicklern sehr schnell ins Persönlich abgedriftet wird, statt die 
Inhalte anzugehen.

Und genau dasselbe erleben wir aucg mit scrum:

Die wird das Aufweichen bestehender Normen in den Himmel gehoben, so als 
seien damit alle Probleme gelöst und sogleich durch neue normierte 
Vorgehensweisen ersetzt. Das Ergebnis sind endlose Diskussionen, in die 
sich jeder unvorbereitet einschaltet und dabei Meinungen vertritt. Was 
dann am Ende gemacht wird, ist davon abhängig, wer gerade am Meeting 
teilnimmt und wer nicht. Sind zwei Vertreter der Meinung X im Urlaub, 
wird auf Y umgeschwnkt, um es dann Wochen später wieder anders zu 
entscheiden, weil sich die Diskutanten geändert haben und es nicht mehr 
gelingt, eine temporäre Meinung durchzusetzen.

Also haben wir einen gewaltigen Eiertanz und Zickzackkurs und jeder 
nutzt scrum als Entschuldigung dafür, nicht geradeaus zu arbeiten, 
nichts hinzuschreiben und sich ja nicht festzulegen.

So weiss jeder alles und nichts und es ist niemand da, der 
Entscheidungen mal verbindlich fällt und Festlegungen trifft, die eine 
Weile halten.

Meine persönliche Erfahrung am eigenen Leib ist: Wer mit anderen 
menschen nicht gut zurecht kommt, hat gute Chancen, sich mit Maschinen 
anzufreunden. Also auch Computer. Ich glaube, daß daher auch der Begriff 
"Computer-Freak" stammt. Viele Computer Fachleute sind Freaks. Seit ich 
mich damit abfinde, fühle ich mich besser.

Im übrigen sind die schlimmsten Straftäter häufig Normalos, die wo alle 
Nachbarn sagen "Ich bin fassungslos, er war doch immer so ein ruhiger 
unauffäliger Typ".

Die Freaks sind die, vor denen man sich am wenigsten fürchten muss. 
Allerdings sind sie dennoch schwierige Menschen, was den Umgang angeht. 
Das will ich gar nicht abstreiten. Jedenfalls gilt das für mich.

Äh, ja - schön, dass Du mal darüber gesprochen hast. Aber wo ist der 
Bezug zum Thema SCRUM?  Sollte dies eine Antwort auf meinen Beitrag 
gewesen sein, so lege Ich wert auf die Feststellung, dass Ich ein sehr 
kommunikationsfreudiger Computerfreak bin.

Allerdings ändert das nichts an der Tatsache, daß bei SCRUM (um wieder 
zum Thema zu kommen) ein EFfekt auftritt, bei dem sich speziell gute 
Redenschwinger mit ihren Ideen und Vorschlägen durchsetzen können. Das 
sind dann oft Leute, die sonst wenig Tiefgang haben und ihre Zeit nur 
die Präparation ihres MINI-Vortrags bei SCRUM verwenden und hinerher 
abschlaffen. So können sie glänzen, andere an die Wand reden und ins 
Hintertreffen bringen. Leute die mehr Denken, als Reden.

Und es ist so, daß dort eben oft ad hoc unsauber, oberflächlich und 
ungenau diskutiert wird, Vieles aus dem Stand kommt und unausgereift 
ist.

Abradolf L. schrieb:
> Michael B. schrieb:
>>> - Schätzungen am Anfang sowieso vollkommen fürn Arsch sind
>>
>> Welche Schätzung ? Kosten ? Gehört nicht ins Pflichten/Lastenheft.
>
> In der echten Welt liegt jedem Projekt ein Budget zugrunde und das
> Pflichten/Lastenheft sollte dazu passen. Und ob es passt oder nicht, ist
> eine Schätzung am Anfang. Und die liegt oft genug meilenweit daneben.

Die Schätzungen passen meist schon, zumindest solange keine 
Sonderwünsche nachgeschoben werden.

Anderer Punkt: Was z.B: soll man tun, wenn man in einer 
Entwicklungsabteilung sitzt, Aufträge von Draußen bekommt, sei es das 
eigene Produktmanagement oder eine externer Abnehmer und die nicht in 
der Lage sind, ihre Anforderungen zu formulieren?

Da kommt allenthalben einen neue Idee, eine Änderung oder etwas wird 
weggelassen, weil jemand merkt, dass er sich verzettelt hat oder einfach 
etwas vergessen hat.

Michael B. schrieb:
> Wozu braucht man die ? Wenn ich ein Zaungitter bestelle, möchte ich ein
> Zaungitter bekommen, und ich wähle vorher welche Farbe bzw. wie es
> aussehen soll. Dann will ich es nur noch geliefert bekommen. So ist das
> auch bei Software, die einen wirklichen Zweck erfüllen soll.

Yo, bis die Frau um die Ecke kommt und sagt "Du Schatz, ich hab mir das 
mit dem Zaungitter nochmal überlegt...".

Jan H. schrieb:
> wenn die
> Entwicklungsabteilung stark ist.

Das machst Du aber auch nur ein- oder zweimal, dann kriegst Du gar keine 
Aufträge mehr, weil es an den BU-Manager eskaliert wurde, der die 
Freigabe erteilt, extern zu bestellen, wovon der Geprellte dann auch 
eifrig Gebrauch macht. Ergebnis ist dann die Reduktion der Entwicklung.

Jan H. schrieb:

> Im Idealfall nachfragen und genauer spezifizieren. Oft ist das nur
> eingeschränkt möglich, dann bleibt eh nur noch ein Ansatz mit vielen
> Zwischenversionen zum Ansehen (z.B. SCRUM).

Das Problem daran ist, daß die Abnehmer zwar jede Menge Zeit verbrennen 
mit solchen Anguckversionen, weil sie nicht wissen, was sie wollen, dann 
aber nur die finale Version und deren Aufwand bezahlen wollen.

Allen beteiligten sollte klar sein, daß die Entwicklung nicht weiter 
arbeiten kann, wenn die Arbeit nicht bezahlt wird. Das bezahlen fällt 
dem Auftraggeber leichter, wenn er versteht, warum die kosten gestiegen 
sind.

Deswegen sollte man zu Projektbeginn klar machen, welche Leistungen in 
der Kostenabschätzung enthalten sind und daß warscheinlich unschätzbare 
Mehraufwände wegen Plan-Änderungen dazu kommen werden. Die muss man 
natürlich sauber dokumentieren.

Das ist zwar lästig, aber kein Problem.

Software-Entwicklung besteht meiner Erfahrung nach ungefähr zu 50% aus 
Testen und 40% Arbeiten an anderen Dingen als dem Programm-Quelltext.

Chris F. schrieb:
> Bei mir ist das bei vielen Projekten eher so:
> 70% Gerede das nichts mit dem Thema zu tun hat,

Dann musst Du eben die privaten Sachen mal weglassen. :-)

Das ist schon eher realistisch:
Stefan U. schrieb:
> oftware-Entwicklung besteht meiner Erfahrung nach ungefähr zu 50% aus
> Testen und 40% Arbeiten an anderen Dingen als dem Programm-Quelltext.

Nur wenn man ein echtes Projekt-Managment mit Planung und 
Nachbetrachtung hat, lernen die Entwickler, ihre Aufwände richtig 
einzuschätzen. Wer das nicht genau protokolliert, hat meist kein Gefühl 
oder ein falsches.

Viele kleine Sachen werden weggelassen oder runtergeredet.

Im ersten Umlauf wird meistens:

10% geplant, 50% programmiert, 20% getestet und 20% inbetriebgenommen

Dann kommen nochmal Änderungen für die Fehler hinzu und viele 
Änderungen, wiel die Planung nicht gestimmt hat. Im zweiten Umlauf sind 
es dann mehr Planungsstunden, als Programmierstunden und eine Menge 
Test.

40% geplant, 60% programmiert, 70% getestet, 60% inbetriebgenommen

Dann kommen die Änderungen durch das PM und alle Positionen müssen 
nochmal überarbeitet werden.

100% Planung, 70% Programmierung, 110% Test, 150% Inbetriebgenommen.

Programmierung inklusive Doku sind also nicht einmal ein Viertel.

Fuer sehr kleine Projekte wird es bei uns eingesetzt, fuer groessere 
Projekte ist es durchaus ungeeignet.

Bei rewe digital wird scrum eingesetzt. Wir sind >200 Entwickler. Es 
funktioniert.

Agile Prozesse funktionieren genau so lange wie Abgabetermin und Kosten 
genauso variabel sind wie das Pflichtenheft. Praktisch will der Kunde 
aber irgendwann das Produkt auch mal verkaufen und muss dann auch wissen 
wieviel Entwicklungsumlage man auf den Endpreis legen muss. Außer an 
Unis, Förderprojekten und Berliner Flughäfen funktioniert sowas selten 
und endet meistens im Streit oder damit das eine Partei drauf zahlt

nnn schrieb:
> Bei rewe digital wird scrum eingesetzt.

Entwickelt ihr denn dann wirklich für einen Auftraggeber? Also, legt ein 
anderer fest, was genau ihr machen sollt? Oder sind die Stakeholder 
innerhalb Eurer Organisation?

Die Stakeholder sind innerhalb der Organisation, was natürlich ein 
Vorteil gegenüber einem "echten" Kunden ist.

Trotzdem war es zu den Anfangszeiten schwierig zu vermitteln, dass das 
ganze anders als Wasserfalls funktioniert. Auch heute noch sind IT und 
Stakeholder teilweise zwei unterschiedliche Welten.

Trotzdem kann und darf es auch bei Scrum feste Termine geben, das muss 
sich nicht widersprechen.

Das deckt sich mit meiner Erfahrung. Bei internen Projekten wo man nicht 
unbedingt in Stein gemeiselte Erwartungen hinsichtlich Features und 
Preis hat und man notfalls nach einiger Zeit einfach einstampfen kann 
hat man agil den wenigsten Streß. Wenn's dann vorbei ist kann man aufs 
unfähige Managements schimpfen das kurz vorm großen Durchbruch immer 
abbricht ;-)

nnn schrieb:
> Trotzdem kann und darf es auch bei Scrum feste Termine geben, das muss
> sich nicht widersprechen.

Naja, schon wenn nur drei oder vier Sprints dazwischen liegen wird's 
schwierig das erwartete pünktlich zu liefern weil es eingangs an irgend 
einer wichtigen Anforderung fehlte.

Das passiert nicht, wenn die grobplanung passt und Abhängigkeiten 
zwischen Teams vorher geklärt sind. Zu dem Zeitpunkt gibt es nur eine 
grobe Schätzung aus dem refinement an der Story (welche n mal, bei jedem 
Team) vorkommen kann. Die endgültige Schätzung kommt im Sprintplanning 
dran.

Von meiner Seite ist das Thema erledigt. Meine Kollegen dürfen seit dem 
ersten Oktober alleine weiterscrummen.

:D

michl42 schrieb:
> ein aus meiner Sicht lesenswerter Artikel zu Scrum&Agile:
>
> 
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
>
> Kurzzusammenfassung: Es setzt die falschen Anreize, löst die falschen
> Probleme und macht Programmierung und Programmierer zu einem notwendigen
> vehikel. Es ist im Prinzip ein permanenter Kriesenmodus.

Endlich mal ein Betrag der die Fakten bennent! Den habe Ich mal direkt 
weitergeleitet, an gewisse Personen. Mal schauen, wie sie sich dazu 
stellen!

Ich bin etwas erstaunt, dass der thread eingeschlafen ist, zumal das 
Thema doch recht interessant ist.

In der jüngeren Vergangenheit wurde bei uns SCRUM sehr stark 
intensiviert. Eine kritische Reaktion auf meine Hinterfragung, wie ich 
sie o.a. angekündigt hatte, erfolgte kaum. Hinter vorgehaltener Hand 
meckern zwar Viele und hinterfragen den Sinn, weil sie das Management 
sehen, das bei rauskommt, trauen sich aber nicht, es offen zu äußern.

Scrum scheint sich auszubreiten wie ein Virus.

Und befallen werden in erster Linie Firmen, die wissen, dass sie im 
Chaos arbeiten und sich diesen Strohhalm greifen, um sich aus dem Sumpf 
zu ziehen.

Gott Sei Dank, habe ich das in Kürze hinter mir!

> Und befallen werden in erster Linie Firmen, die wissen, dass sie im
> Chaos arbeiten und sich diesen Strohhalm greifen, um sich aus dem Sumpf
> zu ziehen.

> Gott Sei Dank, habe ich das in Kürze hinter mir!

Viel besser kan man es nicht zusammenfassen !!!

SEHR GUT !!!

> Bei rewe digital wird scrum eingesetzt. Wir sind >200 Entwickler. Es
> funktioniert.

REWE Aktien verkaufen , kann dazu nur sagen !!!

Hi-Tech-Progger S. schrieb:
> SCRUM

SCRUM? Taylorismus?

Gewachsene Strukturen sag ich!

Nach dem Strohfeuer der ungeregelten technischen Entwicklung hat sie 
sich nun der Lichtgeschwindigkeit angenähert. Immer kleinere Schritte 
erfordern einen immer größeren Aufwand.

Zu Organisation eines teams finde ich es gar nicht schlecht. Es erzeugt 
Transparenz und 2Wochen Sprints kann man einigermaßen 
planen(theoretisch)

Die Gründe für das scheitern liegen mMn nicht unbedingt an scrumm selbst 
sondern an den Menschen die es benutzen. Je nach Team gibt's da immer 
queer schiessende die es geil finden möglichst tief zu schätzen, in 
retros wird sich nur Honig ums maul geschmiert, aus Fehlern nicht 
gelernt usw. Scrumm erfordert viel zwischenmenschliche Kommunikation und 
das in Bereichen wo IT asberger Nerd Autisten arbeiten. Ziemlich 
schlechte voraussetzungen

Wer sowas wie Scrum verwendet ist nur zu blöd um seine eigene Methode zu 
entwickeln

Schon mal darüber nachgedacht weshalb es in Bereichen wie Maschinenbau 
und Elektro-Konstruktion keine derartigen Vorgehensmodelle gibt. Na, 
klingelt es schon langsam.  Aber die IT Fuzzis fallen auf so etwas gerne 
herein...

Einfach unverbesserlich schrieb:

> Schon mal darüber nachgedacht weshalb es in Bereichen
> wie Maschinenbau und Elektro-Konstruktion keine
> derartigen Vorgehensmodelle gibt.

Natürlich:

1. Maschinenbau und Elektro-Konstruktion haben bei
   weitem nicht das Innovationstempo, das die
   angewandte Informatik hat. Nach Moores Gesetz ist die
   Rechenleistung seit meiner Jugend (also in den letzten
   30 Jahren) um den Faktor 1'000'000 gewachsen. Die
   Kenntnisse über Arbeitsteilung und Arbeitsorganisation
   haben schlicht nicht mit der technischen Entwicklung
   mitgehalten.

2. Die Komplexität selbst relativ einfacher Software ist
   viel größer als die von Maschinen oder elektrischen
   Anlagen. Es ist völlig klar, dass das auch andere
   Methoden der Arbeitsorganisation erfordert.

Für Dinge, wie extreme programming z.B. ist SCRUM sehr gut. Man muss 
sich aber immer vor Augen führen, dass es eine Art Notlösung ist, um im 
chaotischen, nicht geplanten stil etwas zusammenzuschrauben und sich 
dabei zu synchronisieren. Ob dabei starre 2 Wochen Perioden sinnvoll 
sind, muss aber bereits bezweifelt werden.

Hinzu kommt, dass SCRUM oft auf alle Softwareprojekte ausgeweitet wird, 
also fehlerhafterweise auch auf solche, die man gut planen hätte können. 
Damit wird alles an Projekten, egal, wie gross, wie lang und wie komplex 
auf ein und dasselbe Raster gepresst. Es liegt auf der Hand, dass das 
nicht stimmig sein KANN!

Vielmehr müssen komplexere und anspruchsvollere Projekte in kleineren 
Zeiträumen einem Monitoring unterzogen werden und brauchen eine lange 
vorgeschaltete Vorlaufphase der Gesamtplanung.

Nur flache, gleichmäßig in der Komplexität verlaufende Projekte wie 
längere Software, kann mit solchen gleichmäßigen Perioden getaktet 
werden und man kann recht schnell starten.

Komplett unsinnig ist es, das nun auch auf das gesamte Projekt ausweiten 
zu wollen, weil die Entwicklung von Mechanik, Hardware und dem 
Gesamtprojekt einen völlig anderen Komplexitätsverlauf hat, als 
Softwareentwicklung.

Bei Mechanik z.B. aber auch ASICs, muss sehr früh sehr genau gedacht 
werden, weil hintendrein fast nichts mehr zu reparieren oder zu ändern 
ist, während man bei SW bis zum Schluss noch ändern kann (auch wenn es 
nicht klug ist, zu viel offen zu lassen.)

Genau das passiert aber:

Wie bei der Software wird an alles drangesprungen, um es mit SCRUM zu 
starten und zu managen, so als wäre es Software.

Die meisten Projektteile, wie z.B. Resourenplanung vertragen aber keine 
Vorgehensweise wie bei SCRUM!

Ich habe SCRUM in mehreren Firmen negativ erlebt, weil es von oben herab 
einer einzigen Abteilung (der Softwareentwicklung) auf diktiert wurde.

Das Problem dabei war stets, dass alle anderen um uns herum nicht 
wirklich agil arbeiten wollten:

- Es gab einen festen Liefertermin.
- Die Kosten standen vor Projektbeginn fest.
- Der Auftraggeber stand nicht zur Klärung von Detail-Fragen zur 
Verfügung (z.B. ob man etwas anders machen darf, weil es einfacher ist).
- Getestet wurde nur einmal nach der Abgabe am Liefertermin, vorher 
stand dazu weder Personal noch Infrastruktur zur Verfügung.
- Die Benutzer wurden bereits vor dem Liefertermin an einer Alpha 
Version geschult.
- Aber die Anforderungen wurden nach und nach vervollständigt.

Der letzte Punkt spiegelt wieder, was diese Unternehmen von SCRUM 
erwarten:

- Die Softwareentwicklung kann schon bei Projektstart beginnen.
- Anforderungen können Schrittweise bis zum letzten Liefertermin 
formuliert werden.
- Anforderungen können beliebig oft geändert werden.
- Für die Einhaltung des Zieltermins und der Kosten ist die 
Softwareentwicklung ganz alleine verantwortlich.
- Für die Dokumentation ist die Softwareentwicklung ganz alleine 
zuständig.

Irgendwer zieht offenbar durch dieses Land und erzählt den Managern, 
dass SCRUM das Unmögliche möglich macht und dass es eine Arbeitsmethode 
für die Softwareentwickler sei.

So wie ich SCRUM erlebt habe, funktioniert es nicht. So wie es im Buch 
steht könnte es klappen. Aber die Manager (die ich erlebt habe) 
übersehen offenbar, das SCRUM weit mehr Personen involviert, als nur die 
Softwareentwickler. Vielleicht wurden sie schlecht beraten.

Udo S. schrieb:
> Wenn du dir auf ein modernes Flugzeug anschaust, oder dem bau eines
> Wolkenkratzers gilt das noch mehr.
> Und dort arbeiten (oder entwickeln) z.T 1000de von Personen zusammen.

Ja, das Argument der Komplexität war falsch, bzw. nicht ganz richtig.

Der Unterschied ist nicht die Höhe der Komplexität, sondern die fehlende 
(bzw. kostenlose) Produktion. Da wo der Maschinenbauer einen 
Handwerker für Prototypen braucht, der Architekt Referenzprojekte, 
drückt  der  SW-Entwickler auf den Compile-button und hat direkt die 
neuste Version vor sich.

Wo Erstellungs-Kosten (haus, Auto, HW) in Entwicklung oder Produktion 
hoch sind, gibt es mehr Planung, weniger Iterationen, weniger 
Komplexität pro Entwicklerstunde.

Und komm bitte niemand mehr, die eigentliche Entwicklung seien die paar 
UML-Skizzen des Architekten, und Codemonkeys nur Handwerker. Das galt 
vielleicht Mal zu Lochkarten-zeiten oder datentypisten heute.

...wir wurden vor 3 Jahren bei der Entwicklung des "applikativen 
(kundenrelevanten) Anteils einer größeren Softwarearchitektur im 
automotive Bereich" (OEM - ja, wir entwickeln den Code SELBST) auch dazu 
gezwungen, SCRUM einzuführen. Mein Ziel war es dabei, sich die 
sinnvollen Aspekte rauszugreifen und den Rest "wie immer" zu machen. 
Zumal wir vorher eigentlich schon agiler (nicht unbedingt chaotischer) 
unterwegs waren, als SCRUM es ermöglicht. Fazit ist, das hat gut 
funktioniert, ich sehe folgende Vorteile bei der Fusion beider Welten:

+ deutlich strukturierteres Projekt
+ feste Taktung durch Sprints (aktuell noch 6 Wochen, weil es gut zu 
anderen Artefakten passte - ist aber eigentlich etwas zu lang)
+ Zwang zu besserer doku & Abstimmung
+ Schätzung der Karten gibt bessere Planbarkeit
+ wir wissen schon jetzt dass wir nachweislich nicht fertig werden :)

- SCRUM per se ist ein akademischer Ansatz der mit der Realität in 
großen, gewachsenen Konzernen nichts zu tun hat
- man muss das Mgmt so hinbiegen, dass sie zufrieden sind mit dem was 
man aus SCRUM nutzt und immer schön alles loben ;)
- deutlich mehr Orga (was aber letztendlich in positiven Effekten endet)

Das dazu von meiner Seite, freue mich über weitere Erfahrungsberichte!

Euer PO.

PO schrieb:
> Mein Ziel war es dabei, sich die
> sinnvollen Aspekte rauszugreifen und den Rest "wie immer" zu machen.

Das ist eigentlich schon falsch, denn genau das verbietet SCRUM 
ausdrücklich.

Zumindest sollte man danach nicht behaupten, man würde SCRUM anwenden.

Egon D. schrieb:
> Maschinenbau und Elektro-Konstruktion haben bei
>    weitem nicht das Innovationstempo, das die
>    angewandte Informatik hat. Nach Moores Gesetz ist die
>    Rechenleistung seit meiner Jugend (also in den letzten
>    30 Jahren) um den Faktor 1'000'000 gewachsen. Die
>    Kenntnisse über Arbeitsteilung und Arbeitsorganisation
>    haben schlicht nicht mit der technischen Entwicklung
>    mitgehalten

 Maschinenbauer oder Elektrotechniker verdienen aber in der Regel 
deutlich mehr als IT Fuzzis in Softwareklitschen

Wenn aber die IT Arbeit deutlich anspruchsvoller wäre  dann müsste das 
Gegenteil der Fall sein. von daher stimmt dieses Argument nicht

Außerdem kopieren doch die meisten Softwerker nur Code aus aus Google 
zusammen

Einfach unverbesserlich schrieb:
> Außerdem kopieren doch die meisten Softwerker nur Code aus aus Google
> zusammen

Und die Maschinenbauer schrauben Teile zusammen, die ihnen fertig 
geliefert werden.

Sorry Mann, du hast keine Ahnung, was gute Softwareentwickler alles 
leisten müssen.

A. S. schrieb:

> Udo S. schrieb:
>> Wenn du dir auf ein modernes Flugzeug anschaust, oder
>> dem bau eines Wolkenkratzers gilt das noch mehr.
>> Und dort arbeiten (oder entwickeln) z.T 1000de von
>> Personen zusammen.
>
> Ja, das Argument der Komplexität war falsch, bzw. nicht
> ganz richtig.

Das stimmt.
Das kommt halt heraus, wenn ich mich mal kurzfassen und
nicht ewig schwafeln will.


> Der Unterschied ist nicht die Höhe der Komplexität, sondern
> die fehlende (bzw. kostenlose) Produktion.

Das stimmt -- aber das eine bedingt das andere.

Je produktiver die Produktion ist, desto größer ist die
Komplexität, die ein einzelner Entwickler beherrschen muss.
Das geht schon im Sondermaschinenbau los, wo heute eben
komplizierte Einzelteile auf der CNC-Fräse hergestellt
werden, was in dieser Weise von 50 Jahren schlicht unmöglich
war.

In der Softwerkerei ist das noch schlimmer; dort ist die
"Produktion" mit dem Ende des Compilerlaufes (nahezu)
abgeschlossen.


> Da wo der Maschinenbauer einen Handwerker für Prototypen
> braucht, der Architekt Referenzprojekte, drückt der
> SW-Entwickler auf den Compile-button und hat direkt die
> neuste Version vor sich.

Genau.


> Wo Erstellungs-Kosten (haus, Auto, HW) in Entwicklung
> oder Produktion hoch sind, gibt es mehr Planung, weniger
> Iterationen, weniger Komplexität pro Entwicklerstunde.

Nicht nur das -- es gibt dort auch mehr Kommunikation,
mehr technische Dokumentation, mehr Bewusstsein für
Qualität.

Udo S. schrieb:

> Man tendiert immer dazu das eigene Fachgebiet höher zu
> bewerten als das was man nicht so gut kennt.

???

Ich habe Mechatronik gelernt und Elektrotechnik studiert.

F. B. schrieb:
> Bist du denn in der Lage, einen Investment-Bot zu schreiben, der dich
> reich macht?

Er nun wieder mit seinem Aktienscheiss....

> Autor: F. B. (finanzberater)
> Datum: 03.10.2019 12:10

Da bist du Quatschkopp ja.

Habe dich schon vermisst, dachte dieses Wochenende gibt es keinen 
Freigang für dich.

Was mich an Finanzberatern mal interessiert, wenn sie so tolle 
Geldanlagetips haben müssten sie doch durch Umsetzen dieser soviel 
Schmodder gemacht haben, daß sie ganzjährig auf den Bahamas Urlaub 
machen und nicht als Finanzberater arbeiten.

Und die Scrum-Consultants müssten doch auch alle eine sehr gut laufende 
Softwarefirma haben und die Methoden derer Organisation mehr oder 
weniger für sich behalten ;-)