Dennis Willkomm - Roadmap durch die VUCA-Welt

Im Gegensatz zum Wasserfallmodell, wo das Produktmanagement und die Entwicklung zwei getrennte Abteilungen bilden, ist der Product Owner Teil eines Scrum Teams und daher auch mitverantwortlich für die gelungene Umsetzung der Anforderungen. Der Product Owner ist dafür verantwortlich, wasgetan wird. In Scrum ist es wichtig, dass es genau einen Product Owner für ein Produkt gibt. Dies soll verhindern, dass sich zum Beispiel ein Komitee nicht einigen kann und somit Entscheidungen sehr träge getroffen werden können. Zwar können verschiedene Personen sich die Aufgaben des PO aufteilen, am Ende muss es aber genau eine Person geben, deren Entscheidung im Zweifelsfall von allen akzeptiert wird.

Das Entwicklungsteam besteht aus den Experten, die das Produkt herstellen. Das Team zeichnet sich durch seine interdisziplinäre Aufstellungaus. Im Scrum-Umfeld wird diese Eigenschaft als „Crossfunktionalität“ (X-funktional abgekürzt) bezeichnet. Es sind Experten aus den unterschiedlichsten Bereichen der Wertschöpfungskette in einem Team vorzufinden, die dann gemeinsam als Team eine Gesamtverantwortung für ein Produkt oder eines Produktbestandteils übernehmen. Dabei bemüht man sich um die Ausprägung eines T-Profils bei den Teammitgliedern (siehe Exkurs).

Exkurs| T-ProfilT-Profil

In klassischen Arbeitsgruppen, die aus Experten der gleichen Fachrichtung bestehen, hat man es in aller Regel mit Spezialisten zu tun. Diese haben eine tiefgehende Expertise in einem bestimmten Fachgebiet. Damit ihre Expertise möglichst effizient genutzt werden kann, ist ihr Arbeitsumfeld so gestaltet, dass sie sich ausschließlich auf diesen Fachbereich konzentrieren können. Auch Mitarbeiterentwicklung findet in diese Spezialrichtung statt. Dies wird oft als I-Profil bezeichnet, weil es eine einzelne, sehr spezialisierte Fähigkeit repräsentiert.

Demgegenüber strebt man in interdisziplinären Teams das sogenannte T-Profil (T-Shape) an. Dies bedeutet, dass das Teammitglied immer noch ein Experte in einem bestimmten Fachgebiet ist, was den Stängel des T repräsentiert. Gleichzeitig bemüht sich das Teammitglied aber auch, Aufgaben aus angrenzenden Fachgebieten zu lernen und bei Bedarf zu übernehmen. Wenn man ein wenig rechts und links seiner eigenen Spezialfähigkeit schaut, dann ergibt sich so der Querbalken des T-Profils.

Erinnern wir uns zurück an die Engpasstheorie, dann sehen wir, dass dieses angestrebte T-Profil kein Selbstzweck ist, sondern sehr wichtig, um die Leistungsfähigkeit eines Teams zu erhöhen. Ein Teammitglied mit I-Profil könnte, wenn ein Engpass gefunden wird, der in einem angrenzenden Arbeitsschritt liegt, nicht unterstützen, da ihm entsprechende Fähigkeiten fehlen. In klassischen Organisationen, die auf Effizienz und Auslastung optimiert sind, würde ein solches Teammitglied sich weiter mit den eigenen Aufgaben beschäftigen. Dies wäre aber eine lokale Optimierung, die dazu führen würde, dass sich vor dem Engpass ein Berg von Arbeit anhäuft. Besitzt das Teammitglied aber ein T-Profil, kann es den Engpass entlasten und somit zur Gesamtleistung des Teams beitragen, selbst wenn einzelne Glieder der Wertschöpfungskette nicht optimal ausgelastet sind.

Oftmals wird das T-Profil so missverstanden, dass jeder im Team in der Lage sein sollte, jede Aufgabe zu übernehmen, die anfallen könnte. Wie Sie oben gesehen haben, ist dies nicht das Ziel (und auch sehr utopisch). Das T-Profil soll vielmehr sicherstellen, dass eventuelle Engpässe entlastet werden können und im Falle des Ausfalls eines oder mehrerer Teammitglieder die Arbeit nicht komplett eingestellt werden muss, nur weil der eine „wissende“ Fachexperte nicht greifbar ist.

Das Entwicklungsteam organisiert sich selbst, so wie es meint, die gesetzten Ziele erreichen zu können. Das Team trägt die Verantwortung, wieetwas getan wird.

In Scrum gibt es keine speziellen Rollen innerhalb des Teams. Es gibt also keine weitere Unterteilung zwischen Entwicklern, Testern, Analysten, Ingenieuren, Layoutern oder welche Spezialgebiete auch immer zur Erstellung eines Produkts benötigt werden. Dadurch soll zum einen die Entwicklung in Richtung T-Profil unterstützt werden, zum anderen aber auch ein Gefühl für die gemeinsam getragene Verantwortung für das Ergebnis gestärkt werden.

Als dritte und letzte Rolle beschreibt der Scrumguide den Scrum MasterScrum Master .Für die meisten Unternehmen, die Scrum einführen, ist diese Rolle ein absolutes Novum, denn in den allerseltensten Fällen gab es zuvor eine Rolle, die eine vergleichbare Aufgabe hatte. Auf der einen Seite soll der Scrum Master das Scrum Rahmenwerk fördern und unterstützen. Er hilft also dem Team zu verstehen, wie genau Scrum funktioniert, und wie ein Rädchen in das andere greift. Zudem besteht sein Hauptfokus aber darauf, die Zusammenarbeit des Teams zu optimieren.

Der Scrum Master hat dafür drei große Fokuspunkte, auf die er sich konzentriert. Zum einen unterstützt er den Product Owner. Er hilft ihm, die Anforderungen zu priorisieren und mit dem Entwicklungsteam in kleine, zu bearbeitende Aufgaben zu zerlegen. Zudem hilft er dem PO, sich in der agilen Produktplanung zurechtzufinden.

Als Zweites richtet der Scrum Master seine Aufmerksamkeit auf das Entwicklungsteam. Hier liegt sein Fokus darauf, das Team zu einer Selbstorganisation zu befähigen und die Zusammenarbeit zu verbessern. Dafür muss der Scrum Master ganz auf seine Überzeugungskraft und seine Coaching-Fähigkeiten zurückgreifen, denn in Scrum ist niemand vorgesehen, auch nicht PO oder Scrum Master, der in irgendeiner Form weisungsbefugt wäre.

Und zuletzt ist die Rolle des Scrum Masters auch dazu gedacht, in die Organisation hineinzuwirken. Wenn man mit Scrum beginnt, wird man schnell feststellen, dass gewisse Hindernisse, die eine selbstorganisierte Arbeit verhindern, nicht nur innerhalb der Teamgrenzen zu finden sind. Viele Probleme und Herausforderungen sind teamübergreifend und zum Beispiel in vorhandenen Strukturen oder Prozessen begründet. Es ist unvermeidlich, dass ein Unternehmen, das sich agil aufstellen möchte und dafür Scrum einführt, sich auch organisatorisch deutlich verändern muss.

Exkurs| Rollen und Positionen

Scrum definiert drei Rollen. In vielen klassischen Organisationen besteht eine sehr starke Fokussierung auf Positionen. Auch wenn beide Begriffe oft synonym verwendet werden, besteht hier ein deutlicher Unterschied. Eine Position ist untrennbar mit einer Person verknüpft. Frau Maier oder Herr Müller haben eine Position inne. An diese Position wiederum sind gewisse Rechte und Pflichten geknüpft. Ein Projektleiter trägt die Verantwortung für ein bestimmtes Projekt und hat vielleicht ein Budget zur Verfügung und dann auch eine Weisungsbefugnis für die Projektbeteiligten. Positionen sind in der Regel ein Kästchen in einem Organigramm, in dem ein bestimmter Name steht.

Rollen hingegen definieren erst einmal nur Verantwortlichkeiten, sind aber nicht personenbezogen. Das heißt, die in einer Rolle definierten Verantwortlichkeiten müssen erfüllt werden, aber es ist nicht unbedingt festgelegt, welche Person dies tut. Somit kann eine Rolle auch durch mehr als eine Person ausgefüllt werden, indem man beispielsweise die Verantwortlichkeiten aufteilt.

In sehr vielen Unternehmen wird eine Rolle an eine Position geknüpft. In manchen Fällen ist der Product Owner, der in Scrum als Rolle definiert ist, eine feste Position mit einer zugeordneten Person. Andernorts sind an die Position (das Kästchen im Organigramm) noch zusätzliche (nicht im Scrumguide definierte) Aufgaben, Rechte oder Pflichten geknüpft. Hier findet schnell eine Vermischung von Rolle und Position statt, die am Ende zu einem falschen Verständnis von den eigentlichen Rollen führen kann.