ScrumCorp Individuelle Skalierung Beispiele:

Rollen

Im ScrumCorp Modell finden sich die klassischen Scrum Rollen in der gleichen Funktion wieder. Unterstützung in Form von Konzeption, Design und Qualitätssicherung haben wir nahtlos integriert sowie die Unternehmensführung, die sich im klassischen Modell nicht behandelt wird.

Entwicklungsteam

Entwicklerteam Beschreibung:
Das Entwicklerteam ist ein Kollektiv aus Individuen, das gemeinsam an einem Inkrement arbeitet, welches am Ende des Sprints potenziell zu veröffentlichen ist.

Durch den Scrum Master wird es zur Selbstorganisation geschult, welche sich in verschiedenen Teilen auslegt. Bei Probleme werden die Entwickler am Anfang auf den Scrum Master zugehen, mit der Zeit werden sie diese Probleme selbst in die Hand nehmen können und diese eigenständig lösen. Jeder einzelne Entwickler wird mit verschiedenen Fähigkeiten zu dem Inkrement beitragen, sodass das Team cross-funktional aufgebaut ist.

Jede Fähigkeit, die erwünscht und gewünscht ist, wird entweder geschult, oder durch einen Entwickler eingeführt bzw. durch Workshops ausgebaut. Aus unseren Erfahrungen heraus bildet sich die Empfehlung, dass ein Team aus zwei bis fünf Entwicklern, keinem oder einem Userinterface Designer (UI Designer) und mindestens ein bis zwei Testern besteht.

Die Gesamtgröße von 8+ dem Team Backlog Owner und dem Scrum Master sollte nicht überschritten werden, dadurch leidet die Kommunikation und es kann sich Unordnung breit machen. Mit diesem Konzept können Sie jegliche Produktentwicklung abdecken.

Benötigen Sie mehr Tester oder einen weiteren Entwickler? Sind alle Tests abgedeckt und laufen diese automatisiert? So sollte der Scrum Master auf das Team hören und Sie können es ganz frei anpassen. Wichtig vor allem hierbei ist, dass der Scrum Master eng mit dem Team zusammenarbeitet, um etwaige Hindernisse zu lösen, selbst wenn es sich nur darum handelt, dass das Team einen Raum für einen Workshop benötigt. Zudem muss das Team durch den Team Backlog Owner stetig mit Wissen um das Produkt informiert werden, damit es weiß woran es aus welchem Grund arbeitet. Steigert sich die Erfahrung als Team, wird nach jedem Sprint ein Inkrement fertig gestellt und die Motivation der einzelnen Entwicklern wird ausgebaut.

Scrum Master

Scrum Master Beschreibung:
Der Scrum Master ist eine neutrale Institution innerhalb eines Teams, um es zur Selbstorganisation, Autonomie und zu der agilen Denkweise zu bringen.

Er sollte nah am Team arbeiten um diese Denkweise zu schulen. Jedes Team wird verschiedene Phasen durchgehen und der Scrum Master wird im besten Falle vom ersten Tag dabei sein. Steht ein Hindernis an? Gibt es ein Problem, welches außerhalb des Teams liegt? Dann kümmert sich der Scrum Master im Handumdrehen darum. Er besorgt Kontaktdaten, hilft in jeglicher Art und unterstützt die Entwickler, wo er kann.

Scrum-Events werden von ihm durchgeführt und moderiert, sowie Workshops, die vom Team gebraucht bzw. benötigt werden. Jegliche Anfragen des Teams werden vom Scrum Master berücksichtigt und respektiert, er sollte sich an die Kultur der Gruppe anpassen und sie im besten Falle mitprägen.

Das Thema Neutralität spielt eine besondere Rolle, da der Scrum Master als Mediator und Vermittler agiert und somit keine parteiische Funktion hat. Löst sich ein Team auf? Bildet sich ein neues Team? Der Scrum Master kann in beiden Fällen Empfehlungen aussprechen und die Leute somit zu ihren geeignetsten Plätzen führen. Er ist eine „Feelgood“ – Person die durch eine motivierende Art und Weise das Team am laufen hält. Werden kritische Themen in einer Retrospektive angesprochen? Somit ist auch Diskretion gefragt, um das Vertrauen des Teams zu erlangen und aufrecht zu erhalten.

PO

Product Owner Beschreibung:
Der Product Owner im klassischen Scrum Framework ist die Person im Unternehmen, die die Vision des Produktes entwickelt, durchsetzt und umsetzten will. Zudem ist er das Ohr für die wichtige Kundenresonanz, sodass die Wünsche, die Anregungen, oder Änderungen des Stakeholders sehr schnell an das Entwicklerteam weitergegeben werden und zur Implementierung führen. Das Stakeholdermanagement ist die Stärke des Product Owners, denn dadurch ist er nach jeder erfolgreichen Sprintreview uptodate. Im ScrumCorp Framework werden mehrere Product Owner genannt, auf diese gehen wir nun ein.

MPO

Multiple Products Owner Beschreibung:
Als Product Owner ist das Produkt das Kind von einem, man behütet es und will es wachsen sehen. Als Multiple Product Owner (MPO) verantwortet man mehrere Scrum Teams und mehrere Produkte, wie es der Name schon sagt. Dies kann zu einem Anforderungsstau führen, den wir als ScrumCorp mit dem Team Backlog Owner umgehen, dazu später mehr.

CEPO/CFPO/CTPO

Corporoate Executive Product Owner/ Corporoate Financial Product Owner/Corporoate Technical Product Owner Beschreibung:
Der Coporate Technical Product Owner (CTPO) kümmert sich darum, dass die Systeme für eine agile Entwicklung funktionieren. Bestellung von neuer Software, Development Pipelines, Environments und Ähnlichem gehören zu seinen Kompetenzen.

Der Corporate Financial Product Owner (CFPO) ist verantwortlich für das OnBoarding, den Einkauf und die finanziellen Mittel in einem Projekt kümmert. Brauchen die Teams einen Java-Entwickler? Wird ein weiterer Architekt benötigt? Der CFPO gibt die Freigaben und schaut auf die Finanzen.

Der Corporate Executive Product Owner (CEPO) ist die ausführende Kraft des Unternehmens, wenn es um das Thema Agilität und Scrum geht. Dieser Product Owner ist geschulter Agilist und weiß wie er das Unternehmen gestalten möchte, um auf den Markt agil zu reagieren. Er führt die Agilität an und weiß, wo er diese auch durchgesetzt haben möchte. Haben die Leute Fragen zur Agilität? Zu Scrum? Brauchen die Leute mehr Workshops, die von den Scrum Mastern durchgeführt werden sollen?
All diese Fragen kann der CEPO beantworten. Wie Sie sehen, haben wir einige Änderungen und Ideen einfließen lassen, um die Rolle des Product Owners nicht nur auszuführen, sondern auch zu spezialisieren.

Stakeholder

Stakeholder Beschreibung:
Sponsoren, Investoren, Kunden oder allgemeine Anforderungssteller werden als Stakeholder bezeichnet, ob intern oder extern. Jeder der Interesse an dem Produkt und dem Prozess hat, kann als Anforderungssteller in Frage kommen. Diese Anforderungen werden als User-Stories erfasst und vom Team umgesetzt.

Stakeholders sind die Quintessenz, die den Weg des Entwicklerteams darstellt, denn sie geben das wichtige Feedback und den wichtigen Input. Als Stakeholder wird man primär mit dem Product Owner zu tun haben, der unterstützend von dem Scrum Master, sowie dem Entwicklerteam begleitet wird, um ein erfolgreiches Stakeholdermanagement durchzuführen.

TBO

Team Backlog Owner Beschreibung:
Wie Sie schon mittlerweile festgestellt haben, ist die Rolle des Team Backlog Owners in keinem anderen Agile-Framework vorhanden und ist exklusiv von ScrumCorp entworfen worden.

Die Notwendigkeit für diese Rolle ergab sich aus verschiedenen Situationen, in denen der Product Owner sich nicht zu Hundertprozent um das Team kümmern konnte, aufgrund von stetigen Meetings oder Ähnlichem. Der Product Owner trägt Verantwortung für das Produkt, die Entscheidungen und die Aufnahme des Stakeholder Feedbacks und ist im skalierten Umfeld in stetiger Absprache mit anderen Product Ownern. Aufgrund dieser zeitlichen Auslastung leidet am Ende das Entwicklerteam.

Es kann vorkommen, dass das Refinement, Sprint-Planning und andere Scrum Events nicht zur Vollständigkeit kommen. Um diese Lücken nicht aufkommen zu lassen, tritt ScrumCorp mit einer Lösung an den Markt, die genau diesen Problemen entgegen tritt, nämlich mit dem Team Backlog Owner.

Als Empfehlung für diese Rolle sehen wir entweder eine/n ausgebildete/n Business AnalystIn oder eine/n User Experience DesignerIn vor. Aufgrund der erworbenen Kenntnisse über Marktstrategien und Kundenzufriedenheit, können diese beiden Berufsfelder die Rolle des Team Backlog Owners am ehesten übernehmen.

Kennen Sie jemanden in ihren Unternehmen, der ebenfalls diese Rolle ausfüllen könnte? Gehen Sie auf diese Person zu, auch wenn es sich hierbei nicht um eine/n UXD oder BA handelt. Das Besondere an dieser Rolle ist, dass sie für das Backlog zuständig ist, während im klassischen agilen Framework der Product Owner alleine diese Kompetenz hat.

Der Product Owner oder Multiple Product Owner entscheidet immer noch darüber, in welche Richtung das Produkt gehen soll und er ist immer noch der erste Ansprechpartner, was den Wunsch des Kunden angeht. Um dies aber zu erfüllen und die Informationen schnell an das Team weiterzuleiten, hilft der Team Backlog Owner als Kompensator, sodass etwaige Verzögerungen gar nicht erst auftreten.

Durch diese Durchlaufstation konstruiert man einen stetigen Informationsfluss.

Ereignisse

Die verschiedenen Scrum Ereignisse haben klare Vorgaben die wir Ihnen gerne etwas detaillierter erläutern möchten. Wir sind bemüht die Informationen in Grafiken darzustellen um Ihnen Zeit zu ersparen und damit Sie ScrumCorp.de als grafisches Nachschlagewerk für Scrum nutzen können.

Das Scrum Framework

Timebox: 1-4 Wochen
Zweck: Sprint Inkrement produzieren
Teilnehmer:

  • Entwicklerteam
  • ScrumMaster
  • Product Owner

Ablauf:
Der Sprint ist das Herzstück von Scrum. Das Entwicklerteam entwickelt selbstorganisierend das vom Product Owner definierte Sprint Inkrement. Die Sprintdauer ist ein fester Iterations-Zyklus und sollte nur in allerhöchsten Notfällen geändert werden.

Daily Scrum

Timebox: täglich zur gleichen Zeit, 15 Min.

Stellen Sie sich vor, Sie hätten ein Treffen, welches täglich stattfindet, um über Probleme, Lösungen und mit den Menschen offen zu kommunizieren, mit denen sie tagtäglich zusammen arbeiten? Genau dies ist das Daily.

Ein maximal fünfzehnminütiges Team-Treffen, in dem der Entwickler einen Einblick gibt woran er gerade arbeitet und was ihn daran hindert. Kommunikation ist alles in diesen fünfzehn Minuten. Dezidiertes Wissen, welches für die Gemeinschaft wichtig ist, wird geteilt, um auch etwaige nächste Aktionen zu planen und auf alles zu reagieren, was vielleicht kritisch sein könnte.

Der Scrum Master nimmt am Anfang eine wichtige Rolle ein, insbesondere bei Teams, die mit diesem Informationsaustausch noch nicht lange vertraut sind.

Später, wenn das Team gereift ist, wird es dazu kommen, dass es sich selbstorganisiert zum Daily trifft, dieses durchführt und auf Probleme selbst reagiert.

Das Daily ist ein Teamtreffen und die Betonung liegt auf Team. Der Product Owner kann gerne an dem Daily teilnehmen, sollte sich aber zurückhalten und keine Informationen abfragen. Das Team berichtet weder an den Scrum Master, noch an den Product Owner. Es ist ein wertvolles Treffen, das zu einem weitgefächerten Verständnis führen kann und das Team, durch den Scrum Master, auf Kurs hält.

Sprint Review

Timebox: 1,5 Stunden pro Sprint-Woche/ max. vier Stunden

Am Ende des Sprints findet eine Sprintreview statt, in der das Entwicklerteam den eingeladenen Stakeholdern und dem Product Owner zeigen kann, was es fertiggestellt hat.

Wichtig hierbei ist, dass es Software ist, die Live gezeigt wird, keine Mockups, keine Powerpoint oder Ähnliches. Ausnahmen sind nur angedacht, wenn man Dinge aus dem Backend zeigt, die schwer für Stakeholder nachzuvollziehen sind. Das Inkrement, das gezeigt wird, soll potenziell auslieferbar sein. Es muss keine völlige Funktion, oder ein vollständiges Feature sein. Manchmal möchten Stakeholder auch nur Kleinigkeiten in einem Sprint geändert haben.

Wie man eine Sprintreview aufbaut, ist jedem Team selbst überlassen. Damit die Entwickler nicht als Ressource wahrgenommen werden, sondern als Menschen, liegt es auf der Hand die Sprintreview in einer für die Entwickler gewohnten Umgebung stattfinden zu lassen, wie z.B. den Entwicklerraum. Die Sprintreview soll keinen Abnahmecharakter haben, der Product Owner hat im besten Fall vorher alle User-Stories auf „done“ gesetzt und weiß, was das Team zeigen wird.

Anhand einer Agenda ist das sehr gut sichtbar zu machen und führt auch bei den Stakeholdern zu keiner Verwirrung. Einleitende An- und Abmoderation übernimmt gerne der Scrum Master. Jeder Entwickler zeigt dann woran er tatsächlich gearbeitet hat. Die Stärke der Review ist das Feedback, was von den Stakeholdern eingeholt wird. Gespräche und Lobungen für die Entwickler, für den Product Owner und daraus resultierende weiterführende Dinge die man für die Stakeholder entwickeln.

Sprint Retrospektive

Timebox: 45 Minuten pro Sprint-Woche

Die Retrospektive ist das stärkste Werkzeug für die Entwicklung der Teamstruktur. Bei diesem Event, das von dem Scrum Master moderiert wird, werden nach und nach Ideen gesammelt, um anschließend daraus Maßnahmen zu formulieren. Dies dient führt zu einem ständigen Verbesserungsprozess. Es gibt mehrere Methoden dazu wie man eine Retrospektive aufbaut und diese ablaufen lässt.

Die Retrospektive findet am Ende des Sprints statt, nach der Sprintreview vor dem Sprintplanning für den nächsten Sprint. Sie dient als Raum, in welchem der Entwickler sich freie Luft schaffen kann, um seine Meinung frei zu äußern. Der Product Owner kann geladen werden, ist aber kein fester Bestandteil der Retrospektive.

Dadurch dass sich in einem Sprint mehrere Probleme oder Reibungen ergeben, können diese in der Retrospektive angesprochen, vertieft und gelöst werden. Ebenso kann man positives vertiefen und ausbauen, damit man seine Stärken kräftigt und das Team ein Gefühl des Erfolges teilt.

Eine allgemeine Regel, die in der Retrospektive herrscht, ist die sogenannte „Vegas-Regel“. Alles, was in diesem Raum stattfindet und besprochen wird, bleibt auch in diesem Raum.

Dies stärkt das Vertrauen des Teams und in den Scrum Master, daher kann es vorkommen das pikante Informationen an den Tag kommen, die nicht für alle Ohren bestimmt sind.

Die Diskretion ist auf Seiten des Scrum Masters gefragt, ansonsten könnte das Team stark darunter leiden.

Wie zieht man den „Erfolg“ aus einer Retrospektive? In erster Linie besteht der Erfolg der Retrospektive darin, dass man die Maßnahmen formuliert und als Scrum Master darauf achtet, dass diese umgesetzt werden, um in der nächsten Retrospektive über die Ergebnisse sprechen zu können. Nimmt man dieses Event ernst und kontinuierlich wahr wird sich ein stetiger Erfolg einstellen.

Sprint Planning

Timebox: 2-8 Stunden

Das Sprintplanning formt das Kernstück des Scrum Frameworks, des Sprints und ist somit aus Sicht der Produktentwicklung eines der wichtigsten Events im Scrum Framework.

Der Product Owner priorisiert das Product Backlog und lädt anschließend zum Zeitpunkt des Sprintplannings ein. Teilnehmer des Sprintplannings sind der Scrum Master, der Product Owner und der wichtigstes Teil das Entwicklerteam. Bei der Verkündung der User-Stories werden diese in das Sprintbacklog gezogen, ein Sprintgoal wird als Vision verkündet und das Team entscheidet, ob dieser Umfang für den Sprint realisierbar ist.

Jegliche Diskussionen und Fragen sind während des Events erwünscht und helfen Klarheit zu schaffen. Wenn zu viele Fragen bei einer User-Story aufkommen und schwere Abhängigkeiten herrschen, wird diese User-Story zurück in das Backlog geschoben.

Das Sprintplannung wird in folgenden zwei Teilen ausgeführt.

Ist das Sprintbacklog vom Product Owner mit entsprechenden User-Stories gefüllt, endet Teil Eins des Sprintplannings.

Der zweite Teil beginnt mit den Einschätzungen der Entwickler für jede einzelne User-Story. Geschätzt wird in der Fibonacci-Sequenz und im besten Fall nach einer agilen-Methodik, wie dem Planning Poker.

Sind die Schätzungen eingetragen, erstellt das Entwicklerteam Sub-Stories, um ihre Arbeit in Arbeitsschritten zu planen.

Es wird nach Komplexität geschätzt, nicht nach „Man-Days“ oder Zeitaufwand.

Der zweite Teil des Plannings passiert autonom ohne den Scrum Master, oder den Product Owner. Ist dies soweit passiert, startet für das Team der Sprint.

Refinement

Refinement:
Das Refinement ist kein offizielles Event in dem Scrumguide wird aber in der Praxis gelebt und hat seine Vorteile bewiesen. Es wird mindestens einmal in der Woche durchgeführt um Klärung zu schaffen. Was ist das Refinement? Es ist ein Treffen mit dem Entwicklerteam und wird von dem Product Owner veranstaltet.

Der Product Owner wird zu dem Refinement eine Liste an User-Stories im Backlog haben, die er für den nächsten oder sogar übernächsten Sprint bereit hält. Nach und nach werden diese dem Team vorgestellt und besprochen, aber noch nicht geschätzt, dies passiert erst im Sprintplanning. Damit man nicht das ganze Backlog auf einmal durchexerziert, liegt hier die Empfehlung als Product Owner maximal zehn User-Stories für das Refinement bereit zu halten. Haben das Team und der Product Owner eine gemeinsame Sprache der User-Stories entwickelt und eine gewisse Routine, wird das Refinement von Mal zu Mal fruchtbarer. Der Scrum Master kann optional als Vermittler hinzugezogen werden.

Artefakte

Die Scrum Artefakte sind notwendig für ein funktionierendes Scrum. Wir haben die 3 festen Artefakten für Sie prägnant und grafisch dargestellt.

Product Backlog

Beschreibung:
Die Anforderungen, die durch die Stakeholder ausgesprochen werden und gewollt sind, werden als User-Story in dem Productbacklog festgehalten. Das Productbacklog ist eine Anforderungsliste, die durch den Product Owner geführt, priorisiert und gepflegt wird. In dieser Anforderungsliste werden neue, sowie alte Dinge festgehalten und Jeder, der etwas hinzufügen möchte, kann dies tun.

Ebenso werden Bugs, fehlende Dinge oder Evaluationen dort festgehalten. Das Productbacklog dient zur Transparenz und dazu, dass das Entwicklerteam weiß, was es zu tun hat bzw. woran der Product Owner zukünftig arbeiten möchte. Das Productbacklog dient zu dem als Basis für das Refinement und das Sprintplanning. Ob man nun mit einem analogen oder digitalen Productbacklog arbeitet ist erstmal trivial, das wichtigste ist das Festhalten der Anforderungen.

Sprint Backlog

Beschreibung:
Nach dem Sprintplanning, wenn die User-Stories aus dem Productbacklog in das Sprintbacklog gezogen worden sind, hat das Team die Aufgabe das Sprintbacklog zu pflegen. Das Sprintbacklog ist somit die „Arbeitsliste“ der Entwickler, die diese sich für den Sprint vorgenommen haben. Wurde zudem ein Sprintgoal geformt, was sehr wichtig ist, kann der Scrum Master in jedem Daily darauf hinweisen und das Team hält das Sprintbacklog aufrecht. Werden User-Stories in das Sprintbacklog gezogen, nachdem man den Sprint gestartet hat? Im besten Falle passiert dies nicht. Das Sprintbacklog ist eine feste Sache, in dem das Team, wie im Sprint, geschützt ist.

Was passiert wenn das Sprintbacklog „leer“ ist? Dann sollte der Scrum Master oder Product Owner informiert werden, damit man User-Stories nachziehen kann. Dies sollte allerdings eine Ausnahme sein.

Inkrement

Beschreibung:
Am Ende eines Sprints werden in der Sprintreview abgeschlossene User-Stories präsentiert. Diese können kleine Änderungen beinhalten, wie zum Beispiel die Farbe eines Buttons, gesamte Epics die bearbeitet wurden, Features eines Produktes, oder neue Anforderungen die schnell entwickelt worden sind. All das sind Lösungen für den Stakeholder und somit ein Inkrement. Dieses Inkrement sollte potenziell auslieferbar sein, selbst wenn der Stakeholder es nicht sofort braucht, ist es für den späteren Gebrauch schon gestaltet.

Crew

Die Scrum Artefakte sind notwendig für ein funktionierendes Scrum. Wir haben die 3 festen Artefakten für Sie prägnant und grafisch dargestellt.

Crew

Die Crews sollten als Ort dienen, in denen man Ideen, Anregungen und Innovationen austauscht und verfeinert. Ganz im Sinne des „Inspect & Adapt“ werden Retrospektiven-Methoden ausgetauscht, Dailyprobleme, Abläufe des Scrum Masters pro Team, oder die häufigsten Impediments aufgeschrieben und angesprochen.

Die Crews und die Idee dahinter ist aber nicht exklusiv für Scrum Master, sondern kann auch für Tester, Java-Developer, oder Architekten aufgesetzt werden. Um auch zu einem Ergebnis zu kommen, sollten diese Treffen als Workshop aufgesetzt werden, mit erarbeiteter Agenda und Maßnahmen bzw. Aktionspunkte am Ende von des Workshops. Diese regelmäßigen Treffen sollten mit einem Moderator geführt werden und Nachhaltigkeit besitzen, damit man stetig Fortschritt erzeugt. Warum sollten Zusammenschlüsse gefördert werden? Es nützt keinem in einem Unternehmen, fernab der Größe, sein Wissen für sich zu behalten und es Anderen vorzuenthalten. Wissen soll geteilt werden, sodass jeder daran wachsen kann. Dazu kann man die Crew Workshops benutzen, um aktiv an Problemen zu arbeiten und diese im besten Fall auch zu lösen. Synergien sind stets förderlich für ein entspanntes Arbeitsverhältnis.

ScrumCorp - Die Skalierung passt zu meinem Unternehmen

Individuell – Organisationsfreundlich – Effizient

Die ScrumCorp Skalierung basiert auf eine produktzentrische Organisationen. Verantwortung gilt Produkten und produktförderlichen Zielen und legt nicht den Fokus auf Führen von Personal. Selbstorganisierende Teams entwickelt in Iterationszyklen das jeweilige Produkt weiter. Produktverantwortliche Personen entwickeln Visionen und Ziele für das Produkt und verantworten marktgerechte, kundenorientierte und zukunftsweisende Produktweiterentwicklung. Führungskräfte verantworten sowohl die Produkte als auch die Förderung der Individuen. Scrum Master verantworten die kontinuierliche Optimierung des Entwicklungsprozess. Komplexität wird auf die geringst mögliche Größe geschrumpft.

„Lean Start-Up trifft auf Komplexe Softwareentwicklung“

Während andere Frameworks ihre Stärken auf Ansätze legen, die aus Scrum ein „Heavyweight“ machen, legen wir als ScrumCorp den Fokus darauf, dass Scrum im Herzen Scrum bleibt und es auch weiterhin als „Lightweight – Framework“ gelebt wird.

Jeder in ihrem Unternehmen wird sich wiederfinden in den verschiedenen Rollen und deren Aspekte – keine Angst beim implementieren, ausprobieren und experimentieren mit dem Framework von ScrumCorp.

Als Empiristen legen wir Wert auf die Erfahrung, die jedes Team, Unternehmen und jede Person als Individuum in der jeweiligen Reise eines Projektes machen wird. Scheuen Sie sich nicht vor Fehlern – Sie sind der beste Lernpartner. Die Expertise, die von den einzelnen Mitarbeitern getragen wird, soll nicht als Geheimnis behütet werden, sondern sollte als Geschenk von der jeder profitieren kann betrachtet werden. Am Ende des Tages sind es Menschen mit denen wir arbeiten, keine Ressourcen und Personen haben Wissen und vorher schon Erfahrungen gemacht, die berücksichtigt werden sollten. Sie werden in dem ScrumCorp Skalierungsmodell optionale, sowie nicht optionale Möglichkeiten finden. Durch die Entscheidungsmöglichkeiten gibt das Modell ihnen die Auswahl Dinge frei zu entscheiden, bei manchen Dingen handelt es sich um obligatorische Sachen, die notwendig sind, damit das Modell zum Erfolg führt.
Dieses Kompendium soll dazu dienen Ihnen nicht nur einen Überblick zu verschaffen, sondern auch hinter die Kulissen zu blicken um unsere Scrum Vision mit Ihnen zu teilen.

Menü