Product Owning à la PentaNEXT 

Wie arbeiten wir bei PentaNEXT? Wie ist es uns als Werkstudierenden möglich, Eindrücke aus den verschiedenen Bereichen von Pentadoc zu erhalten? Die kurze Antwort lautet: SCRUM.

In unserem Artikel "Was ist eigentlich PentaNEXT" haben wir bereits davon berichtet, wer zu unserem Studierendenteam gehört, warum wir als Studierende bei Pentadoc etwas bewirken und unser Wissen und Erfahrungen wirklich erweitern können.  

Experimentieren! 

SCRUM ist ein agiles Framework, das sich durch seine inkrementellen Prozesse und die Outcome-Orientierung auszeichnet. Im Gegensatz zu den herkömmlichen Arbeitsweisen hat Scrum keine umfangreiche Planungsphase und keine in ferner Zukunft liegenden Deadlines, bei dem erst nach Fertigstellung des Produkts Feedback gegeben wird. Im Gegenteil, es ist ein Rahmenwerk, das auf einer Feedback-Kultur basiert ist, bei der das Team, welches keine Hierarchie hat, selbst gemeinsam entscheidet, wie es Anforderungen bewältigt. Wenn ihr die Basics noch nicht kennt, laden wir euch ein, den Artikel "Was ist und was kann Scrum" von einem unserer Vorstände zu lesen. 

PentaNEXT arbeitet mit Scrum. Wie jedes Team haben wir aufgrund unserer Rahmenbedingungen eine Reihe von Anpassungen vornehmen müssen und lernen beständig dazu, damit Agilität nicht zu einem reinen Selbstzweck verkommt. Wir sind ein kleines Team von Entwickler*innen, mit aktuell einer Scrum Masterin und zwei Product Ownern (dazu weiter unten später mehr). Wir führen alle Events des Frameworks durch, also Sprint Review, Retrospektive und Planning sowie tägliche, 15-minütigen Meetings, um uns gegenseitig über unsere Fortschritte upzudaten.  

Product as a Service? 

Was sich zum Scrum Manifest in unserer Arbeit unterscheidet, ist, dass wir im Gegensatz zur SCRUM-Denkweise kein herkömmliches "Produkt“ als Ziel oder ein endgültiges Ergebnis haben, welches wir am Ende des Projekts ausliefern müssen. Das Update des Scrum Guides 2020 kam daher auch unserer Arbeitsrealität entgegen, nach dem als Ergebnis eines Sprints nicht mehr ein, sondern mehrere Inkremente entstehen können – in unserem Fall handelt es sich dabei um die Vielzahl an internen und mandatsbezogenen Lieferergebnisse. Unser mittelbares „Produkt“ ist letztlich – sofern man dieses Wort dafür verwenden möchte – "Junior Berater*innen-Nachwuchs“. Außerdem entspringen aus den Anforderungen eigentlich unvernetzter Stakeholder*innen teils ungeahnte Synergien und Impulse, denen wir nachgehen und als Optimierungen oder sogar als Innovationen zurück in die Organisation transportieren. 

Es wird den PentaNEXT-Mitgliedern die Möglichkeit gegeben, Aufgaben zu übernehmen, die ihnen erlauben, immer weiter in die Welt der Beratung (ala Pentadoc) einzutauchen. Dazu gehören unter anderem das Begleiten von Workshops mit den Kund*innen, das Gestalten von Präsentationen, das Kennenlernen der internen Pentadoc Beratungsleistungen und zugehörigen Tools. Auch hat man die Möglichkeit die Beratungsinstrumente permanent zu verbessern und dabei eigenen Ideen und Erkenntnisse aus dem Studium einzubringen.  

Unser „Produkt“ hat indes keinen Liefertermin – aber ein Studium endet irgendwann. Es hat keine feststehenden Akzeptanzkriterien – aber unsere Stakeholder haben eine Vorstellung davon, was potenzielle Berater*innen auszeichnet. Der „Fertigungsprozess“ verläuft immer anders, denn wir haben immer neue Werkstudierende, die wir dazu motivieren, sich zu unseren zukünftigen Juniorberater*innen zu entwickeln. Unsere einzelnen Arbeitsergebnisse haben Wert und Nutzen – aber das tatsächliche Produkt ist emergent. SCRUM unterstützt uns dabei, mit dieser Komplexität umzugehen, den Herausforderungen einer schnelllebigen und kundenorientierten Beratungswelt gerecht zu werden und gestaltet die Arbeit für Studierende noch interessanter.  

Learn to fly 

Als Product Owner bin ich für die effektive Verwaltung unseres Backblogs verantwortlich, in dem alle Anforderungen und Aufgaben enthalten sind, die realisiert werden sollen. Unsere Stakeholder sind  häufig, aber nicht ausschließlich, unsere Berater*innen, die entsprechend ihrer Bedarfe Anforderungen stellen. Meine Hauptaufgabe ist es, diese Anforderungen aufzunehmen, mit den Stakeholdern zu sprechen und ihren Hintergrund und ihren Zweck zu verstehen. Die dafür notwendige Auseinandersetzung mit den Anforderungen trägt intensiv dazu bei, mich in die verschiedenen Sachverhalte und Kontexte hineinzudenken. Das ermöglicht mir, Prioritäten zu setzen und das Backlog bestmöglich und nach größtem Nutzen zu sortieren. Und natürlich kann jedes Detail wichtig für ein zielführendes und produktives Planning sein. Je komplexer die Anforderung, umso höher auch die Wahrscheinlichkeit, neue Kenntnisse und Fähigkeiten aus dem Erledigungsprozess mitzunehmen. 

Denn meine Aufgabe ist auch, alle umsetzungsbereiten Items des Backlogs in unserem Sprint Planning klar an die Entwickler*innen zu kommunizieren und sie an unser gemeinsames Ziel zu erinnern. Gemeinsam entscheiden wir dann, welche Aufgaben im neuen Sprint durchgeführt werden sollen und wer für jeder dieser Aufgaben zuständig sein wird. 

Dass wir zwei POs haben, klingt natürlich falsch – aber als Werkstudentin verfüge ich gar nicht über genug Kapazität, diese Rolle vollständig wahrzunehmen. Arvid ist daher ebenfalls Product Owner, gemeinsam nehmen wir die operativen Tätigkeiten wahr, zusätzlich ist er als Berater das Bindeglied zum gesamten Unternehmen und sorgt dafür, dass wir im Gesamtgefüge gut aufgestellt sind und auf übergeordnete strategische Ziele einzahlen.  

Aber wer weiß – mit zunehmendem Fachwissen, handwerklicher Effizienz und Vernetzung in Pentadoc werde ich im Sinne der Product Owner Maturity sicher immer mehr Verantwortung übernehmen.