What gets measured is what gets focused on<\/a>\u00a0and what Scrum measures is speed of output with the output judged from the user side only by the product owner. That metric does not value many behaviors associated with great developers.<\/p><\/blockquote>\n\n\n\n2. Alter Wein in teuren Schl\u00e4uchen – Warum das Produkt „Scrum“ gar nicht so innovativ ist wie es vorgibt<\/h2>\n\n\n\n Mit einem unfassbar ausgestalteten Set an neuen Begriffen versucht Scrum seine Neuartigkeit zu unterstreichen. Treffen hei\u00dfen nicht mehr nur „Meeting“, sondern „Daily“, Aufgabenbeschreibungen avancieren zu „Stories“, Aufgabenlisten werden zum „Backlog“ und klassische Feedbackgespr\u00e4che mit Kunden zu umfangreichen „Review-Meetings“ und interne Teamgespr\u00e4che zu „Retrospectives“. All diese Methoden und Objekte, in Scrum „Artefakte“ genannt, sind nicht neu, nur ihre Benennung ist anders. Sie will symbolisieren „ich bin modern ich hei\u00dfe anders, ich bin trendy“.<\/p>\n\n\n\n
Die Aufgaben werden in Scrum typischerweise in Zyklen, „Sprints“ genannt, von 3-4 Wochen geplant, es gibt eine Visualisierung, das „Scrum Board“, und eine Quantifizierung des Outputs in Form des „Burn-Down-Charts“, in dem t\u00e4glich manuell abgetragen wird, wie viele Aufgaben erledigt wurden, um am Ende des Sprints idealerweise bei null offenen Aufgaben anzukommen. Den Aufgaben an sich werden zudem „Story-Points“ zugeordnet, die vom Entwicklerteam im „Planning“ mit speziellen Scrum Cards gesch\u00e4tzt werden m\u00fcssen. Diese „Story-Points“ sind Gewichtungen, aber sie haben bewusst keine Einheit. Sie sind nicht \u00e4quivalent zu Zeit oder Komplexit\u00e4t, sie sind eine mystische Einheit. H\u00fcrdensammlungen werden zu „Impediments“ und Entwickler zu „Developern“.<\/p>\n\n\n\n
W\u00e4hrend diese andere Sprache vll. die Neuartigkeit bekunden oder zur Reflexion des agilen Manifests anregen soll wirkt sie auf Dauer mindestens artifiziell, auf den reflektierten Mitarbeiter vll. mitunter auch albern. Das Anderssein wird zum Selbstzweck und die neuen Begriffe sollen dar\u00fcber hinwegt\u00e4uschen, dass das ganze eigentlich gar nicht so innovativ ist. Die Begriffe sind zudem auch tlw. gar nicht treffend. zwei Beispiele:<\/p>\n\n\n\n
Sprint:<\/strong> Ein „Sprint“ ist ein Kurzstreckenlauf, bei dem ich alle Kraft einsetze. Nach dem Sprint bin ich erst mal ersch\u00f6pft. Es ist kein ausdauernder Lauf, sondern ein einmaliger Aufwand. Eine Iteration dagegen ist etwas, das sich in \u00e4hnlicher Weise stets wiederholt. Der begriff „Sprint“ dr\u00fcckt damit gar nicht das aus, was Scrum eigentlich meint, n\u00e4mlich eine „kurze Iteration“ auf die die n\u00e4chste folgt.<\/p>\n\n\n\nBacklog:<\/strong> Dann gibt es noch die Backlogs: Product-Backlog und Sprint-Backlog. Ist ein Backlog eine „R\u00fcckstandsliste“? In gewisser Weise ja, aber der passendere und einfachere Begriff w\u00e4re vielleicht „Aufgabenliste“. Doch der klingt eben nicht so fancy und so gar nicht neu.<\/p>\n\n\n\nAber Scrum entfaltet sich nicht von alleine. Hinter dem Modell steckt eine ganze Industrie mit absurd klingenden Titeln und Zertifikaten, mit teuren Trainern, Schulungen und Mantras. Original-Zitat eines Trainers: „Der Scrum Master hat die Pflicht, im Unternehmen f\u00fcr Scrum zu werben“. Scrum selbst ist das Produkt, das verkauft werden will, es wurde entwickelt von \u00d6konomen und wird vertrieben wie beim Struktumarketing.<\/p>\n\n\n\n
3. Agilit\u00e4t anders formuliert: Kontrolle schafft Sicherheit<\/h2>\n\n\n\n T\u00e4glich treffen sich die Entwickler in der benannten Timebox „Daily“ um eine Viertelstunde (aber nicht l\u00e4nger) \u00fcber das Alltagsgesch\u00e4ft zu reden, Product Owner und Scrum Master h\u00f6ren eifrig zu und stellen ggf. bl\u00f6de Fragen (sollen sie egtl. nicht, aber tun sie da sie ja mit den Verfahren und Umsetzungen nicht vertraut sind). Diese Methode soll dazu f\u00fchren, dass das Entwicklerteam miteinander spricht, was anscheinend bei Programmierern selten sein muss.<\/p>\n\n\n\n
The fact of being observed changes the way people work. In creative fields, it\u2019s for the worse. It\u2019s almost impossible to work creatively if one has to justify the work on a day-by-day basis.<\/p><\/blockquote>\n\n\n\n
Scrum zielt darauf ab, Strukturen zu etablieren, die die Freiheit eingrenzen und dadurch Erwartbarkeit und Planbarkeit in komplexen Prozessen schaffen. Das ist vom Ansatz her legitim, aber es ist eben zweifelhaft, ob diese Art von Methode dazu f\u00fchrt, dass dieses Ziel mit bestm\u00f6glicher Effizienz erreicht wird. Gerade in Arbeitskontexten, die Kreativit\u00e4t erfordern scheitert Scrum zunehmend. Gerade bei sehr komplexen Produkten, bei deren Umsetzung Scrum ja seine Vorteile auszuspielen verspricht, f\u00fchrt Scrum h\u00e4ufig zu Chaos, Indifferenzen, inhomogenen Arbeitsverteilungen und Entfremdung vom Produkt.<\/p>\n\n\n\nDie Perversion des Chaos-Prinzips – Scrum r\u00fcckw\u00e4rts betrachtet ist „Murcs“<\/figcaption><\/figure>\n\n\n\nSchlechte Qualit\u00e4t dient der Velocity<\/h2>\n\n\n\n Scrum zielt darauf ab, schnell funktionierende Ergebnisse zu liefern. Qualit\u00e4t ist dann erreicht wenn schnell neue funktionale Inkremente ausgeliefert werden k\u00f6nnen. Quantit\u00e4t statt Qualit\u00e4t, denn Qualit\u00e4t erfordert eine tiefere Auseinandersetzung mit dem Produkt. Scrum honoriert das jedoch nicht. Im Gegenteil – was nicht messbar ist verschlechtert die Velocity und damit den gemessenen Erfolg. Umso dramatischer wenn technische Kenntnisse des Product Owners so schlecht sind, dass er kein tiefes Verst\u00e4ndnis des Produkts besitzt.<\/p>\n\n\n\n
Great developers are usually defined by their ability to develop robust code. Unless the product owner is technical, Scrum massively devalues that as the product owner isn’t evaluating the code. It is feature driven and „it runs“ is a functional standard for the provided user stories.<\/li> Great developers are usually defined by their ability to write code which has value both now and in the future. Scrum projects think of everything in two week periods. There is no future.<\/li> Great developers are usually defined as those who can solve tough problems. Scrum encourages picking work that can easily be done and rapidly churned out at a steady pace. A tough problem is a developer being slow on getting the tickets done.<\/li> Great developers are often sought out for advice and for second opinions. But any time doing that is less time spent churning out tickets, so their velocity falls<\/li><\/ul>\n\n\n\nUnd „daily“ gr\u00fc\u00dft der Scrum murcS – Die Abrechnung<\/h2>\n\n\n\n Der begriff Scrum geht auf die Metapher zur\u00fcck, dass viele Individuen intensiv in einem Gemenge, m\u00f6glicherweise bei den Dailys miteinander in Kontakt treten. \u00c4hnlich wie beim Rugby um den Ball gek\u00e4mpft wird, ist die Suche nach Sinn und Ordnung bei Scrum anscheinend nur durch Chaos m\u00f6glich. Aber die Kritik ist viel konkreter. Eine \u00dcbersicht \u00fcber die in der Praxis entstehenden nervigsten und gef\u00e4hrlichsten Probleme bei der Implementation von Scrum:<\/p>\n\n\n\n
Die Daily „Status Meetings“ nerven und avancieren in der Praxis zu oft zu Treffen in denen die Entwickler sich und Ihr tun vor den anderen legitimieren sollen: „Devs have to justify themselves to \u201cscrum masters\u201d and \u201cproduct owners\u201d and layers of non-technical management.“ <\/li> Die Iteration „Sprints“ sind k\u00fcnstlich. Ihre L\u00e4nge ist grundlos definiert und orientiert sich eher an \u00f6konomischen Gesichtspunkten als an projektspezifischen sinnvoll gesetzten Meilensteinen. Zudem hat Scrum eine Obsession zu viel zu kurzen Iterationen.<\/li> Die vielbeworbenen „Inkremente“ sind keine „Inkremente“ sondern nur k\u00fcnstlich definierte Sprint-Ziele.<\/li> Die vielen Scrum-Events st\u00f6ren den „Worflow“, die Einmischung Projekt-fremder Rollen (Produkt-Owner und Scrum-Master) nervt. <\/li> Kreativit\u00e4t wird im Kern und grunds\u00e4tzlich durch Scrum behindert: Was nicht als Aufgabe definiert ist hat keinen Raum. Der Blick nach Links und Rechts oder gar \u00fcber den Tellerrand wird bewusst und substantiell unterbrunden.<\/li> Die Rollen in Scrum f\u00fchren zu ungleichverteilter Verantwortung und inhomogener Arbeitslslast. Scrum-Master und Product-Owner sind rigoros von der Umsetzung ausgeschlossen und entfremden sich vom Produkt.<\/li><\/ul>\n\n\n\nOften, it\u2019s the best employees who fall the hardest when Agile\/Scrum is introduced, because R&D is effectively eliminated, and the obsession with short-term \u201citerations\u201d or sprints means that there\u2019s no room to try something that might actually fail.<\/p><\/blockquote>\n\n\n\n
Scrum ist eine Mode die gut und gerne erprobt werden darf. Scrum ist aber niemals ohne Reflexion und formative Evaluation einzusetzen, sonst wird es gef\u00e4hrlich. Wer die Harmonie in Teams der Ordnung durch virtuelle Regeln opfert, der riskiert das Scheitern eines Projekts. Wer Intransparenz unter dem Mantel eines agilen Effizienzanspruchs verkauft begeht Vertrauensbr\u00fcche, die nur mit viel Aufwand geheilt werden k\u00f6nnen. Wer Harmonie und Vertrauen einem Trend opfert, der Gutes verhei\u00dft, aber Probleme bringt, hat effizientes Projektmanagement nicht verstanden.<\/p>\n","protected":false},"excerpt":{"rendered":"
Scrum ist eine moderne Methode zur Umsetzung von agilem Projektmanagement. Agiles Projektmanagement wiederum beschreibt die Eigenschaft von Projekten, flexibel und rasch auf ver\u00e4nderte Umweltbedingungen reagieren zu k\u00f6nnen. Zudem soll Scrum dabei helfen, die Effizienz im Team zu steigern und f\u00fcr einen kontinuierlichen Fluss an den Output zu sorgen. Aber effizienz hat ihren Preis und manchmal…<\/p>\n","protected":false},"author":1,"featured_media":498,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-495","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-allgemein","entry","has-media"],"_links":{"self":[{"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/posts\/495"}],"collection":[{"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/comments?post=495"}],"version-history":[{"count":5,"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/posts\/495\/revisions"}],"predecessor-version":[{"id":595,"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/posts\/495\/revisions\/595"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/media\/498"}],"wp:attachment":[{"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/media?parent=495"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/categories?post=495"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ragerman.de\/wp-json\/wp\/v2\/tags?post=495"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}