SCRUM

SCRUM

Posts 1-9 of 9
  • Hans-Peter Korn
    Hans-Peter Korn    Group moderator
    The company name is only visible to registered members.
    (In Englisch, weil ich diese Frage an die scrum Alliance via http://agileatlas.org/meta/contact stellte. Antworten in Deutsch willkommen)

    There is a Scrum Guide at scrum.org calling himself "The Definitive Guide to Scrum:
    The Rules of the Game" and - at the end of the content - "Scrum’s roles, artefacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.". And Ken underlies this here: http://www.scrum.org/Portals/0/Documents/Scrum%20Updates/Scr...

    And there is a "Core Scrum" http://agileatlas.org/images/uploads/corescrum.pdf with some important differences compared with the Scrum Guide. For example: In the Scrum Guide I read: "After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.... The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.
    As the Development Team works, it keeps this goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, then they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint."
    In Core Scrum I read: "Often, but not always, the Sprint is given a goal, called the Sprint Goal. This is a very strong practice which helps everyone focus more on the essence of what needs to be done, and less on small details which may not be important to what we really need to accomplish." And this is not mentioned: "The Sprint Goal gives the Development Team some flexibility regarding the functionality"
    An other important difference:
    In Core Scrum I read: "The Development Team forecasts the amount of work they will complete and commit to each other to accomplish it." This is in my understanding that kind of commitment for specific backlog items as it was in the earlier versions of the Scrum Guide and was eliminated in 2011 and changed to:
    " (in part one) the Development Team forecasts the Product Backlog items it will deliver in the Sprint. ...By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment."

    For me this are fundamental differences which may lead to al lot of less useful discussions about the "right" rules of Scrum within a team of "scrum.org - Scrummies" together with "Scrum Alliance - Scrummies"

    So: Should the Scrum Guide be seen as "THE rule of the game" and the Core scrum as a "description" only?
    And: In case of doubt does the Scrum Guide have the lead?
    This post was modified on 05 Apr 2013 at 11:40 pm.
  • Sabine Canditt
    Sabine Canditt    Premium Member   Group moderator
    The company name is only visible to registered members.
    scrum.org und die Scrum Alliance sind zwei unterschiedliche Organisationen mit unterschiedlichen Zertifizierungsprogrammen. Um voneinander unabhängig sein zu können, brauchen beide Organisationen eine Referenz, die der Zertifizierung zu Grunde liegt, und die sie selbst beeinflussen können.

    Der Scrum Guide von scrum.org ist geschrieben von zwei Autoren, Ken Schwaber und Jeff Sutherland. Ob es weitere Personen gibt, die den Scrum Guide beeinflussen können, kann ich nicht sagen, aber ich kann sagen, dass die Scrum Alliance KEINEN Einfluss darauf hat. Core Scrum ist durch einen comminity process der Certified Scrum Trainer und Coaches der Scrum Alliance entstanden. Dabei haben wir versucht, uns an den Scrum Guide anzulehnen, an einigen Stellen sind aber wie bemerkt auch Unterschiede entstanden. Core Scrum ist jetzt für die Scrum Alliance das, was der Scrum Guide für scrum.org ist. (also kein Unterschied zwischen "rule of the game" und "description"). Die Scrum Alliance wird sich auch in Zukunft bemühen, die Unterschiede gering zu halten, dem Scrum Guide aber nicht um jeden Preis in allem folgen.

    Viele Grüße
    Sabine
  • Hans-Peter Korn
    Hans-Peter Korn    Group moderator
    The company name is only visible to registered members.
    Danke, Sabine, für deine klare Antwort.

    Ab jetzt haben wir also zwei Varianten von Scrum mit jeweils darauf basierenden "Zertifizierungen" bzw. "Assessments".

    Jetzt bereits gibt es zwischen beiden "Regelsätzen" für mich wesentliche Unterschiede - nebst den ganz oben beschriebenen Unterschieden betr. "Sprint-Ziel" und "committment auf spezifische Backlog-Items" versus "Flexibilität innerhalb des Sprint-Ziels".
    So etwa bei der Rolle des PO und des SM. Oder bezüglich der Lebensdauer des Produkt Backlog. Oder dazu, wer aller sich beim Daily äussern kann. Und im Core Scrum der Scrum Alliance fehlen gegenüber dem Scrum Guide für mich essentielle Aussagen wie die "drei Säulen von Scrum", zur Teamgrösse, zum Sprint-Abbruch zur Beurteilung des "Fortschritts Richtung Ziel" und schlussendlich diese klare Aussage: "Scrum wird in diesem Leitfaden angeboten. Die Rollen, Artefakte und Ereignisse von Scrum sind unantastbar. Obwohl es möglich ist, nur Teile von Scrum zu implementieren, ist das Ergebnis nicht Scrum". "Core Scrum" stellt diese Forderung nicht - und bietet daher keine Grundlage, um so etwas wie ein "Scrum - but" zu erkennen.

    Schade, dass wir nun auch im Bereich Scrum zwei "Schulen" haben. Für die Nutzer von Scrum sehr unbefriedigend - jedes Team muss sich nun entscheiden, welcher Schule es folgt, Und innerhalb einer Firma stellt sich auch die Frage, ob alle Teams nach nur einer dieser "Schulen" vorgehen.

    Beste Grüsse
    Hans-Peter
    This post was modified on 07 Apr 2013 at 04:59 pm.
  • Sabine Canditt
    Sabine Canditt    Premium Member   Group moderator
    The company name is only visible to registered members.
    Zu all den Themen, die du nennst, gibt es unterschiedliche Einschätzungen, die sich nun in diesen beiden grundlegenden Richtlinien niedergeschlagen haben. In der Realität gibt es noch deutlich mehr Varianten. Man denke nur an die vielen Fachbücher, die eine Definition von Scrum beinhalten. Für mich als Anhängerin der Scrum Alliance Variante ist Core Scrum ein echter Durchbruch. Ich habe nichts dagegen, wenn deutlich wird, dass sich auch die Experten nicht immer einig sind. Das fördert für meine Begriffe eine kritische Auseinandersetzung, anstatt blindes Befolgen eines Dogmas zu verlangen.

    Wenn jemand gerne eine ScrumBut-Diskussion auf Basis des Core Scrum führen möchte, wird ihm das sicherlich gelingen, genauso gut oder genaus schlecht wie mit dem Scrum Guide. Ich finde die ScrumBut-Diskussion nicht besonders hilfreich, da sie alles, was nicht dem Regelwerk 1:1 entspricht, erst einmal abqualifiziert. Mir gefällt zu diesem Thema gut der Blog-Beitrag von Bernd Schiffer "Blasphemy! They call it Scrum!" http://agiletrail.com/2013/03/27/blasphemy-they-call-it-scru.... Er unterscheidet zwischen Novizen, denen ein Vorgehen "by the book" anzuempfehlen ist, und Praktikern, die bereits über einiges an eigener Erfahrung mit Scrum verfügen und Innovationen möchten.

    In der Praxis halte ich die Unterschiede zwischen Scrum Guide und Core Scrum für undramatisch. In meinen Trainings spreche ich z.B. mit meinen Teilnehmern über die Begriffe "forecast" und "commitment", und wir diskutieren über die Unterschiede und die Vor- und Nachteile. Ich rege an, auch mit dem eigenen Team eine solche Diskussion zu führen, damit man sich darüber im klaren und einig ist, was man da eigentlich abgibt im Sprint Planning.

    Einen schönen Sonntag noch!
    Sabine
  • Hans-Peter Korn
    Hans-Peter Korn    Group moderator
    The company name is only visible to registered members.
    Da sind wir - wieder mal - an einem grundlegenden Punkt, der bei Scrum bereits seit vielen Jahren diskutiert wird:

    "Ist es erlaubt, Scrum anders als beschrieben zu praktizieren?"

    Ich möchte zunächst mal diesen Satz in Ken's Scrum Guide ausser acht lassen: "Obwohl es möglich ist, nur Teile von Scrum zu implementieren, ist das Ergebnis nicht Scrum. Scrum existiert nur in seiner Gesamtheit", begründet u.a. hier: http://www.scrum.org/Portals/0/Documents/Scrum%20Updates/Scr... und statt dessen von dieser Überlegung ausgehen:

    Bei jeder Vorgehensweise in einem Unternehmen steht diese Frage am Ausgangspunkt:
    "Was wollen wir mit dieser Vorgehensweise bezogen auf unsere Produkte und Kunden und bezogen auf das Wohl unseres Unternehmens in erster Linie erreichen?"
    Danach folgen - bei einer professionellen Prozess- und Organisationsveränderung - diese Überlegungen:
    "Welche Vorgehensweise - unter Berücksichtigung unserer verschiedenartigen Ressourcen und all dessen, was jetzt bereits ganz gut funktioniert - passt dazu am besten?"
    Als Antwort sind Vorgehensweisen bei anderen Firmen und Muster-"Frameworks" und -"Methoden" gute Orientierungshilfen. Stets aber im Bewusstsein, dass es hier keine "best practices" gibt. Denn jede Situation ist unterschiedlich und es ist höchst kontraproduktiv, irgend eine Art von angeblicher "best practice" oder "Standardlösung" 1:1 einsetzen zu wollen.
    So gesehen ist auch Scrum eine "Standardlösung", deren 1:1 - Einsatz nur in den seltensten Ausnahmen funktionieren wird.

    Scrum jedoch verlangt genau das Gegenteil: Es sei, wird immer wieder betont (siehe auch Bernd Schiffer in http://agiletrail.com/2013/03/27/blasphemy-they-call-it-scru... ) zumindest zu Beginn 1:1 einzusetzen und erst auf Basis der damit gemachten Erfahrungen sollte es verändert werden. Und wenn es verändert wird, dann nur so, dass seine Regeln weiterhin unverändert gelten, jedoch im Sinn eines "Scrum - AND" (siehe Ken in http://agiletrail.com/2013/03/27/blasphemy-they-call-it-scru...) und nicht als "Scrum - BUT".
    Bernd schreibt dazu in seinem blog: “ScrumBut is considered to be bad. I agree. ScrumBut means avoiding problems rather than solving them. It’s like smashing the thermometer just because you discovered a fever.” Also: Es wird behauptet, dass nur das “echte” Scrum problemlos funktioniert. Sehr oft erzeugt Scrum aber Probleme – z.B. wegen der in grossen Firmen unrealistischen Rolle des Scrum PO – die gar keine sind. Ein falsch anzeigendes Thermometer sollte man aber besser wegwerfen.

    Und jetzt wieder zur Ken Schwaber's "Obwohl es möglich ist, nur Teile von Scrum zu implementieren, ist das Ergebnis nicht Scrum":
    Ich respektiere diesen seinen Wunsch als - zusammen mit Jeff - "Vater" von Scrum.
    Meine Konsequenz daraus:
    Ich rede nur dann von "Scrum", wenn es 1:1 dem Scrum Guide entspricht. Da aber, da jede Situation unterschiedlich ist, der 1:1 Einsatz von "Standardlösung" nur in den seltensten Ausnahmen funktioniert, wird dieses "Scrum" nur selten funktionieren.
    Ich unterstütze daher Vorgehensweisen, die zur spezifischen Situation passen und sich - u.a. - von Scrum inspirieren lassen, es aber nicht voll übernehmen.
    Das Ergebnis nenne ich jedoch bewusst nicht "Scrum" sondern bestenfalls "an Scrum orientiert" oder "Scrum-artig". Ich rede dabei auch nicht - abwertend - von "Scrum-But". So etwas gibt es für mich nicht. Es ist eine Desavouierung des ehrlichen und professionellen Bemühens eines Unternehmens oder eines Teams, die zu ihm passende Vorgehensweise zu finden. Und zwar von Anfang an - und nicht erst nach dem Ausprobieren eines 1:1-Scrum, bei dem schon zu Beginn klar ist, was in dieser Situation nicht funktionieren wird. Das ist "Change-Waste".

    Als "Referenz" jedoch finde ich den Scrum Guide - auch wegen seiner Striktheit - sehr wichtig. Das zwingt dazu, sich genau zu überlegen, was der Nutzen davon ist, in einer spezifischen Situation von einigen seiner Regeln abzuweichen.
    Als Richtschnur dieser Überlegungen ist IMHO auch recht hilfreich auf Basis von: http://kenschwaber.wordpress.com/2012/10/05/what-comes-after... zu fragen: "Verlassen wir dabei auch einen dieser vier Punkte? Und wenn ja: Ist uns klar, was uns dazu zwingt? Was wir damit gewinnen?"

    Der Umstand, dass es jetzt zwei solcher Referenzen gibt macht die Sache unnötig komplex. Bisher war es schon komplex genug, dass es in Fachbüchern unterschiedliche Sichtweisen gab.
    Wenn "Core Scrum" nun einige der real gelebten deutlichen Abweichungen vom "Scrum Guide" zu gültigen Regeln erklärt, wird eine zweite weniger anspruchsvolle Referenz geschaffen. Ein "echter Durchbruch* ist das für mich nicht ... eher ein "Zurückbuchstabieren".

    Guten Wochenstart,
    Hans-Peter
  • Jean Pierre Berchez
    Jean Pierre Berchez    Premium Member   Group moderator
    The company name is only visible to registered members.
    Hallo HP,

    Die Gefahr besteht, dass sich das Ganze noch weiter auseinander bewegt.

    Ich habe von Jeff gehört, dass Ken und Jeff überlegen das Planning Meeting evtl. auf ein Meeting zu reduzieren. Sprich es gibt dann im Scrum-Guide keinen Teil1 und Teil2 mehr.
    Dafür aber soll "Backlog Grooming" oder auch "Product Backlog Refinement" (wie es im Agile Atlas heißt und bereits aufgenommen ist) als Aktivität in den Scrum-Guide aufgenommen werden.

    Na ja es bleibt auf jeden Fall spannend. Ich hoffe nur, dass die beiden "Bibeln" nicht zu sehr voneinander abweichen und beide Organisationen vorsichtig und bedacht nach dem Prinzip "Inspect & Adapt" vorgehen und kein "Adapt & Inspect" (frei nach Markus Meuten) praktizieren.

    v.G.
    JP
  • Hans-Peter Korn
    Hans-Peter Korn    Group moderator
    The company name is only visible to registered members.
    Hallo JP,

    "Die Gefahr besteht, dass sich das Ganze noch weiter auseinander bewegt.".

    Für mich - nachdem wir ohnehin schon zwei Schulen haben - besteht hier auch die Chance, die Idee aufzugeben, dass Scum nur dann Scrum ist, wenn es klar definierten Regeln 1:1 folgt, so wie es im Scrum Guide steht.
    Und statt dessen gibt es tausende - zur jeweiligen Situation passende - Varianten von Scrum. Und daher auch keine Scrum - but.
    Und daher auch keine von Scrum-Zertifizierungen lebende Organisationen mehr. Denn bei dieser Menge an Varianten braucht es keine solchen engen Zertifizierungen mehr. Sondern statt dessen etliche Ausbildungsstätten, etwa auch an Hochschulen, die (auch) das iterativ-inkrementell-adaptive Vorgehen und dafür nützliche weitere optionale Methoden (wie Tom Gilb schreibt) auf breiterer Basis und ohne missionarischen Eifer lehren und beforschen. Und insbesondere auch die Hintergründe, nicht nur die "Kochbücher".

    <8-) Hans-Peter
  • Jean Pierre Berchez
    Jean Pierre Berchez    Premium Member   Group moderator
    The company name is only visible to registered members.
    Du weist ja wie das ist mit dem Kochen. - Auch ein Sternekoch hat mal mit einem Kochbuch begonnen -
    Im Bezug auf Scrum haben Dominik und ich mir mal Gedanken darüber gemacht. Dominik hat dann einen Blog Eintrag geschrieben der zum Thema gut passt. Schau mal auf: http://scrumorakel.de/blog/index.php?/archives/38-One-Scrumg...
    cheers JP
  • Hans-Peter Korn
    Hans-Peter Korn    Group moderator
    The company name is only visible to registered members.
    Ja, die drei an Shu Ha Ri angelehnten Varianten im Sinn von "Abstaktionen", die jedoch alle gleichzeitig gelten (so verstehe ich den Blog) machen Sinn - sofern sie aus derselben "Küche" kommen.
    Jetzt aber haben wir zwei Shu-Versionen. eine (wie bisher) von der scrum.org und eine (neue) von der Scrum Alliance.
 
Sign up for free: