A2 – alles Agile: das kleine Agile-Einmaleins

Kanban-Meetings … und die Rollen in Scrum
Kommentare

Mit Scrum und seinen Meetings haben wir uns letzte Woche bereits ausführlich beschäftigt. Jetzt ist es an der Zeit, Vergleiche zu ziehen und einige offene Fragen auszuräumen.

In ersten Teil von A2 – alles Agile haben wir uns mit den Meetings im Scrum-Umfeld beschäftig. Dabei haben wir neben dem Entwicklungsteam zwei weitere Rollen kennengelernt: Den Product Owner und den Scrum Master. Mit den Aufgaben der einzelnen Rollen werden wir uns in diesem Teil intensiver beschäftigen. Danach sollten wir uns jedoch ansehen, wie die Scrum-Meetings in Kanban aussehen – es gibt nämlich vor allem in der Ausrichtung der Meetings einige erhebliche Unterschiede.

Die Rollen im Scrum

Scrum sieht im Gegensatz zu Kanban neben der Rolle des Entwicklungsteams zwei Personenrollen vor: den Scrum Master und den Scrum Product Owner. Es ergibt dabei Sinn, diese beide Rollen getrennt zu besetzen, da der Scrum Master näher am Entwicklungsteam ist und deren Arbeit unterstützen soll. Ebenso kann es nötig sein, dass er Störungen durch den Scrum Product Owner abfängt. Eine Personalunion ist daher kontraproduktiv und nicht zu empfehlen.

Product Owner

Die Rolle des Product Owners ist klar abzugrenzen vom klassischen Projektleiter, was dennoch viele fälschlicherweise in ihm sehen. Der Product Owner gestaltet das Produkt dahingehend, den wirtschaftlichen Nutzen für das Unternehmen auf ein möglichst hohes Maß zu maximieren; er ist somit allein dafür verantwortlich, die Eigenschaften entsprechend dieser Prämisse auszuwählen.

Der Product Owner hält hierfür regelmäßig Rücksprache mit sämtlichen Stakeholdern, um deren Anforderungen und Wünsche an das Produkt zu verstehen. Als weitere wichtige Inputquelle dient ihm das angesprochene Sprint Review, in dem die Stakeholder ihr Feedback zum Produkt geben.

A2 – alles Agile ist eine Serie im zweimonatlich erscheinenden PHP Magazin.

Zur Organisation der Produkteigenschaften verwendet der Product Owner das Product Backlog. Die Eigenschaften werden zusammen mit den Stakeholdern und dem Entwicklungsteam in User Stories festgehalten und im Product Backlog hinterlegt. Es obliegt allein dem Product Owner, diese User Stories in Wichtigkeit für den Erfolg des Produktes zu bewerten und entsprechend zu priorisieren. Die Priorisierung dient zur Festlegung der Entwicklungsreihenfolge in den Sprints. Bei seinen Entscheidungen bezieht er die Meinung der Stakeholder mit ein, ohne das jene ein explizites Stimmrecht hätten – der Product Owner agiert für sich allein und unabhängig.

In größeren Projekten, die auf mehrere Teilprojekte aufgeteilt sind, gibt es pro Teilprojekt einen Product Owner; sowie einen Product Owner für das Gesamtprojekt, der für den Gesamterfolg zuständig ist. Die Abstimmung der Eigenschaften ist in einem solchen Fall komplexer, kann aber ähnlich verstanden werden.

Scrum vs. Kanban

  1. Scrum und seine Meetings
  2. Kanban-Meetings … und die Rollen in Scrum

Scrum Master

Dem Scrum Master kommt im Scrum-Prozess eine besondere Rolle zu. Während der Product Owner für das Produkt und dessen Erfolg verantwortlich ist, ist der Scrum Master für den Scrum-Prozess und dessen Erfolg verantwortlich. Er ist nicht als Teil des Entwicklungsteams zu sehen, sondern arbeitet mit diesem zusammen, führt die Scrum-Regeln (zum Beispiel Abhaltung der Meetings) ein und überwacht deren Einhaltung.

Dem Scrum Master obliegt es, die Meetings in sämtlicher Form zu begleiten und auch im Vorfeld zu organisieren. Treten Störungen im Scrum-Prozess auf, hilft er dabei, sie zeitnah zu beseitigen. Er ist erste Anlaufstelle für das Team, sobald Störungen auftreten.

Oft kommt es gerade in der Anfangszeit von Scrum vor, dass Fachabteilungen oder der Product Owner während des laufenden Sprints Änderungen der User Stories oder neue User Stories wünschen. Hier ist im Besonderen der Scrum Master gefragt, das geschickt zu unterbinden und das Team davor zu schützen. Hierfür muss der Scrum Master die Unterstützung der oberen Führungsebene besitzen. Der Scrum Master gibt dem Team weder Anweisungen, noch beurteilt er es – er dient dem Entwicklungsteam voll umfänglich als Coach für den Scrum Prozess.

Entwicklungsteam

Die User Stories, die der Product Owner festgelegt und entsprechend priorisiert hat, sind vom Entwicklungsteam in dieser Reihenfolge umzusetzen. Das Entwicklungsteam ist demzufolge allein für die Lieferung dieser Produktfunktionalitäten verantwortlich.

Neben diesen funktionalen Anforderungen an das Produkt, trägt das Team auch die Verantwortung für die Einhaltung der nicht-funktionalen Anforderungen, zum Beispiel die Qualitätsstandards. Es organisiert sich komplett selbst. Um dieser Verantwortung gerecht zu werden, ist keiner anderen Scrum-Rollen oder Dritten aus dem Unternehmen eine direkte Einmischung erlaubt.

Dieser Verantwortung kann das Team nur dann gerecht werden, wenn es entsprechend interdisziplinär besetzt ist. Hierbei ist ein Spagat zwischen absoluten Experten und Allroundern wichtig, da grundsätzlich davon ausgegangen wird, dass jeder im Team jede User Story umsetzen könnte. Ein T-Shape-Ansatz für die Mitglieder des Entwicklungsteams ist hier vorzuziehen und sehr zu empfehlen, wobei sich die Spezialisierungen auf Architektur, Entwicklung, Test und Datenbanken aufteilen könnten.

Wir berichten regelmäßig aus diesem Umfeld in unserer Agile-Kategorie!

Die ideale Teamgröße sollte sich zwischen drei und maximal neun Mitgliedern bewegen. Werden die Teams größer, ist der Overhead zur Organisation zu groß. In Zusammenarbeit mit dem Product Owner schätzt das Entwicklungsteam im Product-Backlog-Refinement-Meeting die Aufwände der einzelnen User Stories.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Kanban

Wir haben nun die Rollen im Scrum kennengelernt; die Meetings sollten uns aus der letzten Ausgabe noch im Gedächtnis sein. Allerdings haben wir dort auch über Kanban gesprochen; also sollten wir uns nun noch die Unterschiede in den entsprechenden Meetings etwas genauer ansehen.

Daily Stand-up

Ähnlich dem Daily Scrum gibt es in Kanban ebenfalls ein tägliches Meeting: das Daily Stand-up. Das Team trifft sich hierfür vor dem Board und bespricht zusammen die Tickets und Aufgaben, die bearbeitet wurden und welche es zu bearbeiten gilt.

In dem Meeting wird besonderes Augenmerk auf die Arbeit und weniger auf die Teammitglieder gelegt. Da sich Kanban dadurch auszeichnet, besonders den Arbeitsfluss zu visualisieren, hat das Team jeden Tag die Chance, die Möglichkeit und die Pflicht, diesen Arbeitsfluss zu optimieren. Es werden die Aufgaben besprochen, die den Arbeitsfluss implizit blockieren oder explizit als Blocker markiert wurden. Auch jene Aufgaben die lange Zeit nicht bewegt wurden werden besprochen.

Ähnlich wie im Daily Scrum werden Themen nur angerissen und Lösungen und/oder Lösungsdiskussionen auf einen nahen Zeitpunkt nach dem Meeting gelegt. Das hat den Zweck, den Fokus auf das Wesentliche im Meeting nicht zu verlieren.

Retrospektiven

Kanban zielt wie kaum ein anderer Ansatz darauf ab, Prozesse permanent zu hinterfragen und zu verbessern. Verbesserungen in Kanban finden evolutionär und inkrementell statt und müssen nicht auf das Softwareentwicklungs-Team oder das Softwareprodukt beschränkt sein.

In der Anfangsphase von Kanban sollte sich das Team einmal pro Woche zusammenfinden, um den Prozess zu beleuchten und gemeinsam Verbesserungen herausarbeiten. Erfahrenere Teams werden im Laufe der Zeit diesen Rahmen verlassen können, Verbesserungen kontinuierlich anstoßen und reflektieren.

Auch in Kanban ist weniger mehr: Verbesserungsvorschläge können auf entsprechenden Boards dokumentiert werden und nach dem FIFO-Prinzip abgearbeitet werden. Werden zu viele Vorschläge zur gleichen Zeit bearbeitet, fällt eine zielgerichtete Auswertung schwer, da nicht beurteilt werden kann, welche Verbesserung welche Auswirkung hatte.

Entwickler Magazin Spezial: Agilität

Seit vor vierzehn Jahren das Agile Manifesto ein neues Zeitalter einläutete, ist Agilität eines der zentralen Themen der Softwarebranche. Das Entwickler Magazin Spezial: Agilität beschäftigt sich mit den Vorteilen und Chancen, aber auch mit den Problemen und Herausforderungen, die agile Entwicklung mit sich bringt.

Scrum, Kanban und Co.

Damit möchte ich diese kleine Serie abschließen. Sie haben einen Überblick über die Meetings in Scrum und deren Entsprechungen in Kanban bekommen; außerdem wissen Sie nun, welche Besonderheiten es in der Rollenverteilung in Scrum gibt.

Übrigens: die Kolumne A2 – alles Agile erscheint alle zwei Monate im PHP Magazin!

 

Aufmacherbild: Image of inscription kanban tool colored stickers on a white board. von Shutterstock / Urheberrecht: Karashaev

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -