Agile Softwareentwicklung

Kanban-Meetings und die Rollen in Scrum

René Schröder

© Shutterstock / Karashaev

Im Rahmen unserer JAX-Themenwoche Agile stellt René Schröder die Grundlagen von Scrum in einer zweiteiligen Serie vor. Hat sich Teil 1 mit den Meetings in Scrum beschäftigt, führt Teil 2 den Kanban-Stil ein und beleuchtet die Rollen in Scrum genauer.

Kanban-Meetings und die Rollen in Scrum

Scrum und Kanban Meetings haben einiges gemeinsam und unterscheiden sich doch an wichtigen Punkten. Es ist an der Zeit, Vergleiche zu ziehen und einige offene Fragen auszuräumen.

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.

Lesen Sie auch: Scrum und seine Meetings

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 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.

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.

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

JAX TV: Agile Coach zu werden ist nicht schwer… einer sein dagegen sehr

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.

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

Verwandte Themen:

Geschrieben von
René Schröder
René Schröder
René Schröder ist seit dem Jahr 2001 als zertifizierter Projektleiter (AXELOS, IPMA/GPM, Scrum Alliance) und Softwarearchitekt (iSAQB) erfolgreich am Markt unterwegs. Er ist Experte für die erfolgreiche Implementierung eines ganzheitlichen Methodenmixes bestehend aus Projektmanagement, Softwarearchitektur und Testing in komplexen Entwicklungkontexten, um langfristig den Projekt- und Produkterfolg sicherzustellen. Website: regsus.de, E-Mail: r.schroeder@regsus.de; rs@wizardsofecommerce.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: