Fünf Schwachpunkte von Scrum
Die fünf Schwachpunkte von Scrum, in klaren Worten.
- Rahmenwerk, aber kein Werkzeug
- Die Sprintdauer
- Die Planung & Das Design
- Der Scrum Master
- Die Skalierung
Scrum ist ein wunderbares agiles Management-Framework. Ich mag Scrum. Um ehrlich zu sein ist Scrum als “Agile für Einsteiger” ein genauso geeignetes methodisches Rahmenwerk wie für den enthusiastischen Agilisten. Ich habe mittlerweile einige Jahre Scrum-Erfahrung und darf mich ja selbst als “Zertifizierter Scrum Master” bezeichnen. Trotzdem – oder gerade aus dieser Erfahrung heraus – ist Kritik an Scrum meines Erachtens angebracht. Die kritischen Stimmen zu Scrum werden immer deutlicher, allen voran die erst kürzlich von UncleBob aufgestellten 7 Thesen der Mängel von agiler Software-Entwicklung mit XP & Scrum. In diesem Artikel möchte ich dazu meine Sicht der Dinge wiedergeben.
Scrum ist nicht Perfekt. Ganz im Gegenteil. Mit steigender Erfahrung kann man z.T. gravierende Schwachpunkte in der Methodik feststellen. Das soll jetzt nicht heißen, daß Scrum für ein agiles Projekt zu schlecht oder ungeeignet wäre – Nein. Vielmehr sollte man bei der Anwendung von Scrum ein besonderes Augenmerk auf die Schwachpunkte der Methode legen – um so im Ergebnis weniger Stolpersteine auf dem Weg zum Projektziel zu haben.
Rahmenwerk, aber kein Werkzeug
Scrum ist ein Framework. Nicht für Software-Entwicklungs-Methoden, sondern für Projekt-Management. Doch als Framework für die Projekt-Management-Methodik ist Scrum in vielen Teilen zu unspezifisch. Natürlich ist Scrum gerade durch die wenigen Regeln & Rollen leicht verständlich und relativ zügig einsetzbar. Auf der anderen Seite jedoch ist die Eigenschaft von Scrum, eine “leichtgewichtige” Methodik des agilen Projektmanagements zu sein eine schwere Bürde – sei es inhaltlich oder praxisbezogen. Beispiele gefällig?
- Scrum verlangt Dailies am Scrum Board
Scrum sagt aber nicht wie dieses Board denn verwendet werden soll, welches die primären Ziele des Boards sind und welche Mittel & Wege man hat mit dem Board umzugehen. Wie ist das mit dem Sprint Backlog auf dem Board? Wie werden die Stories abgearbeitet? Wie geht man mit Ausnahmen (z.B. Bugs) um? Scrum schlägt bei diesen Themen sehr leise Töne an. - Scrum nennt Product & Sprint Backlogs
Scrum verrät aber nichts über den Aufbau der Einträge der Backlogs. Ein Product-Backlog ist eine “Wunschliste”, ein Sprint-Backlog ist eine “Taskliste”. Pofessionelle Agilisten belächeln mittlerweile die flachen Scrum-Backlogs und deren mangelhafte Vorgaben. - Scrum hat ein Sprint-Planungs-Meeting
“Gut, daß man bei Scrum auch plant” mag es einem in den Sinn kommen. Doch in Scrum konzentriert sich die Planung zumeist auf ein einziges Meeting, in dem der gesamte, meist 4 Wochen lange Sprint und die in dieser Zeit zu erstellenden Features designed & geplant werden. Software-Entwickler mit gesundem Respekt gegenüber der Ingenieurskunst des “Software Engineerings” würden mit großer Wahrscheinlichkeit so eine Vorgehensweise als “unausgereift” bezeichnen.
Die Sprintdauer
Scrum baut auf Mikro-Organisation. Tägliche Einsatzbesprechung, Aufgabenverteilung und Updates. Scrum stützt dadurch Agilität. Anforderungen können sich ändern, unbedachte Situationen können eintreten. Darauf kann Scrum reagieren mit den Sprints, die die Gesamtleistung in viele kleine Schritte zerlegen. Hier, genau bei den Sprints (Iterationen) und deren Dauer ist die Methodik (bzw. die Umsetzung von Scrum) zumeist deutlich mangelhaft.
Wieso? Scrum schlägt eine Sprint-Dauer von 2-4 Wochen vor. Vorzuziehen sei eine kürzere Sprintdauer, maximal sollte sie jedoch 4 Wochen sein. Doch für ein Rahmenwerk, welches sehr stark auf die Mikro-Organisation fokussiert ist, sind 4 Wochen eine lange Zeit. Denn in der Praxis gibt es wenige Scrum-Projekte, die wirklich den 2-Wochen-Takt implementieren. Die Gründe dafür sind vielfältig. Einer der Hauptgründe ist wohl der Schwenk von einer “klassischen” Projektplanung hin zum agilen Management. In so einem Kontext tendiert man lieber zur 4 Wochen Zeitspanne, weil
- man angeblich mehr Zeit zum implementieren hat;
- angeblich alle 2 Wochen ein ganzer Tag Team-Meeting “ineffizient” ist;
- die wenigsten Anforderungen eines Produktes in 2 Wochen einsatzfähig fertiggestellt werden können.
Im Grunde mehr oder minder schwachbrüstige Argumentationen. Als Randnotiz: meine persönliche Ansicht ist bei diesem Thema ist noch fordernder als die der reinen Scrum-Lehre: 2-wöchige Sprints sind gut, Wochen-Sprints noch viel besser.
Lange Sprintzyklen wirken für agile Verfahrensweisen wie eine angezogene Handbremse. Einen 4-Wochen-Sprint in 4 Stunden Sprint-Planungs-Meeting zu planen ist gelinde gesagt tollkühn. Bei langer Sprintdauer ist die Zahl der Stories und Tasks auf dem Board meist unbeherrschbar. Mehr noch, bei 4 Wochen schleichen sich gerne andere, minder relevante Aufgaben wieder auf’s Board.
Die Releasefähigkeit wird stark eingeschränkt und das obere Management durch die langen Sprintzyklen implizit dazu aufgefordert, mehr “Termin-Management” und Koordinationsleistung zu betreiben. Die empirische Messung der Velocity und die Schätzgenauigkeit des Teams ist mit langen Sprints von deutlich geringerem Wert und Aussagekraft als bei (sehr) kurzen Sprints.
Die Planung & Das Design
In den vorangegangenen Punkten ist dieser Makel schon ein wenig angeklungen; Planung & Design in Scrum sind unfassbar – im wahrsten Sinne des Wortes. Wer schon einmal vor der Aufgabe stand, in einem Sprint-Planungs-Meeting mit den anderen dutzende Stories “implementierungsreif” zu planen & zu designen, der kann sich denken, worauf ich hinaus möchte.
Doch vor der Betrachtung und Kritik am “Planungs-Meeting” möchte ich die generell mangelhafte Planungssituation von Scrum nicht unerwähnt lassen. So sucht man in der Scrum-Methodik vergebens unterstützende Merkmale zu adequater Business-Analyse und der anschließenden Anforderungs-Analyse. “Ohh” – wird sich jetzt manch einer denken – “Ist dass denn dann noch agil?”. Antwort dazu: Es wäre für die Vertreter der agilen Software-Entwicklung schlichtweg ein Debakel, wenn eine wichtige Disziplin des Software Engineerings nicht agil betrieben werden könnte.
In der Praxis wird Scrum leichtsinnig und konzeptfrei mit allem möglichen “agilen Zubehör” bepackt. Da gibt es dann User Stories, Planning Poker, Story Points, Estimation Meetings, Business Value Estimations und vieles mehr. Aus Sicht der Prediger der Scrum-Fibel auch durchaus verständlich, schließlich sei “Scrum ja auch nur ein Rahmenwerk” (siehe 1. Schwachpunkt).
Doch zurück zum Thema Planung & Design von Software und Software-Entwicklung. Man mag wieder argumentieren, das habe nichts mit Scrum, dem Management-Rahmenwerk, zu tun. Dies wäre eine fadenscheinige, viel zu oberflächliche Argumentation, denn auch Management-Methoden sollten die Problemstellungen Ihrer Domäne (hier: Software-Entwicklung) stützen, fördern und verwalten können.
Scrum will dies mit dem Sprint-Planungs-Meeting erreichen. Bedauernswerter Weise in vielerlei Hinsicht inadequat. Was in den Lehrbüchern zu Scrum so einfach klingt, ist in der Praxis kaum durchführbar. Zum Einen ist es eine schier berzerrte Wahrnehmung der Realität anzunehmen, dass eine Gruppe von Software-Entwicklern innerhalb von 4-8 Stunden die meist dutzenden Anforderungen für die nächsten paar Wochen “durchdesignen” können. Zum Anderen soll in diesem Meeting so viel wie möglich an offenen Punkten bzgl. der Anforderungen geklärt werden (um der oft mangelnde Anforderungsanalyse entgegenzuwirken).
Bei aller Liebe zu “Embrace Change” – die Sprint-Planung stellt bei vielen Scrum-Teams mit langen Sprintzyklen eine unvollständige “Erstanalyse” der Geschäftsanforderung dar. Aus einer solchen Besprechung eine adequates und professionelles Software-Design zu verlangen, ist schlichtweg naiv. Für viele, angebliche “Agilisten” ist die Sprint-Planung ein Alibi für Design & Planung. “Ja, wir haben doch schon im Planning darüber nachgedacht – das reicht”. Andere wiederum kommen mit der hochkomprimierten, verlustbehafteten Planung wenig zurecht und lagern in der Planung noch kräftig Analyse-Tasks, Design-Tasks, Dokumentations-Tasks nach. Sogar Analyse-Stories bis hin zu ganzen Analyse-Sprints oder Refactoring-Sprints sind schon gesichtet worden. “Willkommen zurück im Wasserfall” kann man da nur sagen.
Der Scrum Master
Mit dem Scrum Master wird ein heikles Kapitel der Schwachpunkte von Scrum geöffnet. Denn der Scrum Master – als Rolle versteht sich – mag auf den ersten Blick alles andere als eine Schwachstelle in der gesamten Methode verstanden werden. Scrum versteht den Scrum Master als “Facilitator”, als “Change Agent”, als “Servant Leader” – was für lobenswerte Werte. Eine Hymne, die auf den Scrum Master gesungen wird. Er überwacht die (wenigen) Scrum-Regeln, er schafft “Impediments” aus dem Weg, er fördert “die gesunde Veränderung” und moderiert durch die Meetings. Ein smarter Typ, dieser Scrum Master.
Doch der Schein trügt. In der Realität ist der Scrum Master oft keines von all den genannten Dingen. In den meisten Unternehmen ist der Scrum Master Nachfolger des klassischen Projekt-Managers. Er schmückt sich mit der Feder des “Change Agents”, nimmt aber aktiven Einfluß auf Planung, verteilt Tasks & Aufgaben, zweifelt Entwicklungsaufgaben an, mahnt bei Refaktorisierungsaufgaben zur Beachtung des “Business Values” und erklärt sich selbst zum “Manager des Teams”.
Andererseits ist der Scrum Master oft V-Mann und Sklave des konservativen Managements. Er wird genötigt, Aussagen über Releasepläne zu geben, Executive Reports zu erstellen, die Zeiterfassung für die Bilanzierung zu erledigen und gleichzeitig (parallel zur “modischen, agilen Methode”) noch Projektpläne zu erarbeiten, in denen penibel Zeitabläufe, Ressourcen & Meilensteine durchgeplant werden.
Der Scrum Master kann auch ein Entwickler sein, der sich dann auserkoren fühlt und Review-Pate spielt. Er ändert Tasks, ist bei Estimations der Führende und setzt den anderen “seinen Programmierstil” (unbewußt) vor die Nase. Er ist meist zu unkooperativ gegenüber dem Product Owner und pocht auf die “Einhaltung von Abmachungen” (Contracting), anstatt den Aspekt für das Geschäft im Auge zu behalten.
All diese Dinge sind kontraproduktiv für das eigentliche Ziel – eine koordinierte, produktive, agile Software-Entwicklung. Es gibt ganz wenige, um nicht zu sagen äußerst selten anzutreffende Scrum Master, die Agilität & Professionalität in Einklang bringen und die überspitzten, gar realitätsfremden Scrum-Prädikate “Alles-Könner”, “Jeden-Versteher” und “Komplett-Überblicker” erfüllen.
Die Skalierung
Ein offensichtlicher Schwachpunkt von Scrum ist die Skalierung. Scrum in seiner ersten und “reinen” Form ist eher für ein einzelnes Team konzipiert – maximal ein paar Teams. Aber Scrum im Großen, “Scrum in the Enterprise” – das ist dann schon eine etwas andere Sache. Klar, es gibt “Scrum of Scrums” und “Company Backlogs”. Dennoch ist bei Scrum die Integration von ganzen Abteilungen, die Organisation von dutzenden Teams und Koordination zu einem größeren Produkt ein Punkt, der in den Lehrbüchern nur mit der magischen “unsichtbaren Tinte” zwischen den Zeilen geschrieben zu sein scheint.
Ominös umnebelt sind hierbei besonders die Themen Synchronisation und Team-Aufteilung. Sind die Teams jetzt funktional (z.B. ein B2B und ein B2C-Team) oder horizontal (z.B. UI-Team, DWH-Team) oder vertikal (z.B. CMS-Team, CRM-Team) oder kann doch jeder alles? Sprintet jeder synchron? Gibt es einen Release-Plan oder mehrere? Wie können die Ergebnisse zusammengeführt werden? Muss jedes Team einen eigenen Branch und eigenes Board haben? Kann ein Scrum Master drei Teams “betreuen”? Fragen über Fragen, auf die Scrum – wenn überhaupt – nur unscharfe Antworten gibt.
Das Dilemma
Es ist schon ein Dilemma. Scrum ist so verbreitet, weil es einfach ist. Es ist überschaubar und kann auf einem Bierdeckel zusammengefasst werden. Scrum ist so populär, weil es einen einfachen Start in die Agilität bietet. Scrum ist so erfolgreich, weil man damit Geschäfte machen kann. Scrum bringt dem Implementierenden auf mittlere Sicht mehr Produktivität und bietet den Unterbau für eine wesentlich flexiblere professionelle Software-Entwicklung. Nicht zuletzt profitiert auch die Unternehmens- und IT-Consulting-Branche von Scrum.
Doch Scrum ist weit mehr als das. Scrum ist unpräzise. Viele denken, sie praktizieren Scrum, dabei machen Sie kleine Wasserfall-Iterationen. Sie stehen an den Boards und berichten über Status und Aufwände, statt gemeinsam den “Einsatz des Tages” zu besprechen und zu planen. Einige verwalten Bugs am Board und haben eine “Ongoing-Tasks”-Zeile, andere wiederum Pochen auf Tickets, Zeiterfassung und “Live-Burndown-Charts”.
Scrum ist transparent. “Hört sich gut an” mag man denken. Das ist auch richtig, ist aber für prokrastinierende Entwickler-Veteranen und altgediente Unternehmens-Manager kein Spaß. Überwachungskultur und Big-Brother-Gefühle eingeschlossen. Politik und der staubige Filz von Konzern-Lobbyisten tragen dann dazu bei, daß “Agil” und “Scrum” mit “Planungslos” und “Chaotisch” substituiert und verunglimpft werden.
Scrum ist leider aber auch oftmals ein Ausreden-Paket für Entwickler. “Nein nein, das Board macht der Scrum Master”. Der Review? Macht der Scrum Master – der kann doch Powerpoint. Die Transparenz und die plötzliche Selbstorganisation schleudert so manchen festgefahrenen Entwickler aus seiner Bahn. Committed wird nur das nötigste. Ausserdem bestimmt ja das “Team” was gemacht wird oder nicht? “Bloß kein Stress” ist hier die Devise.
Die Qualitätsansprüche der modernen, agilen Software-Entwicklung werden oftmals mit dem Level-Of-Done wieder relativiert – wer braucht schon Dokumentation, Unit Tests oder Analyse? Im Übrigen, geplant wird mit einem Tag sowieso schon zu viel – ansonsten sei man “nicht agil”.
Um es etwas provokant auszudrücken: Scrum ist für Erwachsene.
Die oben genannten Mängel können gravierende Auswirkungen nach sich ziehen. Sie können Scrum-Projekte behindern. Ja, sie sind manchmal sogar Grund für das Scheitern von Scrum. Doch man kann diesen Schwachpunkten entgegenwirken. Und es sei nochmals daran erinnert: nur weil Scrum Schwachpunkte hat, heißt es nicht, daß es absolut ungeeignet ist, um agile Sotware-Entwicklung zu betreiben.
Konsequenterweise bleibt nach dieser mehr oder minder langen Kritikliste an Scrum eine große Frage offen: Was kann man tun, um diese Schwachpunkte zu eliminieren bzw. zu mitigieren? Die Antwort auf diese Frage ist – wie Scrum selbst – nicht so einfach wie es scheint. Dennoch würde ich eine Blog-Serie über Verbesserungsmöglichkeiten anstreben.
Haben Sie selbst die Erfahrung über die genannten Schwachpunkte gemacht? Gibt es Ihrer Meinung nach andere, schwerwiegendere Schwachpunkte? Wollen Sie mehr darüber erfahren, wie man den o.g. Schwierigkeiten entgegenwirken kann? Ihre Meinung ist gefragt!
Jahrtausendealtes Wissen der Fertigungslehre
Die Software-Entwicklung ist auch eine Art der “Fertigung” und unterliegt den gleichen Bedingungen, wie sie in der herkömmlichen Fertigungsorganisation hinreichend genau erforscht sind und alltäglich angewendet und bis heute verbessert werden. Schön, dass sich die Wunderlehren der Informatiker langsam erschöpfen und wir wieder zu einer fachlicheren Arbeitsweise gelangen wollen.
Eine deiner Fragen ist, welche Arbeitsweise ist zielführender? In anderen Branchen ist man um klare Normierungen bemüht z.B. Steckdose mit 230 V, Gewinde usw.. Genormte Schnittstellen und Bauteile sind ein Schlüssel zum Erfolg. Ein anderer ist eine anerkannte Arbeitsweise z.B. Qualitätssicherung durch einheitliche berufliche Richtlinien. Die Windows- und .NET-Welt hat sich einige Jahre im Kreis gedreht. Trotzdem scheinen sich “normbare” Lösungsansätze, die z.T. aus anderen Plattformen herüberschwappen, sich auch langsam in der .NET-Welt durchzusetzen.
Mit einem Baukastensystem, dass sich zumindestens teilweise auf Normteile stützt, kann mit Entwurf und Bau des Systems begonnen werden, um schrittweise die Einzelheiten zu lösen. Ein Steuerungsansatz um die Einzelstränge abzuarbeiten, heißt Scrum – auch nicht neu, vielleicht aber für Informatiker.
Wer Lust auf mehr hat, kann in Schmökern der Fertigungs- und Organisationslehre stöbern und trifft wahrscheinlich auf vieles, das er aus dem eigenen Arbeitsalltag der Informatik kennt.
Zuerstmal: ja, 4 Wochen sind zu lang. Mein Eindruck ist, dass es das schlechtgehütetste Geheimnis von Scrum ist, dass 2 Wochen Sprints eigentlich fast schon die Norm sind.
Die anderen Kritikpunkte kann ich nicht wirklich nachvollziehen:
- sicher, Scrum ist “nur” ein Rahmenwerk. Um es zu einem Werkzeug zu machen, müsste man es mit Praktiken füllen, die aber für jedes Projekt eigentlich andere sein müssen. Also landest Du entweder bei einem XP, dass dann als “dogmatisch” verschrien wird, oder bei einem RUP, bei dem kaum einer es schafft, sich einen angemessenen Prozess zurecht zu puzzeln.
- selbstverständlich kann in der Sprint-Planung nicht der gesamte Sprint durchdesigned werden. Soll er ja auch gar nicht. Es ist nur genug Design notwendig, um die Planung auf solide Beine zu stellen. Weiteres Design findet den gesamten Sprint über statt.
- zum Scrum Master: ist Deine Kritik an Scrum hier wirklich, dass diese Rolle im Allgemeinen misbraucht wird? Inwiefern ist das ein Problem mit Scrum?
- beim Thema Skalierung scheint mir, dass Scrum hier eigentlich genau seine Funktion erfüllt: es zeigt die inherenten Schwierigkeiten der Skalierung auf, anstatt sie durch “Lösungen” auf Prozess-Ebene zu übertünschen.
Statt darauf zu hoffen, die “Schwachpunkte von Scrum” durch Erweiterung selbigens ausmerzen zu können, würde ich eher darauf setzen, den Prozess des “Inspect and Adapt” und die Selbstorganisation des Team, unterstützt durch einen kompetent ausgebildeten Scrum Master (ein zwei-Tages-Zertifikat reicht dafür eben nicht) und bei Bedarf externe Hilfe, wirklich ernst zu nehmen.
Prinzipiell einverstanden, wenn auch von Uncle Bob geklaut?
Eines der wichtigsten Prinzipien der agilen Softwareentwicklung ist ja Feedback und kontinuierliche Verbesserung – auch im Bezug auf den Entwicklungsprozess selbst. Insofern führt sich Scrum mit seinen festen “one size fits all” Vorgaben selbst ad absurdum.
Nichtsdestotrotz schätze ich es als einen guten Startpunkt für die agile Entwicklung ein – gerade weil es auf einen Bierdeckel passt. Die Bierstube außen rum muss man dann selbst definieren und ständig anpassen. Diese Verantwortung nehmen uns auch Schwaber und Sutherland nicht ab.
… und ja, natürlich bin ich daran interessiert, wie man das macht. :-)
@Simon,
bzgl. Uncle Bob: Ich kenne den Post von UncleBob und habe mich, nach dem ich seine Thesen gelesen habe, nochmal für mich selbst reflektiert, ob ich Analogien für mich sehe. Im Endeffekt stimmt vieles mit den Thesen von UncleBob ein. Ich hatte den Literaturverweis zum Post von UncleBob nicht in den Artikel integriert, excusé moi. Ich habe es jetzt natürlich nachgetragen.
Ich persönlich sehe jedoch Dinge als Schwachpunkte, die UncleBob unerwähnt lässt:
1) Die Planung & Das Design
2) Der Scrum Master
Im Übrigen konzentriert sich UncleBob stark auf Agile / XP und geht nur partiell auf die Spezifika von Scrum ein.
Ich finde Deinen Beitrag mit dem Continuos Improvement sehr treffend – aus dieser Perspektive hatte ich daß noch nicht betrachtet :-)
Prinzipiell bin ich einverstanden, es gilt aber “don’t blame the tool, it’s not responsible of how you (your team) use it”.
Es ist die Frage ob man von Scrum erwartet, dass alle Aktivitäten bis zu den kleinsten Detailen geregelt sind.
Laut Scrumt heisst es “Es soll ein Planungsmeeting geben, wo der Entwurf besprochen wird” es heisst aber nicht “Es ist verboten den Entwurf nachher wieder zu besprechen”.
Scrum ist für mich eine Set von Basisregeln, die aber auf keinen Fall statisch sind und nicht erweitert werden können, Stichwort “constant improvement”
Die Länge des Sprints sollte meiner Meinung nach für jedes Unternehmen individuell bestimmt werden. Sprints von einer Woche sind aber in einem Unternehmen wo z.B. das Deployment 2 Tage dauert nicht sehr sinnvoll.
Zu dem Punkt “Scrum Master” gebe ich dir voll Recht, er soll meiner Meining nach nicht als ein klassischer Projektmanager agieren. Das ist aber in Scrum auch nicht so beschrieben, also keine Schwachstelle von dem Prozess.
Dimi’s Kommentar bringt meine Meinung voll auf den Punkt, und fasst “in a nutshell” nicht nur meine Meinung, sondern auch den Ansatz von Scrum zusammen.
Danke Dimi für den konstruktiven Beitrag, eine Eigenschaft, die ich trotz vieler Worte und komplexer Satzkonstruktionen im Original-Post leider völlig vermisse.
[...] einiger Zeit hatte ich über die Fünf Schwachpunkte von Scrum gebloggt. Am Ende des Artikels hatte ich versprochen, mir Gedanken darüber zu machen, wie man [...]
@Dimi: Danke für das Feedback. Ich denke es ist mit eine Verantwortung des Tools, wenn die Eindeutigkeit der Anwendung nicht immer gegeben ist. Es ist wie “Usability” – aber eben nicht für Websites, sondern für die Methodik. Natürlich kann das HTML nichts dafür, wenn man für Überschriften DIV’s verwendet und nicht die dafür gedachten H*. Aber – es ist deutlich erkennbar, das ein H* nicht für Buttons verwendet werden soll, oder nicht? Die Analogie ist natürlich ein wenig weit hergeholt, aber ich hoffe ich konnte meinen Standpunkt rüberbringen.
@Joe: Hmm, Schade dass Dich offensichtlich die Satzkonstruktionen etwas vom Inhalt abgelenkt zu haben scheinen. Am Ende des Artikels steht es meiner Meinung nach ziemlich deutlich, dass ich noch meine konstruktiven Vorschläge einbringen werde. Zunächst war für mich eine Sachdiskussion über die Feststellung der Schwachpunkte im Fokus.
Wie dem auch sei, heute habe ich mich in einen konstruktiven Beitrag zum Thema Sprintdauer geübt:
http://www.gmbsg.com/scrum-die-bessere-sprintdauer/
Hallo *,
SCRUM ist ein Framework für Projektmanagement?
Als zertifizierter Projektmanager (IPMA) und SCRUM Master möchte ich dem wiedersprechen. SCRUM ist viel zu wenig beschrieben, als dass es als PM Framework dienen kann. Meiner Meinung nach.
Die “leichtgewichtige” Methodik ist keine Schwäche, sondern DAS Grundprinzip. Genau deshalb wurde SCRUM erfunden.
Bei der Beurteilung diverser Dinge (Aktien, Prozessmodelle, Autos usw.) tue ich mich immer schwer pauschal von Vor- und Nachteilen zu sprechen oder Stärken und Schwächen.
Alle diese Dinge haben Eigenschaften. Für den einen sind diese Eigenschaften von Vorteil, für den anderen von Nachteil. In der einen Situation sind diese Eigenschaften von Vorteil, für die andere Situation von Nachteil. Kommt drauf an…
Die Sprintdauer passt nicht? Pass es an! Das ist doch das Tolle an SCRUM. Also keine Schwäche. Andere Methoden erlauben das höchstmaß an Flexibilität nicht.
Daß das Design in den Planungs Meetings durchgeführt werden soll, höre ich zum ersten Mal. Design wird während der Sprints durchgeführt. Iterativ und nicht phasenweise.
Wenn der SCRUM Master nicht die Rolle einnimmt, für die er vorgesehen ist, wittere ich eine Schwäche in der Personalführung und der Ausbildung. Ist definitiv keine SCRUM Schwäche.
Bei wem SCRUM nicht funktioniert, sollte es nicht machen.
Nehmt doch XP oder RUP oder …
Natürlich kann man einen Nagel auch mit einem Schraubenzieher in die Wand schlagen. Es geht. Ein Hammer ist meist besser dafür geeignet.
“Wenn man nur einen Hammer hat, sehen alle Probleme aus, wie Nägel.”
Ich mache das so, dass ich in meinem Werkzeugkasten diverse Tools vorhalte und je nach Situation und Problemstellung versuche, das richtige Werkzeug auszuwählen.
Ich unterstelle, wenn Sie alle anderen Entwicklungsmodelle ansehen, werden Sie auch Schwachstellen finden! ;-)
[...] 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 [...]
[...] ist zwar schon eine Weile her, als über die Fünf Schwachpunkte von Scrum geschrieben habe. Die Resonanz auf diesen provokanten, aber aus meiner Sicht treffenden Artikel war [...]
Ihre Meinung ist gefragt!
Archiv
Diskussionen
Meta
Auszeichnungen
Copyright Ilker Cetinkaya using CC BY-NC-SA 3.0 DE | Powered by WordPress | Log in | Artikel (RSS) | Kommentare (RSS) | Styled with gmblue v0.1 (the next arthemia)