Warum dauern Pull Requests so lange?

Question

Hey,
ich suche ein Format oder eine Herangehensweise, wie ich mit dem Team ein Thema bearbeite.
Wir haben für die nächste Retro morgen folgendes Thema gewählt: Team-Umgang mit Pull Requests. Problem: ein Teammitglied ist frustriert, weil die PRs sich so lange hinziehen und das Thema schon so oft angesprochen wurde.
In einer vergangenen Retro haben wir mal Rufe in den Raum formuliert: „alle achten ab jetzt darauf...“, die haben aber nichts gebracht.
Das Team macht PRs unterschiedlich. Ich habe folgende Styles gesammelt:
- wann immer es sich anbietet, unterbreche ich die Arbeit und gucke nach einem PR
- ich bekomme drei mal täglich einen Alarm
- ich gucke morgens und abends je einmal, ich brauche die konzentrierte Arbeit im Tunnel, möchte nicht so of unterbrechen
- ich scheue mich, weil ich mich nicht so kompetent fühle
- ich bin Quereinsteiger und erst neu

Wie würdet ihr auf einen gemeinsam getragenen Umgang mit PRs hinarbeiten?

Answer 1

Hallo Kaspar,

wenn die Vorgehensweise nicht darauf ausgerichtet ist, dass Dinge fertiggestellt werden, dann wird auch ein "Working-Agreement" in einer Retro nicht wirklich helfen.

Ich weiß nicht wie ihr arbeitet, ich würde aber empfehlen euch anzuschauen wie hoch euer WIP (Work In Progress) aktuell ist und ob euch ein WIP-Limit helfen könnte.

Ein WIP-Limit sorgt dafür, dass sich alle gemeinsam darum kümmern, dass Dinge fertiggestellt werden. Und wenn nun mal die Pull-Requests ein Glied der Kette sind um etwas fertigzustellen, dann geht kein Weg daran vorbei. Das Team wird sich die PRs anschauen müssen bevor sie mit neuen Aufgaben beginnen.

Ich hoffe, das hilft!

Comments

Hey Giancarlo, vielen Dank.

Wir hatten ein WIP-Limit am analogen Board, jetzt ist es technisch nicht limitiert, aber im „Großen und Ganzen ist es ok“.
Da manche einfach nicht oft PRs machen, arbeiten sie länger „im Tunnel“. Da sie aber zum Code Review angefragt werden, bleiben manche PRs länger liegen.

Ich nehme den WIP-Limit-Faktor aber mal mit, vielen Dank.

Answer 2

Von außen klingt es so, als wenn jedes Teammitglied wie ein eigenes Silo / eine eigene Abteilung arbeitet. Jeder hat seine eigenen Tickets und möchte hier gut vorankommen. Eine Unterstützung für andere ist von außen zwar erwünscht, aber in erster Linie wird von den Teammitgliedern erwartet, dass >ihre< Tickets gut vorankommen.

In meiner Beobachtung kommt das sogar häufig vor, dass Tickets nicht wie Features, sondern wie Arbeitspakete geschnitten sind. Auf diese Weise passen sie zwar nicht zum Scrum Gedanken, dafür aber zu JIRA, da JIRA einen ja zu exakt >einem< Bearbeiter eines Tickets zwingt.

Eine Möglichkeit das zu ändern sehe ich darin, dass das Projekt (meist in Persona Product Owner:in und Scrum Master:in) eine gemeinsame Linie vertritt, dass im Daily Scrum nicht jeder seinen persönlichen Status reportet (was nicht der Scrum Gedanke ist), sondern dass gemeinsam geschaut wird, welches Ticket man als nächstes "Fertig"/"Done" bekommt und wer hier unterstützen kann, damit es besonders schnell geht. Wenn dann das Augenmerk auf das Ticket mit offenem PR fällt, dann kann noch im Daily Scrum durch die Developer entschieden werden, wer den PR reviewed.

Eine etwas konkrete Art wäre, dass z.B. die Tickets eine Priorisierung haben - hiermit meine ich nicht die ursprüngliche Priorisierung im Product Backlog durch den Product Owner, sondern eine selbstorganisierte Priorisierung der Developer, in welcher Reihenfolge sie die Tickets abarbeiten wollen. Dann kann man z.B. im Daily Scrum nicht personenweise durchgehen, sondern ticketweise... mit dem Ziel, dass immer geschaut wird, wer alles zum Vorankommen eines Tickets benötigt wird... solange, bis sich alle Tickets zugeordnet haben (natürlich darf man auch an anderen Tickets weiterarbeiten, wenn seine Unterstützung bei den priorisierten Tickets bereits erledigt ist oder ggf. aktuell gar nicht möglich ist).