Scrum — Software-Toyotismus?
Das, was wir in der Freien Software und anderswo im Freien Feld beobachten können, gibt es tendenziell auch in der proprietären Produktion. Sonst wäre es auch keine Keimform — die historische Tendenz zeigt sich überall. In der proprietären Produktion sind allerdings die Widersprüche anders gelagert. Während im Freien Feld die Frage vordringlich ist, wo die Leute Knete fürs Leben her bekommen können, um all die netten Sachen zu tun, die sie tun, ist im proprietären Feld diese Frage »geklärt«: Die Kohle ist da, gearbeitet werden muss. Entfremdung nennt man das. Aber auch unter entfremdeten Bedingungen können manchmal sinnvolle Dinge geschehen.
In der proprietären Produktion lautet die Frage wider die Entfremdung: Wie werden die Arbeitenden dazu gebracht, das zu tun, was der Markt resp. der Kunde verlangt? Diese Frage ist deswegen virulent, weil man von den Arbeitenden nicht verlangen kann, dass sie ihren Job motiviert tun, sondern Hauptsache ist, dass sie ihren Job erledigen. Diese Haltung war für die Zeit des Fordismus noch ok, für die postfordistische Ära reicht das nicht mehr aus. Heute ist der ganze Mensch gefragt, seine Motivation, Kreativität, Engagement, Sozialität, Emotionalität. Das verträgt sich nicht mit einer entfremdeten Arbeitssituation, wo ich immer nur für Dritte (Markt, Kunden) etwas tue, aber nichts für mich.
Lösungsvorschläge zur Lösung dieses Dilemmas kamen häufig aus der Auto-Industrie: Gruppenarbeit, Kaizen, Kanban, Toyotismus und wie die technizistischen Ansätze alle hießen. Etwas ähnliches geschah auch in der Software-Entwicklung. Hier wurde das Dilemma auch als das benannt, was es ist: Softwarekrise. Allerdings verstand man darunter — ähnlich technizistisch wie bei der Autoindustrie — im wesentlichen ein Komplexitätsproblem: Wenig Code ist überschaubar und gut, viel Code ist komplex und schlecht. Das ging (und geht) aus meiner Sicht am eigentlichen Problem vorbei, was Annette Schlemm und ich anderenorts einmal als Widerspruch zwischen »Selbstverwertung und Selbstentfaltung« versucht haben auf den Punkt zu bringen. Oder noch platter aus meiner eigenen Projekterfahrung: »Wenn Geld ins Spiel kommt, fangen die Leute an zu spinnen.«
Nun gibt es seit über zehn Jahren Scrum. Das ist ein Vorgehensmodell bei der Entwicklung von Software. Es beansprucht, die Ideen agiler Software-Entwicklung systematisch umzusetzen. Scrum — so erklärt Wikipedia — überträgt die Philosophie des Toyotismus auf die Software-Entwicklung. Wie das?
Scrum gibt den Entwicklern mehr Handlungsmacht und dynamisiert den gesamten Prozess. Die Software wird in iterativen Zyklen von zwei bis vier Wochen entwickelt. Das Entwicklungsteam legt selbst fest, welche Aufgaben es wie erledigen kann. Es gibt keine kleinteilig vorgekauten und festzementierten Pflichten-/Lastenhefte, sondern die Anforderungen werden in einer Feature-Liste (Product Backlog) gesammelt und ggf. erweitert oder geändert. Ein Ausschnitt daraus wird in die Aufgabenliste für den Sprint (Sprint-Backlog) übernommen, wobei sich diese Liste während einer Iteration nicht ändert. Im Sprint werden die Aufgaben vom Team eigenverantwortlich umgesetzt, wobei täglich Status-Feedbacks erfolgen (Daily Scrum-Meeting). Das Ergebnis wird bewertet (Review) und der Sprint wird ausgewertet (Retrospektive). Im Idealfall ist nach 30 Tagen ein substanzieller Fortschritt in der Software-Entwicklung geschafft und die nächste Runde beginnt.
Bei Scrum gibt es nur drei — gleichberechtigte — Rollen: Auf der Auftraggeberseite der Product Owner, auf der Entwicklerseite das Team und dazwischen der Scrum-Master. Die klassischen Produktmanager oder Projektleiter gibt es nicht. Für die Freie Software ist das Modell so ungewöhnlich nicht. Im weitesten Sinne ist der Product Owner der Gründer und Maintainer eines Projektes, das Team sind die Mitglieder in einem Projekt und das Scrum-Master — ist auch wieder der Maintainer. Im Scrum-Prozess müssen Project Owner und Scrum-Master getrennt sein, weil der Owner die Nachfrage- und Geldseite repräsentiert, während der Scrum-Master Transparenz und gute Arbeitsbedingungen im Projekt schaffen soll. Gleichzeitig soll letzterer auch nicht Teil des Teams sein, um auch hier Neutralität zu wahren. Da in einem klassischen und insbesondere doppelt Freien Software-Projekt die Auftragseite wegfällt, wird die Vermittlerposition zwischen der »Geldseite« und »Arbeiterseite« hinfällig. Bei einfach Freien Software-Projekte (etwa im Auftrag) bietet sich hingegen die Scrum-Struktur geradezu an, die für die notwendig ablaufenden Interessenkonflikte eine Vermittlungsinstanz (»Betriebsrat«) parat zu haben.
Löst Scrum die Probleme, die aus dem Widerspruch zwischen Verwertungslogik und Selbstentfaltungswunsch kommen? Natürlich nicht. Denn eine Methode, ein Vorgehensmodell akzeptiert zunächst einmal die Rahmenbedingungen der entfremdeten Software-Produktion. Aber sie kann helfen, die auftretenden Widersprüche offen zu legen, um ggf. einen »Deal« zu finden, der die Interessenkonflikte befriedet. Während inzwischen in der proprietären Auto-Produktion die Re-Taylorisierung marschiert, wird die Softwarebranche ein wenig von agilen Methoden »erfrischt«. Mit dazu beigetragen hat sicher die Freie Software. Doch dass die ganz eigene Methoden braucht, die nicht ohne weiteres auf die proprietäre Software zu übertragen sind, ist inzwischen auch klar geworden.
Fazit: Die Verwertungslogik funktioniert nicht mehr nach Befehl und Gehorsam. Sie braucht den »ganzen Menschen«. Den bekommt sie aber nicht, denn Selbstentfaltung von »je mir« und Befolgen der »fremden« Verwertungsanforderungen sind nicht zusammen zu bringen. Allerdings lässt sich zumindest teilweise eine größere Nähe herstellen. Dazu dienen solch »subjektivistische« Methoden wie Scrum. Unter gegebenen Handlungsbedingungen mehr individuellen und kollektiven Spielraum zu haben, ist ja auch schon was. Und wer schlau ist, erkennt die Hinweise auf die freie Entfaltung, die in Scrum sichtbar werden. Die brauchen dann allerdings auch eine Freie Gesellschaft, um zur Geltung kommen zu können.
Kann jemand seine persönlichen Erfahrungen mit Scrum beschreiben? Sind Scrum und ähnliche Methoden auf dem Vormarsch oder in Zeiten der Krise eher wieder auf dem Rückzug?
Ich war letztens auf einem Vortrag, wo gesagt wurde, dass diese Sicht im Management schon wieder auf dem Rückzug ist. Dort wird zunehmend die mangelnde Kontrolle bei solchen Methoden beklagt und es wird wieder vermehrt versucht den Taylorismus auf die Softwareproduktion anzuwenden. Wahrscheinlich gibt es da über die Jahre eine Pendelbewegung, weil der Konflikt, den Du schilderst eben immer da bleibt.
Scrum ist momentan leider auch ein großer Hype, auf dem viele aufspringen und Scrum verprechen, wo nicht Scrum drin ist. Führt man Scrum mit den in Scrum beschriebenen Rollen, Artefakten und Meetings ein, ist es eine deutliche Bereicherung für das gesamte Softwareentwicklungsvorgehen.
Es bietet Transparenz – durch die Daily Scrums (in denen jeder teilnehmen kann), durch die Sprints, in denen die Teams je Sprint die Ergebnisse liefern müssen, zu denen sie sich vor dem Sprint committed haben, durch Sprint Reviews, in denen je Sprint!!! das Management auf jeden Fall den Fortschritt beurteilen kann (und die Option bekommt auch ein Projekt rechtzeitig in Frage zu stellen), durch die Retrospektive, in denen das Team sich selbst in Frage stellen kann und unheimlich schnell Probleme transparent macht und zur Lösung zwingt.
Der geschilderte Konflikt ist da – aber wie entwickelt wird, entscheidet das Team. Ein schwieriger Algorithmus oder eine unangenehme Aufgabe sind dann Bestandteil des Projektes und das Team stellt sich der Aufgabe ganz anders, als wenn es „von oben“ vorgegeben bekommt, wie es zu lösen ist (oft noch dazu von ebenen, die eigentlich gar keine Ahnung vom detaillierten Lösungsweg haben).
Scrum ist ja nicht komplett frei – sondern bettet sich in einen Unternehmensrahmen ein. Es kann aber aufzeigen, dass evtl. am Rahmen etwas nicht stimmt. Und wenn dass mit Business Value und Fakten untermauert wird, dann läßt sich der Rahmen auch verändern. Das ist Aufgabe des ScrumMasters und des Teams. Widersprüche aufdecken und ordentlich zum Ändern führen.
Die Unternehmen gewinnen enorm, wenn sie auf Scrum setzen – allerdings müssen sie qualifizierte ProductOwner und ScrumMaster einsetzen. Denn Moderation, fachlicher Überblick und Weitblick, das Standing, soziale wertschätzende Verhaltensweisen sind enorm wichtig, um die zarte Pflanze Teamgeist und Motivation nicht sofort im Keim zu ersticken.
Mein Fazit zu Scrum — auf jeden Fall anschauen, Lernen und mit Engagement einführen – dann macht Entwicklung wieder richtig Spass – und Transparenz (die natürlich auch weh tun kann) wird erzwungen. Was will man als Management mehr?!
@Sebastian: Danke für deinen Bericht! Ja, Transparenz kann weh tun. Ich habe schon verschiedentlich gehört, dass Scrum auch katalytisch wirkt und verdeckte Konflikte bis zur Explosion ans Tageslicht befördert. Kann manchmal ganz gut sein, aber es können auch einzelne Leute unter die Räder kommen. Und wenn das Projekt scheitert, ist es für den/die Manager/in auch nicht gerade toll. Ich denke nicht, dass viele Unternehmen wirklich »Scrum-ready« sind.
@Stefan: Oftmals wäre es aber auch genau richtig Leute unter die Räder kommen zu lassen als immer zu verdecken, dass sich manche auf dem Rücken anderer ausruhen können. Schlimm wird es, wenn gerade im Management solche „Faulenzer“ hausieren… und mit Scrum ihre Daseinsberechtigung obsolet wird. Scrum-ready heißt – Veränderungen wollen und nicht den Status Quo akzeptieren – das muss einen bewußt sein. Scrum nicht einführen heißt auch – u.U. marode Strukturen decken und Angst vor wahrem Management mit Herz haben.
Auf der letzten OOP im Januar war „SCRUM BUT“ eine gängige Redewendung. Viele sagen, „Wir machen SCRUM, aber …“. Danach wird SCRUM mit ganz traditionellen Vorgehensweisen verbunden und nur zu Teamsteuerung auf unterster Ebene eingesetzt. Das scheint mir auch der Grund zu sein, warum SCRUM die am häufigste genutzte agile Vorgehensweise ist.
Bei SCRUM fällt mir immer das folgende Zitat ein:
„Wenn nun ein amerikanischer Arbeiter sein ‚Baseball‘ oder ein englischer Arbeit ‚Cricket spielt‘, so wird er alle seine Kräfte anspannen, um seiner Partei zum Siege zu verhelfen; er tut sein allerbestes, so viele ‚Läufe‘ als möglich zu machen. Das Gefühl der Solidarität ist so stark entwickelt, dass einer, der nicht alles hergibt, was an Leistungsfähigkeit in ihm steckt, als ‚Kneifer‘ gebrandmarkt und mit allgemeiner Verachtung gestraft wird.
Am nächsten Tag kehrt derselbe Arbeiter zu seiner Arbeit zurück. Statt nun auch hier alle Kräfte anzustrengen, um möglichst viel zu leisten, wird er in den meisten Fällen mit dem Vorsatz beginnen, so wenig zu tun, als er, ohne aufzufallen, tun kann …“ (F.W. Taylor, vor rund 100 Jahren)
Mit der ganzen Diskussion um die Subjektivierung und die Inwertsetzung des ‚ganzen Menschen‘ kann ich wenig anfangen. Das ist in meinen Augen der soziologischen Reflex auf die Dotcom-Blase. Der Blick auf reale Tendenzen in weiten Teilen der Softwareindustrie wird damit eher verstellt. Für einen theoretisch fruchtbareren Ansatz halte ich die Industrieanalysen der französischen Gruppe „Socialisme ou Barberie“ in den fünfziger und sechziger Jahren. Castoriadis, ein prominenter Vertreter dieser Gruppe, schreibt:
„Seit einem Jahrhundert versuchen sich Taylorismus, Industriepsychologie und Industriesoziologie an folgender Quadratur des Kreises: ausgebeutete und entfremdete Arbeiter zu motivieren, so zu arbeiten, als wären sie nicht ausgebeutet und entfremdet; jene, denen man alle Initiative untersagt, dazu zu bringen, außerordentlich initiativ zu werden, wenn es ’nötig‘ ist (also jederzeit); dafür zu sorgen, dass jene, die man ständig von allem ausschließt, sich an etwas beteiligen. Die Lösung des Problems ist in diesen hundert Jahren um keinen Millimeter vorangekommen. …
Wenn natürlich die bis in ihre äußersten Konsequenzen vorangetriebene Logik des Systems in eine Sackgasse gerät, werden Korrekturen vorgenommen. Aber dies sind nur Schwankungen um einen zentralen Ungleichgewichtspunkt.“ (C.Castoriadis, Ausgewählte Schriften Band 2.2, s.94)
Mit solchen Schwankungen haben wir es wohl auch in der Softwareentwicklung zu tun. Kritische Praxisberichte und Erfahrungen auch aus dem agilen Umfeld würden bei der Analyse sicher weiterbringen.
@Mustkass – schon mal mit Scrum gearbeitet? In der Praxis führt Scrum ohne die beschriebenen Einschränkungen – also wirklich Scrum dazu, dass beim Team wieder ein Leuchten in den Augen entsteht. Ja – Solidarität, Mitspracherecht, Entscheidungsbefugnis bei der eigenen Aufgabe sind entscheidente Kräfte um Teams enstehen zu lassen. Scrum macht Projekte deutlich produktiver und effektiver. Scrum lässt durch die Transparenz, die es bringt auch Konflikte an die Oberfläche kommen, die dann gelöst werden müssen. Für fast jeden Einzelnen wird die Arbeit kommunikativer und ergebnisreicher.
Kopfmonopole werden durch viel Kommunikation aufgelöst. Ziele werden in kurzen Abständen anvisiert und erreicht.
Also ganz ehrlich – für mich ist es eine wirkliche Bereicherung so zu entwickeln. Die Entfremdung der Mitarbeiter wird dadurch verringert.
Ausgebeutet – ja so kann man es auch sehen – allerdings ist ein Angestellter aus meiner Sicht ein wertvolles Mitglied, der Schaffende im Unternehmen. Wirklich gute Unternehmen verstehen es, ihre Angestellten nicht als ausgebeutet darzustellen sondern wertzuschätzen. Natürlich sind Unternehmen an Gewinnen interessiert und müssen auch Managemententscheidungen durchsetzen, die nicht immer im Konsens aller getroffen werden können.
Bzgl. des Zitates zu Scrum. Wenn jemand im Team nicht seine Leistung bringt, sollte man versuchen herauszufinden, woran das liegt. Oftmals sind Frusterlebnisse in der Vergangenheit dahinter, manchmal aber auch die menschliche Neigung bequem zu sein und sich zu arrangieren (nicht umsonst: werd ich je beruhigt mich auf mein Faulbett legen, so sei es um micht geschehen). Wenn offenkundig wird, dass ein Teammitglied nicht mitspielt, es aber könnte, ja dann gehört es auch in jedem Sport auf die Auswechselbank – wieso soll das in Unternehmen nicht so sein? Natürlich muss immer genau die Ursache betrachtet werden. Es geht nicht darum, das jeder ein geistiger Überflieger sein muss, keine Kinder haben darf und möglichst 16h am Tag arbeitet – nein – es geht darum, dass er das in seinem Rahmen mögliche tut, um im Team gemeinsam das Ziel zu erreichen. Im Team integrieren sich verschiedene Charaktere und bringen damit unterschiedliche Aspekte in die Teamarbeit. Ein geistiger Überflieger kann schwierige Aufgaben lösen, ein schneller Umsetzer, kann Implementierungen vorantreiben, 8h am Tag sollten sowieso nicht überschritten werden… es gibt soviele Möglichkeiten Menschen in Teams motiviert zusammenarbeiten zu lassen.
@Mustkass: Schönes Zitat von Taylor, das illustriert das Problem sehr gut. Und auch das Castoriadis-Zitat ist gut. In einer etwas anderen Sprache sagt er doch in etwa das, was ich versucht habe in dem Artikel zu beschreiben. Allerdings sitzt Castoriadis noch der Illusion auf (wie ich vor 10 Jahren auch), dass der Ausschluss von der Initiative (oder noch weiter: von der Verfügung über die Produktionsmittel) das Problem ist. Ist es aber nicht, jedenfalls nicht primär, denn wenn die Arbeiter die Fabrik besitzen, sie also voll initiativ sein »dürfen«, dann müssen sie es auch. Und dann spüren sie, was »Entfremdung« in Form totaler Marktabhängigkeit bedeutet. Die (immer noch) besetzten Fabriken in Argentinien können ein Lied davon singen.
@Sebastian#8: »Ausbeutung« (wie von Mustkass verwendet) oder »Entfremdung« (wie von mir) sind »objektive Kategorien«. Das bedeutet, es ist keine Frage des so oder anders sehen Wollens, und man bekommt das auch nicht mit »Wertschätzung« weg. Nichts gegen Wertschätzung, aber damit änderst du die Bedingungen nicht, denen die Akteure unterworfen sind. Trotzdem glaub ich dir, dass »beim Team wieder ein Leuchten in den Augen entsteht«, wenn sie mal mehr Selbstbestimmung bekommen. Ich habe das (ohne Scrum) auch selbst erlebt. Aber das geht immer nur bis zu einer bestimmten Grenze — ist meine Erfahrung. Irgendwann musste auch ich »Managemententscheidungen« durchsetzen (auch in einem non-profit Laden).
In dem Sinne bin ich auch an kritischen Praxiserfahrungen aus dem agilen Umfeld interessiert.
Jaja, mit den faulen Arbeitern hatte auch Taylor schon seine Probleme.
Mich würden Berichte genau von diesen KollegInnen interessieren, die auf die Ersatzbank müssen. Ein Element von SCRUM ist ja wohl die Erzeugung von massivem Teamdruck.
Jeff Sutherland beschreibt ein Offshore-Outsourcing-Projekt mit SCRUM , bei der die Produktivität angeblich fünfmal so hoch war wie im Industriedurchschnitt. (Wie hoch ist der eigentlich?):
„Mainly to optimize the project, but also he wanted to build a positive competitive dynamic between the teams where every member of every team on either shore, knew that somebody off shore could do their work tomorrow.“
Das sieht Jeff nicht etwa kritisch, sondern als Erfolgsfaktor. Weitere Erfolgsfaktoren sind permanente Überwachung und die Konzentration der Architekten, Master und Owner Onsite, nur das Fußvolk ist in verteilten Teams Offshore.
(siehe http://www.softhouse.se/Uploades/Intervju_070206.pdf)
Nach meiner Erfahrung ist es eine Frage des Kräfteverhältnisses, wieviel Spielraum / Autonomie wir EntwicklerInnen haben. Prozessmodelle sind da sekundär. Autonomie gewinnen wir nicht durch Prozessmodelle und Appelle an das Management. „Break the rules!“ (Alistair Cockburn auf einem seiner Workshops zur agilen Softwareentwicklung)
@StefanMZ: –>damit änderst du die Bedingungen nicht, denen die Akteure unterworfen sind. Wieso nicht? Wenn das Team mehr Spielräume bekommt und mit eigenen Entscheidungen arbeiten kann, sind das doch andere Bedingungen, als ohne Entscheidungsbefugnis und fremdgesteuert arbeiten zu müssen?
@Mustkass–>Ein Element von SCRUM ist ja wohl die Erzeugung von massivem Teamdruck.
Ist das nicht in allen Team-Sportarten genauso? Ist das schlecht?
–>“Mainly to optimize …
Es sprechen ja auch viele Gründe gegen das Offshoring. Ein Hauptproblem aus Projektsicht ist der schlechte Kommunikationsfluss, die Daily Scrums und die Abstimmung mit ScrumMaster und ProductOwner sind deutlich komplizierter.
Daher ist es doch sinnvoll dem Shore-Team zu signalisieren, dass auch viele Gründe für die Erhaltung des Teams sprechen. In Zeiten, in denen Offshoring und Nearshoring immer latent als Gefahr bestehen, finde ich es richtig, dem shore-Team klarzumachen, wie es bestehen kann.
Das hier gesellschaftliche und politische Rahmen nicht stimmen (die das Outsourcing forcieren) steht außer Frage. Aber solange die Unternehmen diesbzgl. nicht begrenzt werden, gehen sie den Weg der Gewinnmaximierung. Mit Scrum kann eher noch verhindert werden, dass zu stark verlagert wird.
–>Nach meiner Erfahrung ist es eine Frage des Kräfteverhältnisses, wieviel Spielraum / Autonomie wir EntwicklerInnen haben. Prozessmodelle sind da sekundär.
Scrum gibt aber den Rahmen und legitimiert zur Kritik und Transparenz!! Dadurch wird erzwungen, das Kräfteverhältnisse in Frage gestellt und nach anderen Kriterien ausgerichtet werden können. Durch die deutlich gesteigerte Kommunikation werden Teams mehr zum Nachdenken und Ändern angeregt (und erfüllen nicht nur isoliert Aufgaben, dessen Zusammenwirken mit anderen Bausteinen unklar bleibt). Von daher ist für den Beginn der Änderung das Prozessmodell im Falle von Scrum primär wichtig.
Autonomie – in vernünftigen Grenzen- kann man auch gewinnen durch sachlich/faktisch untermauerte Appelle an das Management. Begründungen mit Sprint-Ergebnissen, Steigerung der Velocity und Lieferung von BusinessValue wie vor dem Sprint vereinbart erhöhen das Vertrauen in das Team und lassen wieder mehr Spielräume zu.
–>Mich würden Berichte genau von diesen KollegInnen interessieren, die auf die Ersatzbank müssen
Die Ersatzbank ist letzte Maßnahme, um zu zeigen, dass so nicht im Team gearbeitet werden kann. Sobald transparent wird, das Lernen notwendig ist, dann können Teammitglieder gezielt geschult und aufgebaut werden, um evtl. Defizite. Das Team kann soetwas selbst erkennen und versuchen zu verbessern.
Teammitglieder, die permanent gegen das Team arbeiten demotivieren das ganze Team. Hier würde ich gezielt mit dem Teammitglied sprechen und versuchen zu verstehen, wo das Problem liegt und daran arbeiten es zu lösen. Wenn das Problem nicht lösbar ist, dann würde ich das Team anders aufstellen.
Jemand, der im Handball auf dem Feld nicht gut spielt, kommt auf die Auswechselbank, jemand der nicht trainiert und schon auf der Auswechselbank sitzt fliegt aus der Mannschaft.
Und nicht zu Entscheiden und nach deutlichem Ausmachen von Faulenzern auch Konsequenzen zu ziehen sehe ich als schlechtes Management.
Und die faulen Arbeiter … es gibt auch genug faule und oberfaule Manager. Die Arbeiter sind nur einfacher anzugreifen und „scheinbar“ (in der Softwareentwicklung ein Trugschluss – Tom De Marco in „Wien wartet auf Dich“ zeigt, was es wirklich kostet) einfacher zu ersetzen. Aber gerade die Arbeiter tendieren wahrscheinlich viel weniger zum Lenzen, weil sie mehr um ihre Existenz kämpfen müssen.
Existenzangst und der daraus resultierende Leistungswille sind der Hauptgrund, warum Offshoring funktioniert. Die Existenzangst bei uns zu erzeugen ist der einfachere aber aus meiner Sicht falsche Weg. Besser wäre durch Kreativität und Spielräume den Leistungswillen im Team wieder hervorzubringen. Scrum kann dabei helfen.
@Sebastian: Der Vergleich mit dem Sport hinkt, weil im Sport nicht die Existenz dran hängt (außer im Profisport). Dahinter kann keine Methode zurück. Das wollte Stefan wohl ausdrücken. Wenn Entwickler aber gerade gesucht werden und sich quasi ihren Arbeitsplatz aussuchen können, dann stimmt das was Du sagst. So war es noch vor ein paar Jahren. Zufall dass gerade da agile Methoden so gehypt sind? Zufall dass es jetzt teilweise wieder einen Backlash gibt, wo die Entwickler sich um die Jobs kloppen?
Aber hervorgebracht werden muss er, nur welche Methode besser funktioniert, wird noch diskutiert. – Mich erstaunt immer wieder, wie stark der Arbeitsfetisch ist; das wird aus der Diskussion hier deutlich. Als ob Arbeit etwas Gutes wäre und nicht etwas, das man auf das Minimum beschränken sollte! So absurd diese Vorstellungen sind, sie sind keine bloße fixen Ideen, sondern die präzise Abbildung dessen, was Arbeit im Kapitalismus ist: Etwas, das so viel wie möglich stattfinden muss, wobei der Zweck zweitrangig, bestenfalls Vorwand ist (ohne Gebrauchswert der Waren geht’s natürlich nicht; auch zum Motivieren der Arbeiter ist irgendein behaupteter Zweck gut), während es eigentlich um Wertverwertung geht.
Ich werde mehr und mehr zum Materialisten: Die Präzision, mit der die anzutreffenden Vorstellungen sich aus den Bedingungen des Wirtschaftens (bei uns also des Kapitalismus) ergibt, ist erstaunlich. Dieser seltsam verdrehte BWLler-Sprech wird daher auch erst mit dem Kapitalismus verschwinden.
@Martin –>Als ob Arbeit etwas Gutes wäre und nicht etwas, das man auf das Minimum beschränken sollte!
Interessante Einstellung! Mir macht leider? Arbeit Spass – ich arbeite gern und viel – das gebe ich zu. Und am liebsten arbeite ich in motivierten Teams. Gemeinsam erreichen wir Ziele und entwickeln uns weiter. Diese ganze Diskussion über Kapitalismus und die Ausbeutung der Menschen,… führt mir in Verbindung mit Scrum deutlich zu weit. Ja Scrum löst den Kapitalismus nicht ab und verstärkt evtl. Teile und schwächt andere ab – aber!- aber? – das Entwickeln und die Arbeit im Team machen wieder Spaß. Es wird offener kommuniziert. Ziele werden erreicht. Das zählt für mich als leidenschaftlicher Softwareentwickler. Wie habe ich Einzelentwicklung, Arbeit in unmotivierten Teams, zielloses Entwicklungsdahinvegetieren gehasst…
@Benni – der Vergleich mit dem Sport soll doch nicht die existenzielle Abhängigkeit in Frage stellen oder vernachlässigen, sondern die Einstellung in Teams zu arbeiten beleuchten.
–>Zufall dass es jetzt teilweise wieder einen Backlash gibt, wo die Entwickler sich um die Jobs kloppen? Dann haben diese Unternehmen Scrum nicht richtig eingeführt!
@ StefanMz
Allerdings sitzt Castoriadis noch der Illusion auf (wie ich vor 10 Jahren auch), dass der Ausschluss von der Initiative (oder noch weiter: von der Verfügung über die Produktionsmittel) das Problem ist. Ist es aber nicht, jedenfalls nicht primär, denn wenn die Arbeiter die Fabrik besitzen, sie also voll initiativ sein »dürfen«, dann müssen sie es auch. Und dann spüren sie, was »Entfremdung« in Form totaler Marktabhängigkeit bedeutet. Die (immer noch) besetzten Fabriken in Argentinien können ein Lied davon singen.
Da wirst du Castoriadis nicht gerecht. Das ein selbstbestimmter Betrieb an einer entfremdeten Umgebung scheitern kann ist ihm sehr wohl klar. Er vertritt in all seinen Schriften die Postition, dass Selbstbestimmung letztlich ein gesellschaftliches Projekt ist. Sie muss in allen Bereichen angestrebt werden. Das ist deswegen die Crux der meisten Selbstverwaltungsversuche: dass sie sich nicht politisch verstehen in dem Sinne, dass sie nach Ausweitung und Institutionalisierung dieses Prinzips streben (z.B. Marcora-Gesetz in Italien), sondern im Modus der Selbsthilfe und Reparaturmassnahmen bleiben.
Hier wird aus ganz unterschiedlichen Perspektiven auf SCRUM geschaut. Im Gegensatz zu Stefan Radies will ich überhaupt nicht arbeiten. Arbeit ist für mich fremdbestimmt und allein dazu da, Geld zum Leben zu bekommen. Manager brauche ich auch nicht. Ich will gerne gute Software bauen, zusammen mit Kolleginnen und Kollegen – und dann auch noch Software die sinnvoll ist und uns und/oder anderen Menschen nützt. Ich träume von einer Gesellschaft, in der es keine Führer/Manager einerseits und Ausführende andererseits gibt.
Zurück zu SCRUM:
Was sind die Erfolgsfaktoren?
Teamdruck scheint einer zu sein. Das ist hier wohl Konsens, wenn auch unterschiedlich bewertet.
Die Befreiung von bürokratischem Balast ist sicher ein weiterer.
Kundennähe und schnelle Feedbackzyklen ist bei allen agilen Methoden Standard.
Ist es der sportliche Aspekt, der SCRUM von anderen agilen Methoden abhebt?
Was noch?
Wer nutzt SCRUM?
Welche Firmen (große/kleine, Produkthersteller/Dienstleister, etc.) setzen SCRUM wie ein. Wie wird SCRUM „verbogen“. Bei der Allianz soll SCRUM flächendeckend eingesetzt werden. Ist das SCRUM nach der reinen Lehre? In was für Firmen funktioniert SCRUM?
Was entscheidet das Team, wo sind die Grenzen?
Kann das Team seine Tools auswählen, kann das Team die Architektur festlegen?
Wie kommt das Team zusammen?
Kann das Team Refactoring-Maßnahmen beschließen?
Was ist mit Unternehmensstandards?
Wird dem Team mit Projektabbruch gedroht, wenn es nicht die erwarteten Ergebnisse liefert?
Die SCRUM-Propagandisten vereinbaren SCRUM mit CMMI und vertikaler, internationaler Arbeitsteilung (siehe dazu „Deutsche Herren, indische Knechte„) – das zeigt, dass auch die reine SCRUM Lehre eine Managementmethode ist, die sich nahtlos in die gängigen Industrialisierungsbestrebungen eingliedern läßt. Ich glaube, dass die Einfachheit und Flexibiltät („SCRUM BUT“) ganz wesentlich zum Erfolg von SCRUM beiträgt. Das Management kann seinen Plan etwas im Hintergrund halten und das Team sprinten lassen – wenn es sich im oder gar über Plan bewegt, wunderbar! Wenn nicht, wird das Projekt abgebrochen.
@musskass
–>Was entscheidet das Team? Toolauswahl und Archtiktur kann das Team vornehmen, sollte sich aber an den Unternehmenstandards orientieren und genau begründen, warum Tools geändert werden (wenn das mit gesteigerter Implementierungsgeschwindigkeit oder anderen Kriterien ausreichend begründet werden kann, dann hilft es dem Projekt). Die Abstimmung mit dem Architekten (im Team am besten mit dabei) ist sinnvoll.
–>Refactoring — auf jeden Fall, allerdings sollte es schon im Projekt einen Mehrwert bringen oder gut begründet sein. Goldene Türklinken sind nicht im Sinne der Sprinterreichung und können mit Scrum nicht gedeckt werden. Oberstes Ziel ist der Sprint, mit der Vereinbarung ein potential shippable Stück Software abzuliefern.
–>Projektabbruch – ist nach jedem Sprint möglich. Das Projekt wird am ProductBacklog ausgerichtet. Am ProductBacklog wird das Releasemanagment ausgerichtet. Nach jedem Sprint sieht das Team und die Stakeholder, wo das Projekt steht (im Gegensatz zu anderen Prozessmodellen). Öfter werden auch Projekte beendet, wenn der BusinessValue annähernd erreicht ist und zuviel Aufwand ggfb. zu wenig weiterem Nutzen gegenübersteht. Aber genau das ist ja richtig.
Der erwartetet BusinessValue treibt das Projekt. Danach wird das Backlog gewichtet und dadurch ergibt sich die Abarbeitungsreihenfolge im Projekt.
Hier ist die Entscheidungsbefugnis des Teams bei Scrum wirklich gut. Das Team schätzt die BacklogItems bzgl. ihrer Größe in Relation zueinander. Das Team bestimmt, was es sich im Sprint an BacklogItems zutraut und committed sich darauf. Das Team kann im Review Sprintweise die Ergebnisse präsentieren. Das Team kann darüber entscheiden, dass eine Verstärkung sinnvoll ist.
Viele gute Infos zu Scrum bietet Boris Gloger – ein super ScrumTrainer, ScrumAlliance ist ebenfalls ein großer Informationspool.
Von Scrum But halte ich nicht viel. Scrum sollte zunächst mit seiner Vielfalt erprobt und erkannt werden. Die Elemente von Scrum haben zusammen einen Sinn. Einzelne Teile rauszulassen, schwächt wieder andere Teile ab. Wenn man nicht sehr genau weiß, warum man etwas weglässt und was es für Auswirkungen hat, sollte man es zunächst mit dem empfohlenen Weg versuchen. Mit viel Erfahrung – evtl. ergeben sich dann unternehmenspezifische Ausprägungen, in denen Elemente angepasst oder weggelassen werden. Da würden mich aber die genauen Gründe dann sehr interessieren.
Erfolgsfaktoren:
-Transparenz
-Kommunikation, Kommunikation, Kommunikation – Team-Problemerkennung mit Retrospektiven
-Orientierung am Geschäftswert
-Kundennähe und Feedbacks – sind im Modell mit Meetings fest vorgesehen – und damit besonders in Scrum
-Entscheidungsbefugnis über das Wie der Entwicklung im Team – die taktische Ebene wird vom Team übernommen. Das Management hält sich aus der Ebene raus und arbeitet auf strategischer Ebene.
-Enormer Wissenstransport im Team (durch Daily Scrums, evtl. PairProgramming, alle arbeiten an einer Story)
-Crossfunktionale Teams – alle, die im Projekt zum Erfolg beitragen können gehören ins Team
-Ergebnisse und Antrieb je Sprint
-Ein guter ScrumMaster, der täglich die Probleme löst und weiterträgt und an der Lösung dranbleibt. Ein ScrumMaster mit Überblick und Moderationsfähigkeiten, der Besprechungen moderiert und Entscheidungsfindungen im Team ermöglicht.
-Ein guter ProductOwner, der seine Rolle als Produkt-Verantwortlicher wahrnimmt, das Backlog immer aktuell hält, mit dem Kunden kommunziert (das Team auch!), den Releaseplan und den BusinessValue im Auge hat und Ergebnisse im Management bekannt macht. Der ProductOwner kristalliert sich als auch entscheidende Rolle in Scrum-Projekten heraus.
Pläne im Hintergrund:
Der ProductOwner verantwortet das Projektvorgehen mit der Backlog-Reihenfolge und der Backlog-Pflege. Er ist Teil des Scrum-Teams und hat eine entscheidende Rolle. Wenn das Projekt scheitert, scheitert das Team – entsprechend auch der ProductOwner. Einen Plan im Hintergrund halten macht dann nicht viel Sinn.
Unternehmensstandards:
Bilden den Rahmen für die Projekte. In Scrum gelten natürlich diese Standards zunächst. Allerdings können/sollten diese in Frage gestellt werden, wenn dadurch das Projekt am Fortschritt gehindert wird. Durch transparentmachen ist es dann Entscheidung des Managements, ob Verzögerungen bewußt in Kauf genommen werden sollen oder ob evtl. der Standard geändert wird.
@Bigbear: »…dass Selbstbestimmung letztlich ein gesellschaftliches Projekt ist. Sie muss in allen Bereichen angestrebt werden.«
Wie soll das gehen? Ist die Vorstellung, dass lauter entfremdet arbeitende selbstbestimmte Inseln sich irgendwann vereinen und dann ist die gesellschaftliche Entfremdung (und damit Markt, Geld und Staat) weg? Das ist eine ernsthafte Nachfrage, mir fehlt da einfach die Phantasie und ich kenne Castoriadis nicht.
@StefanMz
« »…dass Selbstbestimmung letztlich ein gesellschaftliches Projekt ist. Sie muss in allen Bereichen angestrebt werden.«
Wie soll das gehen? Ist die Vorstellung, dass lauter entfremdet arbeitende selbstbestimmte Inseln sich irgendwann vereinen und dann ist die gesellschaftliche Entfremdung (und damit Markt, Geld und Staat) weg? Das ist eine ernsthafte Nachfrage, mir fehlt da einfach die Phantasie und ich kenne Castoriadis nicht. »
Das wäre sicherlich eine mögliche Strategie (N.B. Nicht «lauter entfremdete», sondern lauter selbstbestimmte («autonome» in Castoriadis‘ Terminologie) Inseln).
Es gibt natürlich keine Blaupause, da einerseits Selbstbestimmung gerade heisst, dass es keine Vorgabe von aussen gibt, andererseits Strategie und Taktik von den Umständen abhängt. Aber das müsste wohl die bewusste Perspektive sein: aus der eigenen Erfahrung, dass ich selbstbestimmt handeln kann (und muss, ggf. auch gegen (!) die Vorgaben, soll der Betrieb irgendwie funktionieren), die Forderung an meine Umgebung und an die Gesellschaft zu erheben, so auch handeln zu sollen und mir niemand Vorgaben machen kann (es sei denn ich hätte ihn/sie dazu autorisiert).
Markt, Geld, Staat sind Institutionen von denen wir uns angewöhnt haben sie als «gegeben» anzusehen, als ausserhalb unserer Verfügunggewalt. Dabei sind sie, wie alle anderen Institutionen auch, unsere eigenen Schöpfungen (genauso wie die Vorstellung (Imagination) von deren Gegebenheit unsere Schöpfung ist). Und damit sind sie prinzipiell unserem Gestaltungswillen unterworfen. Das ist der Kerngedanke von Castoriadis‘ Begriff der «imaginären Institution der Gesellschaft» (so der Titel seines Hauptwerkes).
Meiner Meinung nach handelt es sich zunächst um ein Problem des Bewusstseins: Wir sind so sehr davon geprägt, uns nicht vorstellen zu können, wie wir ohne «Leitung» durch andere handeln können, als dass die Perspektive einer umfassend selbstbestimmten Gesellschaft plausibel erscheint. Ein schönes Beispiel liefert der Fall der Uhrenfabrik LIP in den frühen 1970er Jahren: einerseits haben die Arbeiter damals gezeigt, dass sie Produktion und Vertrieb selbst organisieren können, andererseits wollten sie immer «nur» einen neuen patron, also einen Chef, der ihnen sagt wo’s lang geht.
Von Castoriadis gibt es aus dem Jahr 1960 den Text «Über den Inhalt des Sozialismus» (jetzt in Band 2.1 der Ausgewählen Schriften) der einige Aspekte einer solchen Gesellschaft beschreibt. Trotz seiner etwas antiquierten Sprache («Sozialismus» statt «Autonomie» usw.) ist der immer nocht lesenswert, was soger ein FAZ-Rezensent feststellte.
Den ganzen Castoriadis verbreite ich hier aus Platzmangel lieber nicht. Ich glaube aber, dass sich bei ihm und bei dem, was in den 1950er und 60er Jahren die Gruppe «Socialisme ou Barbarie» gemacht hat, ein (besonders in Deutschland) unausgeschöpftes Potenzial verbirgt. Die Webseiten des Vereins zum Studium und zur Förderung der Autonomie (VSFA) wissen mehr (incl. einiger Castoriadis-Texte).
@Bigbear: Danke! Ich gucke mir das mal an 🙂
Also irgendwie sind wir doch nur Ziegen, die jetzt im Gehege rumlaufen dürfen statt, wie früher, angepflockt zu sein. Und die neue Freiheit hat uns der Ziegenhirte nur gegeben, weil er sich daraus weniger Aufwand auf seiner Seite und höheren Ertrag verspricht. Und darüber, wie groß der Einfluss einer Ziege auf den Hirten ist, braucht man sich auch keine Illusion machen.
Wenn ich Sebastian höre, wird mir heiß und kalt. Intelligent und technisch überzeugend. Aber auf welchen Werten basieren die Argumente? „Business Value“ – sonst nichts. Und was das ist, legt sicher nicht das Team Fest. Das kanns doch nicht sein, oder?
Habe in meiner Projektgeschichte des öfteren mit Leuten zusammengearbeitet, die vom Management als „Low Performer“ identifiziert und gemobbt wurden. Mann, die Leute waren zwar fachlich wirklich nicht an der Spitze aber nett. Ich tue alles, dass die weiter mit spielen, nix Ersatzbank!
Sebastian, ich finde Deine Ausführungen sehr interessant aber im Abgang fehlt mir etwas Distanz und Reflexion. Sorry, ich hoffe, ich verstoße nicht damit nicht gegen irgendwelche Forumsregeln, aber mir blutet das Herz, wenn ich Intelligenz so instrumentalisiert sehe.
Aber Stefan wollte eigentlich was über Scrum-Erfahrung hören:
Habe bei einer Bank 6 Monate laut nach Scrum gearbeitet, jedenfalls hat man mir das so gesagt. Aber nach dem, was ich hier lese war das wohl eher ein Scrum But. Wir hatten 2 Projektleiter, der Scrum-Master war im Team, der Product-Owner hatte letztenendes wenig Entscheidungskompetenz.
Bein kein Experte in den Scrum-Lehren, fasse hier mal meinen Eindruck zusammen, unter der Gefahr, dass ich aus meinem Projekt die falschen Schlüsse auf Scrum ziehe.
Ich fand das im Prinzip ganz angenehm. Bisher hatte ich weitgehend nach Wasserfall gearbeitet. Man braucht so oder so den Kontakt Richtung Fachbereich und bei Scrum ist das quasi Institution und damit einfacher. Die Täglichen Meetings fand ich etwas anstrengend, weil am Ende doch nicht so viel passiert und trotzdem jeder ein paar warme Worte sagt.
Unser Team bestand im Kern aus recht gut qualifizierten Leuten, Beratern, die technisch, fachlich, organisatorisch und in der Kommunikation stark waren. Hier lief die Zusammenarbeit gut. Die Team-Mitglieder, die nicht zum Kern gehörten, also nur 1-2-3 Tage/Woche für das Projekt hatten, waren etwas schwieriger in die Abläufe zu integrieren. Ob das an der wenigen Zeit, oder der etwas schlechteren Qualifikation lag, ist schwer zu sagen. Vielleicht lags auch an mangelnder Akzeptanz aus dem Kern-Team.
Zusammenfassend würde ich sagen, dass die Leute wohl im Wasserfall weitgehend ähnlich gearbeitet hätten. Eine Verbesserung für die Qualifizierteren war sicherlich die Ausdünnung des Fachkonzepts zu den Faeture Sets und deren bedarfsorientierte Anreicherung im Projektverlauf durch die Leute die dann tatsächlich die Software gebaut haben.
Mhm, ich fürchte, dass ist nicht wirklich was Du wissen wolltest, oder?
@Molle: Doch, danke, mir ging es einfach um die Erfahrungen, die ich dann so mit meinen vergleichen kann. Wir bräuchten mehr davon, um dann einen Schritt weiter gehen zu können zu einer kritischen nud verallgemeinernden Reflexion. Macht ja sonst niemand. Wahrscheinlich kann dir Sebastian jetzt erklären, dass ihr eben Scrum nicht richtig angewendet habt, weswegen ihr nun zwar im Gehege rumlaufen durftet, aber das Gehege ziemlich klein war. Mit dem Ziegen-Bild hast du das Dilemma ganz gut auf den Punkt gebracht. Wobei der Ziegenhirt oft keine Person ist, sondern eine abstrakte Struktur, ein Marktzwang, eine Organisationsanforderung oder schlicht eine Budgetlogik.
@Sebastian: Das meine ich mit den Bedingungen, die nicht von Scrum verändert werden können. Trotzdem ist es besser, nicht mehr angebunden zu sein, sondern in einem möglichst großen Gehege rumlaufen zu können, weil das auch eine Idee davon gibt, wie es ohne Gehege sein könnte. Oder wie es Mustkass ausdrückt: Statt gezwungenermaßen Arbeiten müssen für Geld einfach nur gute Software bauen — oder was einem sonst noch so alles liegt.
@Molle – Danke für den vom Blickwinkel abhängig treffenden Vergleich mit dem Ziegenkäfig. Das Bild lässt sich generell auf heutige Unternehmen anwenden. Scrum erweitert den Käfig – finde ich auch (und manchmal macht es auch ein Loch in den Zaun!).
–>Intelligenz so instrumentarisiert – ich selber bin von Scrum überzeugt und finde die Erweiterungen in der Softwareentwicklung klasse. Scrum instrumentarisiert mich dazu anders über Kommunikation und Entwicklung nachzudenken – das stimmt. Scrum im Unternehmen einzuführen ist ein Kampf – nicht einfach alte Denkstrukturen aufbrechen – entsprechend instrumentarisiert das Unternehmen mich schon mal nicht (es sei den das Unternehmen will Scrum von oben und nach seinen eigenen Scrum-Regeln).
Gleich an die gesellschaftlichen Auswirkungen zu denken und damit die Unternehmesstrukturen, das Gewinnstreben, den Kapitalismus in Frage zu stellen halte ich für zu schnell gerannt. Damit macht man Scrum gleich tot. Und es ist nicht Scrums Anspruch. Scrum sollte eine produktivere und effizientere Zusammenarbeiten ermöglichen und erkennt, das menschliche Interaktion entscheidend ist.
–>Die Täglichen Meetings fand ich etwas anstrengend, weil am Ende doch nicht so viel passiert und trotzdem jeder ein paar warme Worte sagt.
Daily Scrum – Was habe ich seit den letzten Meeting erreicht, Was will ich bis morgen erreichen, Was hindert mich – in max. 15min für das gesamte Meeting. Warme Worte – brauche ich hier nicht. Das Team soll sich synchronisieren und der ScrumMaster bekommt neue Hindernisse, die er wegräumen kann. Oft entstehen im DailyScrum Diskussionsansätze, die danach detailliert werden können. Probleme werden oft erst hier genannt oder Vorschläge zu alternativen Vorgehen können im Team gefunden werden.
Kritisch wird es, wenn die Daily Scrum zu Laberrunden ausufern, deutlich länger als 15min dauern und niemals Hindernisse genannt werden. Dann ist etwas faul. Hier ist der ScrumMaster gefragt!
–>… die Leute im Wasserfall weitestgehend ähnlich gearbeitet hätten – dann war hier aber eine Methode von Beiden sehr eigenwillig interpretiert. Scrum unterscheidet sich deutlich vom Wasserfall, allein die Feedbackzyklen, der Ablauf – Analyse, Design, Implementierung … sind ganz anders. Hätten sie mit Retrospektiven gearbeitet? Wann gibt es fachliche (nicht technische) Reviews?
–>“Business Value” – sonst nichts.
Die Ausrichtung am BusinessValue ist für das Unternehmen natürlich entscheidend. (Der Business Value wird vom ProductOwner bestimmt und gilt für den Rest des Scrum Teams als Vorgabe. Natürlich kann das Scrum-Team mit dem PO auch diskutieren und Vorschläge in Richtung Qualitätsverbesserungen unterbreiten, die auch wieder den BusinessValue beeinflussen – mitdenken ist erwünscht!)
Dazu gehört aber auch, dass ein Verschleiss von Mitarbeitern auf Dauer viel Geld kostet, das Projekte in Zusammenarbeit und positiv geprägter Kommunikationskultur produktiver durchgeführt werden können. Der Wert für das Unternehmen und für die Mitarbeiter erhöht sich durch Einführung kreativitätsfördernder Umgebungen – Scrum macht es transparent. Ich finde schon, dass das eine Errungenschaft ist … weitere müssen folgen (Interessant finde ich diesem Zusammenhang übrigens das Thema Grundeinkommen … aber das führt in diesem Blogposting glaube ich zu weit – wäre doch ein super weiterer Blog ;-))
„In Werten dokumentiert sich das, was ein Individuum, eine Gruppe oder eine Gesellschaft als wünschenswert ansieht. Werte sind folglich Auffassungen über die Wirklichkeit, genauer: über die Qualität der Wirklichkeit. Sie beeinflussen damit die Auswahl unter möglichen Handlungszielen, Mitteln und Handlungsweisen. – Bernd Noll“
Einige meiner Wünsche, um besser zusammenarbeiten zu können, werden mit Scrum erfüllt.
–>Übrigens (weiß nicht, ob das im Forum ok ist?) – habe ich vor ein paar Tagen ein tolles kostenfreies (online) Praxisbuch zu Scrum gefunden — http://www.infoq.com/resource/news/2007/06/scrum-xp-book/en/resources/ScrumAndXpFromTheTrenchesonline_German.pdf
Ich verweise mal auf die Ausführungen, die ich in meinem Blog zu dem Thema gemacht habe. Ich stimme im wesentlichen Stefan zu, daß man es hier mit einem Verfahren zu tun hat, mit dem man kreative Prozesse dem Verwertungsinteresse des Kapitals unterwerfen kann. Dabei setze ich insofern einen anderen Akzent, als Scrum – zumindest für meine Firma – im Wesentlichen deshalb von Bedeutung ist, weil man endlich, endlich in der Lage ist, die angepeilten Release-Termine einzuhalten (das Produkt – die Musiksoftware Cubase – verkauft sich so ziemlich von alleine).
Hi,
der name scrum mag ja erst 10 jahre alt sein. Aber nach dieser methode hab ich mal vor 40 jahren ne zeitlang inner gruppe gearbeitet. Lief unuebertroffen gut, bis das projekt eingestellt wurde. Mit dem produkt sollte IBMs DOS paroli geboten werden. Das traute sich Telefunken dann doch nicht zu. Vieles spricht in meinen augen dafuer, dass der markt stillschweigend aufgeteilt war. Die nicht-scrummenden projekte bei tfk ueberlebten laenger. Sie hatten deutlich mehr leute und somit viel mehr firmen-interne lobbyisten. Die waren dann auch am ende, als die staatsknete zurueckgefahren wurde.
Hallo, ich bin gerade auf diese Diskussion gestoßen und wollte etwas aus meinem Scrum-Alltag beitragen. Ich befinde mich jetzt seit 23 Sprints (also knapp 2 Jahre) in einem Scrum-Projekt. Insgesamt kann man das Projekt als außerordentlich erfolgreich betrachten. Bisher waren alle Sprints ausnahmslos erfolgreich, alle Meilensteine eingehalten und die Arbeitsergebnisse durchweg hochwertig.
Dazu muss ich noch sagen, dass wir zeitweise mit zwei Teams parallel gearbeitet haben, da wir nun 16 Leute sind, die über Deutschland verteilt arbeiten. Dazu kommen noch der ProductOwner und ein ganzes QS/Test-Team.
Man ist schon irgendwie stolz auf das alles!
Was mir (rein subjektiv) allerdings mit weiterem Fortschreiten des Projektes auffällt ist, dass es zeitweise immer belastender wird, den Scrum-Rythmus „zu wollen“!
Jeden Tag „abliefern“ zu müssen, immer zur selben Zeit, immer von allen beobachtet. An den meisten Tagen klappt das auch gut, aber es gibt Tage, wo man einfach nicht produktiv sein kann, wo man mies schläft oder sonstwie nicht 100%ig dabei ist. An solchen Tagen belastet Scrum die Seele. An diesen Tagen verfluche ich das Daily und wünschte mir, man würde alle 6-8 Sprints mal einen Sabbat-Monat einlegen, in dem man „normal“ arbeiten kann, ohne jeden Tag Rechenschaft ablegen zu müssen. Vielleicht nur alle 3-4 Tage – Das wäre schon schön! 😉
Aber wie gesagt: Insgesamt halte ich Scrum dennoch für ein sehr mächtiges Instrument und richtig eingesetzt auch für einen „Zufriedensteller“ von Schlipsträgern.
@Steviee: Danke für deinen Erfahrungsbericht! Ich finde, du hast die Widersprüchlichkeit zwischen befriedigender Selbstentfaltung und belastendem Lieferzwang ganz gut beschrieben.
Ich kenne SCRUM nicht aus eigener Erfahrung, bin aber seit 18 Jahren in der Softwareentwicklung tätig…
Die euphorischen Berichte wecken aber die Assoziation zu religiösen Erweckungen, zu Rausch und Extase. SCRUM ist eine Art Strukturvertrieb, eine hochansteckende Religion. Dass die junge Bewegung eine Formel wie „Scrum But“ hervorgebracht hat, macht mich ebenfalls misstrauisch. Werden damit etwa die ausbleibenden Wunderheilungen wegerklärt?
Scrum ist eine gute Möglichkeit für ein Management das bisher schon nicht mitgedacht hat in Zukunft noch weniger mitzudenken und dem Team die Verantwortung für sämtliche Managementaufgaben aufzupressen (Resourcenplanung, Projektplanung, Terminmanagement usw.)
Gibt es Probleme so liegt es natürlich daran dass die Entwickler nicht Scrum können, bzw. an einzelnen Nicht-Scrum-kompatiblen Entwicklern die dann ausgetauscht werden müssen.
Scrum setzt ungute Gruppendynamiken frei: wer die dicksten Ellenbogen hat setzt sich durch, das Team hat darunter zu leiden, das Management schaut zu und wenn die Ergebnisse nicht stimmen wird einfach der Druck im Kessel erhöht. Scrum versetzt Teams zurück in die Storming-Phase. Im einfachsten Fall setzt sich das Alpha-Tier durch und man hat wieder eine hierarchische Struktur im Team, allerdings gehts dann nicht nach Dienstältestenprinzip oder Dr.-Titel. Worst-Case ist dann wenn mehrere Alpha-Tiere dauerhaft gegeneinander arbeiten…
Scrum bringt Unruhe in’s Team…die Work-Life-Balance ist hinüber… ein wöchentliches Teammeeting genügt in normal organisierter Arbeitsumgebung völlig und in kritischen Projekten hat man eh die tägliche Feedbackschleife
Scrum ist eine Plattform für Poser und Selbstdarsteller (endloßes Drecksgelaber beim Daily Scrum, die waren Probleme werden nicht angesprochen da Scrum ja Idealogie ist und nicht kritisiert werden darf, sonst fliegt man raus.) Entwickler die über jahrelange Erfahrung verfügen und einfach nur ihren Job machen wollen und deren Leistung immer zur vollsten Kundenzufriedenheit war sind plötzlich ’nicht mehr kommunikativ genug‘.
In meinen bisherigen Scrum-Projekten war Scrum ein anderes Wort für Chaos.
Scrum geht von einem idealisierten Menschenbild aus, nämlich dem eines Entwicklerteams in einem Startup, d.h. alle beteiligten Entwickler sind Firmengründer und mit ihrem Kapital dabei und entsprechend motiviert. Scrum ist nichts anderes als der Versuch diese Haltung von Angestellten einzufordern bei denen die Situation keineswegs die eines beteiligten Unternehmensgründers ist.
Scrum ist Verantwortungskommunismus: Verantwortung kann niemals an einem Team, sondern immer nur an Einzelpersonen (mit entsprechenden Befugnissen) aufgehängt werden. Wenn man eine Gruppe für etwas verantwortlich macht, so ist hinterher niemand für nichts verantwortlich…
Scrum ist nichts anderes als ein Hype der momentan durch die Branche getrieben wird…
Scrum wird vom Management politisch misbraucht um zu reorganisieren und z.B. die Belegschaft zu verjüngen.
Scrum ist eine prima Methode um mal richtig durchzuholzen und aufzuräumen. Hat man z.B. einen Architekten oder Teamleiter der nicht spurt so ist dieser mit Scrum ruckzuck zum normalen Entwickler degradiert.
Mit Scrum kann man prima funktionierende Strukturen aufbrechen und durch Initialchaos ersetzen – mit der Erwartung dass aus der Ursuppe intelligentes Leben entsteht – wenn man nur genug Spannung anlegt.
Scrum hat mit Professionalität nichts zu tun …
SCRUM ist aus SW-technischer Sicht eine Operationalisierung des von IBM vor vielen Jahren aus der Sicht des prozessorientierten Software-Qualitätsmanagements aufgesetzten RUP – Rational Unified Process.
Aus meiner Sicht wäre mal spannend, die techno-soziale Dimension genauer zu diskutieren, die etwa im Aufsatz http://www.ibm.com/developerworks/rational/library/feb05/krebs von Joe Krebs, Senior IT Specialist, IBM Rational bereits 2005, also deutlich vor dem Hype, aufgemacht wird.
Stefan, Sebastian? Gibt es euch noch? Mich würde brennend eure Reaktion auf den Post von XF (23.08.2011, 05:37 Uhr) interessieren.
@Anja: Ich wollte XF nicht kommentieren, weil es sich um eine Beschreibung seiner/ihrer Erfahrungen handelt inkl. der Schlüsse daraus. Ganz anders sind z.B. die Erfahrungen von Sebastian.
Mein Schluss daraus ist: Scrum ist eine Methode, mehr nicht. Allerdings eine Methode, die in die Zeit passt weil sie sich im Spannungsfeld von Selbstentfaltung und Selbstverwertung bewegt. Sie kann instrumentalisiert werden und Chaos erzeugen (XF) oder genutzt werden, um tatsächlich unglaublich schnelle und innovative Prozesse zu ermöglichen (Beispiel: Wikispeed). Tendenziell passt Scrum viel besser auf Freie Entwicklungen und Projekte als auf proprietäre Entwicklungen und Unternehmen, wo du letztlich für einen fremden Zweck und nicht deine produktiven Bedürfnisse arbeitest.
@Stefan
Scrum ist eine M a n a g e m e n t – Methode, hierarchische Arbeitsbeziehungen sind da vorausgesetzt. SoftwareentwicklerInnen sehen das oft nicht und denken nur an fachlich angemessene Vorgehensweisen (zur Erstellung guter Software). Managern geht es darum, wie mit Softwareentwicklung Profit gemacht werden kann (möglichst plan- und berechenbar), das ist etwas ganz anderes. Scrum ist daher nicht in wirklich selbst organisierten Projekten anwendbar.
@mustkass: Management ist das Organisieren von Prozessen. Das hat nicht notwendig mit der Verwertungslogik, Profit machen usw. zu tun. Management gibt es auch in freien Projekten, nur wird es dort anders genannt (Maintainer, Paket-Verantwortlicher etc.).
Allerdings, und das hatte ich im Artikel genannt, gibt es Aspekte in solchen Methoden, die genau die Verwertungsfunktion vorsehen (Produkt-Owner bei Scrum). In Unternehmen kommt das voll zur Geltung, in freien Projekten nicht. Ich sehe keinen Grund, Scrum nicht auch in freien Projekten zu adaptieren und zu nutzen. Entscheidend ist, dass sich das Projekt insgesamt dafür entscheidet (wg. der Freiwilligkeit der Mitarbeit ist das aber ohnehin default).
Wenn du das anders siehst, würden mich Details interessieren. Hierarchien als solche finde ich noch keinen Grund.
Anfrage von Anja (11.06.2012, 13:45 Uhr) bzgl. Post von XF (23.08.2011, 05:37 Uhr) .Hallo Anja,habe tatsächlich sehr lang nicht mehr bei diesem Blog vorbeigeschaut aber jetzt Deine Anfrage gelesen. Da möchte ich doch gern auf den Blog-Kommentar antworten.XF – da hast Du eine Menge schlechte Erfahrungen mit Scrum gemacht.
Und die Zahl, dass 80% der Scrum-Implementierungen nicht funktionieren stützt Deine Erfahrungen.
Aus eigener Praxiserfahrung – jetzt mittlerweile 4 Jahre mit verschiedenen Scrum-Teams und in einem stark wachsenden Umfeld, als Scrum Master, Team Lead und 13 Jahren Senior Software Developer kann ich Deine Erfahrungen nicht teilen.
Scrum ist eine Methode, die hilft ein Team zu professionalisieren und die wahre Stärke von Teamarbeit zu zeigen. Der Scrum Master hat dabei als ein wichtiges Ziel, ein Team auf dem Weg zu einem hoch performanten Team zu begleiten.
Er dient dabei als Vermittler und Impediment-Löser zwischen Team, Management und Product Owner.
Wenn das Management Dinge wie Planung, Ressourcenmanagement,… auf das Team abwälzen will (dabei spreche ich nicht von der taktischen Ebene im Sprint), dann muss der Scrum Master eingreifen.
Für einen Sprint organisiert sich das Team selbst, übernimmt Verantwortung für sein Commitment (die Anzahl der Stories, auf die sich das Team committed) und beachtet dabei, wer im Sprint im Team dabei ist. Das ist aus meiner Sicht sehr sinnvoll, da dann das Team direkt entscheiden kann, auf was es sich committen kann (wenn z.B. jemand im Urlaub ist,…)
Strategisch – Releaseplanung ist Ebene des Product-Owners bzw. Produkt-Managers. Er hat Kennzahlen vom Team bzgl. bereits durchgeführten Sprints, mit denen er Abschätzungen vornehmen kann. Erkennt er dabei Engpässe, ist das Management gefragt.
Agile Grundprinzipien (aus XP) gehen davon aus, das kreative Arbeit über 8h am Tag nicht sinnvoll möglich ist und stellen sich bewusst gegen Überstunden und Ausbrennen im Team – da das langfristig nichts bringt.
Auch hier ist wieder der Scrum Master und Product Owner gefragt, dass zu erkennen und zu verhindern.
Zusätzlich kann das Team in Retrospektiven auf entsprechend notwendige Veränderungen hinarbeiten. Das ist dann auch wieder Aufgabe des Scrum Masters das Problem zu lösen (oft durch Delegation an das Management)
Wie sich die Rolle des Managements im agilen Umfeld deutlich verändert ist sehr gut in Management 3.0 von Jurgen Appelo beschrieben.
Scrum bringt nicht nur Unruhe ins Team, es bringt Unruhe in das ganze Unternehmen, da es massiv Transparenz erzeugt. Oft wird das für Scrum zum Verhängnis – aber eigentlich sind die Problem ganz woanders.
Bzgl. der Poser im Team,… – das ist ebenfalls eine Teamentwicklungs-Frage. Hier muss der Scrum Master und ggf. das Management methodisch sinnvoll Vorgehen und entsprechend durch Veränderung entstehende Ängste adressieren.
Hier gibt es mittlerweile sehr gute Scrum Change Manager Trainings (z.B. von Boris Gloger), die zeigen, wie wertschätzend Veränderungen durchgeführt werden können.
Mich hat das Buch – „Gewaltfreie Kommunikation“ sehr inspiriert – es fördert das laterale Führen eines Teams.
Aus meiner Sicht zählt in Scrum Teams das Team und wie alle Teammitglieder sich im Team einbringen können.
Es dauert einige Sprints bis sich ein Team mit Selbstorganisation angefreundet hat.
Es werden sicher die Team-Entwicklungsphasen wieder durchlaufen … das ist aber auch notwendig, da jetzt nicht mehr die Stellung im Team diktiert sondern ausgearbeitet werden muss.
Aus meiner Sicht zählen dabei deutlich die Erfahrung jedes Einzelnen und was er/sie im Team beisteuern kann. Ich favorisiere eine natürliche Führung – der, der bei einer Aufgabe am besten helfen kann, kann die Führung übernehmen.
Titel schützen nicht … das finde ich persönlich aber auch gut, denn dann wird die indirekte Kommunikation darüber aufgelöst.
Normalerweise bringt ein Titel (Doktorgrad, …) deutlich stärkere Problemlösungskompetenz mit, was dann wieder dazu führt, dass diese Person eine Führungsrolle übernimmt.
Das Ellenbogen im Team zählt, kann ich nicht bestätigen.
Wenn eine Retrospektive mit Vertrauen aufgebaut ist und der Scrum Master seine Aufgabe richtig macht, werden solche Themen angesprochen.
Mit Ellenbogen kann sich das ganze Team nicht weiterentwickeln … ein deutliches Impediment, dass sich beim Beobachten vom Team vielfältig zeigt.
Z.B. durch genaues Beobachten der Kommunikationswege, wie wird in Pairs programmiert, wie werden Reviews durchgeführt, wie oft wird der Build gebrochen, Steuerung von Redezeiten in Meetings,… es gibt da wirklich sehr viele Möglichkeiten lateral steuernd einzugreifen.
Haltung einfordern – das stimmt … in Scrum ist die Teamarbeit entscheidend. Wer nicht in einem Team arbeiten will und kann, bekommt mit Scrum Probleme.
Es zeigt sich heute aber immer mehr, dass komplexe Aufgaben von Teams gelöst werden sollten.
Entsprechend ist dass dann eine Management-Entscheidung, wie hier weitergegangen wird.
Jemanden in ein Team zu zwingen bringt nichts.
Ich würde aber einige Gespräche führen,um genau zu verstehen, was evtl. Bedürfnisse und Ängste sind. Aus meiner Sicht ist das Gegen Teamarbeit eher ein Symptom – Ursachen zu finden kann hier helfen.
Evtl. kann auch eine andere Position gefunden werden.
Wenn sich das Management für Scrum entscheidet, dann müssen sich evtl. auch Wege trennen. Klingt hart – aber bei Veränderungen müssen Entscheidungen getroffen werden und es gelingt nicht immer, alle von einer neuen Strategie zu Überzeugen.
Scrum als Verantwortungs-Kommunismus und Verantwortung kann nicht an ein Team übergeben werden?
Das habe ich ebenfalls ganz anders erlebt.
Einmal mit einem wirklich committeten Team gearbeitet zu haben, zeigt, wie ein ganzes Team Verantwortung übernehmen kann.
Auch hier hilft die Analogie zu Sport – wenn ein Team verliert, dass ist es nicht sinnvoll einen Einzelnen dafür fertig zu machen … ein Team gewinnt, wenn alle Verantwortung übernehmen.
Es gibt in Scrum verschiedene Ebenen mit unterschiedlichen Verantwortungsbereichen:
* Das Team übernimmt die Verantwortung auf der taktischen Ebene – für das Commitment im Sprint und dafür, dem Produkt-Owner bei Entscheidungen bzgl. des Produktes einzubeziehen, dafür den nächsten Sprint mit vorzubereiten und Qualität gemäß der Definition of Done zu liefern.
* Der Produkt Owner nimmt die Verantwortung das Backlog zu pflegen, die Priorisierung einzufordern und den Abgleich mit den Kunden durchzuführen.
* Das Management hält dem Team den Rücken frei und ermöglich das selbst-organisierte Arbeiten.
Aus meiner Sicht ist Scrum hoch professionell:
* es setzt hohe Anforderungen an Teamarbeit und Teamentwicklung
* kombiniert mit agilen Entwicklungspraktiken und einem hochperformantem Team ist es bzgl. der Produktivität wahrscheinlich nicht zu schlagen
* wie im Buch Tribal Leadership und in Management 3.0 beschrieben – ist Scrum eine Möglichkeit ein Unternehmen in ein WIR-Unternehmen zu führen.
SCRUM ist sehr wohl Ursache von Problemen.
Collective Code Ownership und Time-Boxing.
Nach 6 SCRUM Projekten in den vergangenen 7 Jahren, habe ich festgestellt, dass Entwickler die beiden oben genannten Praktiken am wenigsten moegen. Daher auch die hohe Failure-Rate von 80% von SCRUM.Unglueckcliher Weise vertraegt SCRUM keine Kritik, und dann heisst es, wenn die Methodologie nicht funktioniert, sind die Entwickler dran schuld.
Dem ist aber nicht so. SCRUM ist offensichtlich nicht gut, da die Erfolgsrate bei gerade mal 20% liegt. Es ist auch die einzige Methodologie die bis heute noch nicht wissenschaftlich anerkannt worden ist.
Wir sind dann auf Kanban umgestiegen, es wird jetzt nicht nach fixed time geliefert, sondern wenn es fertiggestellt worden ist (enormer Gewinn des Vertrauens beim Kunden, dass mit SCRUM floeten ging durch hohe Defect Anzahl). Ausserdem haben wir Komponenten Teams und klare Komponenten Leads, die die Verantwortung tragen.
Man kann auch sagen wir haben einfach 2 good practices versus SCRUM eingesetzt:
– Gut Ding will Weile haben vs Time-Boxing
– Zu viele Koeche verderben den Brei vs Collective Code Ownership
aka Commons Sense > Hype
Seit dem ist die Atmosphere auch wieder auf einem guten Niveau.
mfgEC35.
Es ist wie im Fussball: Eine gute Mannschaft gewinnt auch unter einem schlechten Trainer, eine schlechte Mannschaft verliert trotz gutem Trainers. Deshalb ist Scrum m.M. völlig überschätzt, da letztlich die individuelle und sozialle Qualität der Entwicklungsmannschaft über den Erfolg eines Projektes entscheiden.
Es ist vergleichsweise unerheblich mit welcher Methodik „gemanaged“ wird, solange die Methodik nicht die Leute bei der Arbeit behindert (aber auch dann wird ein gutes Team erfolgreich sein [z.B. durch unterlaufen des Managements]).
Ich stoße erst jetzt auf diese Diskussion, finde aber spannend, dass hier der Akzent hauptsächlich auf der Binnendynamik eines Teams liegt — als könne man diese so verändern, dass etwas herauskommt, was einen nicht mehr direkt an Formen entfremdeter Arbeit erinnert.
Ich bevorzuge in der Diskussion von Scrum und anderen Formen des agilen Managements den Gedanken, den Herbert A. Simon vor vielen Jahren in die Diskussion eingebracht hat (The Architecture of Complexity, 1962): Wie wäre es, wenn man Hierarchie mal nicht als Oben/Unten-, sondern als Innen/Außen-Rangordnung läse? Es würde sich noch immer um eine Hierarchie, nämlich um eine Rangordnung von Prioritäten, handeln, hätte aber nichts mit unserem klassischen Verständnis von Hierarchie zu tun. Meines Erachtens sind agile Managementmethoden eine späte Umsetzung dieser Idee von Simon.
Auf meinem Blog habe ich das mal ausgearbeitet (link). Danach folgt die agile Managementmethode strikt dem Prinzip: Nichts ohne Auftrag. Viel Unfug resultiert in der Umsetzung agiler Managementmethoden in der Industrie nicht nur daraus, dass man sie dort einsetzt, wo sie nichts zu suchen haben (in der Standardmassenproduktion), sondern vor allem daraus, dass man diesen Auftrag mit der uneingeschränkten Erfüllung von Kundenwünschen gleichsetzt. Tatsächlich jedoch arbeitet das Team nicht nur an der Umsetzung des Auftrags, sondern auch an seiner Interpretation sowohl durch das Team als auch durch den Auftraggeber. Der Auftraggeber lernt, welchen Auftrag er (zu welchen Preisen) vergeben kann. Und das Team lernt, wie der Auftrag (mit welchem Gewinn) erfüllt werden kann.
Der Rest scheint mir in der Tat ein Prozess der Rückkopplung zwischen Innen und Außen zu sein, dessen Ungewissheit *und* Dynamik die „Begeisterung“ auslösen, die vielfach in echten agilen Teams berichtet wird. Wenn Simon Recht hat, stehen wir mitten in einem höchst spannenden Prozess der Neuerfindung der Organisation als Netzwerkorganisation (von der ja viele andere bereits berichten, nicht zuletzt Walter Powell schon 1990). Deren Prinzip ist die Hierarchie, verstanden als Heterarchie (von Foerster 1984).
PS: Produktionseinheiten, die die Innen/Außen-Differenz gegenüber der Oben/Unten-Differenz priorisieren, heißen bei Stefan Meretz zurecht Produktionsfraktale…
Ich finde, Scrum ist das methodische Abwälzen von Führungsarbeit auf die (eigentlich) ausführenden Kräfte. Der scrum master soll nur noch für das richtige Ambiente sorgen, in dem dann das interdisziplinäre Projektteam sich selbst verwalten soll. Allerdings vom Gehalt der Führungsebene wird nichts abgewälzt. Im Grunde ist es ein schön verpacktes System der innerbetrieblichen Ausbeutung.
Warum soll die klassische Frage eines Geschäftsmodelldenkens – how to capture value – nicht auch für die strategische Gestaltung von Variablen der Personalführung gelten?
Na, also @Heini, das kann so sein, muss aber nicht. Ich arbeite nach scrum und verdiene gut damit. Ich übernehme dafür das für mich angemessene Maß an Verantwortung, ohne dafür einen expliziten Platz in der Hierarchie einnehmen zu müssen. Seit meinem ersten Post von 2009 sind ein paar Jahre vergangen, in denen ich mehr Erfahrung mit Scrum gesammelt habe. Für mich passt das gut, die Last verteilt sich im Team gleichmäßig auf alle Schultern und von außen ist man immer daran interessiert, das Team nicht zu überlasten. Man hört auf uns und gibt uns Freiräume. Mag sein, dass das ein Sonderfall ist, aber immerhin ein Präzedenzfall, bei dem keine Ausbeutung zu Lasten der Entwickler stattfindet und der zeigt, dass es geht. Am Ende produzieren wir ohne besondere Last ganz gute Software und damit sind dann alle zufrieden.