Category Archives for "Scrum Rollen"

4 Scrum Master Title

Der Scrum Master als Schlüsselrolle

Scrum Master

Scrum MasterDer Scrum Master ist eine der drei Rollen aus dem agilen Projektmanagement Framework Scrum. Er befindet sich mit dem Product Owner und dem Entwicklungsteam im Scrum Team. Der Scrum Master hat mit Sicherheit eine sehr wichtige Rolle (wie die anderen auch), oft ist es auch die schwierigste in der Umsetzung.

Der Scrum Master ist derjenige der dafür sorgt, dass alle Teammitglieder Scrum optimal durchführen können. Damit kann er als Prozesswächter bezeichnet werden. Um das zu gewährleisten tritt der Scrum Master als Coach, Servant Leader und Enabler auf. Die Kombination ist sehr mächtig, wie oben angedeutet auch sehr anspruchsvoll. Der Scrum Guide liefert die wichtigen Eckdaten, die der Scrum Master umsetzt.

Der Scrum Master organisiert allerdings keine Aufgaben und auch keine Teams. Er ist kein direkter Vorgesetzter und betreibt kein Mikromanagement.

Scrum Master als Prozesswächter

Die Events, die Rollen und die Artefakte spannen für den Scrum Master den Rahmen des Prozesses auf. Wichtig ist dabei, dass der Scrum Guide ein Framework liefert und keinen fertigen Prozess. Innerhalb des Framework ist das Team der Treiber für einen konkreten Prozess.

Servant Leader

Scrum MasterIch habe in meiner Laufbahn unterschiedliche Scrum Master gesehen. Die, die wirklich gut waren hatten immer einen sehr ausgeprägten sozialen Skill. Sie waren amüsant, haben die Teammitglieder zum lachen gebracht und wirklich gute Laune mit in das Team gebracht. Zudem waren sie immer sehr vernetzt in der Organisation. Sie wussten bei wem sie Impediments adressieren und lösen konnten und halfen dem Team, fragten nach Empfindungen und reflektierten viel. Sie waren in der Lage zuzuhören, bei Problem auf den Punkt zu kommen und schafften es auch mit Charme die ein oder andere Aufgabe geschickt wieder zum Team zurückzuspielen, und das Team diese selbst lösen zu lassen.

Nicht jeder Scrum Master ist so. Das ist auch nicht schlimm, denn wenn ich selbst zum Beispiel einmal in die Rolle für eine sehr begrenzte Zeit schlüpfe, dann kann ich zum Beispiel nie so vernetzt in der Organisation sein, wie das jemand aus dieser Organisation selbst leiste kann.

Die Wichtigkeit das Team in Szene zu setzen und ihm zu helfen Dinge zu lösen, zu reflektieren und sich so kontinuierlich zu verbessern ist in meinen Augen eigen sehr wichtige Eigenschaft, die jeder Scrum Master mitbringen sollte.

Der Scrum Master und die Organisation

Der Scrum Master ist nicht nur dafür verantwortlich, dass das Team die Arbeitsweisen kennt und umsetzen kann, sondern auch immer mit einem Fuß in Aufgaben für die Organisation unterwegs. Das erklärt sich praktisch von selbst, wenn wir einen Blick auf die Hindernisse werfen, die ein Scrum Master aus dem Weg räumen soll. Selten befinden die sich ausschließlich im Team, sondern es gibt Rahmenbedingungen, die die Organisation stellt und die in den Fokus rutschen.

Aus der Erfahrung finden Sie als Scrum Master aber mehr oder weniger schnell zu Ihrer Rolle und auch zum Team. Die Aufgaben und Herausforderungen in der Organisation sind dabei immer eine Stufe schwerer zu lösen. Deshalb sollten Sie für diese Rolle nicht nur die oben genannten Eigenschaften mitbringen, sondern auch Spaß daran haben in der Organisation auf unterschiedlichen Ebenen Ihre Runden zu drehen.

Sie sind dann ein guter Scrum Master, wenn…

Sie haben das grundlegende Verständnis von Scrum, darüber hinaus haben Sie die agilen Werte & PrinzipienScrum Master Champion sowie die Scrum Werte verinnerlicht. Die agilen Prinzipien leben Sie aktiv vor und verfügen über eine Kompetenz im Coaching, auch wenn das keine klassische Ausbildung sein muss. Sie können Gespräche führen, Workshops leiten und verfügen über eine hohe soziale Kompetenz. Eine ausgeprägte Kommunikationsgabe ist Ihnen zu eigen, ebenso haben Sie keine Angst vor Konflikten und Gesprächen über weniger erfolgreiche Projekte und Situationen.

Probleme und Hindernisse spornen Sie zum Finden der Lösung an. Sie sind verantwortlich, dass der Scrum Prozess eingehalten wird und stellen sich vor das Team um es aktiv zu schützen. Sie fördern das Zusammenspiel aller Parteien, auch mit externen Zulieferer und beteiligten Parteien. Eine Timebox ist ein Begriff mit dem Sie etwas anfangen können und diese ist Ihnen auch wichtig. Zudem können Sie spontan und vorbereitet moderieren und Hilfestellung rund um Scrum geben.

Die Retrospektive ist Ihr Meeting, um dem Team zu helfen, den gelebten Prozess ständig zu verbessern!

6 Product Owner

Der Product Owner im Detail (kennen Sie die?)

Der Product Owner

Scrum Product OwnerDer Product Owner ist eine der drei Rollen im agilen Projektmanagement Framework Scrum. Neben den beiden Rollen Scrum Master und Entwicklungsteam, kümmert sich der Product Owner um die Anforderungen im Projekt. Ihm gehört das Product Backlog, eines der drei zentralen Artefakte in Scrum. Nur er darf die Reihenfolge in diesem Backlog bestimmen und ist durch seine Priorisierung in der Lage die Effektivität des Produktes zu bestimmen. Er hat dafür zu sorgen, dass das Backlog transparent für alle beteiligten Parteien verfügbar ist.

Der Product Owner muss die Wirtschaftlichkeit des Produktes im Blick haben. Er darf Produktentscheidungen treffen und muss diese verantworten.

Verantwortlichkeiten und Aufgaben

Der Product Owner hat diverse Verantwortlichkeiten und Aufgaben, denen er in seiner Rolle gerecht werden muss. Und das ist gar nicht so leicht! Das Product Backlog ist sein Artefakt und nur er ist der Eigentümer dieses Product Backlogs. Er hat die Verantwortung über das Product Backlog und muss für dessen Transparenz sorgen. Die Reihenfolge in diesem Backlog ist ebenso in seiner Hoheit und er kann damit die Effektivität (“was”) des Produktes maßgeblich mit bestimmen. Er ist derjenige, der mit dem Kunden die Wünsche erarbeiten muss. Damit hat er auch den ROI (Return of Invest) des Produktes in der Hand.

Der Product Owner hat die Aufgabe zusammen mit dem Kunden eine Vision zu erstellen. Für diese Vision gibt es verschiedene Vorgehen und Formate – ich persönlich mag immer noch die drei bis vier Sätze auf dem Flipchart am liebsten. Am Ende eines Sprints ist er es, der die Product Backlog Einträge abnimmt (übrigens: es muss nicht immer das Ende des Sprints sein, es ist nur der letztmögliche Punkt!)

Der Product Owner denkt immer visionär und unternehmerisch. Er besitzt die Produktverantwortung und sollte 50-80% seiner Zeit für ein Projekt und Team aufwenden können. Er sitzt optimal im Teambereich oder ist greifbar, wenn das Team Rückfragen zu Anforderungen hat. Während er für das Team der Ansprechpartner ist, benötigt es auf der anderen Seite – zu den Stakeholdern – einen Ansprechpartner, den ebenso die Product Owner Rolle einnimmt.

Einer der Scrum Werte ist Mut – diesen muss Product Owner selbstverständlich aufbringen (können), denn ab und zu müssen Backlogeinträge weggeworfen, mit dem Kunden die Reihenfolge diskutiert oder ganz unkonventionelle Wege eingeschlagen werden.

Der Product Owner in Theorie und Praxis

Bei einem Treffen der Agile Augsburg Gruppe haben wir über den Wandel der Product Owner Rolle gesprochen. Ich selbst bin mit der Rolle und dem Ausfüllen dieser Rolle schon vor guten 10 Jahren das erste Mal in Berührung gekommen – damals klassisch in der Softwareentwicklung. Die Gruppendiskussionen haben bei mir wieder einige Punkte in der Reflexion angestoßen, die ich hier kurz einmal vorstelle und zur Diskussion stelle.

Aus meiner Sicht gibt es zwei Faktoren, die sich stark auf die gelebte Rolle des Product Owners auswirken. Diese Faktoren sind mit Sicherheit meine subjektiven Eindrücke und auch keine Szenarien die ich empfehle oder für gut betrachte. Es sind einfach Erlebnisse und Eindrücke, die ich teile.

Unternehmensgröße

Unternehmensgröße

In meiner beruflichen Laufbahn habe ich mehr mit großen, als mit kleinen Unternehmen zu tun gehabt. Auffällig war es für mich immer, dass in großen Organisationen die Rolle des Product Owner weiter weg vom Lehrbuch ist, als in kleinen Unternehmen. Ebenso scheint es mir, es gibt ein Art Selbstverständlichkeit, diese Tatsache in größeren Unternehmen hinzunehmen. Es wird weniger hinterfragt und weniger ausprobiert. Ich tippe auf die Rahmenbedingungen in den Organisationen und auf die Trägheit des Systems als Ganzes, dass sich dieses mir so dargestellt hat. Die Mitarbeiter in großen Organisationen kennen lange Wege in der Hierarchie und bestimmte Dinge werden einfach ausgesessen. Man will sich nicht gleich mit dem Chef anlegen und eine blutige Nase holen. In kleinen Unternehmen herrscht in der Product Owner Rolle der Unternehmergeist. Hier finden Sie häufiger eine Product Owner Rollenimplementierung, die auch empowered ist, Dinge zu entscheiden und zu tun.

Produktinkrement in Scrum

Produktlebenszyklus

Eine weitere Beobachtung, die ich immer wieder machen kann: der Produktlebenszyklus ist entscheidend! Finden wir in Unternehmen Product Owner und ein Produkt, dass eine Neuentwicklung darstellt, wird die Rolle besser gelebt und ausgefüllt, als wenn wir Product Owner vorfinden, die ein Produkt betreuen, das schon etwas in die Jahre gekommen ist. Hier spielt sicherlich auch mit hinein, dass die Product Owner dann oft auch nur einen Teil, eine Funktion oder Applikation eines größeren Produktes betreuen. Je “reifer” das Produkt ist und je weniger innovativ es sein muss, desto eher finde ich die Situation, dass der Product Owner (gerne auf frühere Projektleiter) einfach nur das Backlog verwaltet.

Eine Ursache liegt oft hier begraben…

Scrum Entwicklungsteam

Die Größe von Unternehmen korreliert in meinen Augen sehr stark damit, ob ein Entwicklungsteam im Sinne von Scrum cross-funktional aufgestellt wird. Wenn wir einen Product Owner haben, der nicht befähigt ist, hat er selten ein cross-funktional Team  bei sich. Der typische Fall ist der, dass hier darauf geachtet wird, in bestimmten Funktionen zu denken, nicht aber im Sinne eines Produktes, das in einem Backlog beschrieben wird und von einem Team umgesetzt wird. (Und ja: ich weiß selbst, dass nicht ein Team ein Auto, einen Roboter oder ein wie auch immer geartetes System liefern kann – darum geht es primär auch nicht!)

Genug philosophiert, nun geht es an die Punkte, die ich vom Treffen mitgenommen und mir noch mal durch den Kopf habe gehen lassen.

Kein Befähigung / kein Empowerment

Was tue ich denn nun, wenn mein Product Owner nicht befähigt ist? Eine sehr häufige Frage, die immer wieder in Trainings und Workshops bei mir gestellt wird. Die Teilnehmer wissen nämlich schon zu Beginn, dass die Product Owner Rolle nicht so gelebt werden kann, wie sie angedacht ist. Meine erste Antwort ist dann immer:

Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.

Scrum Guide

Wenn Sie einen schlagkräftigen Product Owner wollen, dann müssen Sie auch auf seine Eigenschaften, Verantwortungen und Aufgaben fokussieren. So funktioniert Scrum und dann, kann Scrum die wahren Vorteile ausspielen. Natürlich geht es auch ohne und es lassen sich viele andere Wege finden. Es ist trotzdem kein Scrum. Was die einen jetzt abtun mit “man muss ja Scrum auch der Realität anpassen” oder “Scrum funktioniert ja nur in der Theorie” ist oft das Ergebnis von Resignation.

Ich kenne es nur zu gut in großen Unternehmen, dass man irgendwann einfach keine Lust mehr hat, die Organisation “überzeugen” zu wollen. Gerade die Scrum Master haben damit alle Hände voll zu tun und diese organisatorischen Änderungen dauern eben sehr, sehr lange.

Natürlich ist der Scrum Master die Person, die bei so einem gravierendem Hindernis eingreifen muss. Er ist der Hüter des Prozesses und sorgt dafür, dass alle Scrum machen können. Was so einfach klingt ist leicht gesagt, aber schwer umgesetzt. Und nicht alle Unternehmen sind bereit für Scrum. Und erst recht haben nicht alle Unternehmen ihre Warum-Scrum-Frage beantwortet und an alle kommuniziert.

Wie ersetze ich meinen Product Owner?

Der Product Owner wird schnell zu einer zentralen und tragenden Rolle. Er kennt den Kunden und die Anforderungen an das Produkt sehr genau. Was passiert nun, wenn der Product Owner einmal ausfällt? Jeder macht Urlaub, der ist planbar. Doch mit Krankheit oder schlimmeren kann verständlicherweise in der Planung schlecht umgegangen werden.

Die Frage lässt sich beantworten, in dem wir einen Blick darauf werfen, wie wir es sonst tun. Wie verlagere ich Wissen auf mehrere Schultern? Typische Wege das zu stemmen sind nicht anders als sonst auch. Hier könnte ein “Lead-Entwickler”, dem das Team vertraut und der ein gutes Wissen hat, den Product Owner vertreten.

Wenn ein Unternehmen größer ist, bestehen ggf. noch andere Möglichkeiten. Es ist aber ähnlich zu einem cross-funktionalem Entwicklungsteam. Es kostet alles einen gewissen Preis. Sie können versuchen (bei entsprechender Unternehmensgröße) eine Art Community of Practice für die Product Onwer etablieren. Das funktioniert gut, wenn Sie mehrere Product Owner haben und diese zu bestimmten Teilen auch andere Produkte betreuen könnten. Das erfordert natürlich, dass Sie nicht alle Product Owner komplett auslasten und noch Verfügbarkeiten existieren.

Wie skaliere ich den Product Owner?

Zunächst einmal bin ich kein Fan, alles gleich über eine Skalierung zu lösen. Ich gestehe allen Skalierungsframeworks eine Daseinsberechtigung zu. Ob SAFe, LeSS oder Nexus, sie sind alle entstanden, da sie Herausforderungen adressieren, die in größeren Kontexten gelöst werden müssen. Um es mit den Worten von Guy Kawasaki zu sagen “It’s not about Scaling, it’s about adopting”. Auch wenn diese Aussage natürlich aus dem Kontext gerissen ist, steht Sie für mich bei der Skalierung recht weit vor.

Kaum ein Unternehmen überlegt sich zu Beginn die Herausforderungen, die mit einer Skalierung gelöst werden sollen. Es gibt ja Frameworks. Einfach einen Blueprint nehmen und dann wird das schon. Funktioniert in der Regel nicht! Wer mit Scrum auf kleiner Ebene scheitert, wird auch bei Skalierungen keinen Erfolg haben.

Warum wollen oder müssen wir den Product Owner denn überhaupt skalieren? Dabei gibt es zwei Ansätze. Zum einen können Sie über die Produkte skalieren. Sie haben also mehrere Produkte und benötigen deshalb auch mehrere Product Owner. Das ist oft der Aspekt, den viele nicht unter der typischen Skalierung verstehen. Der zweite Ansatz geht über das selbe Produkt. Ich will es einmal recht einfach ausdrücken: das Produkt ist groß und kann nicht von einem Product Owner alleine verwaltet werden.

product-owner-skalierung

Sowas sollte aus meiner Sicht emergent wachsen und durch die Organisation selbst entwickelt werden. Je weniger reif die Organisation ist, desto besser funktionieren Frameworks – zumindest von der Überzeugung diese einzuführen.

Fazit

Der Product Owner ist eine klasse Rolle und wirklich toll, wenn die Umsetzung wie gedacht funktioniert. Es gehört allerdings eine Menge dazu, mehr als rein mechanisches Scrum zu machen. Die Organisation braucht eine klare Antwort auf das “Warum machen wir Scrum”, ein passendes Training dazu, die Definition eines Produktes und eine gute Strategie, wie man sich End-2-End zum Kunden aufstellt. Das sind gute Voraussetzungen, damit auch die Product Owner Rolle gut gelebt werden kann.

5 Scrum Entwicklungsteam

Das Scrum Entwicklungsteam

Scrum Entwicklungsteam

Scrum EntwicklungsteamDas Scrum Entwicklungsteam ist eine der drei Rollen, die das agile Projektmanagement Framework Scrum kennt. Das Entwicklungsteam ist die Rolle, die das Produktinkrement am Ende eines Sprints erstellt. Es ist somit auch die Rolle, die konkreten und erlebbaren Mehrwert für die Stakeholder generiert – und nicht etwa ein Manager. Das Scrum Entwicklungsteam hat einige Eigenschaften, die ich in diesem Artikel aufzeige. Dabei sind die Grundlagen natürlich im Scrum Guide zu finden.

Eigenschaften eines Scrum Entwicklungsteam

Neben der Verantwortung für das Produktinkrement am Ende des Sprints, auf das sich das Scrum Entwicklungsteams “commited” (also verpflichten) muss, hat es eine Reihe von Privilegien. So ist das Scrum Entwicklungsteam die einzige Rolle, die bestimmt, wie viel in einem Sprint umgesetzt werden kann. Es ist also nicht der Product Owner (wie man meinen könnte) der die Entscheidung trifft, wie viel in einem Sprint umgesetzt wird.

Oft nicht beachtet wird, dass das Scrum Entwicklungsteam Vollzeit als Team arbeitet. Es wird also nicht zeitlich zusammen gesetzt und trennt sich auch nicht, während es ein Produkt umsetzt. Dabei finden sich in der Praxis oft Abweichungen, die alle nicht optimal funktionieren. Die optimale Teamgröße beträgt acht Personen und in Scrum gehen wir davon aus, dass das Team zwischen drei und neun Personen groß sein kann. Unter drei Personen ist es schlicht kein Team, über neun Personen werden die Kommunikationswege innerhalb des Team so groß, dass es in der Regel in Unterteams zerfällt.

Das Team ist selbstorganisiert, das bedeutet es bestimmt selber, wie die Arbeit umgesetzt werden muss. Es gibt in Scrum keinen Projektleiter, der einem Teammitglied sagt, wie es etwas umzusetzen hat (auch nicht der Product Owner). Um das machen zu können, muss ein Scrum Entwicklungsteam cross-funktional sein.

Das Scrum Entwicklungsteam ist selbst für das Reporting verantwortlich und aktualisiert den Projektfortschritt mit Hilfe von bspw. Burn-Down-Charts täglich selbst.

Die Checkliste für Ihr Scrum Entwicklungsteam

Das Scrum Entwicklungsteam hat eine Reihe von Aufgaben und Verantwortungen. Um diesen gerecht zu werden, benötigt es zu dem noch Kompetenzen. Schauen wir uns diese Punkte in der Übersicht für Sie an.

Eigenschaften

Scrum Werte - Commitment

Enge Zusammenarbeit zwischen dem Scrum Entwicklungsteam und dem Product Owner

Scrum Entwicklungsteam Sprint Ziel

Das Scrum Entwicklungsteam definiert das Sprint Ziels mit dem Product Owner

cross-funktional T-Shaped

Das Scrum Entwicklungsteam ist cross-funktional und hat alle benötigten Skills das PSI zu erstellen

Sprint Backlog

Zusage und Verantwortung zugesagter Product Backlog Items

Scrum Entwicklungsteam

Das Team organisiert sich selbst

Produktinkrement in Scrum

Vorstellung der fertigen Ergebnisse durch das Team

Das Scrum Entwicklungsteam und gängige Probleme

Natürlich sieht die Realität oft anders aus, als die Theorie es vorlebt. Lassen Sie sich bitte hier auch nicht entmutigen, wenn Sie nicht gleich die besten Rahmenbedingungen vorfinden. Ich beschreibe in meinen Udemy Kursen und weiteren Blogartikel, wie Sie auch zu guten Teams kommen. Vielleicht finden Sie sich in den folgenden Punkte selbst auch schon wieder.

Reine Experten im Team

Heutige Organisationen sind noch überwiegend sehr tailoristisch geschnitten und dabei wird oft nur in reinen Funktions- oder Silogedanken mit Teams gearbeitet. Sie wären also nicht das erste Team, das kein cross-funktionales Team ist. Das ist zunächst nicht schlimm und Sie werden und können sich Stück für Stück dann an die Lösung heran arbeiten, der Wille der Organisation und gerade des Managements muss dafür natürlich gegeben sein.

Kein Vollzeit-Team

Sie haben ein Team und Teammitglieder die nicht alle Vollzeit im Team arbeiten können. Sie ich in meinem Artikel über cross-funktionale Teams bereits angerissen habe, ist das natürlich immer einer Frage unter monetären Gesichtspunkten und einer Priorität. Komplett interdisziplinär zu jeder Zeit zu sein bedeutet, dass das Projekt immer die oberste Priorität hat und alle Teammitglieder zur entsprechenden Zeit auch zur Verfügung stehen.

Zugriff von außerhalb auf das Team

Je nachdem wie groß Ihre Organisation ist und wie sich die Wege in der Organisation gestalten, etwas zu bekommen, wird auf Teams gerne direkt zugegriffen. Der PO wird übergangen – das darf uns soll nicht passieren. Sie müssen darauf achten, dass das Team wirklich als Team funktionieren kann. Das passiert öfters mal, wenn zur Serumeinführung nicht alle Mitglieder der Organisation geschult sind und zum Beispiel gerade das Management außen vorgelassen wird.

2

Cross-funktional: interdisziplinäre Teams

Das cross-funktionale Team

Scrum ZertifizierungenEin cross-funktionalen Team in Scrum ist ein Team, dass unterschiedliche Fähigkeiten mitbringt, um anstehende Aufgaben zu erledigen und mit innovativen Ideen Produkte entwickeln, die Kunden lieben! Agile Teams müssen cross-funktional sein, um überhaupt agil arbeiten zu können. Klingt eigentlich ganz einfach, stellt aber beim genaueren Hinsehen fast alle Unternehmen vor eine Herausforderung. In diesem Artikel werden wir uns cross-funktionalen Teams genauer ansehen und klären, was es mit diesem Begriff auf sich hat.

Cross-funktional: Jeder kann alles?

Es hält sich hartnäckig: das Gerücht, dass in einem cross-funktionalen jedes Mitglied alles können muss. Das muss weder Ihrer Personalabteilung noch dem Scrum Master Probleme und Kopfzerbrechen bereiten, denn diese Anforderung müssen Ihre Teams nicht erfüllen, um cross-funktional zu sein.

Cross-Funktionalität definiert sich durch das Ziel!

Fokus Ziel (Daily Scrum Meeting)Bevor wir nun mit gefährlichem Halbwissen um uns werfen, schauen wir uns kurz einmal an, was das Ziel von einem Scrum Team in einem Sprint ist. Das Ziel im Sprint ist das Entwickeln eines Produktinkrementes! Wann ist so ein Produktinkrement fertig? Genau, wenn wir die Definition of Done dazu erfüllen. Es wird immer gerne vergessen, aber wir wollen die Dinge, die wir uns vornehmen fertig bekommen und für die Stakeholder erlebbar machen. Das ist Scrum und dafür brauchen wir zwingend ein Produktinkrement und dafür muss Ihr Team cross-funktional sein!

Jetzt sieht die Definition of Done in jedem Team anders aus und kann ich auch am Ende der Sprint Planung die Definition of Done für den Sprint noch einmal anpassen. Wenn wir nun eine Funktionalität auf einem Entwicklungsrechner als fertig ansehen, dann ist das etwas ganz anderes, als ein Produktivsystem. Wenn Sie einen Motor entwickeln, der schon Serienbedingungen erfüllt sieht eine Definition of Done anders aus, als wenn Sie diesen unter vereinfachten Bedingungen in einem Labor laufen lassen. Je spezieller die Definition of Done sich gestaltet, desto mehr Wissen, Skills und damit auch zwangsläufig Teammitglieder benötigen Sie!

Halten wir also fest: Wie cross-funktional ein Team sein muss, hängt in erster Linie von der Definition of Done ab, wie das Produktinkrement am Ende des Sprint aussehen muss.

Definition of Ready beeinflusst Ihr Team ebenso!

Die Definition of Ready bestimmt, wann ein Product Backlog Item (PBI) aus dem Sprint Backlog in den Sprint gelangen darf. Sie ist zwischen Team und Product Owner festgelegt. Nehmen wir an, Sie haben hier nur Angaben für die typische Entwicklung gelten, dann reicht es wahrscheinlich aus, mit Entwicklern im Team zu arbeiten.

Doch was ist, wenn wir uns etwas weiter bewegen? Was wenn wir darin Marketing-, Verkauf-, Statik-, Hardwarebedingungen haben? Dann ist die Anforderungen an das Team höher und dementsprechend muss Ihr Team cross-funktionaler sein.

Je mehr “unspezifiziertes” Sie haben, je mehr Wissen dafür nötig ist, desto cross-funktionaler muss Ihr Team sein. Sie müssen mehr in Erfahrung bringen, also reine Entwicklungstätigkeiten bei einem Softwareprodukt? Dann muss das Marketing vielleicht ebenso im Team sein, da Aufgaben dazu anfallen werden. Sind solche Themen bereits im Vorfeld geklärt, dann ist ein weniger cross-funktionales Team ausreichend.

T-Shaped – jetzt wird es spannend!

cross-funktional T-ShapedWir wissen alle, dass wir die oben genannten Fähigkeiten gar nicht immer alle benötigen. Wir brauchen also nicht für jede dieser Fähigkeiten genau eine Person im Team. Das wäre bei einigen Produkten aufgrund der Anzahl auch gar nicht mehr möglich. Es gibt daher den Begriff des T-Shaped-Team-Mitglied. Jedes Teammitglied hat eine Spezialisierung in der es auch arbeitet, zudem aber weitere Randbereiche oder gar ganz andere Fertigkeiten und Fähigkeiten, die es kann, in denen es aber nicht so effektiv ist, wie in der Spezialisierung.

Cross-Funktionalität

Ihr Team ist genau dann (ausreichend) cross-funktional, wenn Sie alle Fähigkeiten zum Erreichen eines Produktinkrements für den Sprint im Team besitzen.

Der Bruch mit dem Vollzeitteam

Scrum EntwicklungsteamSie haben darauf gewartet, korrekt? Heute ist es schon Mode, immer in mehreren Projekten zu sein. Mehr zu machen, als nur eines. Wir alle wissen, dass es grundsätzlich Quatsch ist, negatives Multitasking zu betreiben. Negatives Multitasking tritt immer genau dann ein, wenn Sie Dinge liegen lassen müssen, sich neuen Dingen widmen und dadurch Transaktionskosten bekommen, die uns unproduktiv werden lassen. Aber in fast jedem Unternehmen höre ich genau diese Situation.

Ich habe dazu eine einfache und harte Meinung: Wenn dem Unternehmen das Projekt sehr wichtig ist, dann wird es die Vorraussetzungen dafür schaffen. Wenn es der Meinung ist, so wichtig ist es dann doch nicht, dann wird es eben ohne diese Rahmenbedingungen laufen. Dann werden Sie in der Scrum Implementierung viele andere Probleme sehen, mit denen Sie dann leben müssen.

Entweder ist das Projekt das Wichtigste an dem das Unternehmen arbeitet oder nicht. Als nächstes kommt dann sehr oft die Anmerkung, dass eine bestimmte Person im Wissen so exklusiv ist, dass diese in mehreren Teams arbeiten muss. Wenn Sie es schaffen (und ja, ich bezweifle es in vielen Organisationen), dass Sie Teammitglieder on-demand in einem Team verfügbar machen können, dann tun Sie es (also der Marketing-Experte nur dann im Team ist, wenn er gebraucht wird). Die Erfahrung zeigt auch hier, dass dieses schwer ist. Wenn Not am Manne ist, dann in der Regel an zwei Projekten gleichzeitig. Das entscheidende Update im Daily hat der Marketing-Experte dann doch nicht mitbekommen und es resultiert erneut in Problemen. Aber es soll Organisationen geben, die das schaffen können!

Grundsätzlich können Sie davon ausgehen, wenn Sie ein komplexes, innovatives Produkt entwickeln wollen, dann muss Ihr Team sehr cross-funktional sein. Wenn Sie auf Effizienz bedacht sind, werden die Teams weniger cross-funktional sein. Auch hier zeigt sich sehr schön die Effektivität: das Scrum Team selbst ist als Team gut aufgestellt, wie effizient es aber im Prozess bei Ihnen ausgestattet wird, liegt einzig und alleine bei Ihnen!

Vollzeit-Teams und Cross-Funktionalität sind teuer!

Scrum Kurs EinmalzahlungAlles könnte so einfach sein, aber wir müssen ja in unserem Wirtschaftssystem auch immer auf das Geld schauen. Wenn Sie übrigens nicht auf das Geld schauen müssen, dann haben Sie natürlich einen absoluten Luxus und können sich mehr Cross-funktionalität erlauben als andere.

Wir können also leider nicht beliebig cross-funktional sein, auch wenn wir es und unsere Teams gerne wären. Aber dennoch: Es ist ein Weg des Ausprobieres – wieviel Cross-Funktionalität benötigen Sie als Team denn wirklich? Cross-funktional ist eine wichtige Eigenschaft guter Teams. Gutes kostet immer Geld und es gibt nicht die Hausnummer für das richtige Maß der Cross-Funktionalität.

Cross-Funktionalität kostet

Wenn Ihr Team stark cross-funktional ist, dann kostet Sie das Geld.

Ich bin immer ein Fan vom Ausprobieren. Merken Sie, dass Sie nicht in der Lage sind ein Produktinkrement am Ende des Sprints zu erstellen, überprüfen Sie doch einmal, ob Ihr Team ausreichend cross-funktional für Ihr Ziel und Ihr Produktinkrement ist. Schauen Sie sich zudem einmal Ihre User Stories (oder Anforderungen) an. Wie sind diese geschnitten? Unterstützt das Ihre aktuelle Teamaufteilung? Die Retrospektive ist auch hier Ihr Freund!