Retrospectives

Retrospective protocols

18.11.2019 (@rrahn)

TOP1: Pull requests - what did we observe

• lengthy discussions on GitHub -> maybe pair programming?
  • naming
  • design decisions
  • a lot of different opinions
• not-full time employer have lack days in which they can't review
• to many review-cycles where we find new stuff
  • 1-2 days for waiting
• certain reviews take long if only one person is available
• a rebase often causes that the changes are not visible anymore
• Long periods of time between review and applied changes

Suggestions for improving:

• Limit the round of reviews! No more than 3.
• Use new commits for review requests and squash them later!
• First look into the PR and make your notes, than see the developer in one-on-one if it is a big review or if there are a lot of things you feel that they need to be clarified.

Other suggestions:

• Script how many reviews a person has
• Reassign if you don't feel if you have the time
• Communicate who is available for reviewing maybe on Gitter.
• Use Gitter more often for group communication
• Resolve things that were resolved on GitHub.

TOP-2: Weekly todos

• keep them as the group feels they are beneficial
• track each persons todos in trello https://trello.com/b/r9hqtYLq/weekly-todos

04.11.2019 (@rrahn)

Present: 5 members

• Summary of the first iteration:

  • 26 planned tasks
  • 10 active tasks
  • 4 closed

• The team agreed that @rrahn takes on the role as an agile coach for the team.

  • This means that he his responsible for the execution of the agile environment and consultation during the transformation to become more agile in our team.

• Feedback of first "Story Gatherings":

  • In general there was a really positive effect and every member in the team had a good impression of it.
  • There was some discussion: Some members that only recently joined a specific project had the feeling that this was the first meeting where actually the clear picture, vision and reasoning for the project was communicated. Accordingly, the meetings were quite important but not as a story-gathering meeting but rather as a kick-off meeting.
  • A detailed discussion with the project members of the team after the meeting led to the first real initial stories that now can be more refined.

• General feedback:

  • There is a big concern within the team that our PRs take quite long.
  • Looking back to the last 30 days with closed PRs it took on average 67.8 days to close them.
  • The following list identifies some of the reasons:
    • Too much focus on code formatting, naming issues, etc. (Is there a lack of a common coding/naming style? Is there missing domain or technical knowledge?)
    • Too big. (What is a reasonable size? What would be a good measure, e.g. LOC?)
    • Too many rounds of reviews. (Too big? Not focused enough during the review? Missing technical/domain knowledge?)
    • No response in time. (which channels to communicate? when to look into a PR?)
    • Hard to track changes. (Squashed/force-pushed commits)
  • The team decided to actively protocol how PRs are reviewed during the next iteration to get a clear understanding of what takes how long. When does it happen? Why might this happen? Who was the reviewer? Note the last one is not meant to blame anyone but to figure out if there are large gaps in domain/technical knowledge that results in long discussions or many changes? How long do you need to wait between re-requesting a review and receiving the new one etc.

Tasks for next iteration

1. Discuss the topic for the next iteration and define tasks for it.
2. Have another story refinement session to work out more fine grained stories (not tasks!) from the initial stories.
3. Every team member should actively protocol why PRs take so long until they can be merged (see point 4 above)

• Seen from the perspective of the reviewer.
• Seen from the perspective of the reviewed person.