Forum: Ausbildung, Studium & Beruf Verbreitung von SCRUM


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Chris F. (chfreund) Benutzerseite


Lesenswert?

Das Dumme ist und bleibt bei solchen "agilen" Methodenwerken, dass dabei 
so getan wird als wären alle gleich motiviert und befähigt und es gäbe 
eine durchgehende Anwendung davon im ganzen Projekt von Auftrag bis 
Typabnahme.

Das ist nie der Fall und klappt auch schon innerhalb größerer 
Abteilungen in einer Firma nicht. Ich habe bisher noch kein Projekt 
erlebt bei dem diese "Total-Agil-Ideologie" wirklich richtig 
funktioniert hat.

von Peter M. (r2d3)


Lesenswert?

Hallo loeti2,

loeti2 schrieb:
> 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.

Deine Analyse ist vollkommen richtig. Finanzberater sind primär 
Verkäufer und leben typischerweise als Parasit von der Verwaltung 
FREMDER Vermögen.
Ich kenne nur einen amerikanischen Hedge Fonds, der keine fremden Gelder 
einwirbt und nur eigene Gelder, bzw. das seiner Angestellten mehrt.

> 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 ;-)

Scrum-Consultants verkaufe Scrum.
Sie leben nicht von erfolgreicher Softwareentwicklung, behaupten aber 
ohne eigenen Erfolgsnachweis, anderen erfolgreiche Softwareentwicklung 
beibringen zu können.

: Bearbeitet durch User
von klausi (Gast)


Lesenswert?

Chris F. schrieb:
> Ich habe bisher noch kein Projekt erlebt bei dem diese
> "Total-Agil-Ideologie" wirklich richtig funktioniert hat.

Ich auch nicht!

Gerade jetzt wieder in einer einigermaßen großen Bank:

Agil wurde gehypt wie verrückt,  gab viele "agile Scrum Coaches", nicht 
nur das, wurde sogar auf "Management 3.0" umgeschaltet...

Das Ergebnis: voll cool, man hat einen Riesen-Release gestemmt, in 
Produktionssysteme gespielt.

Mit dem Ergebnis: mehrere Tage Ausfall des Ebanking, Kunden verärgert, 
und Support Hotline  hat keine Ahnung über den firmeneigenen Ausfall..!

von Stefan F. (Gast)


Lesenswert?

Chris F. schrieb:
> Das Dumme ist und bleibt bei solchen "agilen" Methodenwerken

Ich finde das dümmste dabei, dass agile Methoden oft als Lösung gegen 
Überlastung des Personals eingeführt wird. Als ob die Softwareentwickler 
dadurch dreimal so schnell würden und zugleich entspannter wären.

Agile Entwicklung bringt ein gewisses Maß an Flexibilität, was auch oft 
ein Grund für die Einführung der Methode ist. Allerdings werden hier die 
Erwartungen oft zu hoch gesteckt. Man pickt sich das gute (Flexibilität) 
heraus, und ignoriert, dass jede Planänderung Zeit und Geld kostet.

"Aber ihr seid doch jetzt Agil", heißt es dann, wenn die Entwickler um 
mehr Zeit bitten.

von Stefan F. (Gast)


Lesenswert?

Peter M. schrieb:
> Scrum-Consultants verkaufe Scrum.
> Sie leben nicht von erfolgreicher Softwareentwicklung, behaupten aber
> ohne eigenen Erfolgsnachweis, anderen erfolgreiche Softwareentwicklung
> beibringen zu können.

Amen.

Es gibt Dinge, die unsere Welt nicht braucht. Diese Berater gehören 
dazu.

von r c (Gast)


Lesenswert?

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

Ich kenne keine Abteilung, die sich zu >50% mit Softwareentwicklung 
befasst, die Scrum NICHT benutzt.

Allerdings gib't es schon extreme Unterschiede, wie es gelebt wird.

von Aufreger (Gast)


Lesenswert?

Irgendwie hat jeder zweite einen Scrum Lehrgang in LinkedIn absolviert 
und nennt sich jetzt dort stolz "SCRUM MASTER". Sogar in WhatsApp oder 
Instagram schreiben die M.Sc. Scrum Master usw.

Meistens sind es Frauen.

Warum ist das so? Warum ist das der neueste Shit im Berufsleben?

Ich höre überall nur noch agil, agil, agil, SAFe, SAFe, SAFe, Scrum 
hier, Product Owner da, Function Owner dort...

Ich kanns nicht mehr sehen und lesen...

von Cyblord -. (cyblord)


Lesenswert?

Aufreger schrieb:
> Warum ist das so? Warum ist das der neueste Shit im Berufsleben?

Es ist halt ein Titel wenn du sonst keinen Titel hast. In Xing oder 
LinkedIn sind doch 90% aller Titel gelogen. Das ist doch jeder Manager 
von irgendwas.

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

Aufreger schrieb:
> Warum ist das der neueste Shit im Berufsleben?

Ist schon wieder Schnee von gestern, bzw. so normal geworden dass man es 
nicht extra erwähnen muss. Aber heute sind alle "Manager" und "Master" 
von irgendwas, sogar Putzfrauen.

Bei uns bewerben sich zur Zeit zahlreiche "Spezialisten", die ihn ihrem 
Spezialgebiet keine 2 Jahre Erfahrung haben und auch keine entsprechende 
Ausbildung/Studium hatten. Das ist lächerlich.

von ●DesIntegrator ●. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Putzfrauen

purge-coordinator

von Abrissbirne (Gast)


Lesenswert?

kann man drehen wie man will:
Sachbearbeiter bleibt Sachbearbeiter, ganz egal ob Scrum-Master oder 
Product-Owner etc.

von Senf D. (senfdazugeber)


Lesenswert?

Abrissbirne schrieb:
> kann man drehen wie man will:
> Sachbearbeiter bleibt Sachbearbeiter, ganz egal ob Scrum-Master oder
> Product-Owner etc.

Sachbearbeiter klingt aber total unsexy und nach Beamtentum, daher 
möchte das keiner sein. Feel-Good-Manager klingt da gleich viel besser 
und moderner.

von Pandur S. (jetztnicht)


Lesenswert?

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

Das machen allenfalls Bastler so. Dann kommt das Deployment. Oft muss 
man sich noch um die Dokumentation nach aussen und Kompatibilitaeten 
kuemmern. Versionsnummern. Konfigurationsfiles. Allenfalls, wie kommt 
die Software an den Anwendungsort.

von Stefan F. (Gast)


Lesenswert?

Pandur S. schrieb:
> Das machen allenfalls Bastler so. Dann kommt das Deployment....> Dokumentation

Und der Test, und die intensive Beobachtungsphase nach dem Deployment.

von MaWin (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Und der Test, und die intensive Beobachtungsphase nach dem Deployment.

Das überlässt der moderne Softwerker schliesslich dem Kunden.

von Stefan F. (Gast)


Lesenswert?

MaWin schrieb:
> Das überlässt der moderne Softwerker schliesslich dem Kunden.

Leider.

Wann immer es geht (und das ist fast immer) testet bei uns erstmal der 
Programmierer selbst samt Protokoll. Dann ein anderer Programmierer, der 
schau auch in die Quelltexte. Dann übergeben wir an die QA zum 
offiziellen Test (wieder mit Protokoll). Und die übergeben an den 
Betrieb, wo nochmal kurz die normalen Fälle getestet und protokolliert 
werden. Die speziellen Corner-Case und Fehlerfälle lässt der Betrieb 
beim letzten Test aus.

Erst danach darf bei uns Software in die Produktions-Umgebung.

Dieser Aufwand ist nicht übertrieben sondern notwendig. Bei unseren 
Anwendungen werden persönliche Daten (Ausweisdokumente) und 
Bezahlvorgänge verarbeitet. Wir haften für alle Verluste durch Design-, 
Software- und Hardware-Fehler.

Wenn jemand den Ablauf par ordre du mufti abkürzt, werde ich immer sehr 
nervös.

von A. S. (Gast)


Lesenswert?

Pandur S. schrieb:
> Das machen allenfalls Bastler so. Dann kommt das Deployment.

Ich habe keine Ahnung, wo Du Egon zitiert hast, aber er hat vollkommen 
recht. Deployment und Co gibt es bei anderen Produkten auch, sind aber 
unabhängig von der Produktion. In seinen Worten steckt konzentriert der 
wesentliche Unterschied zwischen SW und anderen Produkten.

von J. S. (engineer) Benutzerseite


Lesenswert?

A. 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.

Ich glaube eher, dass es deshalb funktioniert, weil die Amis eh gerne 
hemdsärmelig arbeiten und zudem auch eine durchschnittlich schlechtere 
Ausbildung haben, als wir hierzulande. Strategien sind da weniger 
verbreitet und daher ist jede neue besser, als gar nichts.

Warum man sich hier in DE ausgerechnet da dranhängen muss, ist mir nicht 
plausibel! Ich beobachte SCRUM und das, was manche dafür halten, seit 
2008 und kann sagen, dass es schon deshalb nicht funktioniert, weil 
jeder etwas anseres darunter versteht.

Obendrein kommen viele aus Strukturen, die besser funktionieren und 
müssen mit SCRUM ein downgrade durchführen, oder sie haben zumindest das 
Gefühl, dass dem so ist.

Es gab und gibt eine Reihe von unbenannten Vorgehensweisen in der 
Produktentwicklung, die bestens funktionierten. Beispiel:

Stefan ⛄ F. schrieb:
> Erst danach darf bei uns Software in die Produktions-Umgebung.
> Dieser Aufwand ist nicht übertrieben sondern notwendig.

Ja, das kennt man aus gut sortierten Firmen, die SW herstellen, die 
sicherheitsrelevant ist. Nur um das zu tun, braucht man kein SCRUM, weil 
es hier - wie an vielen Stellen - nur ein neues Wort für altes tun ist.

Beitrag #6869366 wurde von einem Moderator gelöscht.
Beitrag #6869438 wurde von einem Moderator gelöscht.
Beitrag #6869468 wurde von einem Moderator gelöscht.
Beitrag #6869485 wurde von einem Moderator gelöscht.
von Jan H. (j_hansen)


Lesenswert?

Jürgen S. schrieb:
> Ich beobachte SCRUM und das, was manche dafür halten, seit
> 2008 und kann sagen, dass es schon deshalb nicht funktioniert, weil
> jeder etwas anseres darunter versteht.

Das beobachte ich auch. Wobei SCRUM eine sehr genaue Definition hat. 
Eine Zahl >90% der "SCRUM"-Projekte die ich gesehen habe waren weit 
davon weg - kein Wunder, dass das nicht funktioniert, wenn man auf sein 
bestehendes Chaos nur "SCRUM" draufschreibt.

von MaWin (Gast)


Lesenswert?

Jan H. schrieb:
> Das beobachte ich auch. Wobei SCRUM eine sehr genaue Definition hat.
> Eine Zahl >90% der "SCRUM"-Projekte die ich gesehen habe waren weit
> davon weg - kein Wunder, dass das nicht funktioniert, wenn man auf sein
> bestehendes Chaos nur "SCRUM" draufschreibt.

Wie kommst du drauf, sass es funktoniert, wenn du die SCRUM Regeln zu 
100% befolgst ?

Nie ausprobiert ? Es funktioniert rein gar nicht.

Du musst auch ein glückliches Leben haben, wenn du zu 100% nach Bibel 
oder Koran lebst.

von Stefan F. (Gast)


Lesenswert?

MaWin schrieb:
> Wie kommst du drauf, sass es funktoniert, wenn du die SCRUM Regeln zu
> 100% befolgst ?

Ich bin nicht der gefragte aber als ich das damals lernen musste stand 
genau diese Behauptung im Lehrbuch und wurde in der Schulung propagiert. 
Scrum funktioniert nur wenn man sich vollständig an das Konzept hält.

Genau daran scheiterte es dann auch. Also scheint die Behauptung wohl 
richtig zu sein. Man kann aber anders agil arbeiten, es muss nicht 
unbedingt nach SCRUM sein.

von Jan H. (j_hansen)


Lesenswert?

MaWin schrieb:
> Wie kommst du drauf, sass es funktoniert, wenn du die SCRUM Regeln zu
> 100% befolgst ?

Weil ich es gesehen habe.

> Nie ausprobiert ? Es funktioniert rein gar nicht.

Warum sollte es nicht funktionieren?

> Du musst auch ein glückliches Leben haben, wenn du zu 100% nach Bibel
> oder Koran lebst.

Ja, ich halte mich an Regeln. Wenn ich mich nicht an die C-Syntax halte 
und irgendwas hinschreibe dann:
* Kann ich nicht behaupten, in C zu entwickeln
* Wird nur Unsinn herauskommen

Wenn ich mich also dafür entscheide ein Projekt mit SCRUM durchzuführen, 
dann sollte ich es auch mit SCRUM machen und nicht irgendwie. Logisch, 
oder?

Beitrag #6869634 wurde vom Autor gelöscht.
von Berufsberatung (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich bin nicht der gefragte aber als ich das damals lernen musste stand
> genau diese Behauptung im Lehrbuch und wurde in der Schulung propagiert.

Das "kein wahrer Schotte"-Phänomen:
https://de.wikipedia.org/wiki/Kein_wahrer_Schotte

Kennt man aus Religionen und Ideologien.

von MaWin (Gast)


Lesenswert?

Jan H. schrieb:
> Warum sollte es nicht funktionieren?

Weil auch das mit dem Sozialismus nicht funktioniert hat.

Und weil auch der Koran nicht zum Leben passt.

Religionen sind Wahnvorstellungen, keine Lösungen.

Scrum ist eine Religion.

Und wer es je ausprobiert hat, gecoatcht, geschult, weiss, dass es nicht 
funktioniert.

von Jan H. (j_hansen)


Lesenswert?

MaWin schrieb:
> Jan H. schrieb:
>> Warum sollte es nicht funktionieren?
>
> Weil auch das mit dem Sozialismus nicht funktioniert hat.
>
> Und weil auch der Koran nicht zum Leben passt.
>
> Religionen sind Wahnvorstellungen, keine Lösungen.
>
> Scrum ist eine Religion.
>
> Und wer es je ausprobiert hat, gecoatcht, geschult, weiss, dass es nicht
> funktioniert.

Also hast du eine religiös-nebulöse Abneigung gegen SCRUM die du nicht 
konkretisieren kannst.

von Rick M. (rick-nrw)


Lesenswert?

SCRUM ist keine Lösung, wenn das Produkt Mist ist.

von MaWin (Gast)


Lesenswert?

Jan H. schrieb:
> Also hast du eine religiös-nebulöse Abneigung gegen SCRUM die du nicht
> konkretisieren kannst.

Nein, weil ich 20 Jahre in mehreren Firmeninkarnationen die immer 
strikter befolgte Umsetzung von Scrum miterleben durfte, und die immer 
dürftigeren Ergebnisse bewundern konnte. Die ersten Schulungen waren 
noch für SixSigma, dann kam das agile Chaos.

Scrum Fanboys von der Realität zu berichten ist ähnlich sinnlos wie 
einen Pfarrer zum Atheismus bekehren zu wollen.

von Chris R. (rcc)


Lesenswert?

Wir haben in der automotive Serienentwicklung bewusst auch mal Projekte 
mit Scrum aufgesetzt zum Lernen und Erfahrung sammeln.
Unterm Strich kam raus dass sowohl SCRUM als auch V-Modell (egal ob 
wenige grosse V oder viele kleine V) saubere Ergebnisse liefern können, 
ebenso kann man ASPICE und ISO26262 mit beiden Modellen abbilden. 
Genauso kann man mit kleinen V auch sich weiterentwickelnde 
Anforderungen gut abdecken.
Und mit beiden Prozessen kann man auch problemlos ein Projekt gegen die 
Wand fahren.

Je nach Teamstruktur (Charaktäre, Integration der Stakeholder uvm.) 
kracht es an anderen Stellen. Kosten und zeitmässig war nicht viel 
Unterschied. Scrum in einer V-Modell Firma ans Laufen zu bekommen hat 
einiges an Zeit gekostet, in beiden Welten ist der Aufwand um den 
Prozess auch in schwierigen Situationen einzuhalten ähnlich hoch. 
Scrum-Fundamentalisten oder bedingungslose Fanboys die nichts anderes 
machen wollen hatten wir bei V-Modell aber bei weitem nicht so 
ausgeprägt.

ASPICE Zertifizierung für den Scrumprozess war vom Aufwand her auch 
nicht anders als für den V-Modell Prozess.

von J. S. (engineer) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Scrum funktioniert nur wenn man sich vollständig an das Konzept hält.

Nun ja, eigentlich gilt das für alle Rezepte und Methoden, daß sie nur 
dann das gewünschte Ergebnis liefern, wenn man sich dran hält.

Neben dem schon festgestellten Umstand, daß sich viele eben nicht 100% 
an die Methoden halten, kommt eben hinzu, dass die Methode selber nicht 
alles abdeckt. Ich sehe z.B. das Problem, daß man Vorgehensweisen, die 
man für SW-Projekte erdacht hat und die in Teilen auch funktionieren 
mögen, kritiklos und unreflektiert auf das gesamte Projektgeschen 
ausdehnt, was regelmäßig scheitern muss, weil weite Teile von 
Entwicklungsaktivitäten außerhalb der Sw eben grundsätzlich andere 
Bedarfe haben. Auch das ist ja bereits erkannt wurden.

Und deshalb, weil viele erkennen, dass SCRUM-Methoden für ihren Bereich 
nicht taugen, wird bewusst oder unbewusst drum herum gearbeitet, was 
mithin wiederum der Grund dafür ist, daß SCRUM auch dort nicht 
funktioniert, wo es funktionieren hätte können.

von A. S. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Genau daran scheiterte es dann auch. Also scheint die Behauptung wohl
> richtig zu sein. Man kann aber anders agil arbeiten, es muss nicht
> unbedingt nach SCRUM sein.

Das ist aber bei jeder Religion so: Entweder es klappt oder man hat 
sich nicht 100% daran gehalten.

Woher kommt eigentlich der Glaube, dass ein paar Männer etwas 
allgemeingültiges gefunden haben. Bei Diäten, Religionen, Yoga, ... 
geschenkt.

von Scrum-Geschädigter (Gast)


Lesenswert?

A. S. schrieb:
> Woher kommt eigentlich der Glaube, dass ein paar Männer etwas
> allgemeingültiges gefunden haben.
Ich glaube es liegt daran, wer das ist und wer ihm nachhängt. Es reicht, 
wenn irgendein abgetakelter Schaubudenhengst (= Professor für irgendwas) 
lautstark auf einem Kongress etwas Tolles vorstellt und es wird 
kritiklos als Allheilmittel übernommen.

Dipl Ing ( FH ) schrieb:
>> 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.
> Viel besser kan man es nicht zusammenfassen !!!
> SEHR GUT !!!
Ich schließe mich an! Unser lieber Konzernboss hat erst vor Tagen wieder 
verkündet, die gesamte Firma auf agil umzustellen und jetzt werden 
Scrum-Master ausgebildet, was das Zeug hält. Jeder, der zum intensiven 
Denken zu bequem oder zu alt ist, um sich mit den Details neuer 
Technologien zu befassen, meldet sich als potenzieller Master, um seine 
Zeit mit managing und Verwaltung zu vertrödeln, weil er das als bequemer 
ansieht.

von Scrum-Geschädigter (Gast)


Lesenswert?

Chris R. schrieb:
> Wir haben in der automotive Serienentwicklung bewusst auch mal Projekte
> mit Scrum aufgesetzt zum Lernen und Erfahrung sammeln.

Interessante Auflistung. Was ist das Ergebnis? SCRUM beibehalten? Global 
oder projektweise?

von Cyblord -. (cyblord)


Lesenswert?

SCRUM funktioniert dann gut, wenn es ohne auch gut funktioniert.

Wenn das Team passt und die Leute kompetent sind, dann bekomme ich mit 
jeder Methode gute Software hin. Wenn das nicht der Fall ist, hilft 
SCRUM leider auch nicht.

von Oliver S. (oliverso)


Lesenswert?

Stefan ⛄ F. schrieb:
> Scrum funktioniert nur wenn man sich vollständig an das Konzept hält.

Wirklich praktikable und robuste Prozesse erkennt man daran, daß die 
auch dann stabil funktionieren, auch wenn nicht alles genau nach Plan 
läuft.

Oliver

von Udo S. (urschmitt)


Lesenswert?

Cyblord -. schrieb:
> SCRUM funktioniert dann gut, wenn es ohne auch gut funktioniert.

So ist es, nur ist es dann eigentlich ein überflüssiges Korsett.

Es ist eigentlich ein Oxymoron, dass man ein Tool/Vorgehen als "agil" 
preist also wendig, schnell an geänderte Problemstellungen anpassbar, 
aber dazu voraussetzt dass das nur dann funktioniert wenn man sich stur 
und zu 100% an diese starre Konzept hält.

von J. S. (engineer) Benutzerseite


Lesenswert?

●DesIntegrator ●. schrieb:
> Stefan ⛄ F. schrieb:
>> Putzfrauen
> purge-coordinator

Unterschätze die Putzfrauen nicht:

Die Kollegen in einer Abteilung, die mit SCRUM arbeiteten, wunderten 
sich des Öfteren, warum Tasks die eigentlich abgearbeitet waren, auf der 
TODO-Spalte wieder auftauchten und umgekehrt in Arbeit befindliche 
Teilprojekte als "erledigt" standen, was immer wieder zu Verdruss und 
Missverständnissen führte. Bisweilen passierte es sogar, dass Aufgaben 
komplett verschwanden oder solche, die schon im virtuellen Papierkorb 
waren, wieder auftauchten.

Es dauerte eine Weile, aber irgendwann konnte ich mit eigenen Augen 
sehen, was passierte: 3x die Woche kam abends die Putzfrau, welche 
feucht durchwischte und danach immer das Fenster öffnete, um  den 
Zitrusduft rauszulassen. Dabei wurden Zettel runtergeweht und landeten 
auf dem Boden. Die Putzfrau war fleißig und pflichtbewusst und hängte 
die bunten Zettelchen einfach wieder auf, ohne um die Wirkung der 
Position der Notizzettel zu wissen. Man fasst es eigentlich nicht, dass 
da keiner drauf gekommen war, aber es stimmte: Die Putzfrau agierte 
ungewollt als Scrum-Master.

von J. S. (engineer) Benutzerseite


Lesenswert?

Udo S. schrieb:
> Es ist eigentlich ein Oxymoron, dass man ein Tool/Vorgehen als "agil"
> preist also wendig, schnell an geänderte Problemstellungen anpassbar,
> aber dazu voraussetzt dass das nur dann funktioniert wenn man sich stur
> und zu 100% an diese starre Konzept hält.

Eigentlich nicht, denn sich formell an etwas zu halten, das inhaltlich 
"Weichheit" vorgibt, ist keineswegs starr. Viele Schluderer sind ja auch 
sehr konsequent schludrig :-)

Das Problem das ich mit SCRUM habe ist dreierlei:

a) inhaltlich gesehen wird ein fester Zeittakt vorgeben, der nicht 
notwendigerweise auf das Vorgehen passt. Es gibt Aufgaben die sehr viel 
enger getaktet werden müssen, um sie zu synchen und umgekehrt.

b) es wird vielfach alter Wein in neuen Schläuchen verkauft und so 
getan, als sei das erstmalige Einführen einer Methode automatisch eine 
Verbesserung, was bekanntlich nur dann stimmt, wenn eine bereits 
existierende Methode auch wirklich verbessert wird. Da SCRUM aber eher 
dazu dient, einen zuvor unorganisierten ->Haufen zu koordinieren, ist 
das wie beim Autopilot im Sportflugzeug: Ein erfahrener Pilot steuert 
besser und genauer und ist faktisch tatsächlich der agilere

c) da SCRUM praktisch eine Koordination vorgibt, die eine gewisse 
Dynamik vorgibt, neigen viele Nutzer dazu, sich noch weniger Gedanken 
über vorausschauendes Handeln in Projekten zu machen, als sie es ohnehin 
schon tun und bei der steigenden Komplexität heutiger Projekte braucht 
es IMO eher mehr Vorausdenken und Vorausplanung, als früher. Damit führt 
die Nutzung von SCRUM (ungewollt) zu mehr Chaos, das es aber nicht in 
der Lage ist, wegzukompeniseren.

Auch der SRUM-Master hat nicht das Potenzial dazu und ist streng 
genommen auch nicht derjenige, der das zu leisten hätte. Mithin habe ich 
auch mit dem Titel des SCRUM-Masters ein Problem, wenn ich sehe, dass 
solch ein Titel in Wochenendseminaren erworben werden kann.

Ich habe große Probleme, mir vorzustellen, dass man in 2 Tagen etwas 
lernen kann, das einen befähigt, einen Entwicklerhaufen zu koordinieren, 
oder sich ihn selber koordinieren zu lassen, damit eine Art von Ordnung 
entstehen kann, die über das signifikant hinaus geht, was sich erfahrene 
Entwickler über Jahre an Vorgehensweisen angeeignet haben.

von J. S. (engineer) Benutzerseite


Lesenswert?

Man kann sogar noch weiter gehen und feststellen, dass diejenigen 
Entwickler, die ein funktionierendes Konzept für die Umsetzung von 
Projekten haben, als starr und unflexibel hingestellt werden, auch wenn 
es genauer und ausgefeilter ist.

Nimmt man z.B. eine typische Geräteentwicklung mit Mechanik, Elektronik 
und Software, dann gibt es ganz bestimmte Zyklen und Punkte, an denen 
das synchronisiert werden muss und es gibt Schleifen, die innen in den 
Komponentensträngen laufen. Wo diese Punkte jeweils sind, hängt von der 
Balance der 3 Komponenten und damit vom Gerät ab. Es gibt Systeme, die 
stark mechaniklastig sind, z.B. Optiken, Präzisionsmechaniken und 
Ähnliches, die zu anderen (früheren) Zeitpunkten eine rudimentäre 
Elektronik und Software brauchen, um sie zu testen und optimieren zu 
können. Dagegen gibt es Systeme, die das gar nicht brauchen und erst 
alle Iterationen in der Elektronik und Software vollzogen sein müssen 
(oder dürfen) bevor man es zusammenwirft. Hinzu kommt, dass je nach 
Projekt unterschiedliche Komponenten schon teilfertig aus Vorprojekten 
übernommen werden.

Solche Dinge aufzuplanen erfordert entsprechendes Knowhow der 
Systemtechnologen und genaues Wissen um die Abläufe. An der Stelle 
könnte man ein SCRUM-System einsetzen, um die Ideen, die Vorschläge und 
die Konzepte gemeinsam in engen Zeitschleifen zu formulieren und zu 
optimieren, um dann etwas weitgehend Durchdachtes an die Entwickler zu 
geben.

Stattdessen läuft es oft genau umgekehrt:

Man springt mit 2 DIN-A4-Seiten an Konzept in die Abteilungen und lässt 
dann alle längs und quer-synchronisieren und verschiebt das SCRUMing so 
in die Abteilungen, wo das halb Angedachte dann ausreifen soll. Da 
denken dann aber oft zu viele- und nicht selten auch die falschen 
Personen mit und entwickeln lokale Lösungen, die dann wieder Aufgaben 
für anderen aufwerfen. Damit steigt der Koordinationsaufwand und die 
Nutzung von SCRUM rechtfertigt sich zu 50% selber.

SCRUM mag zur Lösung einer definierten Aufgabe gut sein, an denen ein 
eng begrenzter Personenkreis mit gleichem Wissen und Befähigung 
arbeitet, damit man Aufgaben schnell umverteilen kann, was ja aus 
Projektleitersicht sehr wichtig ist.

Es macht aber IMHO keinen Sinn, solche Konzepte quer über alle 
Abteilungen zu ziehen, wo jeder etwas anderes tut und anderes Wissen hat 
und damit auch Elektroniker, Tester und Mechaniker mit einzubeziehen, so 
als sei die gesamte Entwicklungsabteilung aus 30 Leuten ein Riesen-Team, 
wo jeder ständig über alles Bescheid wissen muss, um über die nächsten 
Schritte mit zu entscheiden. Das ist definitiv nicht nur nicht 
erforderlich sondern auch kontraproduktiv.

Genau das sehe ich aber in vielen Firmen:

Da stehen 10 und mehr Personen in einer Runde zusammen und berichten dem 
Projektleiter über ihre Fortschritte und jeweils N-1 davon hören mit, 
während deren Zeituhren nutzlos laufen, weil sie mit dem 
Projektfortschritt des Kollegen Müller von gestern auf heute nichts 
anzufangen wissen. Selbst wenn der Herr Müller auch Software macht und 
sogar am gleichen Paket arbeitet, hat es auf die eigene Arbeit keinen 
direkten Einfluss und das breit verteilte Wissen um seine Probleme hilft 
ihm nicht weiter, da man ihm praktisch keine Tipps geben kann, ohne sich 
seine Sachen wirklich ganz genau anzusehen. Daher läuft es oft auf die 
typischen Tipps aus der Hüfte hinaus, die aus gleich mehreren Kehlen 
kommt.

Wichtiger wäre die Definition klarer milestones mit Zeitpunkt und 
Inhalt, damit alle gerade drauf zu arbeiten können und der Synch-Aufwand 
klein bleibt und nicht einer etwas macht, was zu große Auswirkungen auf 
andere hat, die erst beim Umsetzen auftauchen, statt sie sich vorher zu 
überlegen. Schon wenn Elektronik-Entwicklung und Softwareerstellung 
nicht gut genug entkoppelt sind, gibt es Chaos und beide Seiten müssen 
unproduktive Änderungen machen, weil man feststellt, dass das Konzept 
nicht passt.

Die Denkarbeit in den Projekten muss so weit als möglich von der 
Umsetzung entkoppelt werden damit ein Ziel, das definiert ist ohne große 
Änderungen erreicht wird. Iterationen im Projekt müssen mit milestones 
abgefangen werden, z.B. wenn mitten drin neue Anforderung kommen.

Alle Team-Mitglieder müssen sich neu und spontan ergebende Aspekte 
frühzeitig melden, sie müssen erst abgestimmt werden und nach Beschluss 
Eingang in einen kommenden zu definierenden milestone haben. Innerhalb 
eines Projektteilziels sehe ich das nur bei der Umsetzung von einer 
Software, wo drei-vier Leute dran arbeiten - dort macht das Sinn. Wenn 
der Softwerker aber etwas macht, was dann HW-Änderungen zur Folge haben 
sollte, ist was falsch gelaufen.

Daher muss der Projektleiter derjenige sein, der die Übersicht behält 
und die Fortschritte der Mitglieder im Auge hat. Damit das aber klappt, 
braucht es detaillierte Umsetzungspläne, also eine Vorschrift, was 
Müller, Meier und Schulze zu tun haben und zu tun gedenken und das 
müssen sie selber aufplanen und auch selber pflegen. So etwas kann man 
auch elektronisch gestützt machen, indem man sich eine TODO-List 
aufbaut, die Zeiten und Erfüllungsprozente enthält. Dann hat man 
jederzeit eine Übersicht, über das was geleistet ist und wann der 
nächste milestone erfüllt sein wird. Das sieht dann auch der 
Projektleiter, wenn er es spontan abfragt, um zu checken , wo jeder 
steht kann gfs. umplanen. Das muss er aber nicht jeden Tag und auch 
nicht bei Jedem.

Elektronisch gestützt sollte auch ein SCRUM-Management selbst sein. 
Sofern keine andere Software vorliegt, empfehle ich meinen Kunden immer, 
EXCEL zu verwenden. Dort lassen sich die bunten Zettel sauberer 
beschreiben, mit Inhalten und Dokumenten verlinken, als Taskt leicht 
verschieben und es lässt sich auch einfacher mit MS Teams arbeiten, 
sodass niemand auf die Idee kommen muss, das Bunte-Zettel-Board nach dem 
Meeting abzufotografieren, um es durch die Welt zu schicken (was ich 
schon miterlebt habe!)

Und: Es fallen vor allem keine Zettel aus dem Excel raus, sodass die 
Putzfrau zum Scrum-Master wird:
Beitrag "Re: Verbreitung von SCRUM"

von Heino (Gast)


Lesenswert?

Scrum-Geschädigter schrieb:
> Unser lieber Konzernboss hat erst vor Tagen wieder
> verkündet, die gesamte Firma auf agil umzustellen und jetzt werden
> Scrum-Master ausgebildet

Das muss sich um VW handeln :)

Beitrag #7091430 wurde von einem Moderator gelöscht.
von Stefan F. (Gast)


Lesenswert?

Die meisten Firmen könnten viel mehr mit einem "Doku Master" anfangen.

Beitrag #7091531 wurde von einem Moderator gelöscht.
von Egon D. (Gast)


Lesenswert?

Udo S. schrieb:

> Cyblord -. schrieb:
>> SCRUM funktioniert dann gut, wenn es ohne auch gut
>> funktioniert.
>
> So ist es, nur ist es dann eigentlich ein überflüssiges
> Korsett.

Nicht notwendig.
Es gibt in der Realtität mehr als "Schwarz" oder "Weiss".

Scrum versucht -- wie jede andere Methodik -- auch nur,
das lehrbar und lernbar zu machen, was talentierte Leute
"einfach so" können.


> Es ist eigentlich ein Oxymoron, dass man ein Tool/Vorgehen
> als "agil" preist also wendig, schnell an geänderte
> Problemstellungen anpassbar, aber dazu voraussetzt dass
> das nur dann funktioniert wenn man sich stur und zu 100%
> an diese starre Konzept hält.

Der Satz enthält m.E. mindestens drei inhaltliche Fehler.

von Egon D. (Gast)


Lesenswert?

Jürgen S. schrieb:

> a) inhaltlich gesehen wird ein fester Zeittakt vorgeben,
> der nicht notwendigerweise auf das Vorgehen passt.

Das ist zwar richtig, aber ich würde diesen Punkt nicht
dramatisieren. Das ist m.E. ein Zugeständnis an die
Einfachheit der Methode; sie soll ja praktikabel bleiben.


> Es gibt Aufgaben die sehr viel enger getaktet werden
> müssen, um sie zu synchen und umgekehrt.

Ich habe das so aufgefasst, dass die Methode nur ein
Minimum an Zeremonien VORGIBT. Dass sich Teile des
Teams -- oder auch alle -- öfter treffen, als die
Methode vorschreibt, wird ja nicht verboten.


> b) [...] Da SCRUM aber eher dazu dient, einen zuvor
> unorganisierten ->Haufen zu koordinieren, ist das wie
> beim Autopilot im Sportflugzeug: Ein erfahrener Pilot
> steuert besser und genauer und ist faktisch tatsächlich
> der agilere

Das ist sachlich richtig -- aber ein unsinniger Vergleich.

Eine eingespielte Truppe ist NATÜRLICH besser als ein
zusammengewürfelter Haufen -- ist das jetzt echt so
verwunderlich?

Soweit ich gehört habe, sind bei den Amis ad hoc zusammen-
gewürfelte Teams noch häufiger als bei uns. Es hat wenig
Sinn, eine dort entstandene Methode unreflektiert auf
hiesige Verhältnisse zu übertragen.


> c) da SCRUM praktisch eine Koordination vorgibt, die
> eine gewisse Dynamik vorgibt, neigen viele Nutzer dazu,
> sich noch weniger Gedanken über vorausschauendes Handeln
> in Projekten zu machen, als sie es ohnehin schon tun
> und bei der steigenden Komplexität heutiger Projekte
> braucht es IMO eher mehr Vorausdenken und Vorausplanung,
> als früher.

Dem zweiten Teil (Komplexität) stimme ich zu; dennoch
denke ich, dass Du das Pferd vom Schwanz her aufzäumst.

Meiner (durchaus beschränkten) Erfahrung nach können nur
die allerwenigsten Leute kurz und prägnant erklären, wie
Entwicklungsarbeit funktioniert -- und das betrifft m.E.
Entwickler (!) genauso wie Manager.
Das führt dann dazu, dass wechselseitig unsinnige Vorgaben
gemacht oder Wundertaten verlangt werden, die nicht zu
leisten sind.

Eine besondere Gruppe sind die alten Kämpfer -- sie können
es zwar auch nicht immer erklären, wissen dafür aber aus
Erfahrung, was zu tun ist. Da ihre Intuition aber nicht
Kraftpunkt-fähig ist, werden ihre Ansichten einfach vom
Tisch gewischt...


> Damit führt die Nutzung von SCRUM (ungewollt) zu
> mehr Chaos, das es aber nicht in der Lage ist,
> wegzukompeniseren.

Ich denke, die Lage ist noch etwas schlimmer: In einem
"Wasserfall"-Projekt kann man während der Projekt-
laufzeit ganz gut arbeiten, wenn die Führungstruppe
ihr Handwerk versteht.
Das böse Erwachen kommt dann erst ganz am Schluss des
Projektes, wenn nix aneinanderpasst, am Markt vorbei-
entwickelt wurde und dergleichen. Das ist dann primär
das Problem der Chefetage -- und erst sekundär das der
Indianer.

Da die Häuptlinge den "big bang" unbedingt vermeiden
möchten, aber andererseits nicht die leiseste Ahnung
davon haben, was die Nerds eigentlich MACHEN, wenn sie
entwickeln, bietet sich "agil" als Rettung an: Jeder
muss sich ständig mit jedem abstimmen, keine Festlegung
ist verlässlich. Wenn die Entwickler reihenweise in der
Klappsmühle landen, ist das ja ihr PERSÖNLICHES Problem,
kein BETRIEBLICHES. Privatisierung gesellschaftlicher
Risiken.

Ich denke aber nicht, das Scrum das primäre Problem
ist; das ist eher ein hilfloser Versuch der Lösung.

Das Problem ist m.E. die unglaublich gestiegene
Komplexität der Aufgaben. Ironischerweise verschlimmert
die Automatisierung geistiger Routineaufgaben das Problem,
statt es abzuschwächen -- das, was vor 50 Jahren eine
ganze Abteilung geleistet hat, muss heute ein einzelner
Entwickler beherrschen.

Die Folge sind heterogene Team -- da arbeitet eben ein
Mechaniker und ein Programmierer und ein Digitalentwickler
und ein HF-Mensch an einem Gerät, und der Chef ist ein
Physiker.

Folge: Der "allwissende Planer", der vor fünfzig Jahren
vielleicht noch funktioniert hat, ist zur Illusion
geworden; die Projektsteuerung muss (zumindest teilweise)
auch vom Team gemacht werden, weil das von einem Einzelnen
in vielen Fällen nicht mehr beherrschbar ist.

Genau das wird aber nirgendwo gelehrt.


> Ich habe große Probleme, mir vorzustellen, dass man in
> 2 Tagen etwas lernen kann, das einen befähigt, einen
> Entwicklerhaufen zu koordinieren, oder sich ihn selber
> koordinieren zu lassen, damit eine Art von Ordnung
> entstehen kann, die über das signifikant hinaus geht, was
> sich erfahrene Entwickler über Jahre an Vorgehensweisen
> angeeignet haben.

Kann man ganz sicher nicht. Es wäre ja schon etwas gewonnen,
wenn man keine 20 Jahre Erfahrung mehr bräuchte, sondern mit
einem Jahr Training und Anleitung auskäme...

Man muss kein Top-Entwickler sein, um eine Entwicklertruppe
zu führen. Man muss nur wissen, wie Entwickler ticken, muss
ihnen die Verwaltungsarbeit abnehmen und den notwendigen
Input liefern. Die Probleme LÖSEN können sie dann schon
allein...

Der beste Chef, den ich bisher hatte, war... ein Kaufmann.
Man sollte es kaum glauben...

von A. S. (Gast)


Lesenswert?

Egon D. schrieb:
> Man muss kein Top-Entwickler sein, um eine Entwicklertruppe
> zu führen

Doch

Ein Trainer muss auch zum immer ein top Fußballer (gewesen) sein. Ein 
Chefentwickler muss top Entwickler sein. So ist es auch in erfolgreichen 
Firmen.

Natürlich gibt es auch Projektleiter, die die Entwickler entlasten und 
Verwaltungsarbeit abnehmen. Die führen dann aber nicht.

Der Führende muss nicht in jeder Disziplin top sein, nicht Mal in einer 
der gerade verwendeten. Aber er braucht diese Erfahrung, notfalls aus 
einer anderen Disziplin.

von J. S. (engineer) Benutzerseite


Lesenswert?

Egon D. schrieb:
> Soweit ich gehört habe, sind bei den Amis ad hoc zusammen-
> gewürfelte Teams noch häufiger als bei uns.
Genau darauf wollte ich mit meinem Beispiel hinaus:

Eine Methode, die an einer Stelle für eine Gruppe entwickelt wurde, 
passt nicht automatisch auf eine andere, in einem anderen Land.

Gerade die amerikanische Methode der kurzen Ausbildung und der 
hemdsärmeligen Besetzung von Stellen, wo Mr. Miller auf Empfehlung von 
Mr. Meyer eingestellt wird, weil ein Teamleiter für die Besetzung 
"seines" Teams alleinverantwortlich ist, führt zu heterogenen 
Besetzungen, obwohl sie homogener sein könnten. In Deutschland haben wir 
einen anderen Bildungsfokus und Arbeitsstile, die sich ja bisher 
durchaus bewährt haben. Oder sagen wir "hatten", bis man auf die Methode 
USA gesetzt hat.

Ein Punkt z.B. ist, dass Ingenieure in DE immer sehr viel selbständiger, 
fachübergreifender und verantwortlicher arbeiteten, als in vielen 
anderen Ländern. Diese Diskrepanzen sehe ich im Übrigen auch bei der 
Betrachtung von Methoden wie KANBAN und KAIZEN, die aus Japan kommen. In 
Japan wird sehr stark Top-Down gedacht und dort entscheidet oft alleinig 
der Boss.

von ●DesIntegrator ●. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Lesenswert?

Jürgen S. schrieb:
> ●DesIntegrator ●. schrieb:
>> Stefan ⛄ F. schrieb:
>>> Putzfrauen
>> purge-coordinator
>
> Unterschätze die Putzfrauen nicht:
>
> Die Kollegen in einer Abteilung, die mit SCRUM arbeiteten, wunderten
> sich des Öfteren, warum Tasks die eigentlich abgearbeitet waren, auf der
> TODO-Spalte wieder auftauchten und umgekehrt in Arbeit befindliche
> Teilprojekte als "erledigt" standen(...)

> Es dauerte eine Weile, aber irgendwann konnte ich mit eigenen Augen
> sehen, was passierte: 3x die Woche kam abends die Putzfrau, welche
> feucht durchwischte und danach immer das Fenster öffnete, um  den
> Zitrusduft rauszulassen. Dabei wurden Zettel runtergeweht und landeten
> auf dem Boden. Die Putzfrau war fleißig und pflichtbewusst und hängte
> die bunten Zettelchen einfach wieder auf(...)

(ᐛ)

Ich hätte gedacht, dasss die modernen Arbeitsweisen dazu führen sollten,
eben KEINE Zettelwirtschaft mehr zu haben

von Pleitegeier (Gast)


Lesenswert?

A. S. schrieb:
> Egon D. schrieb:
>> Man muss kein Top-Entwickler sein, um eine Entwicklertruppe
>> zu führen
>
> Doch
>
> Ein Trainer muss auch zum immer ein top Fußballer (gewesen) sein. Ein
> Chefentwickler muss top Entwickler sein. So ist es auch in erfolgreichen
> Firmen.

Mourinho, Nagelsmann, Sampaoli, Sacchi, Benitez, Villas-Boas, um nur 
einige Gegenbeispiele zu nennen, die mir auf Anhieb einfallen.

von Stefan F. (Gast)


Lesenswert?

A. S. schrieb:
>> Man muss kein Top-Entwickler sein, um eine Entwicklertruppe
>> zu führen

> Doch

Das habe ich aber anders erlebt. Der mit Abstand beste Projektleider mit 
dem ich (als Softwareentwickler) den vergangenen 30 Jahren zu tun hatte, 
hat noch nie eine einzige Zeile programmiert.

von J. S. (engineer) Benutzerseite


Lesenswert?

Stefan F. schrieb:
> Projektleider
:-)

Stefan F. schrieb:
> hat noch nie eine einzige Zeile programmiert.
die sind bei Vielen sehr beliebt, weil sie denen alles unterjubeln 
können.

Mir sind die Kompetenten lieber, weil die ihre Grenzen und die 
Komplexität des Themas verstehen und meine Lösungsansätze nachvollziehen 
können, statt sich auf die einfachen und schnellen Vorschläge stürzen, 
weil sie aus Unsicherheit nichts überschauen und "sichere" Wege gehen 
wollen.

von T.U.Darmstadt (Gast)


Lesenswert?

Pleitegeier schrieb:
> Mourinho, Nagelsmann, Sampaoli, Sacchi, Benitez, Villas-Boas
allesamt Erst- und Zweitliga-Spieler in ihren Ländern gewesen- also eher 
schlechtes Gegenbeispiel.

von Sergey Z. (sergeyz)


Lesenswert?

Statt ein (Fachfremder) Scrum "master", hätte ich gern ein weiterer 
Entwickler im Team. Jemand der im Meetings sitzt, Zeug delegiert, und 
mich fragt "welches Tier bin ich", brauche ich wirklich nicht.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.