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.
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
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..!
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.
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.
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.
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...
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
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.
kann man drehen wie man will: Sachbearbeiter bleibt Sachbearbeiter, ganz egal ob Scrum-Master oder Product-Owner etc.
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.
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.
Pandur S. schrieb: > Das machen allenfalls Bastler so. Dann kommt das Deployment....> Dokumentation Und der Test, und die intensive Beobachtungsphase nach dem Deployment.
Stefan ⛄ F. schrieb: > Und der Test, und die intensive Beobachtungsphase nach dem Deployment. Das überlässt der moderne Softwerker schliesslich dem Kunden.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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
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.
●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.
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.
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"
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.
Beitrag #7091531 wurde von einem Moderator gelöscht.
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.
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...
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.
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.
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
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.
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.
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.
Pleitegeier schrieb: > Mourinho, Nagelsmann, Sampaoli, Sacchi, Benitez, Villas-Boas allesamt Erst- und Zweitliga-Spieler in ihren Ländern gewesen- also eher schlechtes Gegenbeispiel.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.