05. Juli 2023
Get in touch
Die Welt der Softwareentwicklung hat sich in den letzten Jahren stark gewandelt. Lange Zeit wurden Projekte in der Softwareentwicklung nach einem festgelegten Plan durchgeführt, bei dem jede Phase penibel geplant und dokumentiert wurde (“Wasserfallprinzip”). Doch seit längerem hat sich ein anderer Ansatz etabliert: die agile Softwareentwicklung.
Was ist das Geheimnis hinter dem Erfolg der agilen Softwareentwicklung? Ganz einfach: Flexibilität und Zusammenarbeit. Anstatt starre Pläne und unflexible Prozesse zu verfolgen, setzen agile Teams auf eine iterative und inkrementelle Vorgehensweise. Die Entwicklung erfolgt in kurzen Zyklen, den sogenannten Sprints, bei denen das Team kontinuierlich an einem funktionierenden Produkt arbeitet. Scrum, Kanban und andere agile Methoden haben sich dabei als äußerst effektive Methoden erwiesen, um den Entwicklungsprozess zu optimieren. Das Team organisiert sich selbst, legt Prioritäten fest und arbeitet in kurzen, konzentrierten Sprints. Durch diese dynamische Herangehensweise können Probleme schneller erkannt und behoben werden.
Ein entscheidendes Merkmal der agilen Softwareentwicklung ist die enge Zusammenarbeit zwischen Entwickler:innen, Kunden und anderen Stakeholdern. Statt isoliert vor sich hin zu arbeiten, tauschen sich die Teammitglieder regelmäßig aus, teilen ihre Erfahrungen und stellen sicher, dass das Endprodukt den Erwartungen entspricht. Durch diese kontinuierliche Kommunikation und Rückmeldung können Änderungen schnell umgesetzt werden, was zu einem besseren Ergebnis und höheren Kundenzufriedenheit führt.
Hierbei ist die Kommunikation der am Softwareentwicklungsprozess beteiligten Personen von zentraler Bedeutung für eine erfolgreiche Zusammenarbeit. Für einen möglichst reibungslosen Ablauf sind die Verantwortlichkeiten und die Aufgaben klar im Team verteilt. In diesem Kontext sind die verschiedenen Rollen in der agilen Softwareentwicklung (hier exemplarisch: bei Scrum) hervorzuheben. Nur wenn diese Hand-in-Hand gehen, kann am Ende ein gutes und für den Kunden wertvolles Produkt entstehen.
Ihr wolltet schon immer mal wissen, wie der Arbeitsalltag in einem agilen Scrum Team aussieht? Wir nehmen euch exemplarisch mit in den Alltag der verschiedenen Scrum Rollen bei der AOE GmbH. Melanie, Scrum Masterin, macht den Anfang:
Melanie Tuppi ist als Scrum Masterin bei AOE tätig. Nach ihrem Studium der Arbeits- und Organisationspsychologie hat sie erste Erfahrung mit Scrum Teams und agilen Projekten während ihrer Zeit als Change Beraterin in einer Unternehmensberatung sowie im Change Management eines Logistikdienstleisters gesammelt. Seit 2019 begleitet sie sowohl erfahrene als auch neue Scrum Teams bei AOE.
… werfe ich gemeinsam mit dem:der Product Owner:in einen Blick auf das Backlog. Wir schauen auf die Stories, die er:sie für das nächste Refinement geplant hat: sind alle Informationen enthalten, ist die Beschreibung klar und detailliert genug, sind die Akzeptanzkriterien ausreichend beschrieben. Falls mir Lücken auffallen, spreche ich dies an.
Während des Backlog Refinements unterstütze ich den:die Product Owner:in bei der Durchführung des Meetings. Meist ist der Ablauf folgender: Der:Die Product Owner:in stellt die erste Story vor. Das Team stellt Fragen dazu. Sind alle Fragen geklärt, wird im Team mit Hilfe von Punktekarten (Scrum Poker bzw. Planning Poker) die Größe der Story geschätzt. Auf „drei“ heben alle gleichzeitig die von ihnen gewählte Punktekarte hoch, sodass keiner vorher weiß, was die anderen schätzen werden. Es geht nicht darum, genau zu definieren, ob die Umsetzung einer Story vier oder fünf Tage dauert, sondern ob der Aufwand und die Komplexität größer oder geringer ist als der einer Referenzstory. Die Schätzung ist einerseits sinnvoll, da der:die Product Owner:in so die kommenden Sprints besser planen kann, und ungefähr weiß, wie viele Stories in den kommenden Sprints fertiggestellt werden können. Zum anderen regt das gemeinsame Schätzen auch die Diskussionen im Team an. So kann es sein, dass ein:e Entwickler:in meint, die Story wäre lediglich drei Punkte groß, während ein:e andere:r Entwickler:in die gleiche Story mit dreizehn Punkten schätzt. Meist frage ich dann konkret nach, und rege den:die Niedrigstschätzende:n an, mit dem:der Höchstschätzenden des Teams über den Inhalt der Story zu diskutieren. Alle anderen hören erstmal zu. So kommen oft Missverständnisse oder unterschiedliche Vorstellung über mögliche Herangehensweisen ans Licht.
Manchmal greife ich in die Diskussion ein, z. B. wenn sich das Team in Details verliert, die Story aus dem Blick gerät oder die fachliche Ebene verlässt. Manchmal kommt es auch vor, dass die Story einfach zu umfangreich und daher schwer abzuschätzen ist; vielleicht enthält die Story zu viele unterschiedliche Aufgaben und ein Ergebnis der Diskussion ist, dass der:die Product Owner:in sie bis zum nächsten Refinement besser in mehrere, kleinere Stories schneidet, um sie dann erneut schätzen zu lassen. Nach der Diskussion wird dann erneut geschätzt, solange, bis das Team einen Konsens gefunden hat und sich auf eine Punktzahl einigen kann. Dabei wird die Beschreibung der Story immer konkreter. Ich arbeite gerne mit Scrum Poker, da diese Methode auch die etwas Stilleren anregt mitzudiskutieren.
Die Schätzungen der Stories aus dem Refinement sind Voraussetzung für den:die Product Owner:in, um den nächsten Sprint planen zu können. Hat ein Team schon mehrere Sprints zusammen durchlaufen, wissen wir ungefähr, wie viele Story Points das Team im Schnitt während eines Sprints umsetzen kann. Um eine genauere Aussage über die Velocity für den nächsten Sprint machen zu können, schaue ich, ob jemand Urlaub hat, Schulungen, Feiertage oder andere Veranstaltungen anstehen. Diese Faktoren berücksichtige ich bei der Berechnung der Velocity. So kann der:die Product Owner:in besser abschätzen, welche User Stories in den nächsten Sprint kommen sollen.
Damit er:sie ein gutes Set aus User Stories zusammenstellen kann, ist einiges an Vorbereitung nötig. Gemeinsam schauen wir, ob alle Stories im aktuellen Sprint fertig werden oder ob es sog. „Überkipper“ gibt – also Stories, die nicht abgeschlossen werden können und somit in den nächsten Sprint kippen. Ich achte zudem darauf, dass nur „fertige“ Stories in die Planung des kommenden Sprints miteinfließen. Stories, in denen nur sehr wenige Infos stehen, die noch nicht vom Team geschätzt wurden oder Abhängigkeiten noch unklar sind, etc. können im kommenden Sprint nicht berücksichtigt werden.
Im Sprint Planning stellt der:die Product Owner:in also vor, welche Stories die Entwickler:innen im kommenden Sprint umsetzen sollen. Der:die Product Owner:in entscheidet also, was gemacht wird, die Entwickler:innen entscheiden, wie die Stories umgesetzt werden. Während des Sprint Plannings achte ich darauf, dass wir die Velocity im Blick behalten. Sofern das Entwicklungs-Team mit der Planung einverstanden ist, committet es sich darauf, die Planung auch so umzusetzen. Wenn noch irgendwo Bedenken bestehen, versuchen wir diese aufzulösen. Meist geht das schnell, aber es kann auch vorkommen, dass wir an dieser Stelle noch mal Änderungen vornehmen und User Stories verschieben. Ich achte darauf, dass Bedenken von allen ernst genommen werden und nicht einfach unter den Tisch fallen.
Wenn die Sprintplanung steht, übernimmt das Entwicklungs-Team. Im zweiten Teil des Sprint Plannings (Task Breakdown) legt das Entwicklungs-Team Tasks für die einzelnen User Stories an. Ich bleibe oft in diesem Meeting, um die Diskussion zu verfolgen und mitzubekommen, ob irgendwo doch noch Fragen oder Probleme auftauchen. Da wir noch ganz am Anfang des Sprints sind, können wir offene Fragen noch klären, ohne dass es Auswirkungen auf das Ergebnis des Sprints hat. Entdecken wir Probleme erst später im Sprint, kann es sein, dass nicht alle User Stories fertig werden, daher ist hier noch mal Konzentration gefragt.
Das Daily gehört dem Entwicklungs-Team. Das Team stimmt sich ab, welche Aufgaben es heute erledigen möchte. Auch geht es darum, mögliche Hindernisse, Probleme oder Unklarheiten aufzudecken und zu beheben. Ich bin immer bei den Dailys dabei und gehe gemeinsam mit dem Team durch das Sprint Board. Es ist das erste Meeting für das gesamte Team an dem Tag und ich bekomme mit, ob es irgendwo Schwierigkeiten gibt und kann so meine Unterstützung anbieten und eventuelle Hindernisse zeitnah beseitigen.
In meinem Team dauert ein Sprint zwei Wochen. Das Team ist mit der Umsetzung der User Stories beschäftigt. Währenddessen bereitet der:die Product Owner:in schon den kommenden Sprint vor. Er:Sie holt fehlende Informationen und neue Anforderungen bei den Stakeholdern ein. Ich unterstütze ihn dabei, besonders wenn es um die Etablierung von Arbeitsprozessen geht. Generell bin ich auf drei Ebenen unterwegs:
In der Sprint Review stellt das Team den Stakeholdern die umgesetzten Stories vor und präsentiert die Ergebnisse. Das Feedback der Stakeholder spielt eine große Rolle. Ihre Anmerkungen, Änderungswünsche oder Vorschläge fließen in das Backlog ein und werden so zu neuen User Stories. In der Regel bin ich in diesem Meeting nur stille Beobachterin, manchmal greife ich moderierend ein, z. B. wenn ich das Gefühl habe, dass in einer Diskussion aneinander vorbeigeredet wird oder die Inhalte zu technisch werden etc.
In der Retro lasse ich den letzten Sprint gemeinsam mit dem Team Revue passieren. Zur Auflockerung starte ich meist mit einem kurzen Icebreaker, der etwas mit dem letzten Sprint zu tun hat, sodass wir schon einmal ins Gespräch kommen, was in den letzten beiden Wochen passiert ist. So bitte ich das Team z. B., den letzten Sprint zu malen, mache eine Stimmungsabfrage etc. Kommt ein neues Teammitglied hinzu, organisiere ich z. B. auch mal eine Art „Speed Dating”. Je nach Situation des Teams denke ich mir einen passenden Rahmen für die Retro aus. Ich moderiere das Meeting, lasse aber meist das Team entscheiden, welche Themen sie besprechen möchten. Wir diskutieren z. B., ob unsere aktuellen Prozesse noch zu den Anforderungen passen und versuchen ggf., Verbesserungsmöglichkeiten zu finden und in die Tat umzusetzen. Ist das Team größer, muss meist nach der Themensammlung ein Voting und eine Priorisierung stattfinden, da wir nicht alle Themen in einer Retro unterbekommen. Je nach Problemlage gebe ich auch schon mal ein Retro-Thema vor, wie z. B. unser Vorgehen beim Schätzen oder eine Überarbeitung der Definition of Done.
Ziel ist es, dem Team die Möglichkeit zu geben, über die geleistete Arbeit im letzten Sprint zu reflektieren und gemeinsam Verbesserungen zu erarbeiten. Daher ist es mir auch wichtig, konkrete To-dos, sog. Action Points, zu formulieren. Diese werden im kommenden Sprint umgesetzt und in der nächsten Retro erneut betrachtet und überprüft, ob die gewünschte Verbesserung eingetreten ist.
Dieser Artikel ist Teil einer Serie, in der wir die verschiedenen Rollen der agilen Softwareentwicklung beleuchten. Absolute Leseempfehlung!
