Es ist unfassbar. In letzter Zeit ertappe ich mich ungewohnt oft dabei, wie ich vor dem Bildschirm die Hände über den Kopf schlage, seufze und mir selbst zuflüstere “Ich verstehe das nicht”. So geschehen gestern Abend, als ich den offenen Brief von Boris Gloger zu den 7 Thesen der Scrum/Agile-Schwachpunkte von Uncle Bob gelesen habe. Beim Lesen dieses “offenen Briefes” konnte ich meinen Augen kaum trauen. Die Argumente und Antworten von Boris Gloger sind für mich einfach unglaublich. Nicht nur, weil ich die Kritikpunkte von Uncle Bob größtenteils verstehe. Ich möchte meine Auffassung und Wahrnemung zu diesem Artikel hier widergeben.
Antwort zu: Scrum kennt keine technischen Verfahren
Boris Gloger schreibt: “Scrums primärer Zweck war und ist, Teams, Abteilungen und Firmen zu unterstützen, mit den Prinzipien von eigenständigen Arbeitsteams ihre Aufgaben zu bewältigen. Es war niemals geplant, Entwicklern beizubringen, wie man entwickelt. Wenn man Scrum implementiert, dann erkennt man schnell, dass die Entwickler nicht mit der Arbeitsweise von Agile vertraut sind.”
Ich habe Scrum als agiles Software-Management-Framework kennengelernt. Spezifisch für die Domäne der Software-Entwicklung. Scrum ist kein Selbstorganisatios-Framework. Nicht umsonst ist Scrum ein Vertreter der agilen Software-Entwicklungs-Verfahren, und nicht ein “Autonomie-Team-Modell”. Insofern kann man einem agilen Software-Management-Verfahren schon abverlangen, die Software-Entwicklung als Domäne zu unterstützen und zu fördern.
Antwort zu: Scrum hat zu lange Sprints
Boris Gloger schreibt: “Es wurde NIEMALS ausdrücklich gesagt, dass ein Sprint 30 Tage lang sein muss, sondern es war nur als Vorschlag gemeint. Ken und Jeff machten vor 15 Jahren mit den 30 Tagen große Fortschritte. Nicht mehr und nicht weniger. Sprints sollten so lange sein, wie es das Team und der PO für nötig halten und 2 Wochen werden oftmals vorgeschlagen. Allerdings verkompliziert sich dadurch die Sache für die meisten Entwickler.”
Das schöne an agilen Verfahren ist das Inspect & Adapt. Wenn etwas nicht mehr zeitgemäß ist, oder vielleicht nicht in den Kontext hineinpasst, dann wird es eben verändert. So auch mit der Sprintdauer. Für mich ist es offensichtlich, dass kürzere Sprints deutliche Vorteile bieten – auch bzw. gerade für Entwickler. Eine “Verkomplizierung” sehe ich da nicht.
Antwort zu: ScrumMaster aka Projektmanager
Boris Gloger schreibt: “Der ScrumMaster ist eine neue Führungsrolle. Ken hat dies vor Jahren geschrieben und für die ersten Scrum Experten, wie mich, war dies klar verständlich. Jedoch wollte dies die gesamte Agile Gemeinschaft nicht anerkennen, da es ihrem Verständnis nach nicht nötig war, dass Teams eine Führungskraft benötigen und Scrum eine neue Führungsrolle einnimmt. Ein ScrumMaster ist weder ein PM, noch ein Master des Teams. Er ist der Master innerhalb des Bezugssystems des Prozesses. Er ist der Leiter des Teams und der PO und es ist seine Aufgabe, die Organisation mittels Scrum zu verändern und Scrum als ein Paket von Tools und Grundwerten einzusetzen.”
Mit Nichten. Ich habe in meinen bescheidenen paar Jahren, in denen ich mich Scrum auseinandergesetzt habe und immer noch intensiv beschäftige den ScrumMaster niemals als Führungsrolle verstanden. Ja, es gibt das Prinzip des Servant Leaderships für einen ScrumMaster. Ja, der ScrumMaster ist der Hüter des Scrum-Grals. Ja, der ScrumMaster ist ein Change Agent. Aber Nein, der ScrumMaster ist kein Team-Leiter. Nein, es gibt keine Position “ScrumMaster” in einem Organigramm, sondern die Rolle ScrumMaster. Nein, der ScrumMaster ist kein Entwicklungs-Alpha-Tier.
Antwort zu: ScrumMaster ist kein Leader
Boris Gloger schreibt: “Ein Entwickler hat nicht die Fähigkeiten ein Team zu leiten, eine Organisation zu ändern und sein Team vor der herkömmlichen Organisationskultur zu beschützen. In dieser Hinsicht wird die Rolle des ScrumMasters großteils missverstanden. Er ist ein Moderator, aber das ist Teil seiner Führungsrolle als ScrumMaster. Ein ScrumMaster zu sein, das bedeutet, sich ein Set and Fähigkeiten anzueignen, die erlernt und geübt werden müssen. Dies kann 10000 Stunden in Anspruch nehmen, bevor man davon ausgehen kann, dass man diese Disziplin auch beherrscht.”
Mit Verlaub, Herr Gloger, das geht zu weit. Es tut mir leid Ihnen entgegnen zu müssen, dass Ihre Auffassung für mich nichts anderes als protektionistischer Mumpitz ist! Sie haben gerade die Entwickler, also mich, meine Kollegen und meine gesamte Berufszunft gekränkt. Was fällt Ihnen ein, sich so herablassend über einen Entwickler und seine Fähigkeiten zu äußern? Zugegeben, nicht jeder Entwickler hat das Zeug zum Teamleiter. Nicht jeder Entwickler kann sich eloquent und zielsicher vor Führungsriege oder Investoren artikulieren.
Doch das heisst noch lange nicht, dass alle Entwickler per se nicht geeignet sind, die Rolle des ScrumMasters zu übernehmen. Sie tun mit Ihrer Aussage den vielen Entwicklern da draussen Unrecht, die tagtäglich lernen, die versuchen ihre Entwicklung und ihre Organisation zu verbessern, die ihre Teams und Kollegen leiten. Ja genau, die Entwickler, die sogar auf Kurse von ScrumCoaches wie Ihnen gehen, um das System Scrum sowie die Rolle ScrumMaster zu verstehen und sich dafür zu zertifizieren.
Ihr Verständnis des ScrumMasters als “allwissende, allmächtige” Instanz kann ich nicht teilen. Sie beschreiben den ScrumMaster ja geradezu als den Robin Hood der Scrum-Gemeinde, der sich für die armen bekehrten Entwickler einsetzt und sich mutig und stark vor die etablierte, elitäre Wasserfall-Adelschaft stellt. Nein, Herr Gloger. Sowohl die klassische als auch moderne Software-Entwicklung ist erfolgreich mit Teamgeist, dem verständnisvollen & respektvollen Umgang miteinander und dem gemeinsamen Verständnis für das Ziel. Allesamt Eigenschaften, die ich in Ihrer Aussage kläglich vermisse.
Antwort zu: Mangelhafte Struktur des Backlogs
Boris Gloger schreibt: “Mike Cohn hat uns das beigebracht und ich habe es in meinem Buch beschrieben. Scrum war nicht als ein Set von Tools geplant, das alles beschreiben kann. Der Backlog ist sehr unternehmens-/team-/produktspezifisch und Scrum kann in dieser Hinsicht keine Anleitungen liefern. Nur Best Practises können das.”
Richtig. Zumindest was die Strukturierung des Backlogs angeht, bin ich der Meinung dass dies sehr stark von Projekt zu Projekt variieren kann. Genau hier ist es gut, eine allgemeine, flexible Aussage zu liefern, die da heißt: Es muss ein Backlog geben. Wie das dann aussieht, bleibt im Ermessen der Projektbeteiligten, spezifischer des PO’s und des Teams. Es ist etwas ganz anderes, ein Backlog für ein Webportal aufzubauen als ein Backlog für ein kritisches Leitsystem. Best Practices können da einen guten Leitfaden darstellen.
Antwort zu: Scrum skaliert nicht
Boris Gloger schreibt: “Ich kann euch versichern, dass Scrum auch auf Ebenen oberhalb eines Teams erwiesenermaßen angewendet werden kann. Ich habe dies hunderte Male erfolgreich durchgeführt. Scrum Anwender wie ich haben Möglichkeiten entwickelt, Scrum in Organisationen einzusetzen, genauso wie auf Unternehmensebene. Gut, es wurde nicht in Ken’s erstem Buch beschrieben und viele Scrum Consultants haben keine Ahnung, wie das gemacht werden kann. Wenn ihr euch allerdings an Leute wendet, die Scrum seit 2003 einsetzen und Scrum auf Unternehmensebene angewandt haben, dann könnt ihr erfahren, wie das geht. Zu diesen Leuten gehören: Bas Voode, Mike Cohn, Stacia Broderick, Boris Gloger, Andreas Schliep, und viele mehr. Wie gesagt, man kann dazu nichts in den frühen Büchern finden, sondern in den Köpfen der Leute, die das bereits mehrmals gemacht haben.”
Eine für mein Dafürhalten argumentativ etwas schwachbrüstige Aussage. Mit irgendwelchen Mitteln, ein paar “Scrum Of Scrums”, einem Company Backlog und ein paar Chief Product Owners ist die Skalierungsaufgabe “Scrum” noch lange nicht gelöst. Wenn es funktioniert, ist es gut. Doch die Aussage bezieht sich auf Scrum als Rahmen- und Richtwerk. Dort ist von Skalierung nicht die Rede. Man muss auch mal zugeben können das Scrum einfach nicht für größere Konstrukte “designed” wurde.
Embrace Change!
Alles in Allem interpretiere ich den offenen Brief mit kritischen Augen. Irgendwie kommt es mir so vor, als ob sich in dem Brief das “Ministerium für Scrum” gemeldet hat und ein paar Statements in den Raum wirft, um Scrum als System sowie auch das Ministerium selbst zu schützen. Scrum ist unbestritten ein hilfreiches agiles Management-Werkzeug. Scrum hat in der agilen Bewegung auch zweifelsohne große Beiträge geleistet. Dennoch ist dies kein Grund, konstruktiver Kritik mit derartig pauschalisierten Floskeln zu entgegnen.
Ich glaube an die Vorteile von Scrum, erkenne aber auch Gefahren und Schwachstellen. Alles hat seine Vor- und Nachteile. Wichtig ist für mich der “Agile Spirit”, der im agilen Manifest und vielen agilen Best Practices verankert ist. Inspect & Adapt, Embrace Change, People over Processes, Collaborate. All das sind die essentiellen Werte agiler Software-Entwicklung – und auch von Scrum.
byDominik JungowskionMarch 29th 2010Also ich habe es noch nie so empfunden, dass sie ihn als “Magic Master” empfinden, sondern eher dass er ein Zahnrad des ganzen Uhrwerks ist.
Natürlich gibt es immer einen Unterschied zwischen Theorie und Realität, das brauchst du mir nicht zu erzählen
Ändert aber nichts daran, dass das Konstrukt mit dem ScrumMaster meiner Meinung nach von der Theorie her ein recht gutes und solides ist.
Was das Inspect & Adapt angeht: Mag sein, dass er das tut, so hab ich das ganze aber verstanden. Man macht dann halt nicht mehr Scrum-by-the-book, aber sollte man zum Beispiel (warum auch immer feststellen), dass einen der ScrumMaster eher behindert als hilft, warum sollte man ihn dann behalten?
byIlker CetinkayaonMarch 27th 2010Dominik, echt mal vielen Dank für den Input. Ich werde sicherlich noch länger darüber nachdenken. Dennoch ganz kurz ein paar Kleinigkeiten.
Das Multiaufgaben-Beispiel (Prozessmanager, Projektmanager usw usf) ist nicht eine Andeutung auf Ineffizienz bzgl. mehrerer Rollen, sondern eine Andeutung das ScrumMaster != Prozessmanager != ProjektManager != Teamlead != CTO != Besserwisser-Kasperle ist. ScrumMaster ist eine (verantwortungsvolle) Rolle. Aber kein “Magic Master”. Boris und andere beschreiben den ScrumMaster immer als den Copperfield des Software-Engineerings. Das ist geradezu lächerlich.
Zu Deinem “Inspect & Adapt” und “dann kickt man halt den SM weg!” Beispiel: Haha, sag’ das mal dem Boris! Der kickt dich!
Und zu ScrumMaster is Full-Time: Na also bitte, die 10 Punkte von Boris sind (diplomatisch ausgedrückt) so stichhaltig und standhaft wie ‘ne Sandburg auf Treibsand. Der SM soll schauen, das alle glücklich sind, er soll herumlaufen, um Probleme aus der Welt zu schaffen, er soll sich um die Weiterbildung des Teams kümmern, er soll schauen das er selber was lernt, er soll Meetings moderieren. Hehe, und dafür soll ein Unternehmen min. 100k p.a. investieren? Das ist mal eine ganz nette und liebe Geldvernichtungsmaschine!
Warum können die Leute die Realität nicht akzeptieren? Realität ist, das ich heute 2 Anrufe nach Asien drücke um 20 Dev’s mit 100k ein Jehr lang zu betanken. Das dabei nichts tolles bei rumkommt, ist mir auch klar. Gerade deswegen sollte *jeder*, der hier in “good old Europe” mit Software-Entwicklung zu tun hat, mal endlich klarkommen und realisieren, dass das alles hier kein Spass ist, sondern etwas mit Ingenieurs-Arbeit und -Kunst zu tun hat.
Denn nur eine sehr effektive und dabei hochqualitative Software-Entwicklung ist ein stichhaltiges Argument für Auftraggeber, Investor oder Unternehmen. Es ist das gute Recht eines Unternehmens, für so viel Geld auch adequate Leistung zu bekommen. Alles andere ist Kinderkram.
byDominik JungowskionMarch 27th 2010Zum Thema ScrumMaster und Vollzeit-Job: http://borisgloger.com/2009/04/21/4711-is-a-scrummaster-a-full-time-position/
Die Probleme, die du mit dem ScrumMaster ansprichst, resultieren meiner Meinung nach unter anderem aus folgendem Grund:
ScrumMaster sind deswegen öfter auch Entwickler oder sonstwer, weil sich ein Team entscheidet Scrum zu machen und anstatt einen bereits trainierten ScrumMaster einzustellen (wahrscheinlich auch aus Budgetgründen), macht es halt einer aus dem Team. Wider besseren Wissens (selber erlebt), will dieser aber zunächst nicht nur ScrumMaster machen, sondern seinen alten Kram auch weiter machen
Weiters schreibst du einerseits, dass ScrumMaster kein Vollzeit-Job ist, andererseits meinst du aber “Wenn ein ScrumMaster in einem Unternehmen wirklich Prozessmanager, Projektmanager, Teamlead und Consultant gleichzeitig ist, dann hat sich dieses Unternehmen schon längst von agiler, effizienter Organisation verabschiedet.”. Das widerspricht sich irgendwo selber, weil du ihm einerseits absprichst nur eine Rolle zu sein, andererseits aber sagst dass es ineffizient ist, wenn er mehr als nur eines ist.
Dein Problem mit dem Beruf ScrumMaster ist vielleicht auch ein stückweit, dass es keine IHK Ausbildung oder dergleichen dazu gibt. Zum Entwickler kann man sich ausbilden lassen, für den ScrumMaster macht man nur ein Zertifikat. Andererseits: Gibt es eine Ausbildung zum Projektmanager?
Das mit der Kompetenz mag ein stückweit stimmen. Ein ScrumMaster hat es sicherlich einfacher, wenn es sich um eine Firma handelt, die gerade erst gegründet wurde und nicht aus alten Strukturen heraus Scrum einführt. Dennoch braucht ein ScrumMaster meiner Meinung nach auch hier Kompetenzen und einen gewissen akzeptierten Stand in der Firma. Wie sonst soll er auftretende Probleme bewältigen?
Natürlich wird ein ScrumMaster direkt nach dem Einführen mehr zu tun haben, als 3-4 Monate später. Geht man aber die 10 Punkte von Boris durch, hat man durchaus genug Beschäftigung für einen Vollzeit-Job, das ist zumindest meine Einschätzung.
Ansonsten sagt ja keiner, dass man unbedingt am Scrum – Prozess festhalten MUSS. Es heisst ja “Inspect & Adapt”. Stellt man für sich fest, dass man keinen ScrumMaster braucht, dann kickt man die Stelle eben, das ist ja das schöne an dem Ganzen. Erfahrungsgemäß sollte man sich aber vor allem Anfangs unbedingt an das Scrum “Korsett” halten, weil man sonst sehr schnell auf die Schnauze fliegt (selber erlebt).
Zum Kochrezept: Dass man nicht kochen kann, bloß weil man ein Kochrezept hat, ist richtig. Schließlich kann ich ja auch nicht programmieren, bloß weil ich nen PC hab, es ist aber eine Grundvoraussetzung! Und wie es der Zufall so will, gibt es für ein Gericht mehrere Kochrezepte. Ich habe also mehrere Möglichkeiten mein Ziel, das Gericht, zu erreichen und habe dafür bessere und schlechtere Kochrezepte. Letztendlich ist das ganze auch irgendwo (tolle Metapher) eine Geschmackssache. Wenn ich Mandeln nicht mag, werd ich auch immerhin keinen Mandeln auf meinen Apfelkuchen streuen, sondern diese eben weglassen, muss aber damit Leben, dass ich zwar ein Rezept für einen Apfel-Mandel-Kuchen habe, aber keinen Apfel-Mandel-Kuchen gebacken habe.
byIlker CetinkayaonMarch 27th 2010@Heiko: Woher die Zweifel kommen? Ich hoffe diese Frage hast Du nicht ernsthaft gestellt. Es ist nicht nur offensichtlich, sondern absolut natürlich, dass eine delegierte bzw. oktroyierte Führung im Allgemeinen auf geringere Akzeptanz und Gefolgschaft stossen wird als eine gemeinschaftlich gewählte & anerkannte.
Wenn ein ScrumMaster in einem Unternehmen wirklich Prozessmanager, Projektmanager, Teamlead und Consultant gleichzeitig ist, dann hat sich dieses Unternehmen schon längst von agiler, effizienter Organisation verabschiedet.
byIlker CetinkayaonMarch 27th 2010@Dominik: Danke erstmal für Deine Meinung und Perspektive. Es hilft mir einiges weiter, das Thema besser zu verstehen.
Doch ist mir unbekannt, wo denn geschieben steht, dass ein ScumMaster ein Vollzeit-Job ist. Genau das Gegenteil ist der Fall. Die guten ScrumMaster, die ich kennengelernt habe, die waren vielleicht 2-3 Sprints wirklich beschäftigt. Danach haben sie auch nicht mehr viel gemacht.
ScrumMaster ist kein Beruf – davon bin ich überzeugt. Es ist genau das, was einen echten ScrumMaster ausmacht. Er ist Entwickler, oder Prdukt Manager, oder Business Analyst, oder Tester, oder Admin. Aber er ist definitiv kein Beruf. Zu Deinem Kompetenzargument kann ich nichts anderes entgegenbrignen als verkrustete Organisationsstrukturen, die so eine “Macht dem ScrumMaster” abverlangen müssten.
Meiner Meinung nach sind ScrumMaster nur dann “mit Kompetenzen ausgestattet”, also Vollzeit-Berufs-Manager für Agile-Management-Methoden, wenn das Unternehmen selbst noch im “klassischen Strukturdenken” gefangen ist. Das ist ein Prozess und kann nicht von einem auf den anderen Tag passieren, das ist klar.
Bezüglich des angeblich negativen Eindrucks, welches ich von ScrumMastern hätte, darf ich Dir sagen, dass ich wirklich gute ScrumMaster kenne und ich keinesfalls einen negativen Eindruck habe. Ich vermische da auch nicht Person mit Rolle.
Meine negative Einstellung kommt von all diesen Scrum-Kennern und Scrum-Practitionern und Scrum-Experten und Scrum-Coaches und Scrum-Managern, die glauben, dass ein erfolgreiches, effektives und produktives Team einen festen “Leader”, “Manager”, “Problembeseitiger” braucht.
Genau diese Experten sind es nämlich, die noch nie wirklich in einem agilen Team und Projekt gearbeitet haben. Hätten sie es denn getan, dann würden sie erkennen, das Emergenz niemals durch delegatives, kooperatives, oder partizipatives Management erreicht werden kann – zumindest nicht im streng operativen Bereich, also dort, wo Scrum wirken soll.
Am liebsten würde ich die Scrum-Coaches da draussen mal fragen, ob sie überhaupt in einem agilen Projekt jemals eine andere Rolle ausser “Besserwisser” übernommen haben. Ist das negativ genug ?
Zu dem letzten Punkt “Scrum sagt dem Entwickler nicht wie er entwicklen soll”: Das will ich nicht. Ich habe auch nie gesagt, das ich will, das ein Management-Framework sagen soll, wie man entwickelt. Impliziere also bitte keine Falschaussagen. Ich meine, dass Scrum es sich als agiles Software-Management-Framework nicht so leicht machen kann mit der Aussage “Ich mache Management, keine Software”. Das ist verzerrt. Es geht nicht primär um’s Management, sondern um die Software. (Beachte: Ich sage hier explizit nicht “Projekt”, sondern “Software”).
Im Übrigen finde ich die Metapher mit dem Kochrezept gelungen. Ich hätte es kaum besser beschreiben können. So eine ähnliche Metapher versucht übrigens Boris mit seinem Scrum-Cooking auch zu transportieren. Nichtsdestotrotz kann ich hier nur entgegnen: Ein Kochrezept ist zum Kochen da. Nur weil man ein Kochrezept hat, heisst das noch lange nicht, dass man kochen kann. Man kann alles auf dem Rezept machen – und es wird trotzdem nichts. Ergo: Mit einem Kochrezept wird man kein Koch. Mehr noch: Mit einem Kochrezept kann man kein Restaurant betreiben.
byDominik JungowskionMarch 27th 2010Da ein ScrumMaster seine Arbeit im besten Fall Vollzeit machen sollte, sehe ich keinen Grund, weshalb es nur eine Rolle und kein Beruf sein sollte. Den ScrumMaster nicht als Beruf anzuerkennen, ist meiner Meinung nach ein großer Fehler, den du machst.
Dadurch, dass du ihm den Berufsstatus aberkennst, gestehst du ihm auch weniger Kompetenzen zu, als er tatsächlich braucht. Da ein ScrumMaster nicht nur dafür sorgt, dass die Scrum Regeln eingehalten werden, sondern auch die Probleme des Teams löst, BRAUCHT er diese Kompetenzen sogar.
Ansonsten kriegt man bei dir das Gefühl, dass du der festen Überzeugung bist, ein ScrumMaster sei bei allen unbeliebt. Das ist falsch. Es ist deswegen falsch, weil ein ScrumMaster auch so beliebt ist, wie die Person selber. Der ScrumMaster löst unter anderem die Probleme des Teams, das können mitunter Probleme sein, die die Firmenstruktur an sich betreffen. Dass ein ScrumMaster, der nach der Holzhammer Methode arbeitet weniger beliebt sein wird, als einer, der das ganze konstruktiv im Dialog mit den in der Firma betreffenenden Personen angeht, ist nur verständlich.
Vielleicht hast du bisher nur solche Holzhammer-ScrumMaster kennen gelernt oder ihr habt gar keinen? Ich weiss es nicht, von irgendwo muss deine negative Einstellung auf jeden Fall herkommen.
Ansonsten verstehe ich auch nicht, warum du unbedingt darauf pochst, dass Scrum dem Entwickler sagen MUSS, wie er zu entwickeln hat. Bei Scrum handelt es sich um Agiles Projektmanagement, welches Projektmanagement sagt dem Entwickler denn bitte, wie er zu arbeiten hat? Du kannst dir das ganze wie ein Kochrezept vorstellen: Es steht zwar drin, was du machen musst, z.B. Kartoffeln schälen, aber ob du die Kartoffeln jetzt mit einem Schälmesser oder einem normalen Messer schälst, bleibt völlig dir überlassen. Das Wichtige an dieser Stelle ist, dass dir das Kochrezept sagt, DASS du die Kartoffeln schälen musst, um ans Ziel zu gelangen, dir die Ausführung aber selber überlässt.
byHeiko StapfonMarch 24th 2010Woher kommen die Zweifel?
byIlker CetinkayaonMarch 24th 2010Heiko,
Es mag sein, das Boris das nicht so gemeint hat. Dann bitte schön sollte man es aber auch nicht so schreiben. Überdies kann ich Deine Argumentation nachvollziehen. Man möchte nun mal seine Sache richtig machen, dann muss man auch seine Zeit und Leidenschaft hineininvestieren. Das dann andere Dinge zurückgestellt werden müssen, liegt in der Natur der Sache.
Nichtsdestotrotz möchte ich Deine Meinung noch durch meine Perspektive anreichern. Du erwähnst die “Entwickler-Rolle” und die “ScrumMaster-Rolle”. Das sehe ich nicht so. Ein ScrumMaster ist eine Rolle. Als ScrumMaster hat man Aufgaben, Pflichten, & Rechte. Ein Entwickler ist zwar auch eine Rolle, aber darüber hinaus noch viel mehr. Software-Entwickler zu sein ist ein Beruf. Ein Beruf, den Menschen über viele Jahre erlernen müssen/wollen. Ein Beruf mit vielen Facetten und Ausrichtungen. Ein Beruf, in dem viele verschiedene Disziplinen wahrgenommen werden.
Ein ScrumMaster ist meiner Meinung nach kein Beruf. Ein ScrumMaster ist nichts anderes als eine Rolle. Wäre der ScrumMaster per Definition ein Coach (wie z.B. Boris), dann wäre es sicherlich ein Beruf. Dann wäre Boris auch ScrumMaster. Aber Boris ist ScrumCoach, ein Scrum Experte. Das ist meine Perspektive.
Naja, ein wenig nachdenklich machen mich die Kommentare (inkl. Deinem) schon. Vielleicht ist es wirklich so, wie es Boris sagt. Vielleicht ist der ScrumMaster ein neuer Berufszweig. Vielleicht ist der ScrumMaster Prozessmanager, Projektmanager, Teamlead und Consultant gleichzeitig. Dann aber bezweifle ich stark, das es Scrum-Teams geben wird, die Ihre Arbeit Produktiv, Effizient, Gleichwertig, Respektvoll und mit einer dicken Portion Leidenschaft & Spass zum Erfolg bringen werden.
byHeiko StapfonMarch 24th 2010Zum Thema Entwickler und Scrum Master
Ich hab’ Boris nicht so verstanden, dass er den Entwicklern grundsätzlich nicht zutraut Scrum Master zu werden.
Sondern die Aussage ist, dass man die Rolle Scrum Master üben muss und dass man dafür Erfahrung braucht – viel Erfahrung. Ein Entwickler kann sich dazu entscheiden, diese Rolle anzunehmen. Wenn er es richtig gut machen will, dann bedeutet das für ihn, dass er nicht mehr die Zeit hat, sich in seiner Rolle als Entwickler zu verbessern. Er wird über kurz oder lang die Rolle Entwickler weniger weiterentwickeln können, als die Rolle Scrum Master.
So lief es zumindest bei mir. Heute gehe ich nicht mehr auf OOP-Fortbildungen o.ä. sondern ich geh zu Moderationstrainings und mach eine Coachingausbildung. Schon allein aus finanziellen Gründen muss ich mich hier entscheiden
Natürlich könnte ich auch beides tun, aber dann muss ich Abstriche machen, was den Grad der Perfektion angeht, den ich erreichen kann. Und was die Scrum Master Rolle angeht – da möchte ich keine “halbe” Sachen machen 
von einem der mal Entwickler war und heute Scrum “Master” ist
Viele Grüße Heiko
bySebsonMarch 23rd 2010Also wir machen das im Glogerschen Sinne und es hat sich als schlau erwiesen wenn “Allmacht” und “Scrummaster” in verschiedenen Personen stecken. Ein Azubi und einer unserer Entwickler die man als Senior bezeichnen könnte machen das sehr gut. Der SM ist nur eine Schnittstelle, und ja eine verdammt unangenehme. Als Teamleiter muss man halt auch die Eier haben etwas durekt zu deligieren… aka ein anderer machts und man nimmt selbst in Kauf das dann auch zu verantworten Auch wenn es mal nict so ausfällt wie man sich das vorstellt (ask the team)
Laut meinem Gusto ist der beste SM die Person mit den meisten Social Skills denn hier kann viel gut oder schlecht gemacht werden.
Ich finde es ist simpel: Du fängst mit scrum an und musst dann, weil du so hohe anforderungen an dich stellst, die richtigen werkzeuge wählen. Die müssen aber nicht unbedingt TDD, Buildserver und Pairing sein. Ich glaube darauf wollte Boris raus. Das können wir entwickler schon selber lernen und da stimme ich Boris zu: Dazu brauche ich ihn nicht und auch nichtmeinen Scrummaster
byIlker CetinkayaonMarch 23rd 2010@Sebs, naja zerreden würde ich des nicht nennen. Ok, Agile != Scrum – wenn man agiles Management dann von mir aus dann Lean oder was auch immer nennt. Die Nummer mit der mangelnden Technik nehme ich noch – mit ach und krach – auf.
Aber mal ganz im Ernst. Diese Art von ScrumMaster, die Boris da beschreibt, die wünscht sich kein Management, kein Team, keine Organisation: “Oh, mein allmächtiger ScrumMaster, spreche mit mir!” Demnächst gibt’s noch’ne Scrumlampe zum rubbeln bei Impediments. Nein, ganz ehrlich, das ist nicht im Sinne der Produktivitätssteigerung und Effizienz. Dann lieber ein gepeitschtes Kanban oder etwas ganz anderes.
Zu “Es war niemals geplant, Entwicklern beizubringen, wie man entwickelt.” – Ja, da gebe ich Dir recht. Aber anders herum gefragt: was will denn dann Scrum oder irgendein anderes tolles Framework managen? Eine Brauerei? Vielleicht die Bäckereifachverkäuferin von nebenan? Nein sorry, so einfach ist das glaube ich nicht. Klar kann es nicht die Aufgabe von Scrum sein, dem Entwickler das entwickeln beizubringen. Entwickler sind übrigens keine Analphabeten, sondern gebildete und qualifizierte Leute. Wenn man Software mit einer Horde von Script-Kiddies macht, dann macht man sowieso etwas falsch.
Aber zurück zum Thema. Das Einsatzgebiet von Scrum ist explizit die Software-Entwicklung – vielmehr sogar, es wurde dafür maßgeschneidert. Einem solchen Framework kann man zumindest abverlangen, dass es Entwickler unterstützt. Damit meine ich jetzt nicht die ganzen Tools und des XP-Getue,sondern das “Agile Mindset”, die Prinzipien, die Soft-Skills. Diese weichen Dinge eben, die zum Erfolg der ganzen Sache erheblich beitragen.
bySebsonMarch 23rd 2010Hmm
ich finde teilweise zerredest du hier die Argumente einfach.
Ich kann zum groß0en Teil Boris nachvollziehen. Wobei mir wie immer die aktuelle diskussion um irgendwelche neuerungen am Egal vorbeigeht. Wir mischen hier ja über die Entwicklungsteams auch Kanban und Scrum ohne das es Probleme gibt.
Vielleicht hat man bei Big-Bang Nummern wie sie bei euch laufen dann einfach eine andere Draufsicht.
Aber eines kann ich sagen: “Es war niemals geplant, Entwicklern beizubringen, wie man entwickelt”.
Korrekt so!!!! Agile != Scrum.