ds-incubator: Share best practices in coding

2020-03-17 Coding-sprint retrospective

https://github.com/2DegreesInvesting/ds-incubator/issues/30

People liked working with someone else on the same problem at the same time. We feel that was fun and allowed us to share knowledge (e.g. Jackson showed how to build 2dii-like packages).

The organization of the sprint could have been better.
The communication before and during the sprint was little, both among organizers and between organizers and participants.
The vision of the organizers and participants were misaligned.
Interdependent tasks were not scheduled to maximize efficiency. For example, the r2dii.scenario package wasn't ready on GitHub to push commits to it, and one PR had to wait.
It was unclear who was the "go-to person" for specific technical or conceptual knowledge.
It was unclear that the event was happening until too close to the starting date.
It was unclear what tasks we could work on.
Except for the kick-off meeting, there was no scheduled time to catch up or wrap up. Prior commitments might have interrupted team work.
Work was sometimes unfocused and people "got lost in the woods".

(1-3 above) Have preparatory meeting among the organizers, and between organizers and participants before and during the event.
- Before the event to:
  - Align vision
  - Specify responsibilities
  - Set clear agenda
  - Prepare introduction providing more context and content than in the current one to ensure everyone understand the goal of a) the entire workshop as well as b) of each specific task/function
- During the event to:
  - Ensure everyone is working with someone else and feeling okay.
  - Check if the work in progress is going well and and as planned. Maybe answer: (a) What did we do so far? (b) What do we plan to do? (c) What is impairing our progress?
(4 above) Once all tasks are clear and before people get to work, search for interdependent tasks and schedule them for maximum efficiency. It may help to write each task on a GitHub issue (or sticky note), organize them on a GitHub project board (or the wall), then schedule them with GitHub milestones (or an alarm clock).
(5 above) Nominate technical and conceptual mentors, who could and are willing to train others or navigate pair-programming sessions with those seeking the knowledge they have.
(5 above) Ensure mentors are well advertised, are enough, available, and easy to reach. Each mentor should probably have a personal zoom account, be trained in pair-programming, and know how to remote-control a shared screen.
(6 above) Once we set a date for the sprint, advertise it ASAP and clarify if the cancellation of an in-person event means (a) the event is indeed canceled, or (b) the event happens remotely.
(7 above) Dedicate a repository to the event and collect ideas and comments in the form of GitHub issues (example from others). Each issue may be a piece of the work that needs to be done to address a bigger problem. The dedicated, smaller issues should allow people to discuss and extend your ideas. We should encourage people to self nominate to tackle one of those issues or to propose a new issue.
(8 above) Meet everyone at scheduled times during the sprint to check progress, and also at the end of the event to wrap up.
(9 above) Ask break-out groups (maybe pairs) to talk to each other and schedule blocks of uninterrupted time to work together.
(10 above) Start with a time slot for break-out groups to plan their work (scoping, approach, etc.).

Also:

Encourage working in groups (at least two people most of the time). Pair-programming is a great way to share knowledge, particularly the strong-style pairing but it seems best to mix with other pairing styles. Pairing requires vulnerability and everyone should feel safe and comfortable working with others, regardless of their technical skills.
Lean how others do similar things, e.g.: