4 Iterative and incremental workflow
This guidebook is written following the diátaxis “how-to guide” style. And because this document reflects how we work in the Seedcase Project, it is living and constantly evolving. It won’t ever be in a state of “done”.
This chapter describes how to follow a specific, but very effective, workflow for managing and completing work in teams, especially knowledge work such as software development and research in general that we follow in the Seedcase Project. This chapter covers this workflow and how to generally use it.
4.1 Iterative and incremental development in research settings
The way we’ve designed our work to follow a workflow that is inspired 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 a project or product. On their own, Agile or Scrum workflows don’t generally fit well in more academic and research environments. Certain Agile frameworks like Scrum often assume that:
- You and the team are in a more traditional “business” environment with customers, which isn’t always true in or comparable to research and academic settings.
- Everyone on the team is working only on the project full-time during the iteration (e.g. with the use of “daily standups”). In research settings, projects are a bit more fluid and people may not work on them full-time or consistently, because they are often involved in many projects at the same time.
- Everyone on the team is highly technically skilled and knowledgeable in software development practices, for instance with the “self-organizing” principle in the Agile Manifesto. Skill and knowledge level is highly variable in research settings, and substantial time may be needed to train people, which impacts how well these practices can be realistically applied and followed.
- You have the resources to have dedicated personnel for managing the iteration and planning the product (e.g. with “Scrum Master” and “Product Owner”). In research, the biggest constraint is often funds so you likely have fewer people who have to do a wider variety of tasks and don’t have dedicated personnel for specific roles.
All of these assumptions inherent to Scrum, Agile, or any other common industry workflow can’t be directly applied to research and academic settings. So their effectiveness in those other settings might be very different from their effectiveness in these settings. So this guide to using iterative and incremental development in research settings is slightly modified to fit the needs and constraints typically found in research and academic settings.
4.2 Planning upcoming iterations
The team who uses this workflow needs one person who is responsible for planning and curating the iterations, along with the tasks to do within the iteration. While this person could be anyone on the team, ideally the person is someone who has a strong understanding and big picture overview of what the team is working towards and the milestones needed to get to that final aim. This is usually the team lead, and so for the rest of the iteration documentation, we refer to this person as the “team lead”.
If you are the team lead, you should (ideally) have a general plan or goal for what the team will do in the next two or three iterations. A useful way of doing this is through the use of software that allows creating Gantt charts. Gantt charts are visually ways of listing tasks or milestones, when those tasks or milestones should approximately start and end, and what the dependencies are between the tasks or milestones. GitHub Projects have “roadmap” type layout that act just like Gantt charts.
As the team lead, you can use this roadmap layout to list milestones for planned or in-development products to plan work that the team will do during future iterations. This roadmap can provide a high-level overview of what the team will work on over the upcoming months. However, a limitation of roadmap-style layouts is they aren’t good at very lower-level details and specific tasks. That’s why you use a different layout for tracking iteration-level aims and tasks, called a “board” in the GitHub Projects.
- Use the GitHub Project “status updates” feature to communicate what the purpose and aim of the iteration is. Within the status update, explicitly describe what the tangible aim for the iteration is, making sure to keep the goal focused, small, achievable, and considerate of the time the team has available for that iteration. Ideally, you should write a sub-aim for each person in the team for that iteration.
- Use the “board” layout following the typical Kanban style “lanes” like “todo”, “in-progress”, or “in review” to list tasks for the iteration. Add tasks to the board that are needed to achieve the iteration aim.
- Use “priority” labels for the Project board items to communicate which items need to be completed first. This also helps organise content on the board, as you can sort items by priority label.
Check out all our GitHub Projects). for the Seedcase Project for inspiration.
Having one iteration be one calendar month makes them easier to plan and organise. That way, a year can be divided into 12 iterations, and you can more easily use that to plan the work and aims for the year. It also makes each iteration about 4 weeks, which is generally a good amount of time to be flexible while also having enough time to achieve a meaningful aim. Depending on your project, shorter iterations of 3 weeks might also be appropriate, but we generally don’t recommend going beyond 4 weeks, since the team might lose focus on the aim and it becomes harder to maintain a clear sense of progress.
Having an iteration last one calendar month also makes it easier to schedule the iteration’s start meeting for planning at the beginning of the month and the iteration’s end meeting for debriefing and doing the retrospective at the end of the month. That way, the team can always assume and schedule those dates as meeting dates. You as the team lead should schedule these meetings well in advance and confirm that as many of the team can attend as possible. The scheduled meeting should be put in a calendar that everyone on the team can access or see.
We use Teamup for scheduling meetings and keeping track of the iteration dates. The advantage of Teamup is that anyone (with the right permissions) can add events to the calendar, and you can easily synchronise it with your own calendar app. So there is no “locking-in” to a specific calendar app. We highly recommend using Teamup if you are working in a team with others that may or may not be in the same organisation or who don’t necessarily use the same calendar app as you.