2 Time-constrained iterative 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.
2.1 Iterative 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 development in research settings is slightly modified to fit the needs and constraints typically found in research and academic settings.
2.2 Planning upcoming iterations
The team who uses this workflow needs one person who is responsible for planning and curating the iterations. 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 and will:
- Create an iteration within the main iteration planning board (for the Seedcase Project, they are all listed here). You create an iteration by going into the project board’s settings.
- Write the title of the iteration as the aim for it, while keeping 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.
- Add tasks to the board that are needed to achieve the iteration aim.
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.