# Call for new Anoma work flow

[TOC]

## 1. Summary

## 2. Introduction

When it comes to change, virtual teams are somewhat paradoxical. Team members can perhaps be more responsive, balancing autonomy an interdependence, and more mfocus on their part of the team objective. However, change creates an increased need for communication, clear goals, defined roles and responsibiliies, and support and recognition processes. These things are more difficult to manage in the virtual world.

## 3. Current work flow

### Definitions

##### Concern
A concern is a discrete task or assignment that an Anoma Contributor intends to address during a designated Concern Cycle. Concerns can be tasks of arbitrary sizes: they can be addressed during one of more Concern Cycles.

##### Concern Cycle
A Concern Cycle is a predefined time period, typically lasting two weeks in the current context, during which one or more concerns are actively tackled. Anoma Contributors have the opportunity to nominate their concerns, and Chris will ultimately facilitate the matching process between Anoma Contributors and these nominated concerns.

##### Mid-cycle Report
A mid-cycle report is a status update document prepared by the concern lead to assess the progress of the concern at the halfway point of the concern cycle. This report outlines the accomplishments thus far and outlines the planned activities for the latter half of the concern cycle.

##### End-of-Cycle Report
An end-of-cycle report is a status update document prepared by the concern lead to document the achievements pertaining to concerns at the end of the concern cycle.

### Key roles and responsibilities

##### Chris
Chris has, as the head of research department of Heliax, overall responsibility for making Anoma implementation-ready. His responsibilities include, but are not limited to,
- Identifying project requirements
- Technological strategy planning
- Allocating resources effectively
- Monitoring project progress
- Fostering internal communication and alignment
- Decision-making
- Performing research

##### Anoma Contributor
An Anoma Contributor refers to any employee of Heliax actively involved in contributing to the Anoma project. Currently, the majority of Anoma Contributors are members of the researchers department.

##### Concern Team
A Concern Team is a collection of Anoma Contributors that share a concern. They work together towards tackling a concern during a concern cycle.

##### Concern Team Lead
A Concern Team Lead is an Anoma Contributor who is a member of the Concern Team but bears additional responsibilities beyond those of other Concern Team Members. These responsibilities include
- Coordinating efforts of the Concern Team
- Reporting on the efforts of the Concern Team

##### Concern Team Member
A Concern Team Member is an Anoma Contributor who is a member of a Concern Team but does not assume the role of the Concern Team Lead.

### Current procedures

In the figure above we see an information flow diagram of 4 existing procedures. The colors have the following meaning:
- Red: Tasks completed collectively by Anoma Contributors
- Blue: Tasks that can be performed by any Concern Team Member
- Yellow: Tasks carried out by Chris
- Orange: Tasks carried out by the Concern Team Lead

Furthermore, every procedure has input (incoming arrow) and output (outgoing arrow). An incoming arrow signifies that the procedure relies on the output (e.g., information or results) generated by the procedure from which the arrow originates.

#### Planning procedure
Periodically, subsets of Anoma Contributors meet in person during retreats. These meetups consists of three essential components:
1. Reflecting on past achievements and tasks.
2. Intensifying our efforts on ongoing tasks, with particular attention to complex inter-team work.
3. Strategically planning and shaping the next few months.

The results of the planning procedures are often documented in HackMD and shared in a Slack channel, set up for the retreat.

#### Proposal procedure
Before the start of a Concern Cycle, Anoma Contributors have the opportunity to propose what to work on through the following two-step procedure:
1. An Anoma Contributor can submit a concern proposal on the Anoma Forum.
2. Each Anoma Contributor communicates their preferences to Chris through Slack, specifying which concern they wish to work on, their desired team members, and whether they are interested in assuming the role of Concern Team Lead for that particular concern.

#### Matching procedure
Based on the concern proposal and the preferences from the proposal procedure, Chris will match Anoma Contributors to concerns based on several criteria to ensure productive allocation of resources. Anoma Contributors that are matched to the same concern form a Concern Team. Before a Concern Cycle starts, Chris announces the matchings, Concern Teams and Concern Team Leads.

#### Reporting procedure
Each Concern Team Lead will produce one mid-cycle and one end-of-cycle report. This reporting procedure has basic three steps:
1. Collect status updates from all Concern Team Members.
2. Write a summary of the status updates.
3. Share the report with Anoma Contributors by publishing it on the Anoma Forum.

The mid-cycle report serves as a foundation for the end-of-cycle report, which, in turn, is used to propose concerns for next cycles.

### Assesment
Todo:
- Describe methodology and metrics to allow to assess current workflow
- Explain key limitations and provide proof from interviews
- Summarize what needs to change

## 4. Proposed work flow

### Definitions

#### Definitions Units of Time

##### Milestone Cycle
A Milestone Cycle is a predefined time period, typically spanning three Concern Cycles in the current context, within which efforts are made to achieve one or more milestones.

##### Concern Cycle
A Concern Cycle is a predefined time period, typically lasting two weeks in the current context, during which one or more concerns are actively tackled. Anoma Contributors have the opportunity to nominate their concerns, and Chris will ultimately facilitate the matching process between Anoma Contributors and these nominated concerns. Note that this definition has not changed.

#### Definitions Units of Progress

##### Milestone
A Milestone is a significant point or event that shows progress or marks an important achievement in the Anoma project. It's like a marker that tells you how far you've come or when you've reached a key goal. They help plan schedule and execute parts of the project.

##### Project Plan DAG
A Project Plan DAG is a graphical representation of a project plan within one or more Milestone Cycles. In this graph, a set of Concern Tasks and Milestones are connected by their dependencies. It's called "direct acyclic" because it consists of nodes (concern tasks, milestones) and directed edges (dependencies) between them. This can be done in LucidCharts. The purpose of creating a DAG of milestones is to visualize and manage the sequence of Concern Tasks and Milestones, ensuring that Concern Tasks are completed in the correct order and that there are no circular dependencies that could cause scheduling conflicts or delays.

##### Kanban Board
A Kanban Board is a project board with visual display of smaller tasks. The board is divided into columns representing different stages, such as "To Do," "In Progress," and "Done." It provides a clear and real-time visual representation of work in progress, making it easier for teams to manage, prioritize, and track units of work as they move through various stages of completion.

#### Definitions Units of Work

##### Milestone Cycle Task (MCT)
A Milestone Cycle Task (MCT) is a higher-level work item or task that encapsulates a larger objective or goal within our project. It serves as a container for a group of related Concern Cycle Tasks, which are the smaller, more granular tasks that collectively contribute to achieving the MCT's objective and, by extension, the milestone.
<!-- Tools: we can use Github epics to represent a MCT-->

##### Concern Cycle Task (CCT)
A Concern Cycle Task (CCT) is the smallest task or unit of work within a Concern Cycle. Each CCT represents a specific task that needs to be performed. CCTs are associated with MCTs to indicate how they contribute to the completion of the larger task represented by the MCT.

<!-- Tools: We can use Github issues to represent a CCT-->

#### Types of Reports

##### Project Status Report (PSR)
A Project Status Report is a document that provides an overview of the current status. It typically includes information about progress, milestones, issues, risks, and other relevant project metrics. This report is created at the end of a Concern Cycle.

##### Concern Cycle Proposal Report (CCPR)
A Concern Cycle Proposal Report (CCPR) outlines a proposal or plan related to one or multiple MCTs within the Concern Cycle. It's a document used to present ideas or solutions, and it may lead to the creation of actual CCTs.

##### Matching Report (MR)
The Matching Report (MR) is a document that outlines the assignment of Anoma Contributors to specific MCTs, as originally proposed in the CCPR. Additionally, it provides insights into the composition of Concern Cycle Teams, including the identification of the Concern Cycle Team Lead for each group.

<!--
explain
- purpose
- who creates them
- when it is created
- what tthe format of this document is
-->
##### End-of-Cycle Report (EoCR)
An End-of-Cycle Report (EoCR) is a status update document prepared by the Concern Cycle Team Lead to document the achievements and future work at the end of the Concern Cycle.

<!--
explain
- purpose
- who creates them
- when it is created
- what tthe format of this document is
-->

##### Continuous Activity Report (CAR)
A Continuous Activity Report (CAR) is a type of report that tracks ongoing CCTs within a Concern Cycle. It is created by the Concern Cycle Team Lead, and serves to monitor and communicate the status of these activities within the Concern Cycle Team.

<!--
explain
- purpose
- who creates them
- (how long it lives -> when it is created when its ended)
- what tthe format of this document is
-->

### Key roles and responsibilities

In addition to existing roles, we also have a Project Manager.

##### Project Manager
The Project Manager monitors the status of the Anoma project and makes this eligble to all Anoma Contributors. It does this by maintaining the Project Plan DAG and also producing the Project Status Report. Both are updated at the end of a Concern Cycle.

### Proposed procedures

<!--  -->


#### Monitoring Procedure
At the end of every Concern Cycle, the Project Manager does the following:
1. It reads all the End-of-Cycle reports
2. If deemed necessary, it makes adjustments to the Project Plan DAG, which may include
* Adds Milestone Cycle Tasks
* Change status of a Milestone Cycle Task
3. Subsequently, the Project Manager generates a comprehensive Project Status Report, which is made available on the Anoma Forum. This report serves as a transparent and up-to-date overview of the project's current status, achievements, and any adjustments made to the Project Plan DAG.

#### Milestone Cycle Planning Procedure
The planning procedure is as follows. Before the start of the next Milestone Cycle, there is a Milestone Cycle Planning Meeting. The goal of this meeting is to plan for the next Milestone Cycle. This meetings consists of three parts:
1. The Project Manager kicks off the meeting with a presentation that reflects on the outcomes of the previous Milestone Cycle.
2. Team Leads from the Concern Cycle teams then provide concise presentations outlining their plans for the upcoming Milestone Cycle. These presentations encompass their local Project Plan DAG, which includes milestones and Milestone Cycle Tasks.
3. Following the presentations, there is a collaborative discussion led by Chris. This discussion focuses on offering feedback and aiding in decision-making, particularly regarding prioritization.

After this meeting the Project Manager integrates all local Project Plan DAGs into the global Project Plan DAG, creating alignment and enabling Anoma Contributors to produce Concern Cycle Proposal Reports.

<!--
high uncertainty should create milestones that strike a balance between short-term progress and long-term vision. Frequent, iterative milestones can be effective in managing uncertainty, learning from experimentation, and adapting to changing circumstances
-->

#### Proposal Procedure
Before the start of a Concern Cycle, Anoma Contributors have the opportunity to propose what to work on through the following two-step procedure:
1. Submission of Concern Cycle Proposal Report: An Anoma Contributor can produce and submit a Concern Cycle Proposal Report on the Anoma Forum. This proposal contains at least:
* Summary of the plan
* An explanation of how the plan aligns with specific Milestone Cycle Tasks (from the DAG)
* A rationale justifying why addressing these Milestone Cycle Tasks is essential during the upcoming Concern Cycle.
2. Communication of Preferences to Chris via Slack: Then, each Anoma Contributor communicates their preferences to Chris through Slack. In this communication, they should specify:
* From the proposed Milestone Cycle Tasks, which ones they wish to work on.
* Desired team members
* Whether they are interested in assuming the role of Concern Cycle Team Lead for this particular Concern Cycle.

Proposers can draw insights from different sources: the Project Plan DAG, the Project Status Report, or End-of-Cycle Reports.

#### Matching Procedure
Building upon the Concern Cycle Proposal Reports and the preferences submitted during the Proposal Procedure, Chris orchestrates the formation of Concern Cycle Teams and aligns each team with one or more designated Milestone Cycle Tasks. This crucial process ensures that the project's objectives are efficiently addressed. The procedure is as follows:
1. Team Formation: Chris examines the Concern Cycle Proposal Reports, taking into account the preferences and expertise of Anoma Contributors. Based on this evaluation, it assembles Concern Cycle Teams, bringing together individuals with complementary skills and shared interests.
2. Task Assignment: Following the team formation, Chris strategically assigns each Concern Cycle Team to specific Milestone Cycle Tasks that closely align with the concerns and objectives outlined in the Proposal Reports. This alignment optimizes the team's focus and contributes to the successful execution of the Milestone Cycle.
3. Announcement: In preparation for the Concern Cycle, Chris announces the matchings, revealing the composition of Concern Cycle Teams and identifying the designated Concern Cycle Team Leads. This announcement facilitates clarity and collaboration among team members as they embark on their respective tasks.

*Note for myself: It's important to note that this well-established procedure remains consistent, ensuring the continued effectiveness of the project coordination process. If we have a readable and reliable DAG, this step may be done without relying on any concern proposals. *

#### Execution Procedure
Following the successful completion of the Matching Procedure, Concern Teams are ready to embark on the Concern Cycle, actively addressing their designated tasks. The execution procedure unfolds as follows:
1. Concern Cycle Planning Meeting: At the kick-off of the Concern Cycle, the team leads take the initiative to organize a dedicated Concern Cycle Planning Meeting. During this meeting, they break down the assigned Milestone Cycle Tasks into more manageable Concern Cycle Tasks. This strategic planning ensures a focused and organized approach to task execution.
2. During the Concern Cycle: Throughout the Concern Cycle, the Concern Cycle Team employs a(n) (existing) Kanban Board to monitor and manage progress (Continues Activity Reporting). Here's how this is accomplished:
* GitHub Epics for Milestone Cycle Tasks: The selected Milestone Cycle Tasks are represented as GitHub Epics on the Kanban Board. This provides a high-level overview of the major objectives for the cycle.
* GitHub Issues for Concern Cycle Tasks: To track and address specific details and subtasks, the team utilizes GitHub Issues on the Kanban Board. These issues correspond to the decided-upon Concern Cycle Tasks.

### Rationale for change
Identify the key changes, and explain why those changes are for the better

## 6. Final thoughts
- Pm is an independent service providing role, it does not manage others and others don't manage the PM. We need to clarify this as people are currently wasting their time on PM-related research.
- Currently, there seems to be some confusion within the Typhon group. This is probably because the current Project Manager is also a member of that group. As such, [decisions related to PM](https://research.anoma.net/t/concern-proposal-typhon-p2p-operational-specs-synthesis/185/11?u=nzarin) have been made while the PM wasn't present. It should be clear that the PM is an independent role, not related to any Concern Cycle Team.
- For PM related matters please talk to the PM. It was very dissapointing that some members of the Typhon team were sending Chris messages without talking to the PM first. Input from all members are always considered welcome (and this has been communicated to everyone)
- Change management requires time. Companies such as KPMG and Mckinsey spend months trying to improve processes and workflows at client companies. This is because it's not easy, as such it would be fair to get a little bit time to do it well. Also, currently, too many people are too involed in the process. This does not only frustrate the design and implementation of a new workflow, it also wastes significant resources unnessarily.
- Requirements elicitation (through interviews) is important as we should not optimize things that should not exist in the first place
- We just need to commit to *a* process and not waste time trying to reach consensus about THE BEST process.
-

## Take-aways from interviews so far
- Common recurring issues from interviews
- Decisions are made while relevant parties are not aware of it (standardized procedure for this is lacking).
- A lot of people are happy with any process as longs as people commit it and use it consistently
- Information retrieval is still very hard
- Almost everyone want to be informed about the current status of the Anoma project, but they do not want to scan Github project boards and make estimations/assesments about the current state of affairs. They barely read others teams EoC reports.
- Solo teams find the mid-cycle reports a waste of time. Some even find the EoC reports annoying. Key reason: they don't see how these reports add value to anyone ("sometimes I only get a thumbs up")
- One aspect of Concern proposals people like is planning ahead and already structuring a problem before working on it. Also, by having the proposal somewhere, people can remind themselves not to be distracted by problems discovered during a cycle.
- It's unclear what makes a concern proposal a good one

###