4 Agile overview
The Agile process we use is dynamic. All of the procedures here can and should be changed to improve the group’s productivity, cohesion, and fulfillment.
Scrum is an Agile process for software development and project management that we have adapted to our process. You can learn more about Scrum on Wikipedia, but the key features that we have implemented are described below.
As part of the Agile process, we continually evaluate and improve these procedures as needed.
4.1 Rhythm and Hierarchy of Meetings:
Our group uses the following hierarchy of meetings, from brief daily status reports to quarterly reviews and planning.
- Annual:
- Quarterly:
- Objectives and Key Results (OKRs): Every three months is a quarter, where each quarter has a set of OKRs.
- Quarterly review meetings: at the beginning of each quarter, last quarter’s OKRs are discussed and the current quarter’s OKRs are decided upon.
- Monthly
- Review and update OKRs in first 1:1 of the month
- Bi-Weekly:
- Bi-weekly Sprints: start with a planning meeting and end with a sprint retrospective meeting.
- Weekly: Each group member has a one-on-one meeting (30-60 minutes) week with Kristina.
- Daily standups: Daily progress, plans, and blockers are discussed during daily standup meetings (10 minutes).
4.2 Time Tracking
We use Toggl to track the time each group member spends working on each of the (many) projects that we all contribute to.
This began with the Data Science Incubator, when it became prudent to track the time spent working on each project. We now use it in order to be fair to our collaborators and funders by quantifying the time spent on projects, and making sure that we are allocating effort appropriately across projects. We also use it to populate the Group Effort Spreadsheet, which we use to communicate our activities to stakeholders within the university.
4.2.1 Toggl conventions
- Projects: Each group member likely contributes to many projects. Each Incubator project, externally funded project, workshop or training, or event should get its own project. Group work (e.g. one-on-ones, group meetings, sprint planning) falls under the Group Work project. Although some work may not fall into a project and be appropriately categorized as “no project”, assigning work to projects makes it much easier to track later.
- Labels: In addition to assigning time to a project, you can assign a label (such as “email”, “meetings”, “workshops pre and post”). We use these to get a pulse of how much time we spend on different types of activities. Assigning labels is less important than assigning projects.
- Archiving: When a project is completed, you can archive it. The time entries will remain logged, but you will no longer be able to add time to it.
- Public/private: Unless there is a strong reason to create a private project, create projects as shared across the whole group. This enables us to quickly see how much time we as a group have spent on a project, in addition to each team members’ hours.
- Precision: Generally, hourly to half-day precision is sufficient. We estimate our time as percentages of FTE, not billed down to the minute.
- Comprehensiveness: In keeping with the percentages philosophy, the goal is not to account for 100% of everyone’s time. You certainly can use it to track everything, but it’s not a tool for checking up on members’ work hours.
- Overthinking: Time tracking is meant to be a tool to improve our efficiency and self-awareness around work! It should not become so detailed or complex that it turns into a task of its own.
4.3 A note on metrics
Keep in mind:
“When a measure becomes a target, it ceases to be a good measure.” - Marylin Strathern (Goodhart’s Law)
There are many ways of measuring work - we use OKRs, sprint points, time tracking, among others. These are used to plan, assess, and report. Importantly, these metrics are not used to assess individual performance. Optimizing for such metrics at the individual level is counterproductive, and diminishes the value of such metrics.