Retrospective Notes 2020.08.19 - ISISComputingGroup/ibex_developers_manual GitHub Wiki

Previous retrospective notes

  • We are fine with the size labels on PRs
  • We are fine with the way impeded issues are handled
  • arrival at meetings- got better immediately after but diminished again, we will start on time anyway
  • Might try to virtually "get up" in teams to prompt others to join standup
  • coffee attendance is slightly better but still less than ideal.
  • we were implementing more tickets than reviewing, this seems to have changed now
    • this being brought up has driven people to review more
    • we've got more points done than predicted, maybe because of not doing as well last sprint.
    • try not to read too much into the burn down graph
  • meeting roles seem to be working
  • did we make this release more stressful by imposing arbitrary deadlines? Possibly, but it's more likely that they will always be stressful
    • maybe don't leave enough time between manual system tests and first deployment
    • need to have a meeting about manual which system tests need to be removed

Recording zoom code chats

  • can only store them for 3 months anyway, and need to have permission of all involved, so might be not worth the effort
  • especially if something changes in the future making the code chat outdated, a new watcher might become misinformed
  • only record if somebody is unable to attend but wants to see it
  • only record if everyone is comfortable being recorded, if you are uncomfortable being recorded but not willing to speak up about it, contact K.B. or D.O. and they will champion the issue.

Mantid has a week after release to tidy up

  • this is equivalent of our tech debt stand down, but for a week.
  • Mantid has more of a need for this than we do due to the size of their team and the manner in which they manage their development
  • We might put aside a "no new dev work" sprint in long shutdown, and maybe 1 week per year of this, but no changes right now.

Should we run the system tests locally more?

  • No, this is the purpose of the build servers, only run them on your machine if you think it will break a system test
  • Could try to put something on Jenkins to highlight what was added since the last success, but this might not be possible/helpful given the large number of repositories they are reliant on
  • Perhaps add a step in the PR template to check if anything might impact a system tests, but might be hard to follow due to breadth of system tests

Instrument demo pages

  • Change it to one page with headers for the each release instead of one per demo meeting.
  • Move all previous pages into same format.

Low scientist attendance to some demos

  • If only one person is attending molecular spectroscopy demos each month maybe add them to another group to save dev time
  • Potentially present to their group meeting, check with them.

Good progress with points completed

  • we've got more points done than predicted, maybe because of not doing as well last sprint.
  • try not to read too much into the burn down graph
  • will see if it continues to next sprint

Stand up order

  • If people want to change it then they can do so at their leisure, list is useful so people don't get surprised by being at the start, also highlights people who aren't there.