Im klassischen Verständnis von Scrum besteht ein Scrum-Team (Aufbau) im Wesentlichen aus drei Rollen: einem Product Owner, einem Scrum Master und dem Scrum-Team (vgl. Abb.). Dies hat sich selbstverständlich in zahlreichen Produkt- und Growth Hacking Teams weltweit bewährt…
Mehr dazu im „Agile Team“ Whitepaper
Ähnlich der 4-4-2-Aufstellung beim Fußball. Allerdings ist diese schon wieder überholt, so dass die großen Champions-League-Teams heute wesentlich flexibler in ihrer Aufstellung agieren können. Früher spielten alle bedingungslos mit Libero, danach alle mit Viererkette. Heute wird so gespielt, wie die eigene Stärke und Taktik sowie die des Gegners es eben zulassen.
Genauso flexibel muss man bei der Aufstellung seiner Scrum-Teams vorgehen. Was will ich mit dem Team erreichen? Wie ist die Marktsituation? Welches Budget und welche Ressourcen habe ich zur Verfügung? Welche Stärken und Schwächen haben die bereits vorhandenen Team-Mitglieder?
Erfahrungsgemäß bringt es gar nichts, vorhandene Ressourcen auf eine andere Rolle im Scrum-Team zu setzen. So benötigt ein Product Owner ein gewisses Skillset, das eben nicht jeder mitbringt. Das Gleiche gilt für den Scrum Master und entsprechend natürlich auch für die einzelnen Team-Member.
Dazu passt ein Satz von Jean-Marc Noel, Gründer und CEO von Trusted Shops: „Mache niemals den besten Entwickler im Team zu einem schlechten Manager.“ Denn man verliert nicht nur seinen besten Entwickler, sondern erntet zudem auch noch ein nicht-funktionierendes Team.
Das soll übrigens nicht bedeuten, dass Entwickler nicht Führungspositionen übernehmen können. Vielmehr würde man dadurch alle drei Seiten unglücklich machen: Der Entwickler liefert nicht mehr so gute Leistungen, die gemanagten Mitarbeiter werden nicht ordentlich geführt und es fehlt ein richtiger guter Entwickler. Es hängt demnach immer vom individuellen Skillset und Entwicklungspotenzial ab, wie ein Team besetzt wird.
Noch ein letztes Beispiel aus dem Fußball, welches ich immer gern in Vorträgen und Workshops anbringe: „Du kannst ein einziges Spiel auch mal mit einem Feldspieler als Torwart gewinnen, die Meisterschaft jedoch garantiert nicht.“ Die Verantwortung des Team-Managers ist es somit umso mehr in den Scrum-Teams, die Stärken und Schwächen der einzelnen Personen sowie des gesamten Teams zu erkennen. Stärken konsequent zu fördern und Schwächen immer wieder zu hinterfragen und auszubügeln. Auch diese Eigenschaften – Menschenkenntnis und Empathie – sind nicht jedermanns Sache und darüber hinaus ein weiterer Full-Time-Job.
Details zu dem idealen agilen Team Setup gibt es in unserem kostenlosen Whitepaper!
Nachfolgend die 8 Rollen eines agilen Teams:
1. Product Owner
Die Person, die verantwortlich ist für die kurz-, mittel- und langfristige Produktvision. Die Positionierung des Produktes auf dem Markt sowie der Betrieb und die Weiterentwicklung gehören dabei in der Regel zu den klar abgesteckten Aufgabenfeldern des Product Owners.
Ihm gehören die Product Roadmap sowie das Product Backlog und er ist zudem verantwortlich für die Detaildefinition, die Kommunikation und Vermarktung der entstehenden Features. Ich spreche hier gern vom „Tech-savy Marketing Unicorn“. Er muss alle Disziplinen verstehen – Marketing, IT und Sales. Ein Product Owner hat zudem die Gabe, seine Ideen und Anforderungen an das Produkt-Team möglichst einfach und eindeutig erklären zu können. Erfahrungsgemäß sind visuelle Mockups ein hilfreiches Werkzeug, um Ideen möglichst einfach transportieren zu können. Ein Product Owner ist im gesamten Unternehmen bekannt, liebt sein Produkt über alles und das Produkt liebt ihn.
2. Scrum Master
Die Person, die sich mit dem Product Owner zu 100% verstehen muss, da sie fast die gesamte Arbeitszeit zusammen verbringen. Am liebsten spreche ich vom Ehepaar, welches in den wichtigsten Dingen auf einer Wellenlänge ist, aber auch die Fähigkeit besitzt, unterschiedlicher Meinung zu sein, zu streiten und sich wieder zu versöhnen.
Ein Scrum Master ist dafür verantwortlich, die Product Roadmap mit dem ScrumTeam zusammen umzusetzen und alle möglichen Probleme des Produkt-Teams beim Entwicklungsprozess zu beseitigen. Der Scrum Master schützt das gesamte Team sowie den laufenden Sprint vor äußeren Einflüssen, im schlimmsten Fall auch vor dem Product Owner. Zudem sorgt er für die Einhaltung der wichtigsten und produktivitätssteigernden Scrum-Artefakte wie Dailies, Retrospektiven, Sprint Planning und Sprint Goals.
Diese Rolle steht der des Produkt Owners oder des Scrum-Teams in der Priorität oder der Wichtigkeit – meines Erachtens – um nichts nach. Im Gegenteil. Alle drei Einheiten können ohne die jeweils anderen nichts erreichen, da sie sich perfekt ergänzen müssen.
3. Developer
Je nachdem, um welche Art von Produkt es sich handelt, wird eine beliebige Anzahl an Developer mit den jeweils notwendigen Fähigkeiten dem Produkt-Team hinzugefügt. Wichtig ist, dass die Developer zu 100% dem Produkt-Team zugehörig sind, um sich mit den Teamzielen identifizieren zu können und zudem nicht von anderen Teams weggepitcht werden zu können.
Um Developer-Ressourcen streiten zu müssen, macht niemandem Spaß. Erst recht nicht dem Developer selbst. Zumal die Fähigkeiten der heutigen „modernen“ Developer weitaus fortgeschrittener sind, als viele Manager von gestern noch glauben. Kundenorientierung, agiles Denken und ein Händchen für UX sind heute keine Seltenheit unter Entwicklern.
Ein Entwickler ist demnach nicht mehr der Programmierer von gestern, der ein Lastenheft einfach nur runterprogrammiert und danach auf das nächste Projekt gebucht wird. Vielmehr sind die Entwickler wichtiger Partner bei der Machbarkeitsschätzung der Features, zusätzlich für den Betrieb der Produkte verantwortlich (DevOps), diejenigen, die den technologischen Fortschritt vorantreiben müssen.
Vor einiger Zeit sagte mir ein neuer Entwickler im Team: „Vorher war ich quasi ein Kartoffelschäler.“ Ich entgegnete ihm: „Kennst Du ,Minority Report´? Ihr seid für mich die Precogs. Ohne euch geht gar nix. Und deswegen muss man euch schützen und permanent fördern.“
Entwickler schon in die Product Roadmap Planung einzuladen, ist oftmals sehr effizient, da ein Product Owner direkt ein gutes Gefühl für Aufwände und technische Hindernisse einer Produktidee bekommen kann. Zudem ist das Team auf diese Art und Weise direkt involviert und empfindet die Roadmap als seine eigene Roadmap. Das ist erfahrungsgemäß extrem motivierend.
4. DevOps
Was ist denn eigentlich jetzt schon wieder dieses DevOps? Immer neue Buzzwords, auch für den Aufbau einer Organisation.
DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.
Die DevOps-Kultur gilt derzeit als heißer Trend in der Tech-Szene. Gefühlt strebt jedes Unternehmen an, autonome Teams aufzubauen, die völlig selbstständig für die Weiterentwicklung (Development) und den Betrieb (Operations) ihres Produkts verantwortlich sind.
Baut man in einem Start-up ein neues Produkt von der grünen Wiese auf und sucht sich das Team von Beginn an komplett aus, dann ist der DevOps-Gedanke ein riesiger Gewinn. Niemand muss mehr die ITler fragen, ob sie bei Problemen mit den Mailservern oder der Ladezeit der Website helfen können. Hat man DevOps im Team und sind diese mit allen Fähigkeiten sowie Rollen und Rechten ausgestattet, kann man so enorm an Produktivität und Zielorientierung gewinnen. Vorbei die Zeiten, in denen drei Teams gleichzeitig um die eine IT-Ressource kämpften. Schöne neue Welt, oder? Leider für größere Unternehmen ein enormer Change, der viel Zeit kosten kann.
Die vorhandenen Developer im Team einfach als DevOps zu bezeichnen funktioniert nicht. Schließlich wurden die meisten entweder als Developer oder als System-Administrator geholt, aber eben nicht für beides. Mitunter hat man ein paar DevOps im Team, die von ihrem Skillset und Erfahrungsschatz her die DevOps-Kultur vorleben können. Alle anderen müssen durch Weiterbildungen und ständiges Coaching erst zum DevOps ausgebildet werden. Das ist die einzige Lösung. Schwierig, aber möglich.
Darüber hinaus haben Unternehmen oft eine IT-Architektur, die sehr monolithisch aufgebaut ist. Dies hat zur Folge, dass es für den Betrieb eines Produktes immer auch zahlreiche technische Abhängigkeiten zu anderen Produkten zu beachten gilt. Solange nicht dieser System-Monolith konsequent in unabhängige Module transformiert wurde, kann ein einzelnes Team leider gar nicht vollständig selbstverantwortlich agieren.
Aber was ist zu tun? Die konsequente Modularisierung der IT-Systeme. Mit dem Ziel, dass Produkt-Teams wirklich für die modularen Bausteine der Anwendung die Verantwortung übernehmen können. So können sie eigene Releases durchführen und selbst bestimmen, welche Datenbanken, Applikationen oder Programmiersprachen eingesetzt werden. Hier spricht man häufig von Microservices, also dem Bereitstellen von kleinen autarken Funktionalitäten innerhalb des eigenen Systems. Ein großer und aufwendiger Schritt, den man keineswegs unterschätzen sollte. Als ein Beispiel, das diese Transformation bereits durchlaufen hat, kenne ich das Online-Mode-Magazin „Stylight“ aus München. So berichtet Sebastian Schuon, Gründer von „Stylight“ auf der bitsandpretzels 2016, dass dort diese organisatorische Änderung hin zu vollständig „autarken“ Teams in nur gut einer Woche umgesetzt wurde.
Für größere Unternehmen liegt die Aufgabe demnach darin, die Produkt-Teams immer weiter mit DevOps-Skills und allen Tools und Verantwortlichkeiten auszustatten, so dass sie wirklich autonom agieren können. Von Tag 1 an wird das nicht so funktionieren, wie man sich das wünscht, da die Abhängigkeiten der IT-Systeme noch vorhanden sind und wahrscheinich die Leute im Team DevOps erst lernen müssen.
Meine persönliche Empfehlung ist jedoch, sich auch hier am Lean-Modell zu orientieren und sich erst mal ein Produkt-Team vorzunehmen und dieses mit allem auszustatten, was es benötigt, um das Produkt weiterentwickeln und betreiben zu können. So kann man es auch intern als „Experiment“ verkaufen, statt den Mitarbeitern das Gefühl zu geben, dass man die ganze „funktionierende“ Organisation vollständig auf den Kopf stellt, ohne nachvollziehbare Argumente zu haben.
5. Software-Architekten
Ein Software-Architekt ist ein Developer, der in der Lage ist, die Zusammenhänge zwischen verschiedenen Applikationen zu erkennen und zu optimieren. Welche Funktionalitäten gehören zusammen und welche sollte man separat aufbauen? Entwickelt und betreibt man eine Applikation selbst oder setzt man auf eine Cloud-Lösung? Welche Teile aus dem bestehenden IT-System lassen sich wie herauslösen und durch eine Standard-Software ersetzen? Mit derartigen Fragen hat ein Software-Architekt im besten Fall den ganzen Tag zu tun.
Genauso, wie man in einem Start-up von Beginn an einen CTO im Gründer-Team haben sollte, um das Produkt von Beginn an technisch auf solide Beine stellen zu können, müssen Unternehmen Software-Architekten einstellen, die beim Aufbau der neuen Welt beziehungsweise der Migration zur neuen Welt das Heft in die Hand nehmen können.
Wie organisiert man die Software-Architekten? Starten sollte man mit einem Architekten-Pool, der sich um die gesamte IT-Architektur kümmert. Von dort kommen dann die richtigen Impulse, an welcher Stelle im System man bestenfalls arbeiten muss. Von hier muss auch gesteuert werden, wie man die Produkte technisch so unabhängig voneinander macht, dass sie den DevOps-Gedanken endlich leben können.
Benötigen Produkt-Teams immer wieder Architektur-Support, empfiehlt es sich, dem Produkt-Team einen „eigenen“ Architekten zu 100% zur Verfügung zu stellen. Natürlich muss der Software-Architekt dennoch den Austausch mit den anderen Architekten aufrechterhalten. Dies funktioniert meistens recht gut, über sogenannte Gilden.
6. UX-Designer/ Usability Experts
Hier verhält es sich ähnlich wie bei den Entwicklern. Für die allerersten Mockups, über Clickdummys bis hin zu finalen Designs und HTML-Implementierungen. Es lohnt sich immer, die UX-Designer von Anfang bis Ende des Entwicklungsprozesses vollständig mit einzubinden, statt ihnen zu einem bestimmten Zeitpunkt im Entwicklungsprozess einen zusammenhanglosen Auftrag zu geben, oftmals mit der wenig charmanten Ergänzung: „Mach das doch mal schön.“ Nicht schön für die UX-Designer.
Wiederum ähnlich wie bei den Developern, haben auch die Designer von gestern nicht die gleichen Skills wie die UX-Designer von heute. Es gilt nicht mehr, „nur“ die Entwürfe in ein reines grafisch perfektes Bild zu gießen und dies für die Entwickler fertig zerschnitten für das HTML-Gerüst zur Verfügung zu stellen. Vielmehr geht es darum zu verstehen, wie der User bei der Nutzung des Produktes am einfachsten und schnellsten zum Ziel gelangt (Usability). Um das herauszufinden, dürfen sich auch die Designer nicht mehr hinter ihrem riesigen „100 Zoll-Monitor“ verstecken, sondern müssen das Feedback der User aktiv einholen. UX-Labore, User-Umfragen, Crowdtesting oder solide und korrekt ausgeführte AB-Testings sind dabei die besten Methoden, die UX-Designer heute beherrschen sollten, um für den Kunden die richtige User Experience zu schaffen, so dass er sein Ziel erreichen kann.
Die nachhaltige Wirkung einer guten UX auf die Zufriedenheit der User ist meines Erachtens heute immer noch völlig unterschätzt. Eine tolle UX kann am Ende den Unterschied zwischen einem zufriedenen Kunden und einem begeisterten Kunden, der das Produkt auch wirklich weiterempfiehlt, ausmachen. Allerdings ist dieser Grat wirklich enorm schmal.
Wie baut man die UX-Designer in die agilen Product-Teams ein? Im Gegensatz zu den Developern empfiehlt sich bei den UX-Designern nicht die 100-prozentige Aufteilung in nur ein einziges Team. Im Gegenteil, es ist sogar ratsam, wenn ein UX-Designer seinen Designstil, der schließlich die gesamte Marke über eine Corporate Identity repräsentiert, auch übergreifend in die einzelnen Produkt-Teams bringen kann. Der Nachteil sowohl für das Team als auch den UX-Designer selbst ist jedoch, dass man nicht zu 100% auf den „geteilten“ UX-Designer setzen kann und er somit immer wieder zwischen den Stühlen hängt. Eine schwierige Entscheidung, die man meines Erachtens immer sehr bewusst und individuell entscheiden muss. Schaffen die UXler die Trennung oder sind sie dadurch eher schneller überlastet? Braucht ein Produkt 100% eines UXlers wirklich in jedem Sprint, dann ist es wahrscheinlich eher ratsam, dem Team einen eigenen UX-Experten zuzuteilen.
7. Field Experts
Je nachdem, was benötigt wird, können weitere Rollen als sogenannte Field Experts dem Scrum-Team hinzugefügt werden, gern auch crossfunktional als „Gesandte“ aus anderen Abteilungen wie Vertrieb, Kundenservice, Legal oder Marketing. Denn wichtig ist, dass die Scrum-Teams alles bekommen, was sie brauchen, um ihre Ziele möglichst unabhängig von anderen Teams oder Abteilungen erreichen zu können.
Der crossfunktionale Aspekt hat zudem den wunderschönen Nebeneffekt des nativen Knowledge-Sharings zwischen dem Team und der zugehörigen Abteilung des Field Experts. Zudem fühlen sich diese Mitarbeiter oftmals aufgewertet, da sie unmittelbar bei der Produktentwicklung dabei sind, statt nur ihr Tagesgeschäft abarbeiten zu müssen.
8. Chief Product Owner
Gibt es mehr als drei Scrum-Teams, empfiehlt es sich unbedingt, eine Art Programm-Manager oder Produktportfolio-Manager zu installieren, der für das strategische Produktmanagement verantwortlich ist. Häufig auch als Chief Product Owner (CPO) bezeichnet, ist dieser ständig in der Lage, die einzelnen Produkte und deren Visionen bzw. Roadmaps mit der Unternehmensstrategie abzugleichen und dann entsprechend mit den Product Ownern gemeinsam anzupassen.
Der CPO ist demnach dafür verantwortlich, dass die Unternehmensziele hinsichtlich der Produktentwicklung von den Product-Teams erreicht werden. Dies können klassische Umsatzziele, die mit dem Vertrieb der Produkte in den Märkten erzielt werden sollen, oder aber auch das Erreichen gewisser Kundenzufriedenheits-KPIs wie beispielsweise der Net Promoter Score sein.
Die große Herausforderung für den CPO ist, die sich rasch verändernden Marktbedingungen stets im Blick zu haben und auf die Produktentwicklungs-Strategie zu matchen. Darüber hinaus müssen die Product-Teams dennoch genügend Freiraum erhalten, bedingungslos Kundenwünsche erfüllen oder natürlich auch eigene Produktideen und -features umsetzen zu können.
Regelmäßige Abstimmungen mit der Geschäftsführung sind zudem unabdingbar, um deren 100-prozentiges Buy-in für die Produktstrategie zu erhalten. Ohne das Vertrauen der Geschäftsführung lassen sich keine autonomen Produkt-Teams aufbauen.
Um tiefer ins Thema empfehle ich das detaillierte Whitepaper, in dem ich alle Erfahrungen mit agilen Teams anhand echter Beispiele festgehalten habe.
Angrenzende Themen findest du in unseren Beitrag zur Product Roadmap und in unserer Content-Serie zu Growth Hacker Skills…
