Skip to content

Retrospectives

rrahn edited this page Nov 4, 2019 · 15 revisions

Retrospective protocols

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 the role as an agile coach for the team

    • this means that he his responsible for the execution of the agile environment and consults in 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 about it.
    • There was some discussion, that for some members that were new to a specific project had the feeling that this was the first meeting were actually the clear picture, vision and reasoning for the project was communicated. Accordingly, the meetings were quite important but not for story gathering but rather for a kick-off meeting.
    • A detailed discussion with the project members on the team after the meeting led to the first real initial stories that can now 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 where PRs were closed 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 it 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?)
    • 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 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 rerequesting 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. With initial stories have another story refinement session to work out more fine grained stories (not tasks!)
  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
Clone this wiki locally