Das Scrum Team-Mitglied

Scrum ist ein agiler Prozess für Softwareentwicklung und Projektmanagement. Der größte Vorteil von Scrum im Unternehmen liegt darin, dass man jederzeit greifbare Ergebnisse zur Hand hat.

Man kann flexibler planen und seinen Service oder sein Produkt jederzeit an die Marktveränderungen anpassen. Zu den wichtigen Scrum Rollen gehören neben dem ScrumMaster und dem Product Owner natürlich das Scrum Team-Mitglied, welches für die eigentliche Umsetzung verantwortlich ist.

Das Scrum Entwicklungsteam

Das Scrum Team hat eine zentrale Funktion, denn es ist für die Umsetzung der Anforderungen zuständig. Es besteht idealerweise aus 7 +/- 2 Personen und ist interdisziplinär besetzt. Das ist notwendig, damit es das Sprintziel ohne Abhängigkeit von außen erreicht und beim Wegfall eines Scrum Teamies dessen Fehlen besser kompensiert. Denn das Erreichen des Sprintziel darf nicht gefährdet werden. Das bedeutet, dass ein Team sowohl aus Softwarearchitekten, Entwicklern, als auch Testern, Grafiker und andere Experten besteht. Eine häufige Fehlannahme ist, dass ein Scrum Entwicklungsteam nur Entwickler enthält. Es müssen alle Aspekte eines qualitativ hochwertigen Endproduktergebnis berücksichtigt werden. Das Scrum Entwicklungsteam tritt immer als Team auf. Hauptziel ist das gemeinsame Erreichen des Sprintziels. Auch wenn einzelne Personen im Team ihre Aufgaben zum Sprintziel abgeschlossen haben, gilt es die anderen Team-Mitglieder beim Abschluss ihrer Aufgaben zum Sprintende zu unterstützen.

Aufgaben des Scrum Teams

Zu den Aufgaben und Verantwortungen eines Entwicklungsteams in Scrum zählen die folgenden Bereiche:

• es ist Verantwortlich für die Einhaltung der vereinbarten Qualitätsstandards.
• es verpflichtet sich zum Commitment während des Sprint Plannings und tut alles, um dieses freiwillig ausgewählte Ziel zum Sprintende zu erreichen.
• es agiert als aktiver Berater des ProductOwner.
• es tritt immer als Team auf. Was bedeutet, dass die einzelnen Teammitglieder sowohl Spezialisten als auch Generalisten sind. Sie müssen ihren Entwicklungsteam-Kollegen helfen können, das gemeinsame Sprintziel zu erreichen. Sowohl positive als auch negative Ergebnisse fallen nie auf einzelne Teampersonen zurück, sondern immer auf das komplette Entwicklungsteam.
• es nimmt am Daily Standup Meeting teil und liefert einen kurzen Statusbericht für die Kollegen. (Was habe ich gestern erledigt? Woran arbeite ich heute? Was behindert mich / hat mich behindert?)
• es arbeitet aktiv mit den notwendigen Tools und aktualisiert täglich (!) die Restaufwände seiner Task im Sprint Backlog.
• es zeigt Disziplin und Bereitschaft zur Zusammenarbeit.
• es zeigt Commitment, was folgendes bedeutet: arbeitet zu 100% an der gemeinsamen Aufgabe. Setzt Team-Entscheidungen (auch bei Meinungsverschiedenheiten) um. Sabotiert nicht.
• es ist sein eigener Manager (Selbstorganisierend).
• es kennt das sogenannte Big Picture des Projekts. Falls nicht, lässt es sich darüber aufklären.
• es ist während der Estimation Meetings zum Schätzen des User Story Umfangs verpflichtet.
• es ist während der Estimation Meetings zum eventuell notwendigen Aufteilen einzelner Arbeitsschritte einer Task verpflichtet, wenn diese länger als einen Tag dauern.
• es stellt seine Erfahrungen im Sprint Retrospective Meeting bereit. (Was ist gut gelaufen? Was kann verbessert werden? Wer ist dafür verantwortlich?)
• es liefert nach jedem Sprint ein auslieferbare Version ab.
• es stellt im Sprint Review Meeting die neu gewonnene Funktionalität dem restlichen Team vor. Unfertige Funktionalität oder Präsentationen sind nicht erwünscht. Das Feedback der Beteiligten und eventuell neue Anforderungen werden für den nächsten Sprint berücksichtigt.
• größere Gruppen teilen sich in mehrere unabhängige, aber miteinander kommunizierende Scrum Teams auf (Scrum of Scrum).
• es tauscht sich mit dem ProductOwner aus, wenn es merkt, dass es sich für den Sprint zu viele Commits zugemutet, oder noch zusätzlich Zeit für weitere Commits verfügbar hat.

Was nicht zur Tätigkeit eines Scrum Team-Mitglied gehört

Es gibt ein paar Dinge, die ein Scrum Entwicklungsteam nicht tun sollte:

• es lässt sich nicht die Arbeitsweise vom ProductOwner vorgeben, sondern wählt seine Tasks selbst aus.
• es vernachlässigt nicht das Sprint Backlog.
• es schreibt keine Fachkonzepte.
• es verwechselt ungestörtes Arbeiten während des Sprints nicht mit: “Lass mich in Ruhe, ich arbeite nur an meinen Aufgaben. Ich habe keine Lust anderen Team-Kollegen zu helfen oder zu sagen, woran ich gerade arbeite.”

Probleme von Scrum Team-Mitgliedern

Es gibt ein paar Probleme, mit denen Scrum Entwicklungsteams bzw. einzelne Team-Mitglieder gerade in der Einführungsphase zu kämpfen haben.

Fehlende Akzeptanz der interdisziplinären Anforderungen: So manche Entwicklungsteam-Mitglieder verstehen nicht, warum sie nach Fertigstellung ihrer Sprint-Tasks auch noch den anderen Team-Mitgliedern helfen sollen ihre Tasks zu erfüllen. Sie haben oft ein Problem ihre Arbeit auch zu testen und zu dokumentieren. Es ist wichtig, dass sie erkennen, dass ein starkes Entwicklungsteam Problemen besser gewachsen ist als eine Spezialeinheit. Fällt jemand wegen Urlaub oder Krankheit aus, können andere seine Position füllen, bzw. Teile daraus übernehmen. Das Sprintziel wird durch das Wegfallen eines Einzelnen nicht gefährdet. Das Team erreicht gemeinsam sein Ziel.

Fehlende Kommunikation untereinander: Die täglichen ScrumMeetings (Daily Scrum Standup Meeting) sind nicht dazu da dem ScrumMaster Bericht zu erstatten. Sie dienen dazu mehr Transparenz innerhalb des gesamten Teams zu liefern. Sie sollen die Kommunikation untereinander fördern. Es soll erkannt werden, woran andere arbeiten. Ob es dadurch zur Beeinflussung der eigenen Aufgaben kommt. Ob andere feststecken und eventuell Hilfe brauchen. Ob die Vorgehensweise oder Reihenfolge einer Aufgabe vielleicht nicht ideal ist. Oft kann es hilfreich sein, während des Daily Scrum Meetings nicht nur den ScrumMaster, sondern auch die anderen Mitglieder anzuschauen / anzusprechen, um die Kommunikation zu fördern.

Falsche Einschätzung: Gerade beim ersten Sprint Planning Meeting passiert es, dass Scrum unerfahrene Teammitglieder die bereit gestellte Zeit nicht richtig nutzen. Sie wissen nicht, wie man bestimmte Aufgaben richtig schätzt. Wieviel Zeit eine Aufgabe wirklich in Anspruch nimmt. Welche einzelnen Tätigkeiten mit dem Erledigen einer Aufgabe verknüpft sind. Wer einem bei der Erfüllung einer Aufgabe helfen kann. Oft wird nur oberflächlich geschätzt. Dann passiert es, dass sie erst während der eigentlichen Arbeit an der jeweiligen Aufgabe erkennen, dass es doch einiges mehr zu berücksichtigen gibt als angenommen. Beim Sprint Review Meeting kann das Scrum Entwicklungsteam dann weniger präsentieren als geplant. Diese Lernphase ist oft nicht vermeidbar und sollte sich in der Regel beim nächsten Sprint bessern. Das Team lernt aus seinen Fehlern und wird das nächste Mal mehr Zeit für eine gute Schätzung einplanen. Je besser eine Schätzung verläuft, desto besser einschätzbar ist auch der finanzielle und zeitliche Aufwand für die Stakeholder. Was der Auftraggeber oft als kleines Feature präsentiert, kann durchaus einen großen zeitlichen Aufwand bedeuten. Der sollte von Anfang an nicht nur dem Entwicklungsteam, sondern auch dem Kunden klar sein.

Falsche Definition von “Done”: Abgeschlossene Arbeiten sind nicht wirklich fertig und damit Done. Die Scrum Team-Mitglieder haben noch eine falsche Vorstellung von Done. Was Abgeschlossen bedeutet wird vorher festgelegt und kann beispielsweise folgende Kriterien beinhalten:

Definition of Done: Eine Aufgabe ist dann fertig (Done) wenn sie den dafür festgelegten Kriterien entspricht.

• der Code ist eingecheckt
• alles kompiliert fehlerfrei
• es wurde auf die Testumgebung deployed
• es laufen automatisierte Unit Tests
• es laufen automatisierte Akzeptanztests
• es wurden Performance-Tests durchgeführt
• es wurde manuell getestet

Ungeschultes Team: Das Team ist nicht bereit zur Schulung. Auch wenn viele Tätigkeiten vielleicht als selbstverständlich angesehen werden. Es ist notwendig, dass gerade in der Einführungsphase von Scrum alle Team-Mitglieder die Zeit und Bereitschaft finden an den bereit gestellten Schulungen teil zu nehmen. Gerade zu Beginn tun sich einige schwer sich ihrer Rolle und Verantwortung bewusst zu werden. Sie zeigen noch nicht die nötige Disziplin.

Einführung eines Scrum Teams

Wie ein Scrum Team entsteht ist vor allem bei der Einführung von Scrum im Unternehmen eine häufig gestellte Frage. Gerade zu Beginn ist die fehlende Bereitschaft zu Veränderungen ein großes Problem im Umgang mit Scrum. Egal wie groß oder klein das Unternehmen ist.

In der Einführungsphase ist der ScrumMaster deswegen am wichtigsten. Er schafft die notwendigen Voraussetzungen für Scrum. Er hilft den Beteiligten die jeweilige Rolle und Verantwortung zu erkennen und zu erfüllen. Gerade weil vieles für Scrum Team-Mitglieder noch ungewohnt ist, ist es wichtig am Anfang die notwendige Disziplin und Bereitschaft zur Kooperation mitzubringen. Je disziplinierter das Team ist, desto eher erkennt das einzelne Scrum Team-Mitglied die Möglichkeit selbstverantwortlich zu arbeiten. Endlich hat es die Möglichkeit die Initiative zu ergreifen und andere zu unterstützen. Seine Fähigkeiten werden erkannt, gefördert und bringen anderen einen Nutzen. Die Arbeit im Scrum Team steigert wieder den Spaß an der Zusammenarbeit. Motiviert und ermöglicht ein Arbeiten ohne Druck von oben. Es entsteht nicht nur eine kreative Atmosphäre, sondern auch effiziente und qualitativ hochwertige Lösungen.

Damit die erfolgreiche Einführung von Scrum ins ScrumTeam funktioniert sollten folgende Voraussetzungen gegeben sein:

• Bevor Scrum los geht, sollten alle wichtigen Rollen (ScrumMaster, Product Owner) besetzt sein.
• Es sollte eine klare Zielsetzung und Aufgabenstellung existieren.
• Es muss das notwendige Verständnis aufgebaut werden (Schulungen, Einzelcoaching).
• Es sollte die notwendige Disziplin und Bereitschaft zur Kooperation bewusst gemacht werden.
• Es muss mit den nötigen Mitteln, Tools und Befugnissen versorgt werden und in der Lage sein mit diesen zu arbeiten.
• Es muss zu Beginn die Möglichkeit erhalten aus Fehlern zu lernen und dies im darauf folgenden Sprint besser zu machen, z.B. durch die Einführung kürzerer Sprint-Intervalle.

Download Rollen im Scrum Team

Die oben implementierte Grafik zeigt die wichtigsten Rollen im Scrum Team und deren Tätigkeitsbereich auf. Zum Download einer größeren Version einfach auf den folgenden Link klicken: Download Link

ScrumMaster in München

Unser Schwerpunkt liegt im Bereich agiles Projektmanagement und Qualiätsmonitoring. Unsere Experten aus München bieten ihre Leistung unter anderem als ScrumMaster und Technische Projektleiter an. Sehr gerne unterstützen wir mit unseren Leistungsspektrum Unternehmen aus München und dem Münchner Umland.

Auf unserer Themenseite gibt es weitere Informationen zur Agilen Produktentwicklung.