Time-constrained iterative workflow

We take inspiration from some aspects of Agile Software Development and Scrum, especially this idea of time-boxed periods (“iterations”) of work that follow a specific pattern and process for incrementally building or improving things. The reason we don’t completely use Agile or Scrum workflows is because these workflows generally don’t fit well in more academic and research environments. Scrum and Agile often assumes that:

However, often in academic and research settings, these assumptions are not relevant or applicable. For instance, often everyone is or may be involved in multiple projects. Or we have a broad and diverse range in technical skills around software development practices, often because research and academic environments don’t foster nor support nor are aware of these types of skills and knowledge. All of these impact how effective an Agile or Scrum workflow are in these environments.

Based on these inspirations, an iteration for us follows a general sequence of steps.

Future iteration planning

Team lead sets everything up for the next two or three iterations.

  • Will create an iteration within the main “Team project planning” board (which are all listed here, which is found in the Settings in the board.
  • Will write the title of the iteration as the goal for it, while keeping the goal focused, small, achievable, and considerate of the time we have available.
  • Will add the main tasks to achieve the iteration goal to the board.
  • Will plan iterations so that they either end on a major holiday or are right in the middle of it. If possible, don’t plan the start of iterations a few days before major holidays start.
  • Will plan and decide on how long the future iterations should be (can range from 2-6 weeks, but prefer shorter iterations over longer ones). So far, we find that 3 week iterations work the best.

Start of iteration

Important

We track our iterations’ progress and tasks on GitHub with this project board.

An iteration starts with a first planning meeting that is scheduled well in advance, for between 30-45 minutes and either right after the previous iteration’s debrief and retrospective or in the morning of the next day (to give a bit of break between meetings). Preferably this meeting is in person. The aim of the meeting is to discuss and plan the specifics of the iteration.

Note

A basic agenda for the meeting might be:

  • Assign a timekeeper.
  • Review and agree on the iteration aim and end date.
  • Review the list of tasks already listed.
  • Brainstorm and add any other issues as needed.
  • Schedule the next iteration’s end and start meetings.

In general, only the team lead is required to prepare for the planning meeting. Before the planning meeting, the team lead will move any existing tasks (GitHub Issues) into the iteration that is relevant to the aim of the iteration. The team lead will also create any issues that are missing from the current list of issues. While making issues, keep them as small as is reasonable and as descriptive and targeted as possible.

Other team members can optionally review the aim and output of the iteration board, review the list of issues already listed, and write out any potential issues as needed to complete the iteration aim.

During the meeting, someone will share their screen (if virtual) and the team goes through the tasks on the board together. We’ll discuss and decide or agree on the iteration goal (the “increment” or “milestone”) and the end date.

We’ll review the current list of tasks on the board and brainstorm any other tasks that are needed. We’ll then agree on the number of tasks in the iteration as well as the distribution of priority labels of the tasks.

Then, we agree on and schedule the end date debrief and retrospective meeting, which should be approximately 2-3 hours and preferably before lunch, as well as the next iterations planning meeting. The next planning meeting should either be on the same date after lunch, to ensure a proper break before moving to a new iteration, or the next day to give some break between meetings.

During the iteration

We have a guide that describes in detail how we work on tasks during an iteration.

End of iteration

Important

We track our iterations’ progress and tasks on GitHub with this project board.

The iteration’s end is a last meeting for a debrief and retrospective to discuss how things went. These are between 1-2 hours and are preferably in person. The time and place of this meeting will have been scheduled during the planning meeting.

Note

A basic agenda is:

  • Assign timekeeper.
  • Demo (internally or externally) the progress of the iteration.
  • Evaluate the iteration aim.
  • Go over what we accomplished and how we felt we did (including struggles).
  • Do a retrospective.

During the debrief and retrospective meeting, we will:

  • Assign a timekeeper to keep us on track and so we avoid spending too long on any one topic.
  • Show off and (optionally) demo the output of the iteration all together as a team. We’ll assign someone to be responsible for showing or trying out the demo before the meeting.
  • (Optionally done occasionally, but strongly suggested) Include someone external (a potential user) to try out the product/demo and give some feedback.
  • Evaluate the aim and review whether we’ve achieved the aim.
  • Briefly go over what we each did during the iteration and how we felt we did. Include any barriers, struggles, or challenges that came up during the iteration here.
  • Do a “retrospective”, where we individually write down how things went (“keep doing” category) and what could be improved or removed (“stop doing/improve on” category) in the process. The retrospective should ideally be done in a collaborative “note-taking/post-it notes” system (Figma is really nice for this). These notes will be collected into topics and we will add action items to each of the topics. The team lead will add these action items to issues or posts on how we work.