fbpx
[ultimate_heading main_heading=“ScrumCorp Individuelle Skalierung Beispiele:“ heading_tag=“h3″ alignment=“left“ main_heading_margin=“margin-bottom:15px;“][/ultimate_heading]

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.

[ultimate_heading main_heading=“Entwicklungsteam“ alignment=“left“][/ultimate_heading]

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.

[ultimate_heading main_heading=“Scrum Master“ alignment=“left“][/ultimate_heading]

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.

[ultimate_heading main_heading=“PO“ alignment=“left“][/ultimate_heading]

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.

[ultimate_heading main_heading=“MPO“ alignment=“left“][/ultimate_heading]

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.

[ultimate_heading main_heading=“CEPO/CFPO/CTPO“ alignment=“left“][/ultimate_heading]

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.

[ultimate_heading main_heading=“Stakeholder“ alignment=“left“][/ultimate_heading]

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.

[ultimate_heading main_heading=“TBO“ alignment=“left“][/ultimate_heading]

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.

[ultimate_heading main_heading=“ScrumCorp – Die Skalierung passt zu meinem Unternehmen“ heading_tag=“h3″ main_heading_margin=“margin-bottom:15px;“]

Individuell – Organisationsfreundlich – Effizient

[/ultimate_heading]

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ü