Der Scrum Guide 2013 – was gibt es Neues?

Der neue Scrum Guide 2013 ist seit einer Woche herunterladbar, momentan noch ausschließlich auf Englisch. Es lohnt sich, genauer hinzusehen, was Ken Schwaber und Jeff Sutherland geändert haben.

(Alle Hervorhebungen in Zitaten von mir).

Praxisnäher oder schon ScrumBut?

Viele kleine, unscheinbare Einfügungen (best, usually, …) und Änderungen im Text sorgen für neue Ausnahmen und Relativierungen. Was früher noch zumindest als fragwürdig galt, taucht nun als dezentes Zugeständnis auf:

  • Die Sprintlänge darf jetzt offiziell variieren, sollte es aber am besten nicht („Sprints best have consistent durations throughout a development effort.“).
  • Das Sprintziel darf jetzt im Sprint nicht mehr gefährdet werden, bisher war bereits die Beeinträchtigung verboten („endangered“ ersetzt das alte „affected“). Über die Grenze dazwischen darf spekuliert und viel diskutiert werden. Bei der Arbeit.
  • Die Zusammensetzung des Entwicklungsteams muss über einen Sprint nicht mehr konstant bleiben. Niemand muss sich also mehr verstecken mit Modellen wie einer Teilzeit-Mitgliedschaft (z.B.: Frank ist nur jeden Mittwoch da) oder auch der Austauschbarkeit von Human Resources (z.B.: es muss immer „ein Entwickler“ im Team sein, egal ob das Michael oder Frank ist).
  • Bisher galt: wurde die Sprintlänge gekürzt, mussten auch die Ereignisse SprintplanungSprint-Review und Sprintretrospektive proportional gekürzt werden. Jetzt werden sie in diesem Fall nur als „usually shorter“ bezeichnet. 2015 dann vermutlich als „sometimes shorter“.
  • Tasks haben nicht mehr einen Tag als strikte Obergrenze für ihre Bearbeitungsdauer. Hier halten Ken und Jeff gar nicht erst bei „usually“ inne, sondern zerlegen die Einträge des Product Backlogs often to units of one day or less“.

Höflich zusammengefasst: es wird ab sofort gebilligt, die Arbeit gemäß Scrum dem Arbeiten in vor-agiler Zeit deutlich anzugleichen. Man könnte es auch weniger höflich eine Lizenz zum Bullshit nennen: Ken und Jeff haben hier in der Diskussion zu ScrumButs deutlich Stellung bezogen – für meine Begriffe im sumpfigen Gelände.

Sprintplanung ab sofort ganz neu? Nein.

Die Sprintplanung hat keine zwei gleich langen Teile mehr. Statt dessen werden die beiden Teile zu Themen umdeklariert, ihre Überschriften bleiben aber gleich:

  1. What can be done this Sprint? und
  2. How will the chosen work get done?

Praktisch bedeutet das nur, dass beide Themen unterschiedlich lange diskutiert werden können. Thema 1 muss trotzdem vor Thema 2 abgehandelt werden. Implizit scheint es jetzt auch eine Anwesenheitspflicht für den Product Owner bei Thema 2 zu geben, zumindest wurde die Formel „The Product Owner may be present“ ersatzlos gestrichen.

Heisse Kartoffel Sprintziel: essen will sie jeder

Wozu ein Sprintziel? Als Sinn wird „Kohärenz“ in Bezug auf irgend etwas genannt,  was das Entwicklungsteam zur Zusammenarbeit bringt, statt zur isolierten Arbeit von Einzelnen. Leider spielt laut Scrum Guide keine Rolle, ob das Sprintziel fachlich, technisch oder mit Blick auf das Firmensommerfest kohärent ist:  „The Sprint Goal can be any other coherence“, Hauptsache Teamwork.

Die Fragen während des Daily Scrum werden ab sofort als Erinnerung an das Sprintziel und den teamorientierten persönlichen Beitrag dazu ausgerichtet. Beispielsweise heißt es nicht mehr

  • „What has been accomplished since the last meeting?“ (2011), sondern
  • „What did I do yesterday that helped the Development Team meet the Sprint Goal?“ (2013).

Das finde ich gut, wenn auch etwas angestrengt erzieherisch. Die Verantwortung für das Formulieren des Sprintziels wird allerdings wie eine heiße Kartoffel so schnell im Kreis herumgereicht, dass einem schwindlig wird:

  • „The Product Owner discusses the objective that the Sprint should achieve…“
    Sagte man früher einfach „mitteilen“, „verkünden“ oder „anordnen“, so nutzt man heute „discuss“ (oder das unsägliche „communicate“) – als hätten die Zuhörer etwas mitzureden.
  • After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.“
    „Ein“  Sprintziel wird nachträglich, passend zur Vorhersage des Entwicklerteams ausgearbeitet? Sicher?
  • Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how…“
    Moment: die Entwickler haben das festgesetzt? Wirklich? Oder ist das einfach nur schlampig formuliert?

Zusammengefasst: der Product Owner teilt allen die objective des Sprints mit, das Scrum Team arbeitet ein Sprint Goal aus, und gesetzt hat es am Ende angeblich das Development Team.

So sehr mir insgesamt die neue starke Betonung des Sprintziels gefällt: ich fürchte, als Guide wird hier eher der agile gesunde Menschenverstand nützlich sein als ein Papier mit solch halbgaren Formulierungen. Eine verpasste Chance!

Raider heißt jetzt Twix

…sonst ändert sich nix:

  • Einträge im Product Backlog, die fertig zur Übernahme in einen Sprint sind, wurden die letzten beiden Jahre „ready“ oder „actionable“ genannt. Ab sofort heißt das „Ready“. Mit großem R. Eine kleiner Schritt für die Orthographie, ein großer Sprung vorwärts für die Scrum-Community.
  • Die Definition of „Done“ ist noch nicht done und pendelt absatzweise hektisch zwischen „Done“ und „done“.
  • Die laufende Pflege und Überarbeitung des Product Backlogs wurde die letzten beiden Jahre in der Community meist „grooming“ genannt. Ab sofort heißt das „refinement“.

Feiges Geschwurbel

Manches Buzzword soll offensichtlich unangenehmen Klartext überdecken. Schönstes Beispiel: „Artifact transparency“

Ein als besondere Neuerung angepriesener Abschnitt: Transparenz bei Artefakten sei gut. Und selbstredend ist der Scrum Master verpflichtet, jedem auch bei der Herstellung von noch mehr Transparenz zu helfen. Mehr konnte ich dem Text zunächst nicht entnehmen. Ich habe es redlich und wiederholt versucht.

Einige Gläser (Frappé) später fiel mir dann ein, dass Scrum-Werte wie Offenheit und Mut nicht mehr Teil des Scrum Guides sind (s.u.). Mir dämmerte bei der Lektüre, dass mit „Transparenz“ hier letztlich Wahrheit gemeint ist. Das industrielle Scrum von 2013 hat anscheinend die Kraft verloren, diesen Begriff „Wahrheit“ offen und mutig zu benutzen, um nach mehr davon zu verlangen. Was für eine Ironie.

Rollen: Harder, better, faster, stronger

Es gibt angeblich mehr zu tun, in einigen Rollen:

Der PO…

…konnte sich bisher damit begnügen, die Wertschöpfung des Entwicklerteams sicherzustellen. Aber das altbackene und prozessverdächtige „ensuring“ musste jetzt dem wesentlich dynamischeren „optimizing“ weichen. Wer braucht da noch Kanban!

Für den Scrum Master…

…reicht „Understanding long-term product planning in an empirical environment“ ab sofort nicht mehr, das Wörtchen „long-term“ wurde einfach gestrichen. Eine heimtückische Änderung, finde ich, denn sie ersetzt schlagartig das, was nie existierte, durch das, was jemand anderes als der Scrum Master längst hätte tun müssen.

Auch wichtig: die neue Aufgabe „Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value“. Ich freue mich auf viele heitere Szenen, wenn der in anderthalb Tagen zum CSM geschulte Scrum Master vorschriftsmäßig sicherstellt, dass der ebenfalls in anderthalb Tagen zum CSPO geschulte Product Owner seine Kernaufgabe auch wirklich beherrscht.

Und eine besonders sportliche neue Idee zur Hirnakrobatik in der Sprintretrospektive: „The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.“ Je öfter und länger ich über diese Formel und ihre praktischen Konsequenzen für den Scrum Master nachdenke, desto [Schimpfwörter gelöscht, bitte bleiben Sie sachlich! – die Red.].

Weg damit!

Ist Produktentwicklung zu komplex für Scrum?

Zwei Jahre lang galt: „Scrum is a framework structured to support complex product development.“ Diese Struktur möchten Ken und Jeff jetzt offenbar lieber durch (ihr?) zusätzliches Consulting schaffen und streichen den Passus ersatzlos. Erhalten geblieben ist an anderer Stelle nur das nebulöse „Scrum is a process framework that has been used to manage complex product development.“

Vision? Endlich Geschichte.

Aufatmen beim Scrum Master: „Clearly communicating vision“ steht nicht mehr auf seiner To-Do-Liste. Diese Unterstützungsleistung für den PO entfällt ersatzlos, vielleicht, weil eine Vision, die klar vermittelt werden soll, ja zuerst einmal existieren müsste. Das ist im industrialisierten Scrum immer unwahrscheinlicher geworden, also weg damit – das Wort „vision“ taucht jetzt im Scrum Guide nirgendwo mehr auf.

Was nur konsequent ist und dem Schicksal der „values“ folgt. Die Scrum-Werte (Respekt, Mut, Offenheit, Fokus und Commitment – wie es in den Sagen und Mythen vergangener Zeiten lautet, falls ich mich recht entsinne) wurden ja bereits getilgt: hieß es im Scrum Guide 2009 noch, der Scrum Master habe dafür zu sorgen, dass sich das Team an „Scrum values, practices, and rules“ halte, lautet die Formel seit 2011 „Scrum theory, practices, and rules“.

Da scheint mir bizarr, wie Ken Schwaber kürzlich kritisierte, andere hätten wohl das agile Prinzip „Individuals and Interactions over Processes and Tools“ aus den Augen verloren. Er empfiehlt: „Keep the values, keep the principles, think for yourself.“ Eat your own dog food, Ken.

Du musst es nicht tun, sondern nur verstehen!

Und nochmals Aufatmen beim Scrum Master: das naive „Teaching the Development Team to create clear and concise Product Backlog items“ (2011) gehört nicht mehr zu seinen Aufgaben, es weicht endlich einem professionellen „Helping the Scrum Team understand the need for clear and concise Product Backlog items“ (2013).

Ich finde, das spart Arbeit. Denn man darf getrost voraussetzen, dass dieser Bedarf jedem längst schmerzlich bewusst ist. Somit fällt für den Scrum Master auch hier keine wirkliche Mehrarbeit an. Trotzdem – es wäre sicher mehr drin gewesen. Für die kommende Version des Scrum Guides schlage ich etwas vor wie: Nurturing the Scrum Team’s appreciation of the need for transparent Product Backlog items.

In der Gosse gelandet: vom festen Event zur formellen Gelegenheit

Welcher Satz stammt aus dem Scrum Guide 2011 und welcher aus dem Scrum Guide 2013?

„Although improvements may be implemented at any time, the Sprint Retrospective provides…

  • „… a dedicated event focused on inspection and adaptation.“
  • „… a formal opportunity to focus on inspection and adaptation.“

Muss ich auflösen? Allenfalls für Menschen, die Geburtstagspartys als formelle Gelegenheiten betrachten, um sich ihren Freunden zu widmen. Oder auch nicht.

Easter eggs – Lachen mit Scrum

Ken und Jeff haben durchaus Sinn für Humor, wie ein paar Fundstücke zeigen:

  • 2011 hielten sie Scrum noch für „Extremely difficult to master“, jetzt haben sie das „extremely“ entsorgt.
  • Der Product Owner muss nur noch optional lügen, also im Sprint Review nicht mehr unbedingt „completion dates based on progress to date“ extrapolieren – in Klammern folgt jetzt ein neckisches „(if needed)“.
  • Abweichlern, die Scrum nicht als Framework bezeichnen wollen, werden die Instrumente gezeigt: die zugehörige Überschrift „Scrum Overview“ wird zu „Definition of Scrum“ umgetitelt. Nehmt das, Ihr Ketzer! Auch sonst werden die Zügel der Orthodoxie straffer angezogen – 2011 schienen noch „Specific strategies for using the Scrum framework“ denkbar, jetzt sind es nur noch „Specific tactics.

Mein subjektives Fazit

Der neue Scrum Guide 2013 ist ein konsequenter Schritt in Richtung industriell betriebenes Scrum. Werte waren bereits 2011 ausgemerzt, die Produktvision wird es jetzt. Aus dem Sammelsurium von vermeintlichen Kleinständerungen stechen bei genauerem Hinsehen viele ScrumButs ins Auge, die den Segen der Scrum-Erfinder bekommen. Um nur ein zwei zu nennen: Tasks, die länger als einen Tag dauern; oder Teammitglieder, die bei laufendem Sprint aus dem Team abgezogen oder in das Team entsandt werden können.

Die Verbesserungen sind demgegenüber marginal, wenn auch einige überfällige darunter sind, etwa das Einfordern eines Sprintziels.

Wer im Vergleich dazu lesen möchte, was gut gelebtes Scrum wirklich sein kann, dem empfehle ich als Erholung nach dem Scrum Guide das neue Buch von Tobias Mayer zu lesen, seine Essaysammlung The People’s Scrum.

Bildnachweis:
The 10 Commandments © John Taylor | CC BY 2.0

15 Antworten auf „Der Scrum Guide 2013 – was gibt es Neues?“

  1. Nun, seit anfangs 2013 gibt es ja nebst dem Scrum Guide auch noch das „Core Scrum“ der Scrum Alliance auf das sich DIESE bei IHREN Zertifizierungen bezieht….
    Die Bedeutung des Scrum Guide von Ken Schwaber (egal welcher Version) wird damit ja erheblich relativiert – und ist ja nur für die „Assessments“ von Scrum.org von Bedeutung. Dass Ken immer wieder „einfordert“ dass nur sein Scrum Guide das „richtige“ Scrum beschreibt (und dann auch noch gegen andere agile Vorgehensweisen wie etwas das SAFe heftig vom Leder zieht) betrachte ich persönlich als „Rückzugsgefecht“ in einem immer enger werdenden Beratungs- und Trainingsmarkt.

    Interessant aber wäre dennoch ein ähnlicher Vergleich zwischen dem Scrum Guide 2013 und dem Core Scrum.

    Und interessant wäre auch, wie denn ein CSM der Scrum Alliance in einer Firma arbeitet, die nach Scrum Guide 2011 oder nach Scrum Guide 2013 arbeitet … oder ist das in der Praxis ohnehin alles egal …. weil eh irgendwelche „Scrum But“ dominieren?
    Dann aber erübrigt es sich, immer wieder neue „Guides“ oder „Cores“ zu publizieren und einige bisherige „Buts“ zu legalisieren und andere – bis zur nächsten Version – als „Buts“ bestehen zu lassen. Dann ist all dieses Geschreibe ja bloss waste….

    1. Hallo Hans-Peter,

      so richtig spannend wird ein Vergleich zwischen „geführtem“ und „kernigem“ Scrum für mich erst, wenn sie sich gravierend widersprechen. Damit rechne ich nicht, eher mit wachsender Beliebigkeit und Wurstigkeit in beiden Texten.

      Und natürlich mit Verteilungskämpfen, da stimme ich Dir ganz zu. Die wird das Publikum aber auch als solche erkennen.

      Bis zu einem echten Religionskrieg grübele ich da lieber ein bisschen darüber, was post-agil bedeuten könnte…

      Gruß,
      Rolf

      1. Für mich ist „post agil“ die Rückbesinnung auf all das, was VOR dem Trendwort „agil“ bereits diskutiert und (tw) gemacht wurde … und dann vom Begriff „agil“ vereinnahmt wurde… wobei Vieles davon weiterhin unerfüllt blieb.
        Mehr dazu von mir findet sich demnächst hier:
        „Agile Konzepte“ In: Bartsch, Oliver; Lindinger, Markus (Hrsg.): IT-Servicemanagement. http://www.tuev-media.de/produkte/91154-it-servicemanagement.php
        und
        „Das „agile“ Vorgehen: Neuer Wein in alte Schläuche – oder ein „Déjà-vu“?“, in http://fg-wi-vm.gi.de/veranstaltung0/workshops/vorgehensmodelle-2013.html

        1. Hallo Hans-Peter,

          der Artikel zum Link scheint mir keine *gravierenden* Widersprüche zu beschreiben, die sich nicht weginterpretieren lassen.

          Aber ich sehe schon: Du wirst erst zufrieden sein, wenn ich das Weginterpetieren auch versuche! 😉

          Grüße,
          Rolf

          1. Hallo Rolf,

            dieses „Weginterpretieren der Unterschiede“ ist ja auch beim Guide 2013 in Bezug auf 2011 möglich …. bzw. auch das „Hineinintergepieren wesentlicher Unterschiede“ bei „eigentlich kleinen“ Veränderungen etwa der Wortwahl oder von relativierenden Zusätzen.

            Wenn wir auf der Schiene der „Weg- und Hinzuinterpretierungen“ bleiben, dann enden wir rasch bei der Forderung nach so einer Art von Bundesverfassungsgericht für Scrum….. und zwar eines, das der Scrum Alliance und Scrum.org übergeordnet ist ….

            Fakt ist, dass heute nebeneinander irgendwelche Scrum-Varianten abgeleitet aus diversen Guide-Versionen und dem „Core“ (je nachdem, wann und bei welchem Trainer die Leute waren) existieren …. in der grossen Mehrheit aber KEINEM dieser „Regelwerke“ entsprechen …. und vielleicht GERADE DESHALB funktionieren …. siehe als Illustration dazu: „Agile Entwicklung – Scrum in der Praxis: Knarzen im Gebälk“
            http://www.zuehlke.com/uploads/tx_zepublications/257_dnp_knarzen_im_Gebaelk_pd_fme.pdf
            Auszug aus dem Fazit:
            „“
            Von den beschriebenen Projekten sind alle auf die eine oder andere Art von der reinen Scrum-Lehre abgewichen. Die besten Resultate werden unserer Erfahrung nach dann erzielt, wenn der Prozess nicht nur optimal zu Projektziel und -dauer, sondern auch zum Umfeld passt und die Projektleitung keine Vorgaben für die Auswahl des Prozesses erhält. Auch innerhalb eines Unternehmens unterscheiden sich die Rahmenbedingungen für Projekte stark, sodass die Einführung eines firmenweiten Entwicklungsprozesses unter Umständen keine Verbesserungen bringt.
            „“

            Also „Scrum-But“ ist der Regelfall … und genau deshalb funktioniert Scrum (oder etwas, das so bezeichnet wird) überhaupt …

          2. Hallo Rolf,

            wenn wir bei den Vergleichen zwischend den diversen „Regelversionen“ (Guide und Core) auf dem Weg von „Weg- un Hineininterpretationen“ dessen, was an „objektiven“ textlichen Unterschieden vorliegt weiterwandern dann enden wir rasch bei so etwas wie dem Anrufen eines „Bundesverfassungegerichtshofs für Scrum“, der der Scrum Alliance und Scrum.org übergordnet ist ….

            Fakt ist: Es existieren heute nebeneinander irgendwelche Scrum-Implementationen abgeleitet aus irgendwelchen Regelversionen je nachdem, wann und bei wem Scrum „gelernt“ wurde. Und zwar ABGELEITET… nicht 1:1 praktiziert … und vermutlich funktioniert das genau DESHALB …
            Siehe als Illustration „Agile Entwicklung – Scrum in der Praxis: Knarzen im Gebälk“
            http://www.zuehlke.com/uploads/tx_zepublications/257_dnp_knarzen_im_Gebaelk_pd_fme.pdf
            Auszug aus dem Fazit:
            „“
            Von den beschriebenen Projekten sind alle auf die eine oder andere Art von der reinen Scrum-Lehre abgewichen. Die besten Resultate werden unserer Erfahrung nach dann erzielt, wenn der Prozess nicht nur optimal zu Projektziel und -dauer, sondern auch zum Umfeld passt und die Projektleitung keine Vorgaben für die Auswahl des Prozesses erhält. Auch innerhalb eines Unternehmens unterscheiden sich die Rahmenbedingungen für Projekte stark, sodass die Einführung eines firmenweiten Entwicklungsprozesses unter Umständen keine Verbesserungen bringt.
            „“

            Also: Der Normalfall ist „Scrum But“ …. und deshalb funktioniert es ….
            Eigentlich sollte es dann nicht „Scrum“ genannt werden …
            Aber eben: Es gibt ja keinen „Bundesverfassungegerichtshof für Scrum“ der entscheidet, was Scrum genannt werden darf …

  2. Hi Rolf,

    danke, so spar ich mir das Dokument zu lesen, denn das klingt nach Zeitverschwendung. Klingt nach weichgeprügelt durch zu viel Consulting und einer Aufgabe vor dem eigenen Werk. Man könnte es auch Bibel für klassische Consulting-Fehler oder Fehler bei einer Scrum-Einführung nennen.

    Naja, vielleicht schau ich mir den Guide doch noch an. Wobei ich Konjunktive nicht mag 😉

    Grüßle,
    Sven

  3. Hallo Rolf,

    schöne, kritische Zusammenfassung der Änderungen im Text und der schleichenden Veränderung der Schwerpunkte von Scrum.

    Mir fehlt bei der Betrachtung noch, das jetzt die Kapazität („projected capacity of the Development Team“) als Voraussetzung für die Sprint-Planung genannt wird.

    Für mich war und ist Scrum vor allem ein Denkmodell und Idealzustand als ein immer 1:1 umzusetzendes Framework. Gerade deswegen freue ich mich über die jetzt inkludierten Sprint Goals und ärgere mich über immer weiter reduzierte Verbindlichkeit und dem Wegfall der Vision.

    Allgemein bin ich aktuell verwundert über die Diskussionskultur bei einigen agilen Vordenkern, u.a. Ken.

    Grüße
    Felix

    1. Hallo Felix,

      zur Sicherheit hab ich’s nochmal nachgeprüft – die „projected capacity“ gab es schon im Scrum Guide 2011 beim Input für die Sprintplanung. Vielleicht hattest Du mit dem Scrum Guide 2010 verglichen?

      „Denkmodell und Idealzustand“ finde ich eine sehr gute Formulierung. Ich sage meistens noch stärker „Glaubensbekenntnis“ dazu, aus einem einfachen Grund: solange es keine wissenschaftlich fundierte Aussagen darüber gibt, welche Methodiken „allgemein“ bessere Resultate bringen als andere, hängt für mich der Erfolg von Teams entscheidend von ihrem Glauben an ihren Weg ab. Insofern sehe ich heute viele Scrum-Getaufte und eher weniger Scrum-Gläubige.

      Je weniger Du wirklich glaubst, desto mehr Abstriche und Relativierungen hältst Du im Laufe der Zeit für erträglich. Das kann man für den normalen Lauf der Dinge halten, aber lobpreisen muss man es nicht. Außer als Anstoß für einen neuen Glauben. 😉

      Gruß,
      Rolf

  4. Im Scrum Guide 2013 steht: „Scrum (n): A framework within which people can address complex adaptive problems“

    Die Lösung komplexer adaptiver Probleme erfordert jedoch immer ein spezifisches und einmaliges Vorgehen. Dabei werden jedoch bekannte „Vorgehensmuster“ – angepasst – genutzt und bestimmte übergreifende Techniken eingesetzt. Und es werden bestimmte allgemeine Prinzipien – etwa die 12 Prinzipien des Agilen Manifests – verfolgt.
    Im Bereich des Projektkmanagements ist PRINCE2 etwa eine Sammlung solcher „Vorgehesnmuster“, die jedoch je nach Situation spezifisch „zurechzuschneidern“ sind. Auch für dieses „tailoring“ beschreibt PRINCE2 übrigens „Vorgehensmuster“.

    Scrum kennt das nicht. Im Gegenteil, es verneint sogar das „tailoring“ explizit: Ken schreibt das: „Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety.“
    Komplexe adaptive Probleme können damit nicht gelöst werden. Das passt eher zu wiederkehrenden und recht gut bekannten Aufgabenstellungen wie das Konfigurieren eines Webshops.

    Scrum stets 1:1 einsetzen zu wollen entspricht einem statischen, formalistischen und sicher nicht „agilen“ Denken und Handeln.

    Wobei ich unter „agil“ das verstehe:

    • Robustheit: die Fähigkeit, aufgaben-, situations- und bedingungsübergreifend effektiv zu bleiben;
    • Belastbarkeit: die Fähigkeit, sich von Unglücksfällen, Schäden oder einer destabilisierenden Störung der Umgebung zu erholen oder sich darauf einzustellen;
    • Reaktionsfähigkeit: die Fähigkeit, auf eine Veränderung der Umgebung rechtzeitig zu reagieren;
    • Flexibilität: die Fähigkeit, mehrere Lösungsmöglichkeiten einzusetzen und nahtlos von einer zur anderen überzugehen;
    • Innovationsfähigkeit: die Fähigkeit, neue Dinge zu tun und die Fähigkeit, alte Dinge auf eine neue Art und Weise zu tun;
    • Anpassungsfähigkeit: die Fähigkeit, Arbeitsprozesse zu ändern und die Fähigkeit, die Organisation zu ändern.

    (gemäss Alberts, David S.; Hayes, Richard E.; Honekamp, Wilfried (Übersetzer): Power to the Edge. Re Di Roma Verlag, 2009)

    Möglicherweise sind die von Rolf eingangs aufgezählten jetzt neu hinzugekommenen Relativierungen ein zaghafter Versuch, dieses „tailoring“ durch die Hintertüre doch noch zu ermöglichen.

  5. Danke Rolf für deine Zusammenfassung, schaut nach Arbeit aus 🙂

    Mein Feedback:

    „später fiel mir dann ein, dass Scrum-Werte wie Offenheit und Mut nicht mehr Teil des Scrum Guides sind“ – Das finde ich persönlich schade (Der Link s.u. auf #values leitet, glaube ich, falsch um, er geht auf die Startseite).

    „das Wort «vision» taucht jetzt im Scrum Guide nirgendwo mehr auf.“ – Hm, bisher habe ich es so verstanden das es die Aufgabe des Product Owners aus einer Vision ein klares Produkt mit Anforderungen zu formen. Eine Vision, im Sinne einer ersten Idee die zu einem langfristigen Ziel wird – ist aus meiner Sicht zwingend notwendig.

    Habe ich da etwas falsch verstanden?

    1. Danke Dir, habe den Link korrigiert.

      Ich glaube nicht, dass wir den Stellenwert der Vision falsch verstanden haben. Wenn man dem Scrum Team jetzt keine Vision mehr vermitteln muss, entfällt aber auch der Druck, sich eine überzeugende einfallen lassen zu müssen. Vielleicht ist das ja so beabsichtigt?

      Gruß,
      Rolf

      1. Ich finde es logisch, dass „Vision“ nicht mehr erscheint. Im Guide 2011 hieß es:
        „The Scrum Master serves the Product Owner in several ways, including:… Clearly communicating vision, goals, and Product Backlog items to the Development Team;“
        Diese Formulierung hat mich gestört: Damit wurde nämlich die essentielle Trennung der Verantwortung für das WAS (= PO) und dem WIE (= Dev.Team) und für das Vorgehen als solches ( = SM) verwischt. Und der SM wurde damit „zum verlängerten Arm des PO im Team“. Für mich ist aber „Clearly communicating vision, goals, and Product Backlog items to the Development Team“ eine nicht delegierbare Aufgabe des PO, die er tagtäglich (und nicht nur beim planning) als Mitglied des Scrum-Teams zu leisten hat.
        Jetzt könnte man natürlich argumentieren, dass das „communicating vision … to the Development Team“ als Aufgabe des PO erscheinen müsste. Dem würde ich zustimmen, wenn der Scrum Guide Sprint-übegreifende Artefakte und Ereignisse beschreiben würde, also etwas in Richtung Releases oder Gesamtprodukt. Ab der Version 2011 jedoch beschränkt sich der Guide bewusst nur auf das, was EINEN Sprint betrifft mit der Begründung, dass die Regeln nur das in allen Fällen Erforderliche beschreiben und nicht Dinge, die optional sind. Und Releases sind eben nicht zwingend sondern nur in bestimmten Situationen nötig.
        Wegen der Begrenzung nur auf den Sprint als solches wird logischerweise auch keine etliche Sprints umfassende Produktvision erwähnt (und dieser im Guide 2011 daher unlogische Passus gestrichen). Statt dessen gibt es ein klar hervorgehobenes „Sprint Goal“ als essentielle Orientierung.

        Für all das, was einen Sprint überschreitet gilt weiterhin: „Scrum exists … as a container for other techniques, methodologies, and practices.“
        Dazhu würde ich auch die Erarbeitung und Vermittlung der – in der Regel teamübergreifenden – Produktvision sehen, etwa in diesem Sinn: http://www.scaledagileframework.com/vision/

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.