Unser geschätzer Zimmermann Frank2000 setzt sich in diesem ausführlichen Gastbeitrag mit der Welt von Scrum auseinander. Dies dürfte der vermutlich längste Gastbeitrag (oder überhaupt Beitrag) sein, den wir bisher einzeln online gestellt haben. Aber es lohnt sich auf jeden Fall: Einem jeden Leser sei unbedingt(!) empfohlen den Artikel in seiner Gänze zu lesen, auch wenn man eine Weile beschäftigt ist.
Auch wenn man meint davon noch nicht selbst betroffen zu sein: Scrum ist ein sich ausbreitendes Thema und die Mechanismen dahinter gehen weit über die Welt von Softwareentwicklung hinaus. Aber ich will nicht zu sehr vorgreifen, bilden Sie sich ein eigenes Bild!
So jetzt komme ich gleich in die Verlegenheit meinen eigenen Senf dazu zu geben:
Wenn man Software entwickelt (und das ist eine meiner Tätigkeiten), dann hat man sicher schon von Scrum gehört. Ich hatte bis jetzt das Glück, dass der Kelch an mir noch vorüber gegangen ist, aber man ist doch bei einigen Kooperationen immer wieder mit Scrum konfrontiert und die Diskussion kommt auch immer wieder auf, ob man nicht auch ..... wie dem eben so ist.
Ich halte, ganz ähnlich wie Frank, aber nicht so fundiert, nicht allzuviel von Scrum. Was vor allem damit zu tun hat wie mir Scrum oft verkauft wird: Als die Revolution schlechthin. Mit Scrum würde alles besser, alle würden viel produktiver, alles wird irgendwie runder, Entwicklungen werden schneller und überhaupt. Das Problem, dass ich bisher damit hatte ist aber ein anderes: Methodik ersetzt kein Fachwissen, keine Qualifikation und auch keine Erfahrung. Ich sehe etliche Scrum-Teams, die teilweise aus Leuten bestehen, die kaum zwei Jahre von der Uni sind und meinen sie würden jetzt die Welt auf den Kopf stellen. Dabei bin ich nicht einmal sicher, ob Scrum nicht tatsächlich einiges bewegen kann, nur: Das ist wenn überhaupt nur eine Arbeitsverbesserung, es ist keine Revolution. Wo nix ist, kann auch nichts sein, dass weiß schon der Volksmund. Und daran ändert Scrum auch nichts.
Wenn ich die weiteren, deutlich qualifizierteren Äußerungen von Frank lese, dann drückt sich mir eine ganz andere Parallele in den Kopf: Die Schaffung des "neuen Menschen", das "jeder nach seinen Fähigkeiten und jeder nach seinen Bedürfnissen", das kenne ich doch schon. Ja, genau. Das ist Kommunismus, schlicht und einfach. Und fast alles was ich da lese bestätigt mich genau darin: Gleichmacherei, Abschaffen von Meritokratie, Übertragung von Verantwortung auf die Gruppe, das ist schlicht nichts anderes. Und ein sehr guter Grund sich davon fern zu halten.
Für jemanden, der mit PRINCE2 sozialisiert worden ist und schon in ein paar Projekten die Starrheit und Unflexibilität dieser Methode erlebt hat, klingt der agile Ansatz erst mal vielversprechend. Vor allem, wenn man eben nicht aus der reinen Produktentwicklung kommt, sondern in Implementierungsprojekten die Content-Seite vertritt.
Ich sehe aber auch die Nachteile, die Frank beschreibt, nämlich dass die Methode zum Selbstzweck wird - "we're working ÄDSCHAIL". Oftmals ist das nur ein schicker Aufkleber und ein wenig Selbstbestätigung - ich erinnere mich an eine Projektevaluation, bei der ich den ganzen Konferenzraum in schallendes Lachen versetzt habe durch die Frage, ob es nun tatsächliche Nachteile für den Projektverlauf gehabt hat, dass wir (product Owner) dem Dienstleister den versprochenen Scrum Room nie zur Verfügung gestellt haben .
Was ich aber nicht wirklich nachvollziehen kann, sind die "ideologiekritischen" Punkte von euch beiden. Ich glaube, da muss man schon eine gewisse Priorität auf der Methode als Prämisse mitbringen (und da kenne ich tatsächlich Leute, wo man sich nach 3 Wochen Zusammenarbeit ganz gut erklären kann, warum der Berliner Flughafen nie fertig wird), und die fehlt mir irgendwo - letztendlich war eigentlich immer die Qualität des Produkts und die Zusammenstellung der Leute entscheidend für den Erfolg.
Das die Zusammensetzung der Leute (gemeint sind die Mitarbeiter?) eine entscheidende Rolle spielt: da sind wir uns ja einig.
Aber genau da sind Scrum-Befürworter anderer Meinung: jeder Mensch könne "reifen" und in einem Scrum-Team spiele die individuelle Leistung irgendwann keine Rolle mehr.
Oder noch deutlicher ausgedrückt: früher spielte auch Selektion eine wichtige Rolle. Man suchte bewusst leistungsfähige Mitarbeiter. Scrum behauptet jetzt, dass das Diskriminierung war und jeder Mensch leistungsfähig sei: man habe bisher die Menschen lediglich davon ABGEHALTEN, kreativ, motiviert und leistungsfähig zu sein. Nach dieser Sicht, ist eine Leistungskontrolle nicht geeignet, Faulheit zu vermeiden, sondern die Menschen sind faul, WEIL sie überwacht werden.
Wenn man den Mitarbeitern Vertrauen entgegen bringt, sie vollkommen in Ruhe lässt und alles dem Team überlässt - dann wird jeder Mitarbeiter (mit sanfter Führung durch den Scrum Master) eine Leistungsexplosion zeigen, Verantwortung übernehmen und kreativ sein.
___________________ Jeder, der Merkel stützt, schützt oder wählt, macht sich mitschuldig.
Witzig, die Referenz im Artikel auf den Beitrag im Blog von Sternkopf Consulting hat mich direkt getriggert - Mr. Sternkopf war Projektleiter bei einem der Projekte, wo ich auf Seiten des Lieferanten maßgeblich beteiligt war. Es darf geraten werden, welches davon es war: https://sternkopf-consulting.com/projekte/
Die Beschreibung des Projekts deckt sich nun nicht 100% mit meinen Erinnerungen, aber die Sichtweisen sind ja oft sehr unterschiedlich...auf eine Verbindung zu "agil" wäre ich bei der praktizierten Vorgehensweise aber nicht gekommen. Auch zu anderen Punkten gäbe es viel zu sagen, würde ich aber nur im Schutz totaler Anonymität tun...
Jetzt muss ich erst mal weiterlesen, ich hätte da auch noch ein paar Meinungen zu Scrum, Kanban und natürlich zur Mutter aller agilen Softwareentwickungsideen "XP" mitzuteilen.
Zitat von Meister Petz im Beitrag #3 Für jemanden, der mit PRINCE2 sozialisiert worden ist und schon in ein paar Projekten die Starrheit und Unflexibilität dieser Methode erlebt hat, klingt der agile Ansatz erst mal vielversprechend.
Es spricht ja nichts dagegen aus Fehlern des einen Systems zu lernen und Sachen besser zu machen. Deswegen muss man aber nicht mit der Tür ins Haus fallen. Bestes (neutrales) Beispiel, dass mir immer dazu einfällt ist: Duke Nukem whenever (okay, hiess eigentlich forever). Die haben ohne Rücksicht auf Verluste jahrelang ein Spiel produziert, bis sie am Ende festgestellt haben, dass sie hoffnungslos hinter der Zeit her waren und das nur noch einstampfen konnten (Dungeon Master 2 hatte ein ähnliches Problem). Da ist dann offensichtlich die starre Struktur nie hinterfragt worden. Aber das sind (hoffentlich) Ausnahmen.
Wenn ich etwas entwickele (was ich ja nun hauptberuflich mache), dann kriege ich schon mit was sich so auf dem Markt tut oder ob das noch Sinn hat. Und es ist Aufgabe des Projektleiters auch mal eine Entwicklung zu hinterfragen, gerade wenn sie sich lange zieht. Aber deswegen stelle ich nicht alle zwei Wochen (oder wie lange so ein Sprint gerade dauern soll) meine Projektziele in Frage.
Zitat letztendlich war eigentlich immer die Qualität des Produkts und die Zusammenstellung der Leute entscheidend für den Erfolg.
Aber genau das verneint Scrum ja. Und das ist auch meine zentrale "Ideologie"-Kritik. Wenn ich fähige Leute habe ist es bisweilen nicht von kriegsentscheidender Bedeutung nach welchem System ich arbeite. Die liefern in aller Regeln immer was gutes ab (wenn wir mal vorraussetzen, dass die Spezifikation nicht völlig absurd war, das gibt ja nun auch (Zitat aus einer Mail: "Was ist dem Kunden eigentlich genau verkauft worden?")). Umgekehrt kann ich mit einem Haufen von unerfahrenen Millenials, die alle unglaublich viele Kompetenzen haben aber vom Fach keine Ahnung (sorry, auf das Bild kann ich nicht verzichten) so viel Scrum machen wie ich will, die kriegen das nicht auf die Kette. Methode ersetzt kein Fachwissen.
Zitat von Frank2000 im Beitrag #4Wenn man den Mitarbeitern Vertrauen entgegen bringt, sie vollkommen in Ruhe lässt und alles dem Team überlässt - dann wird jeder Mitarbeiter (mit sanfter Führung durch den Scrum Master) eine Leistungsexplosion zeigen, Verantwortung übernehmen und kreativ sein.
Und erstaunlicherweise(?) erlebt man in der Realität GENAU das Gegenteil. Denn die Idee gab es ja bereits im Sozialismus. Und was passiert ist ganz simpel: Die Mitarbeiter tun fast gar nichts mehr. Weil es nämlich keinen Vorteil mehr hat. Wer sich in einem regulären Betrieb durchsetzt, der tut das in den seltensten Fällen aus altruistischen Motiven, sondern weil es ihm selber Vorteile bringt. Wenn ich diese Komponente aber beseitige, dann optimiert der Mitarbeiter nicht mehr den Nutzen ("das Lob") sondern die Kosten. Und Arbeit sind nun einmal Kosten. Sprich: Der arbeitet nicht mehr. Weil sein Kosten/Nutzen Verhältnis eben besser ist, wenn er faul rumsitzt. Daran ist die DDR zugrunde gegangen. Und hier wird wiedert einmal (...) das Gegenteil propagiert.
Ein schöner Beitrag, lieber Frank, noch dazu einer aus einer mir völlig unbekannten Welt, was den Wert des Artikels für mich erheblich steigert. Vor der Lektüre Ihres Beitrages hätte ich bei dem Stichwort "Scrum" noch mit den Achseln gezuckt. Ich lebe halt doch in einer anderen Filterblase als so mancher Co-Zimmermann.
Es ist wohl nur der hinter Scrum steckenden Ideologie geschuldet, dass die Mystifikation der Teamarbeit auch in diesem Konzept aufrechterhalten wird. Tatsächlich gibt es keine Teamarbeit, sondern nur unterschiedlich intensive Aggregierungen individueller Arbeit.
Zitat von Llarian im Beitrag #1der vermutlich längste Gastbeitrag (oder überhaupt Beitrag) sein, den wir bisher einzeln online gestellt haben.
Launisches aus zween Schienen.
6600 Wörter. Der längste Beitrag, den wir, zumindest in der Nach-Zettel-Ägide, hatten, war meine Levin-Schücking/Jonathan-Swift-Ausgrabung im letzten April; der kam knapp über 11.000 Wörter. Ist insofern natürlich nicht satisfaktionsfähig, als das kein originärer Beitrag war.
Zum anderen habe ich es mir frivolerweise zur Faustformel gemacht, "revolutionäre" Techniken, Verfahrensweisen, Damm- und Bahnbrüche und Radneuerfindungen, die mit englischen Akronymen oder ungeläufigen englischen Vokabeln etikettiert daherkommen, prinzipiell unter "Wiedervorlage" abzulegen, in der sicheren Erwartung, daß man fürderhin nichts weiter davon vernehmen wird oder das ausgesprochen niederschwellig zum Alltäglichen zählen wird, ohne revolutionären Elan zu entwickeln. NLP, RFID, VASIMR, CRISPR lassen grüßen.
"Les hommes seront toujours fous; et ceux qui croient les guérir sont les plus fous de la bande." - Voltaire
Ich bin selber eigentlich auch kein großer Scrum-fan, der Artikel hier scheint mir jetzt aber so einseitig, dass ich doch gerne ein paar Kontrapunkte setzen würde:
- Das Hauptrisiko bei einem Wasserfallprozess ist nicht, dass sich der Markt so schnell ändert, sondern dass die Spezifikation von vornherein falsch war. Und das ist ja erfahrungsgemäß gerundet immer der Fall. Abgesehen von extremen und deshalb auch extrem teuren Sonderfällen (Raumfahrt, medizinische Geräte....) kann der Auftraggeber von dem was er will im Voraus nur eine ganz grobe Richtung erklären. "Philosophisch" kann man das damit erklären, dass in der Hausbauanalogie der eigentliche Bau weg fällt, den macht nämlich der Compiler. Bei der Softwareentwicklung liegen also fast alle Kosten in dem Teil der Kette, den man beim Hausbau Planung nennen würde. (Mal abgesehen davon, dass natürlich auch ein Haus eher selten in der geplanten Zeit zu den geplanten Kosten mit den geplanten Eigenschaften fertig wird ...)
- Dementsprechend scheint es mir durchaus sinnvoll, von vornherein einzuplanen, dass sich der Plan öfter ändern wird. Abgesehen vom Hype der sich immer anlagert scheint mir das die eigentliche Grundidee von Agilität zu sein. Die einzige realistische Alternative ist Realitätsverweigerung - und das habe ich in der Praxis schon erlebt. Wenn man offiziell nicht iterativ arbeiten kann, dann hat man eben einen offiziellen Plan von dem die meisten Ausführenden den größten Teil seiner Lebensdauer wissen, dass er bereits gescheitert ist, das aber nicht wirklich ansprechen dürfen. Dann gibt es eben ein "Beamten-Mikado" (wer sich zuerst bewegt hat verloren) wer dann als erstes zugibt, dass es zu spät ist. Das ist nach meiner Erfahrung extrem demoralisierend und nach meiner Vermutung wirtschaftlich auch nicht im objektiven Interesse des Unternehmens. (Der zweite Teil ist nur Vermutung, weil man einwenden könnte, dass unrealistische Pläne immerhin Leistungsdruck erzeugen, das Fass will ich aber jetzt nicht auch noch aufmachen.)
- Die Dialektik, dass man einerseits planen muss, andererseits aber auch nicht wirklich zuverlässig planen kann ist übrigens nichts neues. Kann man für den Krieg schon alles bei Clausewitz nachlesen.
- Zumindest ursprünglich kommt Scrum weniger aus Endkundensoftware sondern aus der Automatisierung von Geschäftsprozessen. Inzwischen verkauft man so etwas glaube ich als "digitale Transformation". Ohne konkrete Zahlen vermute ich mal, dass das auch heute noch mehr ausmacht als Apps und Spiele, einfach weil Apps vom Softwaremarkt außerhalb des Silicon Valleys (wo kaum jemand Scrum verwendet) insgesamt einen kleinen Anteil haben.
- Dass man Apps in kurzen Zyklen ausliefert ist einfach sinnvoll. Bei klassischen Desktopanwendungen spricht gegen häufige Upgrades, dass Upgrades für den Benutzer lästig sind. Das ist bei Handy-Apps aber im Wesentlichen nicht mehr der Fall, was ein schöner technischer Fortschritt ist. Für häufige Upgrades sprechen dagegen die klassischen Probleme seltener Upgrades: Man muss auf nützlichen Dingen, die eigentlich schon fertig sind und Nutzen bringen könnten lange sitzen. Man muss öfter mal ein Release verschieben, weil noch dringend etwas rein muss, das wirklich nicht mehr auf das nächste warten kann. Man kriegt erst spät Feedback aus der Praxis und hat daher ein höheres Fehlsteuerungsrisiko.
- Dass Software oft als Bananenware (reift beim Kunden) ausgeliefert wird ist tatsächlich ärgerlich, aber schon seit Jahrzehnten so - und hat deshalb mit dem konkreten Entwicklungsprozess nichts zu tun. Habe ich jedenfalls auch schon in einem Wasserfallprozess mitgemacht.
- Ich kann mir schon Situationen vorstellen, in denen ein Scrum Master eine Art Politkommissar wird. Ähnliche Funktionen entwickeln sich wahrscheinlich immer wenn ein Prozess ohne Rücksicht auf die Realität durchgesetzt werden soll. Das ist aber jedenfalls nicht die offizielle Grundidee. Die eigentliche Idee ist eher den Umsetzungsverwaltung (beim Scrum Master) von der Anforderungsverwaltung (beim Product Owner) zu trennen. Und das scheint mir sinnvoll, weil zwischen den beiden Funktionen zumindest kurzfristig schon ein erheblicher Interessenkonflikt besteht. Ganz platt ausgedrückt ist der Scrum Master dafür zuständig, dass Anforderungen und reale Möglichkeiten ungefähr im Gleichgewicht bleiben. Wenn man sich darum nicht bewusst kümmert, ist es ja ziemlich erwiesen dass kaum jemand das von allein schaffen kann. Nun ist es natürlich eine offene Frage ob die Korrektur auch funktioniert und so viel ich weiß gibt es dazu noch keine nennenswerten empirischen Daten. Wenn es aber funktioniert, dann ist die Investition für den erwarteten Gewinn sogar ziemlich billig. Man stelle sich mal analog vor, die Politik hätte beim berliner Flughafen für 1/14 mehr alle zwei Wochen einen realistischen Überblick über die tatsächliche Lage gehabt.
- Das auch normal komplexe Prozesse zu komplex für einen echten zentralen Überblick sind, ist eigentlich eine Erkenntnis die rhetorisch eher zur Leserschaft von Zettels Raum als in die politische Linke passt. Reeds Bleistift, Heyek, u.s.w. Und für Softwareentwicklung muss man das verteilte und implizite Wissen eben zentralisieren und explizit machen und dabei werden sich natürlich jede Menge Umstände herausstellen, die auch der firmeninterne zentrale Planer nicht wusste. Ganz schlimm allerdings der gar nicht seltene Fall, dass der Chef die Illusion hat er könne so einen Überblick haben...
- Dass es über dem Team keinen Vorgesetzten mehr gäbe mag sich der eine oder andere Scrum-Jünger wünschen es ist aber weder von Scrum vorgeschrieben, noch in der Praxis irgendwie üblich.
- Dass Scrum versucht die Entwickler austauschbar zu machen ist aus Entwicklersicht ein berechtigter Kritikpunkt. Das hat aber nichts mit mit sozialistischen Ideen zu tun, eher mit turbokapitalistischen. Für den Unternehmer ist es natürlich wünschenswert möglichst wenige standardisierte Stellenbeschreibungen zu haben für die am Markt im Wesentlichen gleichwertige Alternativmitarbeiter verfügbar sind. Und für den Mitarbeiter dessen Marktposition dadurch geschwächt wird natürlich nicht.
- Zusätzlich haben der Arbeitgeber und langfristig auch die Entwickler noch ein weiteres Interesse an einer gewissen "Kollektivierung" der Softwareentwicklung: Wenn die Spezialisierung zu stark wird, hat man wahrscheinlich bald Codeteile für die nur einer "zuständig" ist und die deswegen auf Dauer auch nur noch einer versteht. Wenn der dann irgendwann die Firma verlässt, dann hat man extremen Mehraufwand wenn sich jemand komplett neu einarbeiten muss. Das ist quasi eine Kostenzeitbombe, von der eine unvorsichtige Geschäftsführung möglicherweise erst zu spät etwas merkt. Wenn die Software absehbar eine kurze Lebensdauer hat kann es sich schon lohnen sich den Mehraufwand der Wissensverteilung zu sparen. Das ist aber eine Abwägung, die man sich völlig bewusst machen sollte, sonst sammelt man eben Pfennige vor der Dampfwalze. Und nein, mit mehr Doku kann man das nicht lösen. Selbst wenn die Zeit für eine gute Doku da ist, kann der Einzelenntwickler die Fragen eines zunächst Außenstehenden nicht realistisch vorhersagen.
- Dass die Kontrolldichte für den einzelnen Mitarbeiter bei Scrum geringer wird halte ich nun wirklich für ein Gerücht. Sie wird freilich freundlicher verpackt. Praktisch hat man aber ein Sprint Plannig faktisch also zweiwöchentliche Zielvereinbarungen und einen Daily Scrum, faktisch also tägliche Rechenschaft über den erreichten Stand. Das wird ein Bischen dadurch abgemildert, dass der Disziplinarvorgesetzte jeweils eigentlich nicht im Raum sein soll. Aber selbst wenn der Teil eingehalten wird ist es immer noch ein extrem hohes Maß an sozialer Kontrolle, auf jeden Fall mehr als der durchschnittlich überlastete Vorgesetzte normalerweise im Wassefallprozess leisten kann.
- Mal ehrlich, wenn ein Projekt im Wasserfallprozess scheitert, wird der Chef sich dann selbst die Schuld geben oder vielleicht doch eher seinen Untergebenen? Um's mal auf Deutsch zu sagen: Die Scheiße fließt unabhängig vom Prozess immer nach unten. - Das soziale und arbeitsrechtliche Kontrollen ihre Grenzen haben stimmt. Dass viele Menschen nicht mehr arbeiten als sie müssen auch. Der Zusammenhang zu Scrum erschließt sich mir aber nicht. (Außer man wäre so naiv anzunehmen, dass die Eindrücke des Scrum Masters und des Product Owners nicht zu den Disziplinarvorgesetzten durchsickern. Das wäre aber wie gesagt naiv. Deutlich naiver als ein realer Softwareentwickler, und da ist ein gewisser Halbautismus schon mit eingerechnet.)
- 30% für "alles außer allein am Rechner sitzen" halte ich in jedem Prozess für optimistisch.
- Dass der Aufwand noch weiter steigt, wenn man weniger formalisierte Prozesse in Meetings gießt wird sicherlich stimmen. Auch dass Arbeitsteilung gegenüber der Anwesenheit des Gesamtteams Voreile haben kann stimmt. Aber 1: Da kommt mir ganz schnell der Verdacht, dass das auf eine Arbeitsteilung nach der klassischen Entwicklerkonjugation ("I architect, you implement, he tests") herausläuft. Und das funktioniert nun mal tatsächlich erwiesenermaßen nicht. Erst recht nicht, wenn die höherwertigen Tätigkeiten bei einem Softwarearchitekten oder Projektmanager liegen, der in der Praxis nicht mehr selbst programmiert. Aber 2: Ungefähr die Hälfte dieser Meetings dienen ja der erhöhten Kontrolldichte.
- Faktisch ist bei der Motivation zwischen X und Y natürlich ein Kontinuum in dem sich der reale Mitarbeiter irgendwo in der Mitte bewegt. Mit keiner von beiden Motivationskomponenten wird man allein auskommen. Wer nun merkt, dass er im Wesentlichen als X-Mensch geführt wird, der wird sich psychologisch nicht mit seiner Tätigkeit identifizieren können und damit den Y-Teil seiner Motivation verlieren. Andererseits reicht der Y-Teil eben auch nicht, so dass ein gewisses Maß an X-Motivation aufrecht erhalten werden muss. Wenn man moralische Aspekte mal ausklammert, wäre aus Arbeitgebersicht eigentlich also ein Prozess optimal, der den Mitarbeitern eine möglichst weitgehende Selbstbestimmungsillusion lässt, die aber möglichst illusionär bleibt. Preisfrage: Wie könnte der denn wohl aussehen? Genau, der geneigte Leser hat richtig geraten.
- Nebenbei bemerkt: Der traditionelle Wasserfallprozess schafft so eine Kontrollillusion beim Managment. POSIWID.
- Unter'm Strich ist es natürlich einfach so, dass alle sozialen Systeme und damit auch alle Softwareentwicklungsprozesse aus Gründen zutiefst disfunktional sind und auch dauerhaft sein werden. Der Erfolg den man sich von einem guten (Projekt-)Managment verspricht ist im Regelfall einfach nicht möglich. Und deswegen wird natürlich alle 15 Jahre eine neue Sau durch's Dorf getrieben, die es diesmal richten soll. Im Moment halt Scrum. Und natürlich wird auch Scrum letztlich aus diesem Grund im Wesentlichen scheitern. Das ändert aber nichts daran, dass auch der Wasserfall nicht nur nicht funktioniert, sondern, wenn man sich mal auf die unmittelbaren Gründe beschränkt und die gemeinsame Letztursache weg lässt, sogar ziemlich genau aus den Gründen nicht funktioniert, die ein Agilitätsjünger nennen würde.
Zitat von hubersn im Beitrag #5[...] ich hätte da auch noch ein paar Meinungen zu [...] Kanban und natürlich zur Mutter aller agilen Softwareentwickungsideen "XP" mitzuteilen.[...].
Gruß hubersn
Werter Hubersn,
Ihre Meinungen dazu würden mich durchaus interessieren. Insbesondere bin ich genuin neugierig darauf zu erfahren, inwiefern man zu Kanban eine Meinung haben kann.
Zitat von Llarian im Beitrag #7Weil sein Kosten/Nutzen Verhältnis eben besser ist, wenn er faul rumsitzt. Daran ist die DDR zugrunde gegangen. Und hier wird wieder einmal (...) das Gegenteil propagiert.
Lieber Llarian,
diese Aussage würde ich in Zweifel ziehen wollen, denn daran ist die DDR ganz bestimmt nicht zugrunde gegangen (und wer da zu faul war, konnte mitunter richtig Ärger kriegen).
Zugrunde gegangen ist die DDR am Fehlen zentraler marktwirtschaftlicher Elemente in Sachen Selbstständigkeit/Unternehmertum, Preisbildung, offene Märkte etc.
In einigen Punkten sind wir nicht sehr weit auseinander, in einem bestimmten aber schon. Fangen wir damit an, wo wir nur geringe Unterschiede in der Sichtweise haben, die sich vermutlich durch andere Erfahrungen erklären.
Gilbert: "der Artikel hier scheint mir jetzt aber so einseitig..."
Scrum als Werkzeugkasten enthält eine Reihe sinnvoller Bausteine.
Als allererstes ist das Review zu nennen. Von allen Elementen ist dieses das mit Abstand wichtigste. Egal, welches Arbeitsmodell ich verwenden würde: ein Review in sinnvoll kurzen Zeitabständen wäre dabei. Allerdngs würde ich variable Zeiträume vorschlagen. Das festhalten an der Sprintlänge (seien es nun zwei oder drei Wochen) ist für mich keine allgemeingültge Lösung. Ich würde beim Planning dem Team die Chance geben, eine sinnvolle Länge vorzuschlagen und daraus den fixen Review-Termin ableiten. Der Lerneffekte wäre der gleiche (zu einem bekannten Zeitpunkt fertig werden), aber es fällt die Ausrede weg, "man habe ja gar nicht fertig werden können, da zwei Wochen nie realistisch war". Als Antwort auf diese Ausrede bietet Scrum die Idee an, die Aufgaben eben noch kleiner zu schneiden... aber man kann es drehen und wenden, wie man will: Aufgaben sind nicht beliebig teilbar. Entweder die Aufgabe ist zu lang oder zu kurz. Aber besser wäre, von Anfang an eine Aufgaben-spezifische Zeitabschätzung.
Auch das Planning halte ich für sinnvoll.
Beim Daily bin ich extrem skeptisch. Das verkommt noch wenigen Wochen zur Routine (gestern habe ich blabla gemacht. Heute mache ich blabla). Optimalerweise dauert das Daily nur 10 Minuten, aber letztlich zerstückelt es den Tag. Wenn ich was von meinem Kollegen wissen will, dann frage ich ihn einfach. Dafür ist man ja in einem Team. ("Wir greifen zur ultimativ letzten Waffe: wir REDEN miteinander...")
Retro: ich habe noch nie eine Retro erlebt, die dauerhaft etwas positives bewirkt hätte. Noch nie. In keinem Team; weder selbstgeführt noch als Teilnehmer oder Gast.
Sinnvoll ist das Backlog und das Sprintbacklog. Aber da sind wir beim Bullshit-Bingo: was ist denn ein modernes Lastenheft anderes als ein Backlog? Sollte tatsächlich ein Vollhonk auf die Idee kommen, mir ein Lastenheft als Ausdruck im DIN A4-Ordner in die Hand zu drücken, dann würde ich selbstverständlich daraufhinweisen: "Falsches Medium". Aber wenn man ein Lastenheft digital pflegt und die modernen Methoden nutzt, dann ist da kein Unterschied: Clusterung der Lasten zu Hauptthemen = Epic. Begründung der Lasten im ersten Task = User story. Priorisierung der Lasten = Feature. Ob diese Informationen in einem Word-Dokument ertfasst sind oder einem TFS ist doch nur ein technisches Kriterium und das kann eben effiozient oder ineffizient sein. Aber der INHALT ist der gleiche.
Das zentrale Artefakt in Scrum ist das "Inkrement": das lauffähige und lieferfähige Zwischenergebnis. Da bin auch ziemlich skeptisch, was komplexe Softwareprojekte betrifft. Ich habe nichts gegen die Grundidee - aber so lange eine Software noch als "Version" geplant wird, ist das in der Praxis zum scheitern verurteilt. Ich bin absolut überzeugt davon, dass sich der Aufwand nicht lohnt, die Idee der inkrementellen Entwicklung bei Scrum und die Versionsplanung (in der Regel jährlich) unter einen Hut zu bringen. Scrum (oder etwas ähnliches) würde ich nur anwenden, wenn TATSÄCHLICH eine inkrementelle Lieferung an Kunden erfolgt.
Gilbert: "Dementsprechend scheint es mir durchaus sinnvoll, von vornherein einzuplanen, dass sich der Plan öfter ändern wird. "
Ihr Kritik an Wasserfall scheint sich noch sehr auf Methoden aus den 70ern zu konzentrieren. Leider gibt es solche Projekte noch; bevorzugt, wenn die öffentliche Hand dabei ist. Berühmte Beispiele sind die Infrastrukturprojekte der Bundeswehr: da wird am Anfang ein auf 10 Jahre dauerndes Projekt aus der Taufe gehoben und im Jahr 9 stellt man fest, dass die Welt anders ist. Grauenhaft.
Aber in der Industrie wird doch schon lange nicht mehr so projektiert. Die Projekte werden in Teilprojekte aufgeteilt - oft in Jahresscheiben, manchmal auch Halbjahresscheiben. Stellt man nach einem Jahr fest, dass man in die falsche Richtung läuft, kann man gegensteuern oder die Idee aufgeben. Und ein halbes Jahr sollte man schon mit Arbeit füllen können, wenn man ein hinreichend komplexes Problem vor sich hat. Ich kann mir spontan kein Thema vorstellen, wo ich so wenig Informationen habe, dass ich nur die ersten zwei Wochen überblicken kann, aber bereits der nächste Monat völlig im Nebel vorborgen ist. Wenn ich mit so einem Problem konfrontiert wäre, dann würde ich zunächst eine Machbarkeitsstudie erstellen - schon, um das Risiko abzuschätzen.
Gilbert: "Zumindest ursprünglich kommt Scrum weniger aus Endkundensoftware sondern aus der Automatisierung von Geschäftsprozessen."
Ganz ursprünglich kam das aus der Ecke des Notfallmanagements bei Wartungsprojekten, die aus dem Ruder laufen. Da sind die Umstände natürlich speziell: 1. Klares Ziel (= Epic): DIE SCHE... MUSS WIEDER FUNKTIONIEREN 2. Klarer Zeitpunkt: UND ZWAR BEREITS GESTERN 3. Klare Autoselektion bei den Teammitgliedern: IST MIR EGAL, WAS DIE ZUR ZEIT MACHEN: NEHMT DIE BESTEN LEUTE, DIE WIR HABEN! DIE SOLLEN ALLES STEHEN UND LIEGEN LASSEN 4. Hohe Motivation bei den Teammitgliedern: MIR EGAL, WIE IHR DAS HINKRIEGT - MACHT ES, SONST SIND WIR ALLE AM ARS...
Meine These ist ja: Scrum ist nicht alltagstauglich. In besonderen Situationen kann ich mir das gut vorstellen.
Gibert: "Die eigentliche Idee [des Scrum Masters] ist eher die Umsetzungsverwaltung"
Da widerspreche ich. Die Aufgaben eines Scrum Masters sind ausführlich und abschließend im Scrum guide beschrieben. Der Scrum Master soll gerade kein Teilprojektleiter sein und auch kein Sekretär. Der Scrum Master ist im Kern NUR für die Kaderschulung zuständig, denn die Grundidee ist, dass ein Scrum Master sich selbst überflüssig macht. Der heilige Gral bei Scrum ist, dass der Scrum Master sich überhaupt nicht mehr im Team einmischt, keine operativen Tätigkeiten mehr hat, ja nicht mal auf dem Laufenden ist. Macht alles das Team selbst. Und die Überflüssigkeit des Scrum Masters widerspricht völlig der Idee der "Umsetzungsverwaltung" - denn eine Verwaltung ist laufende Tätigkeit.
Ihr Sichtweise zum PO teile ich.
****
Kommen wir nun zu den Punkten, bei denen wir sehr weit auseinander sind: zur Führungsstruktur
Gilbert: "Dass es über dem Team keinen Vorgesetzten mehr gäbe mag sich der eine oder andere Scrum-Jünger wünschen es ist aber weder von Scrum vorgeschrieben, noch in der Praxis irgendwie üblich."
Das Scrum in der Praxis kaum umgesetzt sind, da sind wir uns einig. Aber das Scrum das so will, ist kein Geheimnis. Welche Aufgaben hat ein Vorgesetzter? - Fachliche Führung (zuteilen von Aufgaben): widerspricht der Idee von Scrum, dass der PO sein priorisiertes Backlog hat und das Team völlig frei entscheidet, wer im Team welchen Anteil an der Abarbeitung hat. Das Team zieht die Feature in den Sprint Backlog, entscheidet selbst über den Aufwand (zB durch die Abschätzung der Sprintpoints), entscheidet selbst über die technische Umsetzung und wer was dazu beiträgt. - Belohnung und Bestrafung: widerspricht der Idee von Scrum, die Mitarbeiter intrinsisch zu motivieren. Außerdem werden Einzelleistungen gar nicht erfasst, damit fehlt die Grundlage einer individuellen Belohnung oder Bestrafung - Kontrolle über den Gesamtfortschritt: widerspricht der Idee von Scrum, dass der PO den Gesamtfortschritt beurteilt und NUR der PO. - Team-übergreifende Kommunikation: widerspricht der Idee von Scrum, dass das Team selbst Quantität und Qualität der Team-übergreifenden Zusammenarbeit festlegen soll.
Gilbert: "Ganz platt ausgedrückt ist der Scrum Master dafür zuständig, dass Anforderungen und reale Möglichkeiten ungefähr im Gleichgewicht bleiben."
Das ist nun das genaue Gegenteil von dem, was Scrum will. Genau dafür ist das Developer-Team zuständig.
Gilbert: "- Dass die Kontrolldichte für den einzelnen Mitarbeiter bei Scrum geringer wird halte ich nun wirklich für ein Gerücht. Sie wird freilich freundlicher verpackt. Praktisch hat man aber ein Sprint Plannig faktisch also zweiwöchentliche Zielvereinbarungen und einen Daily Scrum, faktisch also tägliche Rechenschaft über den erreichten Stand. Das wird ein Bischen dadurch abgemildert, dass der Disziplinarvorgesetzte jeweils eigentlich nicht im Raum sein soll. Aber selbst wenn der Teil eingehalten wird ist es immer noch ein extrem hohes Maß an sozialer Kontrolle, auf jeden Fall mehr als der durchschnittlich überlastete Vorgesetzte normalerweise im Wassefallprozess leisten kann."
DAS ist ja nun genau der Punkt, auf den ich hinauswill; "wenn Wissen durch Gewissen ersetzt wird". Das UNTERNEHMEN hat in Scrum so gut wie gar keine Informationen mehr über die Individuen. Die Scrum Master weigern sich (zumindest in der westlichen Welt), die Vorgesetzten mit individuellen Leistungsbeurteilungen zu versorgen. (In Indien wird zwar auch gern mal "Scrum" genutzt, aber das hat inhaltlich praktisch nichts mit Scrum zu tun und ist streng hierarchisch organisiert. Dort fungiert der Scrum Master als Vorgesetzter).
Statt dessen soll soziale Kontrolle einsetzen. Und ich bezweifle, dass das funktioniert. Und warum soziale Kontrolle bei uns meiner Meinung nach nicht funktioniert: das behandelt mein Artikel. Der real existierende Sozialismus hat auch sehr viel auf soziale Kontrolle gesetzt. Aber im Gegensatz zu @Frankenstein bin ich der Meinung, dass soziale Kontrolle im Kontext unserer Gesellschaft nicht funktioniert. Funktionierende soziale Kontrolle setzt ein ganz anderes Wertesystem voraus, dass letztlich auf religiösen Motiven beruht. Das führt jetzt alles ein bischen weit, aber stellen wir uns doch statt dessen das ganze einfach mal in der Praxis vor.
Daily: Kollege A: Ich arbeite an Feature x. Ist kompliziert. Keine Ahnung, ob ich das bis Sprint-Ende schaffe. Kollege B: Ich arbeite an Feature y. Ist kompliziert. Keine Ahnung, ob ich das bis Sprint-Ende schaffe.
Beide gucken sich an und zucken mit den Schultern.
Wo genau setzt da die soziale Kontrolle ein? Wer will denn wen unter Druck setzen? Und warum? OK, ergänzen wir das ganze um einen PO. Gleiche Situation wie oben.
PO sagt: ich brauche aber die Feature. Kollegen: Schon klar, aber schneller geht es nun mal nicht. PO: Muss aber. Kollege: Hier muss gar nix. Wir arbeiten dran und das so schnell, wie es eben geht.
Wo ist hier die soziale Kontrolle? Das der PO sauer ist? Uuuh, wie gruselig. Der PO hat doch überhaupt keine Handhabe, um das Team zu irgendwas zu zwingen. Tatsächlich hat der PO auch gar nicht genug Informationen, um das Team zu irgendwas zu zwingen, denn im Tagesgeschehen ist der nicht dabei.
___________________ Jeder, der Merkel stützt, schützt oder wählt, macht sich mitschuldig.
Gilbert: "Praktisch hat man aber ein Sprint Plannig faktisch also zweiwöchentliche Zielvereinbarungen"
Das ist das zentrale Missverständnis. Wir sollten diesen Satz so lange zerlegen, bis wir ein gemeinsames Verständnis haben.
Wenn man Scrum einsetzt, gibt es keine individuellen Zielvereinbarungen. Es gibt nur "Commitments" (Zusagen) durch das Team. Damit fehlt komplett die Grundlage, um eine einzene Person in den Senkel zu stellen. Wenn der PO mit dem Ergebnis des Sprints nicht zufrieden ist, dann kann er seinen Unwillen ausdrücken. Aber das verpufft doch völlig - da sein Unwillen kein Ziel hat. Das Team wird also ausgeschimpft? Na und? ICH habe doch gearbeitet wie Tier. Muss jemand anders schuld sein, dass das nicht geklappt hat.
Und was passiert, wenn die Team-Zielvereinbarung nicht eingehalten wird? Wenn schon eine kollektive Verantwortung propagiert wird, müsste es mindestens auch kollektive Bestrafungen geben. Mal vollkommen abseits davon, dass ICH kollektive Bestrfafungen für unmenschlich, lebensfeindlich und pervers halte: die Grundaussage ist nun mal unbestreitbar:
WENN man eine kollektive Verantwortung will, DANN muss es auch kollektive Belohnung oder Bestrafung geben.
Aus dieser Schlussfolgerung kommt man nur raus, wenn man grundsätzlich in Abrede stellt, dass Belohnung und Bestrafung erforderlich sind. Die "antiautoritäre Erziehung" behauptet so was ja zum Beispiel. Oder eben die Yplus-Theorie bzw. die Loevinger-Theorie. Also irgendwas mit "die Menschen arbeiten freiwillig, weil sie sich dann toll fühlen". NUR DANN kann man auf Belohnung und Bestrafung verzichten. Ich weiß ja nicht, wie Sie das sehen: aber ich würde nicht 40 Std die Woche arbeiten, wenn ich dafür keine Kohle bekäme. Ohne Belohnung (= Gehalt) keine Anstrengung. Und wenn mich niemand überwacht, dann senke ich meine Anstrengung (verwende meine Arbeitszeit für private Angelegenheiten), weil ich damit dem ökonomischen Prinzip gerecht werden:
Bei gegebenem Output (mein Gehalt) den geringsten Aufwand (Stress, Zeitverbrauch...) aufwenden
Warum sollte ich mehr oder intensiver arbeiten als ich muss? Das ist doch die Frage!
Ich behaupte als Fazit:
Scrum, so wie es gedacht ist, funktioniert nicht. Statt dessen wird doch wieder ein autoritäres Element eingebracht (zB in Form eines Pseudo-Scrum Masters, der die Macht und Rolle eines Vorgesetzten einnimmt). Dieses autoritäre Element stellt sicher, dass der nächste Sprint individuelle Arbeitsaufträge hat. Auf der Basis dieser individuellen Arbeitsaufträge erfolgt auch eine individuelle Belohnung und Bestrafung.
___________________ Jeder, der Merkel stützt, schützt oder wählt, macht sich mitschuldig.
Zitat von Frank2000 im Beitrag #13Aber im Gegensatz zu @Frankenstein bin ich der Meinung, dass soziale Kontrolle im Kontext unserer Gesellschaft nicht funktioniert.
Ich verstehe ehrlich gesagt nicht so recht, worauf Sie sich da beziehen.
Soziale Kontrolle hin oder her: Mein Punkt war der, dass die DDR auch dann gescheitert wäre, wenn jeder 100% gegeben hätte, da das ökonomische System (Sozialismus) an sich dysfunktional war bzw. ist. Es ist diese Erkenntnis, die mich politisch konvertiert hat. *
Daran, dass die Leute faul rumgesessen haben (wie Llarian es sinngemäß formuliert hat) ist die DDR jedenfalls ebensowenig gescheitert wie am Vorhanden- oder Nichvorhandensein sozialer Kontrolle.
* Anmerkung: Mir ist im Nachhinein vollkommen unbegreiflich, dass in meinen 13 Jahren Schule nicht ein einziger Tag der ökonomischen Alphabetisierung gewidmet war. Diese vollkommene Abwesenheit der Vermittlung wirtschaftswissenschaftlicher Zusammenhänge ist auch einer der wesentlichen Gründe dafür, dass so viele intellektuell überdurchschnittlich begabte junge Leute ins linke Milieu abdriften. M. E. handelt es sich dabei auch um ein Totalversagen konservativ-liberaler Bildungspolitik.
Zitat von Frankenstein im Beitrag #15 Daran, dass die Leute faul rumgesessen haben (wie Llarian es sinngemäß formuliert hat) ist die DDR jedenfalls ebensowenig gescheitert wie am Vorhanden- oder Nichvorhandensein sozialer Kontrolle.
Naja, ich weiß von meinen Verwandten, dass sie in der DDR zum Beispiel während der Arbeitszeit zum Friseur oder einkaufen gegangen sind und dass -nach deren Aussage- jeder das so gemacht habe. Ist das jetzt "faul"? Man füllt halt die Zeit - aber nicht mit der Arbeit, für die man bezahlt wird.
Und dann gibt es ja auch noch den Unterschied zwischen "beschäftigt sein" und "arbeiten". Jeder kann sich beschäftigen. Auch bei uns in der Firma ein beliebtes Werkzeug: fülle den Kalender mit möglichst vielen Besprechungen und schon glaubt dir jeder, du würdest hart arbeiten. In Wirklichkeit arbeitet man gar nicht und ist blos beschäftigt.
___________________ Jeder, der Merkel stützt, schützt oder wählt, macht sich mitschuldig.
Mit SCRUM ist es wohl wie mit den meisten Methoden: Als reine Lehre funktioniert das fast nie. Aber es kann als Anregung sinnvoll sein, gewisse Sachen zu übernehmen und etwas in eine neue Richtung zu gehen.
Was mir so ganz unsortiert am Artikel aufgefallen ist:
Zitat Und da "Fluss" nicht dramatisch genug klingt, hat sich der Begriff "Wasserfall" eingebürgert.
M. W. soll der Wasserfall die großen Projektphasen auseinander halten. D. h. man kann innerhalb einer Phase wie z.B. Testen durchaus etwas vor und zurück, aber man kommt nicht mehr in früherer Phasen zurück, die liegen oberhalb des Wasserfalls.
Zitat In beiden Fällen werden unvollständige, oft sogar nutzlose Zwischenprodukte ("Alpha", "Beta") dem Kunden angeboten ...
Das halte ich doch für ein Randphänomen, das man im wesentlichen nur bei manchen Spielen findet. Ansonsten ist es im Kern eine klassische Versionsplanung, nur können die Versionen kleiner und schneller sein, weil der Roll-Out so einfach ist. Aber bei den meisten Apps muß m. E. schon die Startversion voll funktionstüchtig sein und einen Kernbestand an nützlicher Funktionalität bieten - ansonsten wird die Neuerscheinung sich nicht auf dem Markt etablieren und updatet ins Nirwana.
Zitat Wörtlich steht im Scrum Guide - der einzig gültigen Anleitung für Scrum
Das ist doch wohl eher Theorie bzw. Wunschdenken mancher SCRUM-Gurus. De facto habe ich (wie bei den meisten Methoden) eher den Eindruck, daß jede Firma sich ihren eigenen Scrum-Set definiert, oft nur die Begrifflichkeit verwendet.
Zitat Nach dieser Sichtweise ist ein Scrum-Projekt gescheitert, weil ich es "nicht richtig gemacht habe". Kommt das bekannt vor?
Das soll wohl auf den Sozialismus angespielt werden und das paßt durchaus. Aber eigentlich erhebt jede SW-Entwicklungs oder Arbeits-Organisations-Methodik einen solchen Anspruch. Und kommt damit durch, weil fast niemals die vorgeschriebene Theorie wirklich 1:1 umgesetzt und gelebt wird. Immerhin, im Unterschied zum Sozialismus, gibt es in der Regel eine klar beschriebene Theorie.
Zitat Zu guter Letzt darf man noch ansprechen, dass viele Untersuchungen zum Erfolg von Scrum Auftragsarbeiten sind und keine wissenschaftlich fundierten Doppelblindstudien.
Korrekt. Das Problem ist natürlich, daß Projekte nie komplett vergleichbar sind. Und auch nie ein Projekt mit verschiedenen Methoden parallel probiert wird. Es ist also ziemlich unmöglich, den Erfolg von Methoden wirklich nachzuweisen. M. E. sind die meisten Methoden tendenziell "erfolgreich" in dem Sinn, daß die Arbeit etwas effizienter und effektiver wird. Alleine schon deswegen, weil man sich über das eigene Vorgehen Gedanken macht, das Team etwas abgestimmter arbeitet und das planlose Loswurschteln etwas geringer wird.
Zitat Nach dieser Rechnung ist also 0,5 einer Planstelle in einem 7-Personen-Team nur für "Kaderschulung" zuständig. Das ist schon gewaltig.
Nicht unbedingt. Nach meiner Erfahrung als Projektleiter kann es sehr sinnvoll sein, wenn sich in einem Team (von etwa 7-10 Leuten) einer sich im wesentlichen um die "Meta-Ebene" kümmert. D.h. nicht im eigenen Klein-Klein ersäuft, sondern dafür sorgt, daß die übrigen Team-Mitglieder die nötige Doku schreiben, sich an nötige Standards halten, zwischen ihren Arbeitsbereichen keine Lücken lassen und so weiter. Was noch keine echte Gehirnwäsche ist ... Wenn man den rhetorischen Firlefanz wegläßt scheint mir der Scrum Master weitgehend eine solche Funktion zu erfüllen.
Zitat Jedes Teammitglied soll sich anstrengen, bei jedem Aspekt der Entwicklung mitreden zu können.
Das finde ich erst einmal nicht schlecht. Wobei ich unter "mitreden" nicht verstehe, daß sich jeder in Sachen reinhängt, von denen er nichts versteht. Aber umgekehrt ist es nicht gut, wenn lauter Fachidioten nebeneinander arbeiten und die Arbeit der Anderen nicht im Ansatz verstehen. Ein Datenbank-Spezialist soll die DB optimieren und muß nicht in der Lage sein, ein Web-GUI zu designen. Aber er sollte wissen, wie Web-GUI grundsätzlich geht und was da leicht oder schwer machbar ist. Insofern gefällt mir erst einmal das Bild mit dem T. So ein bißchen von jedem beteiligten Bereich verstehen, aber dann seinen eigenen Schwerpunkt haben. Aber genau dieses T-Bild sollte eigentlich heißen, daß eben nicht jeder jeden nach Belieben ersetzen kann. Mir scheint die SCRUM-Ideologie hier widersprüchlich zu sein.
Zitat Im Review gibt es keine Einzelleistungen.
Interessant. In unserer IT wird derzeit etwas eingeführt, was mit Kanban/SCRUM bezeichnet wird. Und dazu gehört auch, daß jeder jeden Morgen seine persönlichen Arbeitspäckchen darstellt und damit auch transparent macht, ob er über- oder unterlastet wird. Was de facto eine ganz brutale Überwachung von Einzelleistungen bedeutet - der Betriebsrat ist entsprechend auf den Barrikaden.
Im übrigen habe ich den Eindruck, daß SCRUM irgendwie ganz drinnen in der EDV von Nerds für Nerds entwickelt wurde. Und ganz schlimm mit der Realität kollidiert, wenn die Entwicklungsziele und Durchführungsdetails nicht vom Team selber erfunden werden dürfen, sondern vertraglich vorher mit einem Kunden fixiert wurden. Ganz zu schweigen von den vielen BAU-Tätigkeiten, die nichts mit der Neuentwicklung von Software-Paketen zu tun haben.
Zitat von Frankenstein im Beitrag #15 Daran, dass die Leute faul rumgesessen haben (wie Llarian es sinngemäß formuliert hat) ist die DDR jedenfalls ebensowenig gescheitert wie am Vorhanden- oder Nichvorhandensein sozialer Kontrolle.
Naja, ich weiß von meinen Verwandten, dass sie in der DDR zum Beispiel während der Arbeitszeit zum Friseur oder einkaufen gegangen sind und dass -nach deren Aussage- jeder das so gemacht habe. Ist das jetzt "faul"? Man füllt halt die Zeit - aber nicht mit der Arbeit, für die man bezahlt wird.
Und dann gibt es ja auch noch den Unterschied zwischen "beschäftigt sein" und "arbeiten". Jeder kann sich beschäftigen. Auch bei uns in der Firma ein beliebtes Werkzeug: fülle den Kalender mit möglichst vielen Besprechungen und schon glaubt dir jeder, du würdest hart arbeiten. In Wirklichkeit arbeitet man gar nicht und ist blos beschäftigt.
Drücke ich mich denn wirklich so unverständlich aus?
Das Problem der DDR war doch nicht, dass da zu viele oder zu wenige Leute faul rumsaßen, sondern ihr ökonomisches System an sich. Der Faulheitsfaktor ist von daher m. E. praktisch irrelevant.
Wie gesagt: Auch wenn alle 100% Gas gegeben hätten, wäre der Staat früher oder später an dem zu Grunde liegenden Systemfehler gescheitert.
Zitat von Llarian im Beitrag #6wenn wir mal voraussetzen, dass die Spezifikation nicht völlig absurd war
Das ist die ganz wesentliche Vorausetzung. Nach meiner Erfahrung stirbt ein Projekt immer schon ganz vorne: Wenn die Aufgabenstellung unklar und lückenhaft war und dann die folgenden Planungen/Schätzungen in die Irre laufen müssen. Wenn dagegen der Kunde/Produktverantwortliche weiß, was er will (und das auch kommunizieren kann), dann ist die verwendete Methodik ziemlich zweitrangig. Und die Qualität der Mitarbeiter (so sie über dem nötigen Minimum liegt) beeinflußt fast nur noch die Geschwindigkeit, aber nicht so sehr den Projekterfolg selber.
"De facto habe ich (wie bei den meisten Methoden) eher den Eindruck, daß jede Firma sich ihren eigenen Scrum-Set definiert, oft nur die Begrifflichkeit verwendet."
Exakt. Und die häufigste Abweichung ist, dass der Scrum Master die Rolle eines Teilprojektleiters einnimmt (also fachliche Führung eines Teams). Genau das schlagen Sie ja auch vor:
"...sondern dafür sorgt, daß die übrigen Team-Mitglieder die nötige Doku schreiben, sich an nötige Standards halten, zwischen ihren Arbeitsbereichen keine Lücken lassen und so weiter. "
Auch Sie sind schnell zum Kernproblem vorgestoßen: entnehme ich der Scrum-Welt bloß ein paar Bausteine- oder versuche ich tatsächlich ein SELBSTsteuerndes Team einzuführen? Sie schreiben:
"Und dazu gehört auch, daß jeder jeden Morgen seine persönlichen Arbeitspäckchen darstellt und damit auch transparent macht, ob er über- oder unterlastet wird. Was de facto eine ganz brutale Überwachung von Einzelleistungen bedeutet - der Betriebsrat ist entsprechend auf den Barrikaden."
Sie meinen das Daily und nicht das Review, aber ich habe schon verstanden, was Sie meinen. Der Punkt ist doch der: was passiert, wenn ein Teammitglied beim Daily sagt "Ich bin noch dran und völlig überlastet"? Ist das nur ein Ritual oder was passiert dann? Ist jemand beim Daily eingebunden, der sagt "ich glaube dir nicht, dass du überlastet bist. Du hast schlicht zu viel getrödelt" ?
Was genau will der BR monieren? Dass man sagen soll "Ich bin beschäftigt"? Das man rein formal eine Aufgabe nennen soll, mit der man beschäftigt ist?
Eine mitbestimmungspflichtige ArbeitsÜBERWACHUNG entsteht zum Beispiel, wenn man eine Statistik erheben würde, wer wieviele Feature bzw Task abgearbeitet hat. Wenn man individuelle Durchschnittswerte erhebt und vergleicht, wer wieviele Sprint points abgearbeitet hat. Aber all das widerspricht Scrum.
Der bloße Formalismus, einmal am Tag so zu tun, als wäre man beschäftigt, taugt wohl weder zum Ansporn noch zur Überwachung.
___________________ Jeder, der Merkel stützt, schützt oder wählt, macht sich mitschuldig.
Als Softwareentwickler finde ich es interessant, wie sehr die Meinungen zu Scrum auseinander gehen können. Also nicht das ich jemanden kennen würde der Scrum auf fundierte Weise verteidigen könnte, sondern dass die kanonische Kritik an Scrum der von Frank2000 in der Regel diamental entgegengesetzt.
Zu Scrum selbst ist zu sagen, dass es die wohl zynischste unter den agilen Methoden ist. Überspritzt gesagt ist es der Sinn von Scrum, Scrum zu verkaufen. Um Scrum herum hat sich eine Industrie entwickelt, die sich damit beschäftigt Scrum zu implementieren und zu schulen. An sich ist das nichts verwerfliches, frappierend hingegen ist, wie sehr Scrum auf die Kommerzialisierung optimiert ist. Der Scrum-Master hat wie Frank2000 richtig erkannt hat die Rolle Scrum zu evangelisieren. Der Sinn dahinter ist jedoch weniger die Mitarbeiter ideologisch zu beeinflussen, sondern die Marke „Scrum“ zu stärken. Ein Scrum-Master wäre damit vergleichbar, wenn Microsoft von seinen Kunden verlangen würde Mitarbeiter dafür abzustellen, im Unternehmen sich für die Vorteile von Microsoft Produkten stark zu machen.
Die Eigentlich Zielgruppe von Scrum ist daher nicht der Entwickler, sondern das höhere Management. Um Scrum verkaufen zu können muss dieses von den Vorteilen von Scrum überzeugt werden. Die Elemente von Scrum müssen nicht für den Entwicklungsprozess vorteilhaft sein, sondern aus der Business-Perspektive so aussehen als würden sie Sinn ergeben. Die meisten Elemente von Scrum sind so gehalten, dass sie wie eine Anwendung der aktuellen Management-Trends auf die Software Entwicklung wirken. Schnellere Iterationen und Auslieferung werden aus der Business-Perspektive als Reduktion des notwendigen Umlaufvermögens interpretiert (Lean Produktion, Just-in-time). Wenn sich das Team selbst verwaltet, kann das mittlere Management weitgehend entfallen. Scrum generiert eine Vielzahl an Kennzahlen, die eher sinnfrei sind, aber dem Management etwas in die Hand geben, mit dem es sich beschäftigen kann (Story points und alles was davon abgeleitet ist). Und selbstverständlich verspricht Scrum nicht, dass sich die Mitarbeiter der Verantwortung entziehen kann. Die mit Abstand häufigste Kritik an Scrum ist es, dass es die Mitarbeiter einen konstanten und unnachgiebigen Druck aussetzt:
Zitat von Frank2000 im Beitrag #20Ist jemand beim Daily eingebunden, der sagt "ich glaube dir nicht, dass du überlastet bist. Du hast schlicht zu viel getrödelt" ?
Also wenn das wirklich jemand sagt oder auch nur andeutet ist das Vertrauensverhältnis bereits soweit beschädigt, dass man sich im Interesse Aller nach einer anderen Stelle umsehen sollte.
Das Bild mit dem Microsoft-Mitarbeiter hat was. :-)
Aber auch bei Ihnen - zumindest, wenn Sie den zitierten Artikel unterstützen - sind ein paar Missverständnisse. Es ist zu spät für eine längere Antwort, die Sie verdient haben!
Aber schon mal als Hinweis:
Im Artikel steht "This is true at the daily Scrum meeting where individuals make commitments on what they will work on and complete today ..."
Scrum kennt keine Commitments im Daily und bietet dafür auch gar keine Werkzeuge an. Scrum kennt nur das Team-Commitment im Sprint planning. Das Daily hat zwei Gründe: a) Inspect & Adept b) Informationsaustausch
Ich melde mich Morgen. Danke für Ihren Beitrag!
___________________ Jeder, der Merkel stützt, schützt oder wählt, macht sich mitschuldig.
Zitat von Frank2000 im Beitrag #20dass der Scrum Master die Rolle eines Teilprojektleiters einnimmt (also fachliche Führung eines Teams). Genau das schlagen Sie ja auch vor:
Nein. Ein Teilprojektleiter müßte sich m. E. um Termine und Ablieferungen eines Teilteams kümmmern. So eine Funktion habe ich bei gerade mal 10 Leuten im Team nicht gebraucht. Im Prinzip war das ein Methoden-Knecht, der für alle zuständig war, aber eben nur für die Anwendung von Standards und Abmachungen. Das war insbesondere deswegen nötig, weil alle im Team neu in der Firma waren und sich in eine ganz neue IT-Welt (UNIX) einarbeiten mußten.
Zitat Sie meinen das Daily und nicht das Review ...
Ich meine gar nichts ;-) Das IT-Management nennt das den morgendlichen "war-room", die Vorgesetzten sind präsent und obwohl natürlich nicht offiziell Statistik geführt wird wollen die Chefs die Chance nutzen zu sehen, wer wieviel schafft. Jedenfalls die Chefs, die auf diese Veranstaltung dringen. Die guten Chefs brauchen das nicht, die wissen, was in ihren Teams läuft. De facto bringt das natürlich gar nichts. Die Mitarbeiter haben schnell rausgekriegt, wie man seine täglichen Pakete so definiert, daß man immer die gewünschten 2-3 in der To-Do-Box hat und weder Überforderung noch Faulheit signalisiert. Und die schlechten Chefs merken das nicht, eben weil sie zu wenig Ahnung von der eigentlichen Arbeit des Teams haben.
Zitat Ist das nur ein Ritual oder was passiert dann?
Da ich nicht mehr in der IT bin, habe ich da nur ausschnittweise Infos. Aber wahrscheinlich kam bisher keiner auf die Idee, so etwas auszuprobieren. Im Zweifelsfall wird dann erst einmal große Hilfsbereitschaft simuliert und die Kollegen zur Unterstützung verdonnert. Und im Wiederholungsfall kriegt einen Eintrag auf der nicht existierenden schwarzen Liste.
Zitat Was genau will der BR monieren?
Keine Ahnung. Sie werden halt davon ausgehen, daß die Chefs (trotz fehlender offizieller Statistik) sich sehr wohl merken, wieviele Päckchen jeder beim Rapport meldet.
Zitat Aber all das widerspricht Scrum.
Wahrscheinlich. Aber es geht ja auch nicht darum, eine nicht-verstandene Methodik korrekt einzusetzen. Sondern man will Management simulieren.
Zitat von Frank2000 im Beitrag #14Also irgendwas mit "die Menschen arbeiten freiwillig, weil sie sich dann toll fühlen.
Der Witz ist: Diese Annahme hat ja einen wahren Kern. Fast niemand will wirklich sein Leben lang nur faulenzen. Sinnvolle und interessante Beschäftigung ist für die meisten Menschen etwas, das sie auch ohne Gehalt oder Bestrafung machen würden - das Ausmaß des freiwilligen Engagements in Deutschland ist ja schon erheblich. Es gibt auch immer wieder Fälle, wo Leute ganz normal weiterarbeiten, auch in unattraktiven Berufen, wenn sie das finanziell wegen Erbschaft oder Lottogewinn gar nicht mehr müßten.
Und es gibt ja auch Bereiche, in denen Hobby und Beruf fast zusammenfallen - im akademischen Bereich ist das eigentlich die Normalität, nicht umsonst ist es üblich, daß Professoren auch nach Pensionierung weiterarbeiten und dafür sogar Infrastruktur an den Unis vorgehalten wird.
Gerade im IT-Bereich haben ja viele Leute das Gefühl, daß sie im Prinzip für das bezahlt werden, was ihnen ohnehin Spaß macht. Und zwar sehr gut bezahlt werden - das gibt dann Schuldgefühle und viele IT-ler sind dann politisch links.
Ich halte es für keinen Zufall, daß Ideen wie SCRUM oder "Bedingungsloses Grundeinkommen" sehr stark im akademischen und im IT-Bereich Anhänger finden.
Die Betreffenden übersehen eben, daß die meisten Leute das anders sehen bzw. angesichts ihrer Arbeitsmöglichkeiten anders sehen müssen. Auch die meisten IT-Projekte sind thematisch nicht so prickelnd wie im open-source-Bereich üblich, wo ja viele Leute freiwillig erhebliche Arbeit leisten. Und auch wo die Arbeit selber interessant ist, ist sie oft mit unangenehmen Randbedingungen wie früh aufstehen oder pendeln verbunden.
Zitat Scrum, so wie es gedacht ist, funktioniert nicht.
Den Eindruck habe ich auch. Oder zumindestens: Es funktioniert vielleicht in manchen Bereichen, aber darüber hinaus eben nicht.
Bitte beachten Sie diese Forumsregeln: Beiträge, die persönliche Angriffe gegen andere Poster, Unhöflichkeiten oder vulgäre Ausdrücke enthalten, sind nicht erlaubt; ebensowenig Beiträge mit rassistischem, fremdenfeindlichem oder obszönem Inhalt und Äußerungen gegen den demokratischen Rechtsstaat sowie Beiträge, die gegen gesetzliche Bestimmungen verstoßen. Hierzu gehört auch das Verbot von Vollzitaten, wie es durch die aktuelle Rechtsprechung festgelegt ist. Erlaubt ist lediglich das Zitieren weniger Sätze oder kurzer Absätze aus einem durch Copyright geschützten Dokument; und dies nur dann, wenn diese Zitate in einen argumentativen Kontext eingebunden sind. Bilder und Texte dürfen nur hochgeladen werden, wenn sie copyrightfrei sind oder das Copyright bei dem Mitglied liegt, das sie hochlädt. Bitte geben Sie das bei dem hochgeladenen Bild oder Text an. Links können zu einzelnen Artikeln, Abbildungen oder Beiträgen gesetzt werden, aber nicht zur Homepage von Foren, Zeitschriften usw. Bei einem Verstoß wird der betreffende Beitrag gelöscht oder redigiert. Bei einem massiven oder bei wiederholtem Verstoß endet die Mitgliedschaft. Eigene Beiträge dürfen nachträglich in Bezug auf Tippfehler oder stilistisch überarbeitet, aber nicht in ihrer Substanz verändert oder gelöscht werden. Nachträgliche Zusätze, die über derartige orthographische oder stilistische Korrekturen hinausgehen, müssen durch "Edit", "Nachtrag" o.ä. gekennzeichnet werden. Ferner gehört das Einverständnis mit der hier dargelegten Datenschutzerklärung zu den Forumsregeln.
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Offline
.
