Koordinierte Scrum-Teamarbeit
Der Grundstein für Scrum, dem beliebtesten Agile-Management-Framework, wurde 1986 mit einem von Hirotaka Takeuchi und Ikujiro Nonaka verfassten Harvard Business Review-Artikel gelegt. In dem Artikel führten Takeuchi und Nonaka den Begriff „Scrum“ ein, als sie die Teamarbeitsstrategien hervorgehoben haben, die Rugby-Teams verwenden, um Punkte zu erzielen, und schlugen vor, dass Produktentwicklungsteams ähnliche Methoden verwenden könnten, um ihre Erfolgsquote zu verbessern.
Die in dem Artikel vorgestellten Nachforschungen ergaben, dass kleine, selbst organisierte Teams bei komplexen Produkten deutlich bessere Leistungen zeigten, wenn sie Vorgaben erhielten, aber selbst bestimmen durften, wie sie diese Vorgaben erreichen.
Ken Schwaber und Jeff Sutherland entwickelten in den 1990er-Jahren das Scrum-Framework und formalisierten die Rollen von Scrum-Teammitgliedern. Im Jahr 1995 veröffentlichten sie eine Abhandlung mit dem Titel „SCRUM Software Development Process“. Nachdem sie schrittweise weitere Verbesserungen an Scrum vornahmen und weitere Abhandlungen schrieben, veröffentlichten Schwaber und Sutherland 2010 die erste Ausgabe des Scrum Guide.
Der Scrum Guide bezeichnet Scrum und die Teamrollen als einen „Rahmen, in dem Personen komplexe adaptive Probleme angehen und gleichzeitig produktiv und kreativ Produkte von höchstmöglichem Wert liefern können. ... Das Scrum-Framework umfasst Scrum-Teams und die dazugehörigen Rollen, Ereignisse, Artefakte und Regeln.“
Beschreibungen der Teamrollen im Scrum Guide sagen aus, dass das „Scrum-Team aus einem Produktinhaber, dem Entwicklungsteam und einem Scrum-Master besteht. Scrum-Teams sind selbstorganisierend und funktionsübergreifend. Selbstorganisierende Teams entscheiden, wie sie ihre Arbeit am besten erledigen, anstatt von anderen außerhalb des Teams geleitet zu werden. Funktionsübergreifende Teams verfügen über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne von Personen, die nicht Teil des Teams sind, abhängig zu sein. Das Teammodell in Scrum wurde entwickelt, um Flexibilität, Kreativität und Produktivität zu optimieren. Scrum-Teams liefern Produkte iterativ und inkrementell und maximieren so die Möglichkeiten für Feedback.“
Schwaber und Sutherland haben im Juli 2016 eine aktualisierte Ausgabe des Scrum Guide veröffentlicht. Der nennenswerteste Inhalt, welcher der Ausgabe von 2016 hinzugefügt wurde, ist der Abschnitt „Scrum-Werte“, der Details darüber enthält, wie Mitglieder von Scrum-Teams miteinander und mit anderen Mitarbeitern des Unternehmens interagieren sollten.
Leitfaden zum Projektmanagement
Alles aus einer Hand für alle Fragen zum Projektmanagement
Sind Sie bereit, mehr aus Ihrem Projektmanagement herauszuholen? In unserem umfassenden Projektmanagement-Leitfaden finden Sie Tipps, Best Practices und kostenlose Ressourcen, mit denen Sie Ihre Arbeit effektiver verwalten können.
Empfehlungen zu Scrum-Teamgrößen
Um ein geschlossenes Scrum-Team aufzubauen und die Teamarbeit innerhalb der Gruppe zu maximieren, geben Experten oft Ratschläge zur Größe des Teams. Schwaber, der Scrum-Schulungen über seine Organisation Scrum.org anbietet, gibt in seinem Buch „The Enterprise and Scrum“ aus dem Jahr 2007 Empfehlungen zur Größe von Teams. Laut Schwaber sollten Scrum-Teams „in der Größe begrenzt sein, um die Geschwindigkeit, den Inhalt, die Genauigkeit und die Bandbreite der Kommunikation zu maximieren. Die Teamgröße sollte bis zu neun Personen betragen.“
Später in seinem Buch gibt Schwaber folgenden Rat: „Halten Sie die Teamgröße so nah wie möglich an sieben. Sieben Köpfe scheinen in der Lage zu sein, sich auf ein gemeinsames mentales Modell eines Systems und seiner Darstellung im Design und Code ohne künstliche Hilfsmittel wie Dokumentation zu einigen und es beizubehalten. Missverständnisse und Aufzeichnungszeit werden minimiert.“
Mindi Schnase, Projektmanagerin für Renown Health, besitzt eine CSM-Zertifizierung (Certified ScrumMaster) von der Scrum Alliance und eine PMP-Zertifizierung (Project Management Professional) vom PMI (Project Management Institute). Bei International Game Technology (IGT), dem früheren Arbeitgeber von Schnase, arbeitete sie als leitende Qualitätssicherungstechnikerin, bevor sie zur Rolle des Scrum-Masters wechselte. Schnase hat Erfahrung mit der Arbeit mit Scrum-Teams unterschiedlicher Größen.
Schnase meint, dass sieben bis neun Personen pro Team eine gute, überschaubare Größe sei, aber sie erklärt auch, dass die Teamgröße von den Projektbesonderheiten beeinflusst wird. „Es kommt auf den Umfang des Projekts an. Ich war Scrum-Master für mehrere Teams; eines hatte drei Mitglieder, andere sieben bis 10.“
Sutherland, der Scrum-Kurse über seine Organisation Scrum Inc. anbietet, hat viele Informationen über Teamdynamiken auf der Website seines Unternehmens aufgenommen, darunter die folgende Analyse zu Teamgrößen und Produktivität:
„Lawrence Putnam, eine legendäre Figur in der Softwareentwicklung, hat es zu seinem Lebenswerk gemacht, zu untersuchen, wie lange es dauert, Dinge zu tun und warum. Seine Arbeiten zeigten immer wieder, dass Projekte mit 20 oder mehr Personen mehr Aufwand erforderten als Projekte mit fünf oder weniger Personen. Nicht nur ein wenig, sondern viel mehr. ... Also untersuchte er 491 mittelständische Projekte in Hunderten verschiedenen Unternehmen. Dies waren alles Projekte, bei denen neue Produkte oder Features erstellt werden mussten, keine Umfunktionierung alter Versionen. Er unterteilte die Projekte nach Teamgröße und bemerkte sofort etwas. Sobald die Teams größer als acht wurden, brauchten sie deutlich länger, um Dinge zu erledigen. Gruppen aus drei bis sieben Personen erforderten etwa 25 Prozent des Aufwands von Gruppen von neun bis 20 Personen, um die gleiche Menge an Arbeit zu erledigen.“
Es scheint, dass sieben Teammitglieder die magische Zahl ist. Scheuen Sie sich jedoch nicht, die Anzahl der Mitglieder basierend auf bestimmten Projekten anzupassen.
Workflow- und Scrum-Ereignisse machen Scrum-Teams effektiver
Teams aller Formen und Größen durchlaufen einen bestimmten Workflow, wenn sie sich entscheiden, Scrum als Teil des Agile-Projektmanagements zu nutzen. Scrum-Ereignisse haben einen wertvollen Zweck: sie fördern regelmäßige Kommunikation, insbesondere zwischen Teammitgliedern, und minimieren die Notwendigkeit zusätzlicher Meetings, die nicht in Scrum definiert sind.
Ohne die Einbeziehung von Scrum-Ereignissen in ihre Zeitpläne wären Teams nicht so effektiv oder fokussiert. Die folgende Liste stellt den typischen Workflow dar, den Scrum-Teammitglieder für die Produktentwicklung verwenden.
Produktvision – Der Produktinhaber fasst die Produktvision in einer Erklärung zusammen, nachdem er Input aus verschiedenen Quellen erhalten hat, darunter Endbenutzer, Kunden, Teammitglieder und andere Stakeholder. Die Produktvisionserklärung enthält Geschäftsfalldetails über die Produktziele und wie das Produkt zu den Strategien des Unternehmens passt.
Produkt-Backlog und -Refinement – Produkt-Backlog-Elemente stellen alles dar, was unabhängig für ein Projekt geliefert werden kann. Die meisten dieser Elemente konzentrieren sich auf die Lieferung von Mehrwert für Kunden, genau wie Produkt-Features und User-Storys. (User-Storys stellen spezielle, detaillierte Szenarien dar, um zu erklären, was Benutzer mit einem neuen Feature erreichen.) Produkt-Backlogs können auch Marktanforderungen, Spezifikationen, Anwendungsfälle und andere Elemente enthalten.
Der Produktinhaber priorisiert Produkt-Backlog-Elemente entsprechend des Geschäftswerts, den jedes Element darstellt. In der Regel liegen 80 % des Werts eines Produkts in 20 % seiner Features. Die Zuweisung eines Geschäftswerts zur Priorisierung von Produkt-Backlog-Elementen stellt sicher, dass die Features mit dem höchsten Wert zuerst erstellt werden. Die Elemente, die im Produkt-Backlog ganz oben stehen, sind gut definiert und in einem kommenden Sprint enthalten; andere Elemente müssen während eines Meetings zum Produkt-Backlog-Refinement weiterentwickelt werden.
Einige Produktinhaber und Entwicklungsteams halten in der Mitte oder am Ende des aktuellen Sprints ein Meeting zum Produkt-Backlog-Refinement ab, um Produkt-Backlog-Elemente für künftige Sprints noch schneller weiterzuentwickeln. Andere Scrum-Teams behandeln das Refinement als kontinuierlichen Prozess.
Durchführung effektiver Sprints: Die folgenden beiden Schritte werden abgeschlossen, um Teams bei der Durchführung effektiver Sprints zu unterstützen. Ein Sprint (manchmal auch Iteration mit fester Länge genannt) ist der Zeitraum, in dem Teams eine einzelne Iteration von Arbeit abschließen, bevor sie sich wieder treffen und auf die nächste vorbereiten, und ist ein wichtiger Bestandteil des Agile-Projektmanagements.
- Sprintplanung – Der Produktinhaber, der Scrum-Master und das Entwicklungsteam treffen sich während einer Sprint-Planungssitzung, um Produkt-Backlog-Elemente für den kommenden Sprint auszuwählen und ein Ziel festzulegen. Die Mitglieder des Entwicklungsteams wählen Elemente aus, die ganz oben im Produkt-Backlog stehen, bis sie über genügend Arbeit verfügen, um den Zeitrahmen des Sprints zu füllen. Die ausgewählten Elemente werden in einen Sprint-Backlog verschoben.
- Sprint-Backlog und Scrum-Board – Alle Elemente im Sprint-Backlog müssen bis zum Ende des Sprints abgeschlossen sein. Um ein Gefühl der geteilten Verantwortung zu gewährleisten, werden die Elemente in einer der Spalten – in der Regel mit den Bezeichnungen Ausstehend, In Bearbeitung und Erledigt – auf einem physischen oder digitalen Scrum-Board (Task-Board) platziert. Das Scrum-Board muss für das gesamte Team sichtbar sein und die zugehörigen Elemente (die oft auf Haftnotizen als Aufgaben oder User-Storys geschrieben werden) müssen den Status des Sprints in Echtzeit widerspiegeln. Das Befolgen dieser Vorgaben ermöglicht es dem Team, Anpassungen vorzunehmen, wenn ein bestimmtes Element nicht im Zeitplan liegt.
Sprint – Sprints dauern eine bis vier Wochen. Jeder Sprint stellt einen kurzen Entwicklungszyklus dar und führt entweder zu einer Produktinkrementierung (offiziell als Potentially Shippable Product Increment (potenziell ablieferbare Produktinkrementierung) bezeichnet) oder zu einem fertigen Produkt. Teams sind nicht immer in der Lage, eine Produktinkrementierung abzuschließen, die ablieferbar ist, insbesondere zu Beginn. Dies ist jedoch etwas, was das Team anstreben sollte, wenn es sich im Laufe der Zeit verbessert.
Daily Scrum – Während jedes Sprints nehmen die Mitglieder des Entwicklungsteams an täglichen Standup-Meetings teil, die als Daily Scrum bekannt sind. Die maximale Meetingdauer beträgt 15 Minuten, da die Teilnehmer nur ihre Antworten auf drei grundlegende Fragen geben: 1) Was wurde seit dem letzten Meeting erreicht?, 2) Was wird vor dem nächsten Meeting getan? und 3) Welche Hindernisse stehen im Weg?
Der Zweck dieses Meetings besteht darin, dem Entwicklungsteam die Möglichkeit zu geben, Bemühungen zu koordinieren, Arbeit zu synchronisieren und Hindernisse (technische Probleme, Hindernisse in Abteilungen usw.) zu melden. Dies ist nicht die Art von Meeting, bei der Mitarbeiter ihrem Vorgesetzten einen Fortschrittsbericht vorlegen. Der Scrum-Master kann anwesend sein, um herauszufinden, welche Hindernisse er oder sie beseitigen muss, aber der Produktinhaber nimmt in der Regel nicht daran teil.
Scrum-of-Scrums-Meeting – Eine Aussage von Scrum-Ausbilder Mike Cohn auf der Website von Scrum Alliance beschreibt das Scrum-of-Scrums-Meeting als „eine wichtige Technik für die Skalierung von Scrum auf große Projektteams. Diese Meetings ermöglichen es Gruppen von Teams, ihre Arbeit zu besprechen und sich insbesondere auf Bereiche der Überschneidung und Integration zu konzentrieren. Stellen Sie sich ein perfekt ausgewogenes Projekt mit sieben Teams à sieben Teammitglieder vor. Jedes der sieben Teams würde (gleichzeitig oder nacheinander) sein eigenes Daily-Scrum-Meeting durchführen. Jedes Team würde dann eine Person auswählen, die auch an einem Scrum-of-Scrums-Meeting teilnimmt.“
An den Scrum-of-Scrum-Meetings, die Schnase einrichtete, waren Scrum-Master, Produktinhaber, technische Führungskräfte sowie einige QS-Manager, Programmsponsoren und Abteilungsleiter, die direkt mit den Projekten verbunden waren, an denen die Scrum-Teams arbeiteten, beteiligt. „Wir hielten alle zwei Wochen ein Scrum of Scrums ab, um Erfolge, Meilensteine, Fortschritte, Abhängigkeiten und Hindernisse zu besprechen.“, sagt Schnase.
Sprint-Überprüfung – Am Ende jedes Sprints führt das Team eine Sprint-Überprüfung (auch Iterationsüberprüfung oder Sprint-Demo genannt) durch, um die während des Sprints erstellten Produktfunktionen den Stakeholdern, den Personen, die direkt vom Ergebnis des Produkts betroffen sind, zu demonstrieren. Sprint-Überprüfungen oder Sprint-Demonstrationen sind auch eine wertvolle Gelegenheit, das Produkt den Mitarbeitern, welche die Software verwenden und sofortiges Feedback geben können, vorzuführen.
Sprint-Retrospektive – Nach der Sprint-Überprüfung nimmt das Scrum-Team an einem retrospektiven Meeting teil, um die Erfolge und Schwächen des Sprints zu besprechen und Pläne für Verbesserungen zu erstellen. Ein weiterer Zweck der Retrospektive besteht darin, den Prozess und die Praktiken, die das Scrum-Team verwendet, weiterzuentwickeln und sie für den nächsten Sprint effektiver zu machen.
Das Team findet auch Wege, um die Produktqualität zu erhöhen und, falls erforderlich, Elemente entsprechend der Definition of Done zu ändern. „The Basics of Scrum“ bei Scrum Inc. definiert die Definition of Done: „Ein Element im Backlog ist bereit, wenn es unabhängig und umsetzbar ist, einen Punktwert zugewiesen hat und über eine klare Definition der Kriterien verfügt, die bedeuten, dass es abgeschlossen ist. Dies wird wiederum als Definition of Done bezeichnet, die sicherstellt, dass jeder genau weiß, was von einem Element erwartet wird, wenn es geliefert wird.“
Scrum-Team-Entwicklungsmodell
Um ein effektives Scrum-Team aufzubauen, ist es laut Schnase wichtig, dass alle Beteiligten Leidenschaft und eine positive Einstellung zum Prozess haben, damit Teammitglieder gut zusammenarbeiten können. Viele Scrum-Ressourcen nennen das Teamentwicklungsmodell von Bruce Tuckman als eine effektive Methode, die beim Aufbau eines Scrum-Teams oder beim Hinzufügen neuer Mitarbeiter zum Team befolgt werden kann. In Tuckmans Artikel „Developmental sequence in small groups“, der 1965 im Psychological Bulletin veröffentlicht wurde, heißt es, dass neue Teams verschiedene Phasen durchlaufen müssen, bevor sie ein hohes Leistungsniveau erreichen und optimale Ergebnisse liefern. Tuckman bezeichnete diese Phasen als: Forming, Storming, Norming und Performing.
Der Name jeder Phase innerhalb des Teamentwicklungsmodells von Tuckman spiegelt die Teamdynamik während der jeweiligen Phase genau wider.
Forming – Tuckman bezeichnete diese Phase als eine, die sich auf Orientierung, Tests und Abhängigkeit konzentriert. Die Teammitglieder haben sich noch nicht kennengelernt und betrachten ihre Arbeit noch als individuelle Aufgaben anstatt als gemeinsame Anstrengung des gesamten Teams als Ganzes. Teambuilding-Sitzungen und Mittagessen mit der Gruppe helfen dem Team oft, eine Beziehung zueinander aufzubauen.
Storming – In der Storming-Phase halten die Teammitglieder in der Regel an ihrer Meinung fest und widersetzen sich verschiedenen Aspekten des Teameinflusses, weshalb es häufig zu gruppeninternen Konflikten kommt. In der Storming-Phase werden die Teammitglieder ermutigt, zu akzeptieren, dass es Meinungsverschiedenheiten innerhalb des Teams geben wird, da Vielfalt zu mehr Ideen und einer gesteigerten Produktivität führen kann. Um in die nächste Phase überzugehen, brauchen Teammitglieder Gewissheit über die Anforderungen ihrer Aufgaben. Wenn Vertrauen und Stabilität hergestellt werden, wird es einfacher, Konflikte zu lösen.
Norming – Bis das Team die Norming-Phase erreicht hat, haben die Mitglieder Bereiche festgelegt, in denen sie sich einig sind und einen Konsens erzielt. Es wurden klare Richtlinien für die einzelnen Rollen festgelegt, was zu einer neu gewonnenen Offenheit und Zusammenhalt unter den Mitgliedern führt. Das Ziel in dieser Phase ist es, gemeinsam Gruppenstandards zu entwickeln und relevante Ideen und Interpretationen zu diskutieren.
Performing – Innerhalb der Performing-Phase hat die Gruppe eine einheitliche Vision, kollektive Energie und ein Zielbewusstsein. Das Team hat gelernt, zusammen gute Leistungen zu erbringen und Probleme auf positive, diplomatische Weise zu lösen. Laut Tuckman sind die Rollen flexibel und funktional geworden, und die Teamstruktur begünstigt ein höheres Leistungsniveau.
Schnase empfiehlt, das Tuckman-Modell zu berücksichtigen, wenn Personen zu einem Scrum-Team hinzugefügt werden, da ein neues Mitglied die Teamdynamik verändert. Sie sagt, dass das Team jedes Mal, wenn es sich ändert, die Forming-, Storming-, Norming- und Performing-Phasen durchläuft. „Das Tempo nimmt ab, wenn Sie ein neues Teammitglied hinzufügen, also sollten Sie das berücksichtigen.“
Schnase wies auch auf einen weiteren Grund hin, warum Sprint-Retrospektiven effektiv sind. „Retrospektiven sind wichtig, denn das Team muss über Positives nachdenken und darüber, welche Elemente es möglicherweise verbessern könnte. Das hilft dem Team, die Performing-Phase zu erreichen.“
Frühes Scrum-Team-Buildung
Wie bei den meisten Entwicklungsmodellen braucht es Zeit, um Ergebnisse zu erzielen; das gleiche gilt für Scrum-Teams. Ein neues Team wird nicht sofort bessere Ergebnisse erzielen. Wie lange es dauert, bis ein Team die Performing-Phase erreicht, hängt von den Einzelpersonen und anderen Faktoren ab, einschließlich der Einheit des Teams, weshalb Team-Buildung unerlässlich ist.
„Frühes Team-Building ist von Vorteil, um Vertrauen zu schaffen und damit alle im Team die Stärken anderer Teammitglieder erkennen.“, sagt Schnase. „Es braucht Zeit, um als Team zu wachsen.“
Der Schlüssel zum Team-Building besteht darin, etwas zu finden, das für alle interessant ist, und keine unangenehmen Übungen zum Team-Buildung durchzuführen, an denen niemand gerne teilnimmt. Erstellen Sie eine Liste potenzieller Teamaktivitäten und fragen Sie Teammitglieder, welche ihnen gefallen, und bitten Sie um zusätzliche Vorschläge. Sie können einen Ausflug außerhalb der Arbeitszeit in Betracht ziehen, wie einen Ausflug in ein Museum oder eine lokale Sportveranstaltung, eine freiwillige Gruppenaktivität oder ein einfaches Mittagessen im Team, um ein starkes Teamumfeld zu fördern. Darüber hinaus hilft Ihnen die gemeinsame Teilnahme an einem Scrum-Schulungsworkshop – insbesondere einem mit Breakout-Sitzungen – dabei, Stärken von Einzelpersonen zu analysieren, von denen das gesamte Team profitiert.
Remote- vs. Scrum-Teams am selben Standort
Team-Building ist schwierig, wenn sich Teammitglieder in verschiedenen Städten befinden, geschweige denn in verschiedenen Ländern. Schnase hat mit Scrum-Teammitgliedern aus der ganzen Welt zusammengearbeitet. Obwohl einige Experten empfehlen, nur Teams mit Mitgliedern aus derselben Region zu bilden, da es oft einfacher ist, bei der Zusammenarbeit an einem Ort Zusammenhalt und Vertrauen zu entwickeln, meint Schnase, dass dies nicht immer machbar ist.
Bei IGT arbeitete Schnase beispielsweise mit Scrum-Teammitgliedern aus Australien und China sowie verschiedenen Städten in den USA zusammen. Sie sagt, dass die Zeitzonenunterschiede zwar eine Herausforderung sein können, insbesondere für Gruppen-Meetings, es aber dennoch möglich ist.
In diesen Situationen muss der Team-Building-Prozess online mit einem Videokonferenz-Tool stattfinden. Einige Unternehmen verstehen den Vorteil davon, früh eine gute Beziehung zwischen Teammitgliedern herzustellen und übernehmen die Kosten für Schulungen oder andere Team-Building-Prozesse an einem zentralen Ort. Wenn dies bei Ihrem Arbeitgeber der Fall ist, können Sie Scrum-Teammitglieder fragen, ob sie die Idee, sich zum Beispiel auf einer Scrum-Schulungskonferenz zu treffen, befürworten würden. Wenn alle dafür sind, schlagen Sie diese Option Ihrem Arbeitgeber vor.
Scrum-Teamrollen, Verantwortlichkeiten und bevorzugte Eigenschaften
Die ersten Scrum-Entwickler stellten sich Scrum-Teamrollen in einer selbstorganisierenden Struktur vor, ähnlich der, die Rugby-Teams verwenden, wenn sie einen Ball hin- und herpassen und als geschlossene Einheit das Feld überbrücken. Die Scrum-Teamstruktur ist mittlerweile ein bewährtes Modell für Produktentwicklungsteams, mit dem sie kontinuierliche, koordinierte und zuverlässige Ergebnisse erzielen können.
Ein ausgewogenes Scrum-Team umfasst:
- einen Produktinhaber , der die Produktvision fördert und das Produkt-Backlog priorisiert, um die Funktionalität und den Wert des Produkts für den Kunden zu maximieren;
- ein Scrum-Master , der im Endeffekt das Entwicklungsteam coacht, Ereignisse organisiert und Ablenkungen eliminiert, die den Fortschritt des Teams beeinträchtigen;
- und Mitglieder des Entwicklungsteams , die sich darauf konzentrieren, die Leistungen in Inkrementen abzuschließen (die abgeschlossene Produktfunktionalität am Ende jedes Sprints) und ein hochwertiges Endprodukt zu produzieren.
Sutherland und Schwaber betonen, dass es Gründe für bestimmte Scrum-Rollen gibt, und dass die Kombination dieser Rollen oft zu einer Abnahme der Produktivität führt. Arbeitgeber sollten auch erkennen, dass Teams viel produktiver und stabiler sind, wenn sich ihre Mitglieder nur auf ein Produkt pro Sprint konzentrieren und nicht an mehreren Produkten oder mit anderen Teams arbeiten müssen.
In den folgenden Abschnitten stellen wir die Verantwortlichkeiten und bevorzugte Eigenschaften jeder Rolle dar, um es den Einstellungsmanagern zu erleichtern, Bewerber entsprechend zu bewerten.
Die Rolle des Produktinhabers
Der Scrum Guide beschreibt die Rolle des Produktinhabers als verantwortlich für „die Maximierung des Werts des Produkts und der Arbeit des Entwicklungsteams“. Mit anderen Worten ist der Produktinhaber dafür verantwortlich, ein qualitativ hochwertiges Produkt zu liefern, das den Return on Investment (ROI) der Organisation maximiert. Die anderen primären Verantwortlichkeiten beziehen sich auf das Verständnis und das Erklären der Erwartungen des Kunden an ein Produkt sowie die Verwaltung des Produkt-Backlogs, einer priorisierten Liste der Produkt-Features.
Schnase sagt, dass der Produktinhaber eine Person sein sollte, die „dem Team hohe Anforderungen und Vorgaben für das Produkt stellt, aber dem Team ermöglicht, selbst zu bestimmen, wie diese Ziele erreicht werden sollen“.
Produktinhaber haben in der Regel Erfahrung im Produkt- oder Projektmanagement, Marketing oder User Experience (UX)-Design. Sie haben oft einen Hintergrund in der Analyse von Kundenerwartungen, Wettbewerbsprodukten, Marktanforderungen und zukünftigen Trends für die Art des in der Entwicklung befindlichen Produkts. Die akademischen Qualifikationen hängen von der Art des Produkts, dem Unternehmen und der Branche ab. Am wichtigsten ist, dass der Produktinhaber eine starke Vision und Verbindung zum Produkt hat.
Die folgende Liste stellt die Verantwortlichkeiten dar, die ein Produktinhaber haben sollte, um innerhalb dieser Rolle erfolgreich zu sein.
- Entwickelt die Produktvision und betont die Erwartungen des Kunden – Der Produktinhaber sollte jemand sein, der Informationen aus verschiedenen Quellen bewerten, eine Produktvision entwickeln und diese Vision fördern kann. Der Produktinhaber muss in der Lage sein, wichtige Produktbotschaften zu präsentieren, die gut beim Scrum-Team, den Stakeholdern und anderen Personen in der Organisation ankommen. Es ist besonders wichtig, dass der Produktinhaber den Standpunkt des Kunden vertritt, wenn er das Produkt erklärt und wie dessen neue oder verbesserte Features die Erwartungen übertreffen werden.
- Betrachtet die geschäftliche Seite der Produktentwicklung – Produktinhaber sollten geschäftsaffin sein, die Unternehmensanforderungen in der Produktentwicklung verstehen und sich der Bedeutung von Timing, positiven Marktbedingungen und Entscheidungen auf der Grundlage von Budgetbedenken und dem ROI bewusst sein. Produktinhaber müssen auch strategisch sein, wenn sie Pläne für Produktreleases entwickeln und das Produkt auf mehreren Ebenen bewerben, sei es auf dem Markt, bei der Unternehmensführung oder beim Scrum-Team.
- Motiviert das Team mit klaren, inspirierenden Vorgaben – Ein Produktinhaber muss die allgemeinen Anforderungen und Vorgaben jedes Projekts mit dem Entwicklungsteam besprechen, alle Fragen beantworten und das Team entscheiden lassen, wie diese Erwartungen erfüllt werden. Der Produktinhaber ist für die Priorisierung des Produkt-Backlogs verantwortlich, aber die Mitglieder des Entwicklungsteams entscheiden, wie viel Arbeit sie während eines Sprints erledigen können und wie viele Sprints benötigt werden. Daher muss der Produktinhaber eine Person sein, die Teammitglieder motiviert, ohne sie kontrollieren zu wollen.
- Maximiert den Produktwert und den Fortschritt des Entwicklungsteams – Dieser umfassende Verantwortungsbereich betont, wie wichtig es für den Produktinhaber ist, korrekt zu identifizieren, welche Produkt-Features derzeit am wichtigsten sind und für den nächsten Sprint ganz oben auf der Priorisierungsliste stehen sollten. Um diese Aufgabe im Laufe des Produktentwicklungsprozesses zu erfüllen, muss der Produktinhaber die Produkt-Backlog-Elemente ständig weiterentwickeln und neu priorisieren. Produkt-Backlog-Elemente, oder genauer gesagt Produkt-Features und User-Storys, sollten entsprechend dem Wert, den sie für das Produkt bringen, priorisiert werden. Einige Experten gehen noch einen Schritt weiter und sagen, dass der Wert durch den Kompromiss mit dem höchsten Geschäftswert für die kostengünstigsten Elemente bestimmt wird. Manchmal ist es jedoch notwendig, wichtige Kunden zu befriedigen und andere Faktoren der Geschäftsstrategie zu analysieren.
- Priorisiert und Verwaltet den Produkt-Backlog – Als einzige für den Produkt-Backlog verantwortliche Person, erkennt ein erfahrener Produktinhaber Abhängigkeiten, die berücksichtigt und richtig beurteilt werden müssen. Die effektivsten Produktinhaber verstehen die Notwendigkeit, selektiv zu sein, wenn sich jemand an sie wendet, um eine Änderung oder ein neues Feature anzufordern. Sie wissen, dass sie nicht alles genehmigen können und sorgen trotzdem dafür, dass die anderen Aspekte der Produktentwicklung in Einklang mit dem Geschäftswert und den realistischen Erwartungen stehen. Zu wissen, wann man „Nein“ sagt, ist ein wichtiger Teil des Berufs.
- Entwickelt regelmäßig den Produkt-Backlog weiter – Um sicherzustellen, dass das gesamte Team alle im Produkt-Backlog aufgeführten Features versteht, erklärt der Produktinhaber die Beschreibungen, erläutert deren Bedeutung und fragt das Team, ob es offene Fragen gibt. Diese Details tragen auch dazu bei, dass sich das Team für ein qualitativ hochwertiges Produkt engagiert, das den Erwartungen des Kunden entspricht. Einige Produktinhaber bitten Mitglieder des Entwicklungsteams, dem Produkt-Backlog technische Spezifikationen und andere ähnliche Details hinzuzufügen, aber die Zeit, die Entwickler für diese Aufgaben aufwenden, sollte auf ein Minimum reduziert werden.
- Stellt User-Storys vor, die sich auf die Produktfunktionalität konzentrieren – Das Entwicklungsteam ist für den Sprint-Backlog verantwortlich, der während des Sprint-Planungs-Meetings festgelegt wurde, aber der Produktinhaber ist für User-Storys verantwortlich, aus der Perspektive des Benutzers geschriebene Feature-Beschreibungen. Einige Produktinhaber erstellen die meisten User-Storys selbst, andere beziehen das gesamte Team in den Prozess ein.
- Bleibt mit dem Team in Kontakt und ist ständig verfügbar – Wenn Sie sich für das bestmögliche Produkt engagieren, müssen Sie aktiv mit Ihrem Team zusammenarbeiten. Produktinhaber betonen ihre Verfügbarkeit für das Team und nutzen ihre Kommunikationsfähigkeiten, um starke Beziehungen zu entwickeln.
- Erweitert Wissen durch Networking – Produktinhaber sollten wissen, warum es notwendig ist, sich durch regelmäßige Teilnahmen an Konferenzen und Workshops mit anderen in der Branche zu vernetzen. Es ist eine großartige Möglichkeit, Wissen zu erwerben, da Sie hören, was andere über Geschäftsmodellierungstechniken, gewonnene Erkenntnisse, Produkt-Erfolgsgeschichten und mehr zu sagen haben.
Die Rolle des Scrum-Masters
Der Scrum-Master ist in erster Linie dafür verantwortlich, dass das Scrum-Team die Scrum-Praktiken und -Regeln versteht und befolgt. Neben dieser Verantwortung stellt der Scrum-Master sicher, dass andere innerhalb der Organisation die Scrum-Theorie genug respektieren, um das Scrum-Team mit möglichst wenig Ablenkungen zu belasten und Feedback zu Interaktionen annehmen, die den Fortschritt des Teams beeinträchtigen.
Als Teamcoach und Moderator in komplexen Projekten bietet der Scrum-Master einen Mehrwert, indem er so viele Hindernisse wie möglich beseitigt, damit sich das Entwicklungsteam auf seine Ziele konzentrieren kann. Schnase sagt, dass Scrum-Master das Team unterstützen sollten, indem sie, wenn notwendig, Hindernisse beseitigen. „Wenn jemand nicht auf einen benötigten Netzwerkordner zugreifen kann oder die Testumgebung ausgefallen ist, können Scrum-Master helfen, diese Probleme weiterzuleiten und zu lösen.“, sagt Schnase. „Scrum-Master müssen in der Lage sein, mit jedem Stakeholder zu kommunizieren, und darüber hinaus auch durchsetzungsfähig und engagiert sein.“
Scrum-Master können eine Vielzahl von Hintergründen und akademische Disziplinen haben, darunter Design, Technik, IT, Marketing, Produkt- oder Projektmanagement, Qualitätssicherung und Testung. Sie haben Qualitäten wie Demut, Ausdauer und Loyalität sowie eine breite Wissensbasis und starke Führungsqualitäten, die es ihnen ermöglichen, ausgezeichnete Moderatoren und Verhandler zu sein, die wissen, wie man Konflikte löst. Scrum-Master müssen auch unabhängig vom Druck, der von anderen Quellen ausgeht, an Scrum festhalten.
Um kontinuierlich auf hohem Niveau zu arbeiten, müssen Scrum-Master mehrere Verantwortlichkeiten angehen und bestimmte persönliche Merkmale aufweisen, wie die folgende detaillierte Liste zeigt.
- Ist sowohl Diener als auch Führungspersönlichkeit – Ein Scrum-Master weiß, dass der Fokus darauf liegen sollte, dass das Team das hat, was es braucht, um dem Kunden Ergebnisse so zu liefern, wie es die Geschäftsvorgaben des Unternehmens erfordern. In dieser Hinsicht ist der Scrum-Master an mehreren Stellen gleichzeitig Diener: für die Teammitglieder, den Kunden und das Unternehmen. Laut dem Scrum Guide umfasst die Rolle des Scrum-Masters bestimmte Verantwortlichkeiten im Dienste des Produktinhabers, des Entwicklungsteams und der Organisation. Der Scrum-Master geht mit gutem Beispiel voran und ist die Art von Person, an der sich andere im Team orientieren. Ein inspirierender Scrum-Master ermutigt andere, an ihre Fähigkeiten zu glauben und an ihrem Potenzial zu arbeiten, auch wenn die Dinge nicht wie geplant verlaufen.
- Übernimmt Verantwortung, ohne sich wie eine Autorität zu fühlen – In seinem Blogbeitrag mit dem Titel „Leader of the Band“ erklärt Cohn die Erwartung der Verantwortung ohne Macht: „Ein Scrum-Master übernimmt zwar nicht die Verantwortung für den Erfolg des Projekts – diese bleibt beim Team – aber ein Scrum-Master übernimmt die Verantwortung für die Übernahme von Scrum und dessen Praxis durch das Team. Ein Scrum-Master übernimmt diese Verantwortung, ohne eine autoritäre Position einzunehmen, die nützlich sein könnte, um dies zu erreichen.“
In einem anderen Beitrag, „Advice for Interviewing Scrum Masters“, ging Cohn genauer auf die Erwartungen ein, indem er sagte: „Ein Orchesterdirigent hat einmal erklärt, dass er keine wirkliche Kontrolle darüber hat, wie die einzelnen Musiker spielen. Dennoch fühlt er eine enorme Verantwortung, ihnen zu helfen, die besten Musiker zu sein, die sie sein können.“
- Beseitigt und vermeidet, wenn möglich, Hindernisse – Der Scrum-Master schützt die Arbeit des Entwicklungsteams, indem er Hindernisse nach Möglichkeit beseitigt. Oft erzählen Teammitglieder dem Scrum-Master während des Daily Scrum von einem Hindernis und erklären, warum das Hindernis ihre Fähigkeit beeinträchtigt, die Arbeit während eines Sprints abzuschließen.
In aktuellen Stellenanzeigen haben Personalmanager eine Präferenz für Scrum-Master gezeigt, die über ein umfassendes technisches Wissen verfügen und/oder die Details einer bestimmten Branche vollständig verstehen. Scrum-Master mit dieser Art von Wissen haben den Vorteil, dass sie ihren Teams helfen können, Hindernisse in Bezug auf technische Probleme schneller zu beseitigen.
Nicht offensichtliche Hindernisse sind Bedrohungen für die Gesamteffektivität des Teams, weshalb die Einstellung eines aufmerksamen und engagierten Scrum-Masters, der solche Bedrohungen beseitigen kann, sehr wünschenswert ist. Je erfahrener ein Scrum-Master, desto einfacher ist es für ihn/sie, ein potenzielles Problem zu erkennen und zu lösen, bevor es zu einem tatsächlichen Problem wird.
- Zeigt dem Team, wie es sich verbessern kann – Scrum-Master coachen ihre Teams, indem sie auf der Grundlage ihres Wissens und ihrer Erfahrung Beispiele geben und sie anleiten, ihr Potenzial zu nutzen. Auf diese Weise helfen sie den Teammitgliedern, sich selbst besser zu verstehen und Praktiken der Selbstorganisation und Erfüllung mehrerer Funktionen zu implementieren. Wenn Scrum-Master Selbstorganisation fördern, übernehmen Teams mehr Verantwortung für ihre Arbeit, treffen leichter Entscheidungen und Arbeitsschätzungen, und haben ein stärkeres Gefühl, zusammen ein gemeinsames Ziel zu erreichen.
Cohn vergleicht Coaching von Scrum-Mastern mit der Unterstützung, die Personal Trainer bieten. „Betrachten Sie die Hilfe eines Scrum-Masters ähnlich wie bei einem Personal Trainer, der Ihnen hilft, ein Übungsschema einzuhalten und alle Übungen korrekt durchzuführen. Ein guter Trainer motiviert und stellt gleichzeitig sicher, dass Sie nicht schummeln, indem Sie eine harte Übung überspringen. Die Autorität des Trainers ist jedoch begrenzt. Der Trainer kann Sie nicht dazu zwingen, eine Übung zu machen, die Sie nicht machen möchten. Stattdessen erinnert sie der Trainer an Ihre Ziele und daran, wie Sie sie erreichen wollen.“
- Erkennt und löst Konflikte so schnell wie möglich – Jeder in einem Scrum-Team hat die Freiheit, kontraproduktive Einstellungen und Verhaltensweisen anzusprechen, aber manchmal entstehen Konflikte durch Missverständnisse oder die Notwendigkeit, Kompromisse einzugehen. In diesen Fällen sollten Scrum-Master Konflikte im Team früh genug erkennen, um sie zu lösen, bevor zu viel Schadensbegrenzung notwendig ist. Scrum-Master wissen auch, dass einige Konflikte unvermeidlich und nicht immer eine schlechte Sache sind. Die Fähigkeit, Konflikte zu überwinden, wird das Team letztendlich stärker machen.
In seinem Blogbeitrag mit dem Titel „Advice for Interviewing Scrum Masters“ erläutert Cohn, wie die kollaborative Denkweise von Scrum-Mastern zur Lösung von Konflikten beiträgt. „Ein guter Scrum-Master sorgt dafür, dass innerhalb des Teams eine Kultur der Zusammenarbeit vorherrscht. Der Scrum-Master muss sicherstellen, dass sich die Teammitglieder in der Lage fühlen, Probleme offen zu diskutieren. Wenn es zu Streitigkeiten kommt, ermutigen kollaborative Scrum-Master die Teams, Lösungen zu finden, von denen alle Beteiligten profitieren, anstatt Gewinner und Verlierer zu haben.“
- Organisieren Scrum-Ereignisse – Die besten Scrum-Master scheinen instinktiv zu wissen, wie sie Ereignisse organisieren und Menschen anleiten können. Die meisten Scrum-Master lernen dies in Führungskursen und/oder durch jahrelange Erfahrung. Die Teilnehmer ihrer Scrum-Ereignisse schätzen ihre Vorbereitung und die Fähigkeit, klare Erwartungen zu setzen.
- Hört zu und beobachtet – Auch hier ist Ausgewogenheit entscheidend. Effektive Scrum-Master verfügen über außergewöhnliche Kommunikationsfähigkeiten, wissen aber auch, wann sie zuhören und beobachten müssen. Mit Zuhören meinen wir konzentriertes, aktives Zuhören. Beim Beobachten reden wir vom Beobachten, was nicht explizit kommuniziert wird, aber durch genaue Beobachtung der Körpersprache, Mimik und anderer Aspekte dennoch sichtbar wird.
- Ist Scrum-Ausbilder und -Förderer – Scrum-Master stellen nicht nur sicher, dass Scrum-Teammitglieder Scrum verstehen und befolgen, sondern auch, dass andere Mitarbeiter, die mit ihren Teams zu tun haben, Scrum verstehen. Wenn Organisationen Scrum zum ersten Mal anwenden, sind es die Scrum-Master, die diese Bemühungen anführen, indem sie die Scrum-Implementierung planen, Änderungen vorschlagen, um die Produktivität des Scrum-Teams zu steigern, und durch einen Anpassungszeitraum Unterstützung bieten. Bei großen Unternehmen umfasst diese Anstrengung manchmal, mit anderen Scrum-Mastern zusammenzuarbeiten, um die Effektivität von Scrum zu erhöhen.
Während sie anderen etwas über Scrum beibringen, kann es notwendig sein, dass Scrum-Master einigen Personen die Skepsis nehmen, indem sie den Wert von Scrum und wie dessen Rahmenbedingungen und Leitprinzipien bereits zu bedeutenden Ergebnissen in anderen Unternehmen geführt haben, klarstellen.
- Nutzt Vermittlungsfähigkeiten, um Personen im Unternehmen zu überzeugen – Erfahrene Scrum-Master wissen, dass sie in der Lage sind, das Verhalten von Personen zu ändern, indem sie ihnen einen Grund geben, anders zu handeln oder sie überzeugen, indem sie die Kultur und die Bedingungen ändern, innerhalb derer sie arbeiten müssen, aber wirklich ändern können sie Personen nicht. Diese Scrum-Master wissen auch, wie sie Überzeugungsarbeit und Motivation nutzen, um andere auf verschiedenen Ebenen in einer Organisation zu beeinflussen, denn sie verstehen, wer die großen Entscheidungen trifft, wie sie bestehende Allianzen nutzen können und wie sie Personen umgehen, die am ehesten Hindernisse darstellen.
Rollen im Entwicklungsteam
Die Personen, die das Produkt erstellen, werden Entwicklungsteam genannt. Zu dieser Gruppe gehören in der Regel Fachleute, die Erfahrung und Schulung als Softwareentwickler, Benutzeroberflächendesigner, Datenbankspezialist, Betriebstechniker, Qualitätssicherungstechniker, Tester, Systemanalyst und technischer Redakteur (Dokumentationsspezialist) besitzen. Im Scrum Guide heißt es: „Scrum erkennt keine anderen Titel für Mitglieder des Entwicklungsteams als den eines Entwicklers an, unabhängig von der Arbeit, die von der Person ausgeführt wird; es gibt keine Ausnahmen zu dieser Regel.“
Die Hauptaufgabe des Entwicklungsteams besteht darin, die für eine erfolgreiche Reihe von Sprints und Produktschritten erforderlichen Arbeiten auszuführen, gefolgt von der Lieferung eines qualitativ hochwertigen Endprodukts. Wenn Sie planen, jemanden für Ihr Scrum-Entwicklungsteam einzustellen, schlägt Schnase vor, eine Fachperson zu suchen, die bereit ist, Testunterstützung zu leisten und andere Aufgaben wie Automatisierung zu erfüllen. „Jedes Teammitglied sollte bereit sein, sich gegenseitig zu schulen und zu helfen.“
„The Basics of Scrum“, veröffentlicht von Scrum Inc., befasst sich auch mit der Bedeutung eines funktionsübergreifenden Entwicklungsteams. „Darüber hinaus sollte es mindestens zwei Personen im Team geben, die ein beliebiges Element im Produkt-Backlog abschließen können. Dies hilft, Abhängigkeiten von den Fähigkeiten eines bestimmten Teammitglieds zu beseitigen, wenn dieses krank wird, Urlaub nimmt oder einen anderen Job annimmt.“
Die folgende Liste enthält die vom Entwicklungsteam geteilten Verantwortlichkeiten sowie die wünschenswerten Eigenschaften guter Teammitglieder.
- Liefert das versprochene Funktions- und Qualitätsniveau – Die Mitarbeiter, die sich am besten für Scrum-Teamarbeit eignen, sind Personen, die zusammenarbeiten und kommunizieren, sich kontinuierlich verbessern, je länger sie im Team bleiben und in der Lage sind, Features wie geplant zu implementieren und qualitativ hochwertige Arbeit zu leisten. Durch ihre Handlungen zeigen sie ein starkes Engagement für Ziele und die Fähigkeit, in einer Scrum-Umgebung erfolgreich zu sein.
- Ist ernsthaft daran interessiert, ein Endprodukt herauszubringen, das Kunden zufriedenstellt – Die wertvollsten Teammitglieder sind diejenigen, die ihre Kunden gut kennen und von sich selbst enttäuscht wären, wenn sie sich nicht genug anstrengen, um die Erwartungen des Kunden zu übertreffen. Diese Mitarbeiter sind stolz auf ihre Arbeit und sind begeistert, wenn sie positives Feedback von Kunden erhalten.
- Hilft dem Team, sich auf die Fertigstellung zu konzentrieren – Entwicklungsteams sind für alle Aufgaben im Sprint-Backlog verantwortlich. Leistungsstarke Teams notieren diese Aufgaben in ein Scrum-Board und aktualisieren diese häufig, um sicherzustellen, dass jeder über eine Echtzeit-Referenz zum Status einer Aufgabe verfügt. Die Spalten des Scrum-Boards sollten klar angeben, welche Aufgaben abgeschlossen wurden und wie viel Fortschritt bei den verbleibenden Elementen erzielt wurde. Teammitglieder, die diese Richtlinien befolgen, vermeiden Verwirrungen und sorgen dafür, dass das Team weiter voranschreitet.
- Nutzt Daily Scrum und andere Meetings als Kommunikationsmittel – Gewissenhafte Teammitglieder wissen, dass ihre Zeit kostbar und begrenzt ist, und respektieren die Zeit ihrer Mitarbeiter genauso. Sie nutzen Daily Scrum und andere Meetings wie vorgesehen und bereiten sich auf die Kommunikation innerhalb der zulässigen Zeit vor. Auch in anderen Kommunikationen mit Mitarbeitern halten sie sich kurz und kommen auf den Punkt.
- Bleibt realistisch – Wer seine Zeit effektiv verwaltet, erkennt, dass ein bestimmter Teil des Tages unproduktiv ist. Jeder braucht Zeit, um sich zu entspannen und neue Kräfte zu tanken, vor allem, wenn wir die Kreativität fördern wollen. Zu diesem Zweck und um unerwartete Situationen und Notfälle angemessen zu planen, ist ein gewisses Maß an Leerlaufzeit in unseren Zeitplänen erforderlich. Erfahrene Entwickler wissen das und planen ihre Fristen für Verpflichtungen entsprechend ein.
- Schlägt Ideen für künftige Sprints vor – Jeder schätzt ein Teammitglied, das Initiative ergreift und Vorschläge für nicht behandelte Elemente unterbreitet, die es im Produkt-Backlog bemerkt. Obwohl der Produkt-Backlog Teil der Verantwortlichkeiten des Produktinhabers ist, kann das gesamte Team Ideen zur Verfeinerung seiner Inhalte vorschlagen. Die Verbesserung von Produkt-Backlog-Elementen verbessert unweigerlich die Produktschritte und das Endprodukt.
- Nimmt Gelegenheiten für Weiterbildung wahr – Wachstumsorientierte Teammitglieder freuen sich über zusätzliche Lernmöglichkeiten, denn sie verstehen die Wichtigkeit von Innovationen und passen sich ständig an ein sich schnell entwickelndes technisches Umfeld an. Sie sind offen für Änderungen und bereit, Neues zu lernen und sich kollaborativ einzubringen. Sie sind auch bereit, ihre Erfahrungen mit anderen Mitarbeitern zu teilen und neuen Teammitgliedern als Mentor zur Seite zu stehen.
- Kombiniert technische Erfahrung mit Geschäftskenntnissen – Mitglieder von Entwicklungsteams, die Geschäftskonzepte fast genauso gut verstehen wie Technologie, sind in vielerlei Hinsicht wertvoll. Sie können nicht nur Geschäftsleuten die Technologie erklären, sondern sie auch über die Folgen der Veröffentlichung eines Produkts informieren, das sich zu sehr auf das Marketing anstatt auf die zugrunde liegenden technischen Faktoren konzentriert.
Wenn beispielsweise das Hinzufügen zu vieler Features die Gesamtleistung des Produkts belastet, informieren diese Entwickler den Produktinhaber so schnell wie möglich über ihre Bedenken. Diese Entwickler sind eine wertvolle Bereicherung, da sie ihre Bedenken so äußern können, dass der Produktinhaber sie versteht, signalisieren können, dass sie an möglichen Lösungen arbeiten wollen, und zeigen können, dass sie verstehen, wie technische Aspekte wie die Leistung den Marktwert eines Produkts beeinflussen können.
- Setzt eine Nicht-Einmischungskultur für das Team durch – Andere Personen in einem Unternehmen können versucht sein, ihre eigenen Anforderungen an ein Entwicklungsteam zu stellen, was wahrscheinlich der Grund ist, warum der Scrum Guide es für notwendig hielt, diese Tendenz zu thematisieren: „Niemand darf dem Entwicklungsteam sagen, dass es sich an anderen Anforderungen orientieren soll, und das Entwicklungsteam darf nicht das machen, was jemand anderes sagt.“
Allgemeine Einstellungstipps für alle Scrum-Teamrollen
Nachdem wir nun die Besonderheiten behandelt haben, lassen Sie uns eine allgemeine Liste der Qualitäten thematisieren, nach denen Scrum-Experten bei Teammitgliedern suchen würden.
- Gibt Fehler zu und lernt daraus – Jeder macht Fehler, aber es ist wichtig, dass Mitarbeiter aus diesen Fehlern lernen und sich dadurch verbessern. Bevor Sie jemanden einstellen oder einladen, sich Ihrem Scrum-Team anzuschließen, sollten Sie identifizieren, welche Bewerber nicht zugeben würden, dass sie Fehler gemacht haben – dies könnte ein Zeichen für noch beunruhigendere Eigenschaften sein, wie zum Beispiel, nicht verantwortungsbewusst zu sein. Teams arbeiten an zahlreichen Details zusammen, daher ist es wichtig, dass Sie einen Bewerber aufnehmen, der sich reibungslos in eine Teamrolle einfügen kann, ohne die Tendenz zu zeigen, Schuld bei anderen zu suchen.
- Schätzt Feedback – Achtsame Teammitglieder wissen, wie sie auf klare, unkomplizierte und respektvolle Weise Feedback geben und erhalten. Sie wissen auch, dass Feedback hilfreich und ermutigend sein sollte. Wenn möglich, geben diese Teammitglieder ihr Feedback privat. Vertrauen spielt auch eine wichtige Rolle. Teamkollegen, die sich gegenseitig vertrauen, arbeiten besser zusammen. Ordentlich zu beurteilen, was Bewerber von Feedback und Vertrauen halten, sagt viel über ihren Charakter aus.
- Bringt Humor, Energie und gute Laune in die Arbeit – Um Teil eines Teams zu werden und sich mit anderen verbunden zu fühlen, muss jeder einen Beitrag leisten. Mitarbeiter, die ihre Persönlichkeit durch Humor, Energie und gute Laune zeigen, bauen oft schneller Beziehungen zu anderen auf. Es ist nicht immer einfach, diese Qualitäten bei Vorstellungsgesprächen zu beurteilen, aber allgemeine Fragen zu ihren Interessen und Hobbys sowie Reisen und Wochenendaktivitäten zu stellen, kann einige Hinweise darauf geben, wie gut der Bewerber in ein bestimmtes Scrum-Team passen würde.
Scrum-Tools für den Beruf
Kollektive Verantwortung ist ein wichtiger Bestandteil von Scrum. Um sich als Team zu verbessern, ist es hilfreich, Leistung und Fortschritt mit einer Vielzahl von Tools nachzuverfolgen.
- Scrum-Board – Es gibt verschiedene Arten von Task-Boards, aber das häufigste Modell, das in Scrum verwendet wird, ist das zuvor in diesem Artikel erwähnte Scrum-Board. Wie wir beschrieben haben, enthält das Scrum-Board Spalten, die in der Regel die Bezeichnungen Ausstehend, Wird bearbeitet und Erledigt tragen. Jede der Aufgaben aus dem Sprint-Backlog wird auf Haftnotizen notiert und in einer dieser Spalten platziert, damit das Scrum-Team feststellen kann, wie viel Arbeit noch vor dem Ende des Sprints erledigt werden muss.
Scrum-Boards können auch verwendet werden, um die Teamleistung mit einer Metrik, die als Schnelligkeit bekannt ist, nachzuverfolgen. Um die Schnelligkeit zu messen, weist das Team jeder Aufgabe aus dem Sprint-Backlog einen relativen Punktwert zu. Wenn der Sprint abgeschlossen ist, kann das Team in der Spalte „Erledigt“ Punkte eintragen und die Gesamtschnelligkeit des Teams für diesen bestimmten Sprint berechnen. Diese Methode hilft Teams, eine Basis für die Teamleistung zu schaffen und vorherzusagen, wie viel Arbeit sie in zukünftigen Sprints bewältigen können.
Teams können Scrum-Boards und Schnelligkeit auch verwenden, um das Abschlussdatum eines Projekts zu prognostizieren oder zu analysieren, ob eine Anpassung des Workflows dem Team tatsächlich geholfen hat, seine Leistungsrate zu verbessern. Weitere Informationen finden Sie in der Scrum-Board-Kursarbeit auf Scrum Inc.
- Burndown-Diagramm – Im Laufe eines Sprints können Teams ein tägliches Sprint-Burndown-Diagramm verwenden, um die verbleibende Arbeit im Sprint-Backlog anzuzeigen. Die verbleibende Arbeit wird auf der vertikalen Achse nachverfolgt und die Zeit (entsprechend den Tagen innerhalb eines Sprints) auf der horizontalen Achse. Diese Art der visuellen Darstellung kann Teams helfen, Fortschritte zu messen und sicherzustellen, dass sie bis zum erwarteten Abschlusstermin fertig sind. Burndown-Diagramme können auch nützlich sein, um Trends zu verfolgen und innerhalb der Releasefrist eines Produkts zu arbeiten. Weitere Informationen zur Erstellung eines Burndown-Diagramms finden Sie in der Sprint-Burndown-Diagramm-Kursarbeit auf Scrum Inc.
- RACI-Matrix – Wie jedes Team weiß, gibt es Zeiten, in denen individuelle Verantwortung notwendig ist. In diesen Fällen hilft es, ein Tool wie die RACI-Matrix (responsible (zuständig), accountable (verantwortlich), consulted (beratend), informed (informiert)) zur Verfügung zu haben, um Aufgaben und Leistungen in einem übersichtlichen Rollen- und Verantwortlichkeitsdiagramm darzustellen. Weitere Informationen zu diesem Tool finden Sie unter „Ein umfassender Projektmanagement-Leitfaden zum Thema RACI“.
Verwenden Sie Smartsheet, um Scrum-Projekte problemlos zu verwalten
Von einfacher Aufgabenverwaltung und Projektplanung bis zu komplexem Ressourcen- und Portfoliomanagement hilft Ihnen Smartsheet, die Zusammenarbeit zu verbessern und das Arbeitstempo zu erhöhen – und befähigt Sie, mehr zu schaffen. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.