Skip to main content

Es gibt eine Fülle an Inhalten, Leitfäden, Fachbüchern, Kursen und Zertifikaten zum Thema Agiles Produktmanagement. Ehrlich gesagt, brauchen Sie das alles nicht.

Im Kern basiert Agiles Produktmanagement auf einer einfachen, menschenorientierten Philosophie. Viele der Prozesse, in denen sich agile Methoden ausdrücken, sind einfach und leicht verständlich. Die Komplexität entsteht jedoch durch Missverständnisse bezüglich Erwartungen, Rollen und Abläufen.

In diesem Leitfaden werden wir:

Want more from The CPO Club?

Sign up for a free membership to complete reading this article:

Step 1 of 2

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
  • Agiles Produktmanagement erkunden, seine Philosophie sowie die Prozesse, in denen es Gestalt annimmt.
  • Die Rollen betrachten, die ein typisches agiles Produktentwicklungsteam ausmachen, was sie beinhalten und wie sie zusammenarbeiten.

Das Verständnis dieser Schlüsselbereiche ist wichtig. Es verschafft Ihnen die Werkzeuge, um agiles Produktmanagement einzuführen oder zu verbessern – sowohl in Ihrem Team als auch in der gesamten Organisation.

Was ist agiles Produktmanagement?

Agile ist eine Philosophie darüber, wie Teams effektiv zusammenarbeiten können, um ein Ziel zu erreichen. Das ursprüngliche Agile Manifest, veröffentlicht 2001, bringt die agilen Prinzipien am besten auf den Punkt:

  • Individuen und Interaktionen stehen über Prozessen und Werkzeugen
  • Funktionierende Software steht über umfassender Dokumentation
  • Kundenzusammenarbeit steht über Vertragsverhandlungen
  • Reagieren auf Veränderung steht über dem Befolgen eines Plans

Das ist der Kern des agilen Produktmanagements. Es gibt keine Erwähnung von Story Points oder Swimlanes. Keine Stand-ups oder Sprints.

Obwohl das Agile Manifest nicht vorschreibt, Prozesse und Werkzeuge zu nutzen, wird deren Bedeutung zugunsten menschzentrierter, anpassungsfähiger Zusammenarbeit heruntergespielt. Gerade wenn Sie das agile Produktentwicklungsmodell zum ersten Mal angehen (oder es auffrischen möchten), kann es erhellend sein, sich nochmals auf die Grundwerte des Manifests zu besinnen.

Wenn wir uns nun mit den praktischen Aspekten von Agile beschäftigen, ist es wichtig, das Manifest stets im Hinterkopf zu behalten. Prozesse, Dokumentationen und Planungen sind alle nützlich. Doch wenn Sie oder Ihr Team merken, dass diese wichtiger werden als das Team oder ein funktionierendes Produkt, sollten Sie genauer hinschauen.

Sehen wir uns einige Feinheiten der agilen Produktentwicklungs-Denkweise an.

Menschenfokus

Agile Software-Entwicklung konzentriert sich darauf, die Menschen im Produktteam zu befähigen. Um sie richtig zu praktizieren, müssen Sie jenen, mit denen Sie arbeiten, wirklich vertrauen. Fehlt das Vertrauen, ist die psychologische Sicherheit des Teams gefährdet und produktive Zusammenarbeit leidet.

Fokus auf Nutzer*innen

Ein kompromissloser Fokus auf Ihre Nutzer*innen ist ein Muss. Schließlich – bauen wir nicht genau für sie?

Ein effektives agiles Team holt ständig Feedback von Nutzer*innen ein. Es werden Umfragen versendet und ausgewertet, um die Priorisierung der Weiterentwicklung neuer Funktionen zu steuern. Agile Produktmanager*innen suchen stets nach Wegen, um die Arbeit in kleine, auslieferbare Abschnitte zu unterteilen, die entlang des Prozesses validiert werden können, ohne dabei in das Feature Creep zu geraten.

Wenn wir Nutzer*innen nicht regelmäßig einbinden, kann das, was wir heute planen, morgen wertlos sein.

Herausfordernd

Agiles Produktmanagement ist eine große Herausforderung – und zwar aus Gründen, die Sie vielleicht nicht erwarten.

Wirksame agile Teams haben im Allgemeinen weniger Prozesse und formale Berichtswege als nicht-agile Vergleichsteams. Das liegt daran, dass Agile auf einem stetigen Arbeitsfluss und Transparenz basiert, um die Zusammenarbeit zu fördern, statt lediglich einzelne Meilensteine abzuarbeiten.

Mit dem Mangel an Prozessen geht für viele Produktmanager*innen auch ein Gefühl des Kontrollverlusts einher. Dennoch bleibt eine hohe Verantwortung, die mit der Rolle einhergeht. Das richtige Gleichgewicht zu finden, um den Fokus des Teams nicht zu gefährden, ist eine Kunst, die sich von Team zu Team unterschiedlich gestaltet.

Wenn Produktmanager*innen jedoch einen moderierenden, dienenden Führungsstil einnehmen, kann dies langfristig sogar zu mehr Vorteilen – und ironischerweise mehr Kontrolle – führen als sonst. Das liegt an den positiven Effekten, die bewährte und vertraute agile Praktiken entfalten können.

Idealerweise existiert eine Unternehmenskultur, die Agile unterstützt. Es ist zwar möglich, ohne Rückendeckung für Agile zu starten, doch wird dies deutlich schwieriger sein und bedeutet, gegen den Strom zu schwimmen. Ein Unternehmen, das Agile unterstützt, kann mit bewusst vagen Plänen umgehen, da es versteht, dass die Planung im Laufe der Zeit klarer werden wird.

Lean

Lean zu handeln ist entscheidend. Ein zielgerichteter Fokus auf Ergebnisse hält Agile-Teams auf Kurs und minimiert Ablenkungen. Das Konzentrieren auf die geringstmögliche Arbeit, die zur Zielerreichung notwendig ist, hilft dem Team, beständig voranzukommen und Markterfolg so schnell wie möglich zu erzielen.

Agiler Ablauf

agile flow infographic
Der allgemeine Ablauf der agilen Methodik: von der Strategie über das Experimentieren, Testen und Validieren. Dieser Prozess wird wiederholt, um kontinuierliche Iteration zu fördern.

Bevor wir auf einige konkrete Prozesse eingehen, mit denen Sie agiles Produktmanagement umsetzen können, besprechen wir den allgemeinen Prozessablauf und die Schritte der agilen Methodik, denen die meisten Prozesse folgen. 

Verwandter Artikel: Wie Sie Prinzipien des agilen Produktportfoliomanagements umsetzen

Strategie

Große agile Entwicklung beginnt mit einer guten Strategie und Ausrichtung. Alle Teammitglieder zusammen in einen Raum (oder in ein Zoom-Meeting) zu holen, kann Wunder wirken, um eine einheitliche Produktvision und Richtung festzulegen. Ziehen Sie den Einsatz spannender visueller Kollaborationssoftware in Betracht, damit niemand abschaltet.

Dies bietet dem Team die Möglichkeit, sich über Geschäftsplan, visuelle Ausrichtung, Zielnutzer und mehr auszutauschen. Es dient als gemeinsamer Ausgangspunkt, auf den sich das Team konzentrieren kann.

Es ist wichtig zu beachten, dass die in dieser Phase erstellten Pläne und Dokumentationen als Annahmen behandelt werden. Sie sind bereit, regelmäßig überprüft und im Laufe der Zeit iteriert zu werden.

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

Experimentieren

Alles ist ein Experiment. Gleich zu Beginn sollte das erste fokussierte Arbeitspaket zeitlich begrenzt und dann mit Anwendern getestet werden. Diese Arbeit kann sehr rudimentär sein, sogar so einfach wie grobe Skizzen, durch die man jemanden führt.

Das Ziel ist, die Arbeit mit der Denkweise der wissenschaftlichen Methode anzugehen. Wir sind Wissensarbeiter – unser Fokus liegt nicht nur auf der Ausführung, sondern auch auf Wissensgenerierung und Entdeckung.

Testen

Jedes Experiment sollte qualitativ und quantitativ getestet werden. Mit einer regelmäßigen Überprüfung der Resultate verfügen Sie über die Werkzeuge, um zu bestätigen, dass das, was Ihr Team entwickelt, wertvoll ist und am Markt akzeptiert wird.

Validieren

Nachdem Sie eine neue Funktion veröffentlicht haben, sollten Sie diese kontinuierlich überprüfen. Wird sie genutzt? Wird sie gefunden? Haben andere Teile Ihres Produkts durch die Einführung dieser Funktion positiv oder negativ reagiert?

Durch regelmäßiges Review und Überwachung dessen, was Sie nach der Fertigstellung ausliefern, erhalten Sie weitere Werkzeuge und Hinweise für noch bessere Entscheidungen.

Wiederholen

Dies ist der wichtigste Schritt. Durchlaufen Sie den agilen Prozessablauf weiterhin immer wieder – wie ein Motor. Dieser Ablauf ist bewusst zyklisch, nicht linear, um Lernen zu fördern. Lernen Sie daraus. Passen Sie sich an. Feiern Sie es. Nehmen Sie den Wandel an.

2 Gängige Agile-Ansätze

Agilität ist eine ermächtigende Philosophie, die Teams gemeinschaftlich zu einem gemeinsamen Ziel führt – auf kollaborative Weise, wie es mit zu stark strukturierten Prozessen und Berichtwesen nicht möglich ist.

Allerdings sind einige Prozesse sinnvoll. Wenn sie richtig implementiert und auf die einzigartige Kultur eines Teams abgestimmt angewendet werden, können Prozesse als Leitplanken dienen, die das Team fokussiert halten und dennoch kreative Freiheit ermöglichen.

Wir schauen uns einige der beliebtesten Prozesse an, mit denen die agile Philosophie praktisch umgesetzt wird.

Scrum

Scrum ist vermutlich der beliebteste agile Prozess und das aus gutem Grund: Er unterteilt Verpflichtungen und Lernphasen in dedizierte Zeitblöcke, die "Sprints" genannt werden. Das fördert Lernbereitschaft und bietet mehr Gelegenheiten, auf die Erkenntnisse zu reagieren.

Kernstück dieser Sprints ist das Scrum-Team selbst. In Scrum gibt es keine Titel: Jede*r im Team hat die Rolle "Entwickler/in". Das fördert einen ausgeprägten Teamfokus auf Zusammenarbeit und Zielerreichung für jeden Sprint. 

In der Praxis bedeutet das, wenn ein*e Testingenieur*in auf ein Feature zum Testen wartet, kann er/sie sich in die Entwicklung eines neuen Features einbringen. Diese funktionsübergreifende Denkweise ist unglaublich wirkungsvoll, wenn sie funktioniert, da das Team großartige Ergebnisse liefern kann.

Scrum versucht, Meetings zu minimieren, um konzentrierte Entwicklungszeit zu fördern. Dazu gibt es eine Reihe von wiederkehrenden Meetings oder Zeremonien:

  • Sprint-Planung: Wird genutzt, um die Arbeit zu planen, zu der sich das Team für den kommenden Sprint verpflichten möchte.
  • Sprint-Review (Demo): Eine Zeit, um allen Beteiligten und Stakeholdern erzielte Fortschritte zu präsentieren sowie gewonnene Erkenntnisse zu teilen.
  • Sprint-Retrospektive: Eine offene Gelegenheit für das Team, auf den vorherigen Sprint zurückzublicken und zu besprechen, was gut lief, was nicht gut lief und wo Verbesserungsmöglichkeiten bestehen.
  • Backlog-Pflege und Schätzung: Dies ist ein wiederkehrender Zeitraum zum Überprüfen und Priorisieren des sich ständig ändernden Product Backlogs, basierend auf geschäftlichen und technischen Erkenntnissen. Sobald Einigkeit zu Einträgen im Backlog besteht, werden diese für die weitere Planung geschätzt.
  • Tägliche Stand-ups: Ein regelmäßiger Tageszeitpunkt, an dem das Team bespricht, was gestern erledigt wurde, woran heute gearbeitet wird und ob es Blockaden gibt.

Um die auf den Sprint ausgerichtete Arbeit mit dem Gesamtbild zu verknüpfen, fördert Scrum die Verwendung von „Story Points“ zur Aufwandsschätzung in strukturierten Sprint-Planungssitzungen. Diese stellen eine willkürliche Aufwandsbewertung dar, die das Team jedem Eintrag im Backlog zuweist.

Ich verwende eher Story Points als Zeitschätzungen. Wenn ich gegen Ende eines Sprints einen hohen Story-Point-Wert sehe, weiß ich, dass wir das Thema angehen oder den Vorgang aufteilen müssen.

Silvia Dake

Das besonders Leistungsfähige daran ist, dass es die Nutzung der Velocity (Geschwindigkeits-)Verfolgung unterstützt. Das bedeutet, dass die durchschnittliche Anzahl an Story Points, die das Team in einem Sprint abschließt, gemessen wird. Nach einigen ersten Sprints sollte dieser Wert an das Team angepasst sein und kann für gezieltere Release-Vorhersagen sowie die Planung verwendet werden.

Setzt das Team all diese Werkzeuge gewissenhaft ein und werden sie von einem erfahrenen Scrum Master begleitet, kann Scrum ein wirkungsvolles Vorgehen sein, das gezielte agile Entwicklung unterstützt und ausreichend Gelegenheit für effektive Iteration bietet.

Kanban

Kanban übernimmt viele Elemente aus Scrum, wie z. B. Backlog-Pflege, ein Board ähnlich wie ein Sprint-Board und weitere bekannte Bestandteile.

Während Scrum jedoch den Fokus auf eine kleine Menge Arbeit legt, betont Kanban die kontinuierliche Flussverarbeitung der Arbeit.

Im Mittelpunkt dieses Vorgehens steht das Kanban-Board. Aufgaben werden links kontinuierlich priorisiert und durchlaufen den individuellen Prozess des Teams von links nach rechts, bis sie unter „Erledigt“ einsortiert werden. Häufig wird zur Ausbalancierung der Auslastung eine Work-in-Progress-(WIP-)Grenze pro Spalte festgelegt, die bestimmt, wie viele Aufgaben gleichzeitig bearbeitet werden dürfen.

Kanban eignet sich hervorragend für Supportaufgaben oder Teams, die unregelmäßig Kapazitäten zusagen können.

SAFe, XP und andere

Es gibt viele weitere Varianten agiler Vorgehensweisen, die jeweils auf bestimmte organisatorische Anforderungen und kulturelle Normen zugeschnitten sind.

SAFe ist ein umfassendes Agiles System zur Umsetzung von Agilität im großen Maßstab, typischerweise in Großunternehmen. Es besteht aus mehreren „Agile Release Trains“, im Grunde mehrere Scrum-Teams. Verschiedene Rollen und Zeremonien sorgen dafür, dass alle Teams auf gemeinsame Ziele und Releasepläne hinarbeiten.

Extreme Programming (XP), DevOps, Modern Agile und andere Methoden existieren, um agile Ansätze für bestimmte Rollen oder Unternehmenskulturen bereitzustellen.

Mit unterschiedlichen agilen Methoden zu experimentieren, ist sinnvoll. Das kann zu einem wirkungsvollen Verständnis führen, welche Ansätze zu Ihrem Unternehmen passen.

Agile-Produktmanagement-Zertifikate

Sie haben wahrscheinlich schon die zahlreichen Zertifikate entdeckt, die Sie für verschiedene agile Arbeitsweisen erwerben können. Sie werden beworben, um den Eindruck zu erwecken, ihre Methode sei der einzige Weg und ohne ein kostenintensives Zertifikat könnten Sie das Vorgehen nicht wirklich anwenden.

Ignorieren Sie das.

Im Idealfall gibt Ihnen dieser Leitfaden genügend Anstoß, um selbst einen passenden Lernpfad einzuschlagen. Agile Methoden sind ein Werkzeugkasten für Praktiker, kein Prüfungsstoff. Die Vertrautheit mit den Prozessen, Zeremonien und der zugehörigen Dokumentation jeder Methode ist wertvoll; aber zurückblickend auf das Manifest, ist es noch wichtiger, Ihr Team aktiv in die Umsetzung Ihres gewählten agilen Prozesses einzubinden. Es gibt Organisationen, die darauf spezialisiert sind, Zertifikate zu schaffen und zu erhalten; es liegt natürlich in ihrem Interesse, Prozesse wichtiger als Menschen erscheinen zu lassen.

Ist das wirklich agil?

Alles dies sei gesagt als eine warnende Geschichte auf deinem eigenen Weg des Agile-Lernens. Zertifizierungen können wertvoll sein. Wenn du an einem Workshop teilnimmst, kann dies ein gezielter Weg sein, um schnell alle Details eines bestimmten Prozesses zu erlernen. Manche Organisationen schätzen es, wenn sie sehen, dass du zertifiziert bist, um schnell Vertrauen aufzubauen.

Wenn das Anstreben einer Zertifizierung dir hilft, dein gewünschtes Ziel zu erreichen und nur minimalen Aufwand erfordert, dann mach es. Wenn du jedoch keine Zertifizierung brauchst, ist das Experimentieren und kontinuierliche Lernen in der Umsetzung von Agile der effektivste Weg auf deiner Agile-Reise.

Verwandt: 4 Beste Online-Zertifizierungen im Bereich Agile Product Management

Was sind agile Produktentwicklungsrollen?

Durch die Betrachtung agiler Prozesse sind wir auf eine Reihe von Kernrollen eingegangen, die ein agiles Produktentwicklungsteam ausmachen. Zu diesen Rollen gehören:

  • Product Manager
  • Product Owner
  • Entwickler
  • Designer
  • Testingenieur / QA

Jede Organisation hat in der Regel ihren eigenen Ansatz dazu, was diese Rollen beinhalten. Beispielsweise kann das Verantwortungsgebiet eines Product Managers in einem Unternehmen eher den Aufgaben eines Product Owners in einem anderen entsprechen. Doch mit dieser Flexibilität im Hinterkopf werfen wir einen Blick auf einige der breiteren Definitionen, die die Rollen in einem Produktteam veranschaulichen.

Häufig gibt es Überschneidungen zwischen Product Ownern, Product Managern und Projektmanagern, und Teams haben manchmal eine, zwei oder alle drei Rollen. Product Manager oder Product Owner übernehmen oft Projektmanagement-Aufgaben, wenn es keinen Projektmanager im Team gibt.

Product Manager

Also, was macht ein Product Manager? Der Product Manager ist – nun ja – für das Management des Produkts verantwortlich.  Die Hauptverantwortung der Rolle im Produktmanagement besteht darin, sicherzustellen, dass alles darauf ausgerichtet ist, die wichtigsten Ergebnisse auf Basis von Benutzer-Tests, Team-Input und strategischer Planung zu erreichen.

Effektives Produktmanagement bedeutet jedoch, das Produktteam zu befähigen. Dafür ist der Product Manager eine Generalistenrolle. Das heißt, sie müssen ein breites Kompetenzspektrum abdecken, um effektiv zu sein, müssen aber nicht unbedingt ein erfahrener Entwickler oder Designer sein (obwohl es oft vorkommt, dass Producer-Rollen ins Produktmanagement wechseln).

Ein generalistischer Skillset befähigt den Product Manager, ein empathischer und dienender Leiter für sein Team zu sein. Indem er gerade genug Verständnis für die Entwicklungsanforderungen aufbringt, kann der Product Manager das Team bei der effektiven Produktdefinition und -planung unterstützen, ohne den Fähigkeiten des Teams im Weg zu stehen.

Weiterlesen: Warum Produktmanagement wichtig ist

Aufgaben des Product Managers

Product Owner

Während der Product Manager die Verantwortung für den taktischen Erfolg des Produkts trägt, ist der Agile Product Owner für den geschäftlichen und marktwirtschaftlichen Erfolg verantwortlich.

In der Regel ist der Product Owner eine essenzielle Geschäftsrolle, die manchmal auch ein zentraler Stakeholder für das Produktteam sein kann. Ihr Marktwissen und der Blick aufs Geschäft aus der Vogelperspektive machen sie zu einer entscheidenden, kenntnisreichen Ressource, um das Produktteam zum Erfolg zu führen. 

Aufgaben des Product Owners

  • Produkterfolg 
  • Marktforschung und Marktkenntnis
  • Geschäftsentwicklung
  • Finanzierung
  • Schiedsrichter bei Streitfragen

Eine häufige Herausforderung ist die Überschneidung und die Unterschiede zwischen der Rolle des Product Owners und des Product Managers. Manchmal ist diese Rolle Teil der Product-Manager-Rolle und umgekehrt. Wenn die beiden Rollen getrennt sind, gibt es oft Überschneidungen. Einige Organisationen vertauschen sogar die Verantwortlichkeiten von Product Manager und Product Owner.

Das ist jedoch in Ordnung!

Trotz der Herausforderungen, die auftreten können, können bei einer gesunden, sich ergänzenden Zusammenarbeit dieser Rollen großartige Ergebnisse erzielt werden. Zum Beispiel kann sich eine Rolle ausschließlich auf das Produkt konzentrieren, während die andere sich auf das Geschäft fokussiert. Eine kann sich um die Details und Funktionalitäten des Produkts kümmern, die andere ist für die übergeordnete Marktpositionierung verantwortlich.

Wenn diese beiden Rollen gemeinsam zusammenarbeiten, können bahnbrechende strategische Erkenntnisse unerwartet entstehen, die den Erfolg des Produkts und des Teams deutlich positiv beeinflussen. Schließlich gilt: Vier Augen sehen mehr als zwei!

Entwickler

In einem effektiven Produktteam beschränkt sich die Entwicklerrolle nicht nur auf das Schreiben von Code: Sie arbeiten mit allen Rollen zusammen an strategischer, technischer Planung und geben Empfehlungen.

Entwickler, die über fundiertes Wissen zu Produktentwicklungs-Tools, Nutzerbedürfnissen und Produkt-/Marktzielen verfügen, können einen technischen Plan erstellen, der zum Produkt passt wie maßgeschneidert. Die Entwicklungsteammitglieder mit diesem Wissen zu befähigen und ihnen die Möglichkeit zu geben, essenzielle technische Entscheidungen zu treffen, kann über den Unterschied zwischen einem Entwicklungszeitraum von einem Monat oder einem Vielfachen davon entscheiden – je nachdem, welche technischen Kompromisse mit diesen Entscheidungen einhergehen.

Wenn deine Entwickler in den Produktbereich deines Entwicklungsteams eingebunden sind, können sie den Erfolg des Teams multiplizieren.

Aufgaben eines Entwicklers

  • Produktentwicklung
  • Technische Planung und Recherche
  • Beratung bei der Wahl des Technologie-Stacks
  • Funktionales Prototyping
  • Unit Testing
  • DevOps (manchmal eine eigene Rolle)
    • Erstellung und Verwaltung von Deployment-Pipelines

Designer

Ähnlich wie Entwickler sich nicht nur aufs Programmieren beschränken sollten, sollte sich der Einfluss von Designern im Produktteam nicht nur auf das Erstellen von Designs begrenzen. Tatsächlich entstehen einige der besten Zusammenarbeiten im Produktteam zwischen dieser Rolle und der des Product Managers.

Designer in Produktteams starten meist mit einer strategischen Betrachtung der Produktstrategie und des Geschäfts. Sie sind oft die größten Anwälte für die Nutzerinteressen im Team. Diese Erkenntnisse versetzen sie danach in die Lage, gezielt und fokussiert zu gestalten.

Effizienzen für Entwicklung und Lernprozesse zu ermöglichen, ist ein zentraler Fokusbereich für Design-Rollen. Durch die Entwicklung von Designsystemen erhalten Entwickler die Möglichkeit, neue Features schnell über Continuous-Integration-Workflows zu bauen. Interaktive, visuelle Prototypen ermöglichen Nutzertests, bevor eine Zeile Code geschrieben wird, um einen weiteren Investitionsaufwand abzusichern.

Aufgaben eines Designers

  • Produktdesign
  • Mockups
  • Prototyping
  • Erstellung von Styleguides
  • Entwicklung und Pflege von Designsystemen
  • Nutzertests, in Zusammenarbeit mit dem Product Manager
  • Laufende User Research

Testingenieur / QA

Ein Testingenieur (manchmal auch Quality Assurance oder QA genannt) kann eine der einflussreichsten Rollen in einem Produktteam sein. Auch wenn der Hauptfokus auf dem Testen von Produkteigenschaften vor ihrem Rollout für Nutzer liegt, kann sein genauer Blick die Ausrichtung des Teams bereits vor Entwicklung einer neuen Funktion schärfen.

Testingenieure sollten von den frühesten Phasen der Produktentwicklung an dabei sein. So kann diese Rolle Akzeptanzkriterien für die User Stories des Produkts definieren, die als Leitfaden für das restliche Team bei der Umsetzung dienen.

Mit einer starken Nutzerorientierung können Testingenieure auf mögliche Konsequenzen eines anstehenden Releases im Voraus hinweisen. Wenn diese Rolle den Product Owner strategisch beraten kann, hat das spürbare Auswirkungen auf den Unternehmenserfolg – oder -misserfolg – einer neuen Benutzerfreigabe.

Aufgaben eines Testingenieurs/QAs

  • Funktionstests
  • Regressionstests
  • Exploratives Testen
  • Definition von Abnahmekriterien
  • Laufende Risikoanalysen und -bewertungen

Weitere Rollen

Während die zuvor genannten Rollen ein Produktteam bilden, gibt es viele weitere Rollen außerhalb des Teams, die den ergebnisorientierten Fokus des Teams unterstützen.

Zu diesen Rollen zählen Marketing, Vertrieb, Kundensupport und mehr. In der Regel werden diese Funktionen in die Organisation geholt, um das Produkt zu unterstützen, sobald sich der Markterfolg einstellt. Normalerweise sind sie nicht Teil des Produktteams. Eine enge und kooperative Zusammenarbeit mit diesen Rollen trägt jedoch zusätzlich zum Geschäftserfolg bei.

Zusammenarbeit

Obwohl jede Rolle im Produktteam ihren eigenen Fachbereich hat, wird angenommen, dass alle zusammenarbeiten. Wenn jede Rolle eine „t-förmige" Denkweise ins Team einbringt, kann jede Person ihre Spezialität einbringen und zugleich den Fokus auf das Produkt als Teil der Rollenbeschreibung anerkennen. Jede:r geht tief in das eigene Fachgebiet, während gleichzeitig breit in die anderen Kompetenzbereiche vorgestoßen wird, um als Team gemeinsam erfolgreich zu sein.

Zusammenarbeit in einem Produktteam bedeutet einen kompromisslosen Fokus auf Produktergebnisse und Nutzererlebnis. Alle werden einbezogen, um diese Vision zu realisieren und gemeinsam als eine geschlossene Einheit voranzuschreiten.

Fazit

Wichtigste Erkenntnisse

  • Agile Produktentwicklung ist eine auf Menschen und Nutzer fokussierte Philosophie, um schnellere und bessere Ergebnisse zu erzielen.
  • Auch wenn Agile im Kern einfach ist, bringen Prozesse, Unternehmenskultur und weitere Aspekte Komplexität und Herausforderungen mit sich.
  • Agile Prozesse und Rollen können durch Rahmenwerke wie Scrum, Kanban, SAFe und andere geleitet werden.
  • Zu einem agilen Produktteam gehören unter anderem Entwickler:innen, Designer:innen, Testingenieure, ein:e Produktmanager:in und ein:e Product Owner.

Agiles Produktmanagement ist absichtlich und bewusst einfach gehalten. Es ist eine kraftvolle Philosophie, die den Wert, den Ihr Team schaffen kann, enorm steigern kann. Je tiefer man jedoch in die Prozesse und unterstützenden Rollen eintaucht, desto komplexer kann es werden.

In dieser Komplexität verbergen sich Möglichkeiten, das Produktteam und die Organisation zu stärken. Es ist ein Balanceakt, diese Methoden mit Ihrem Team zu nutzen, ohne dabei unnötige organisatorische Hürden für die alltägliche Zusammenarbeit zu schaffen.

Gut umgesetzt und mit einer experimentierfreudigen Haltung kann Agile die Zukunft des Erfolgs Ihres Produktteams maßgeblich prägen.

Haben Sie selbst schon erlebt, wie Agile implementiert wurde oder bereits Erfahrungen damit gesammelt? War dies ähnlich oder anders als in diesem Leitfaden beschrieben? Lassen Sie es uns in den Kommentaren wissen! Vergessen Sie nicht, unseren Newsletter für Product Manager zu abonnieren, um weitere Einblicke und Anleitungen zu erhalten.

Oder bleiben Sie dran und hören/lesen/schauen Sie in diesen Podcast rein, den Sie ganz bequem konsumieren können: Alignment Through Product Roadmaps (mit Brandon Blackman von Crema)

Verwandte Artikel:

Auch einen Blick wert:

Michael Luchen

Michael ist Director of Product bei Float, der Ressourcenmanagement-Plattform zur Planung der besten Arbeit Ihres Teams. Als zukunftsorientierter, menschenfokussierter Produktleiter bringt Michael mehr als 10 Jahre Erfahrung mit, in denen er Teams dabei unterstützt hat, digitale Produkte für über 50 Unternehmen, kleine Firmen und Start-ups in verschiedenen Branchen zu entwickeln. Als Produktmanager, Agile Coach und Technologe unterstützt er Teams dabei, ihre Zusammenarbeit zu verbessern, um komplexe Probleme zu analysieren und zu lösen.