Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Last updated: 2024-11-21 22:06:59.223703 File source: link on GitLab
At NuNet, we’ve adopted the following ceremonies and developed automations to help us monitor essential resources and prioritize dependent tasks, so we can complete milestones as efficiently as possible:
Critical Chain Daily Meetings: These meetings are held daily to monitor critical chain progress, ensuring projects/milestones stay on track. Mandatory attendance for the milestone technical owner and individuals directly or indirectly involved in critical chain issues. Optional for other developers unless their attendance is directly requested by a team member on a critical chain AND/OR in case of not providing an async update in a WIP GitLab issue.
Weekly Tech All-Hands: A weekly obligatory meeting for all engineering team members aimed at providing clarity on broader context and tech-related updates.
Ad-hoc Sync Meetings: Scheduled sessions to discuss issues in detail, identify blockers, and set the course for resolution.
Automatic Processes: Implementing automation to update the Kanban board and post messages to Slack channels regarding updates related to Critical Chain Project Management (CCPM) and Kanban.
Definition: Daily meeting to discuss the critical chain of a milestone with a locked project buffer (=defined scope of the milestone) as per CCPM methodology.
Purpose: Monitor progress along the critical chain to maintain project/milestone alignment and enable developers to streamline technical collaboration and move fast with the issues on the critical chain (see the section at the end of this document about how Drum Buffer Rope (DBR) methodology works - drum buffer roll).
Duration: 15-to-30 minutes
Attendance: Mandatory attendance for the milestone technical owner and individuals directly or indirectly involved in critical chain issues (see below). Optional for other developers unless their attendance is directly requested by a team member on a critical chain AND/OR in case of not providing an async update in a WIP GitLab issue.
An automatic message is posted in the #status-update-<milestone> Slack channel each day, listing the critical chain work packages and the developers associated with them (as shown in the picture below).
Developers with direct involvement in the critical chain can request attendance from others indirectly involved by sending a message in the #status-update-<milestone> Slack channel.
If multiple milestones have locked project buffers, separate meetings will be held for each milestone. In other words, if a developer is on a critical chain in both milestones with locked project buffers, they will be expected to attend two daily meetings.
Definition: One meeting per week with the whole team to update about all milestones.
Purpose: Provide comprehensive clarity on the broader context, ensuring that the development team understands the overarching scope of NuNet projects.
Duration: 30 minutes
Attendance: Obligatory attendance for all tech team members.
Responsibility: The milestone owner is responsible for updates. The owner can choose to share the word with others to give a better view of the update if needed.
Create a summary written record of those meetings, and post it in the #status-update Slack channel that is used to general updates about the milestones.
Send the updated portfolio fever chart every week to the #status-update Slack channel.
Definition: Periodical synchronization meetings according to the needs.
Purpose: Provide an opportunity for everyone to update and discuss their issues. Also important to highlight blockers and set the course.
Suggested duration: 30 minutes to one hour
Responsibility: Responsibility to create and manage these meetings is up to the team leads. Each team lead can schedule it from every day to once a week depending on the project and team’s needs.
The team lead can also schedule more than one meeting, splitting the team, according to the topics being discussed.
The team leads (Kabir, Dagim, Janaina) can also schedule meetings with people from different teams.
In summary, the idea is to have ad hoc meetings according to the needs at the moment.
The team leads need to make a clear and shared agenda for these sync meetings. If there is nothing on the agenda 1-day prior to the scheduled meeting, just skip it.
In addition to these synchronization meetings, asynchronous collaboration via GitLab issues, research blogs, and documentation is essential due to our distributed context, open source projects, community participation, and multiple time zones.
Weekly company-wide All-hands: A 30-minute meeting once a week to share general updates with the entire NuNet team.
Technical discussions: One hour meeting dedicated to discussing specific topics that are important to the development team. Once a topic is defined, team participation will be suggested so individuals can determine whether their attendance is necessary.
Retrospective: These sessions will be scheduled on demand to discuss the development process with all the development team.
Kick-off meetings: Held to start a new project following the CCPM methodology.
Mission control: Conducted to address critical issues urgently.
Code review sessions: These sessions will be scheduled on demand to ensure code quality and consistency while promoting team collaboration and knowledge sharing.
Technical management board consists of Kabir, Dagim, Janaina and Vyzo. The goal of this board is to agree on high-level architectural concepts and align communication to the team. Concrete concerns/aspects to take into account and solve by this board:
Kabir is responsible for the high-level conceptual architecture of the platform and the process of translating the concepts (actor model, graph traversals, etc.) into specifications that can be implemented by the team.
Vyzo is responsible for translating high-level requirements and architectural principles into implementable technical designs and prototypes to validate architectural decisions and work with Dagim and the development team to ensure prototypes are scalable and can be transitioned into full production systems.
Dagim is responsible for the coordination of low-level development and code refactoring work, communicating with developers, etc. For that, high-level conceptual architecture has to be aligned with the low-level tech possibilities and constraints.
Janaina is responsible for the project management process, task and issue alignments, milestone designs, etc., and thus often needs to relate high-level architectural concepts and decisions with everyday tasks and issues on a lower level.
Meetings:
Tech board alignment: Weekly architecture alignment call 30-60 minutes for in-depth discussion of the architectural aspects to be implemented.
Daily alignment call: 15 minutes for:
Identifying aspects that need to be aligned and communicated to the team;
Distributing technical leads to the respective priorities.
Last updated: 2024-11-21 22:06:58.733122 File source:
This document outlines the project management and technical development processes at NuNet, engineering meetings and ceremonies, and the rules of engagement for the Engineering Team Members. Contributors have comment access, and team members are invited to submit suggestions via merge requests to this file, with @janainasenna indicated as the reviewer.
Last updated: 2024-11-21 22:06:59.512323 File source:
Drum: The drum is the constraint, which sets the pace for the entire system, much like a drumbeat. In a software development setting, this might be a particular stage in the workflow that is the slowest or has the least capacity.
Buffer: This is a time buffer placed before the constraint to ensure it is always fed with work and never starved. This helps to accommodate variability and keep the constraint working continuously. In software terms, it could mean prioritizing tasks so that the development team (the constraint) always has a backlog of ready work.
Rope: This is the mechanism that controls the release of new work into the system. The rope ensures that work is introduced at a rate that the constraint can handle, preventing excessive work-in-progress (WIP) that can lead to bottlenecks and delays.
sDBR is just normal DBR without a constraint buffer and has only a project buffer, as in our case. The market / release plans are considered the constraint and the drum is set to meet all the due dates. When you have a market constraint, you need to explicit that constraint by making sure you are on time to all customers.
In sDBR, the drum is the due date. Therefore there is no need to sequence jobs at the constraint or the ‘would be’ capacity constrained resource (CCR) since the constraint is the market. Raw materials (tasks / work to be done) are released to the team on the task due date (scheduled in the gantt chart) minus the project buffer. Releasing the right jobs in the right order is critical. Therefore the most important thing is to set priorities for jobs / tasks.
DBR is a ‘pull’ system. When constraint finishes a task, another task is released into the system (from the backlog). Kanban is a ‘don’t push’ system - if the Kanban board is full we do not push more into the WIP / doing. In DBR, the buffer is time; In Kanban, the buffer is space.
Kanban's ‘don’t push’ system aligns well with the rope aspect of DBR, controlling WIP by only pulling new work when the current work is completed. This reduces the risk of overburdening the system and helps maintain a smooth workflow. DBR adds an extra layer by focusing on the constraint and ensuring it's always productive.
Project management page for the milestone: https://docs.nunet.io/project-management-portal/device-management-service-version-0-5-x
All About Lean provides an in-depth look at the DBR method and compares it with other methodologies like Kanban, discussing its advantages and potential drawbacks: All About Lean - A Critical Look at Goldratt's Drum-Buffer-Rope Method (AllAboutLean.com).
Velocity Scheduling System offers a comprehensive summary of DBR, including simplified versions and practical applications in scheduling: Velocity Scheduling System - Drum Buffer Rope Summary (Velocity Scheduling System).
Smartsheet discusses how DBR can be applied within Agile and Kanban frameworks, providing insights into its implementation in software development: Smartsheet - All About Kanban Software Development (Smartsheet).
Last updated: 2024-11-21 22:06:59.760929 File source:
This documentation provides an overview of the processes, procedures, and frameworks used at NuNet to enhance the development workflow.
Useful documentation related to the development process:
NuNet development team process is based on Kanban, a visual project management methodology aimed at optimizing workflow efficiency and flexibility. Its primary objectives include visualizing work to enhance transparency, limiting work in progress (WIP) to prevent bottlenecks, and focusing on continuous delivery and improvement. The issues are visible on and we move them through stages: backlog, doing, review and done. If an issue has a blocker, we put it on stage on hold to make it visible allowing the team to clearly understand why progress on certain issues has stalled and what is required to move them forward.
An automatic message (as shown in the picture below) is posted in the #status-update Slack channel each day, listing:
team members without assigned issues;
issues with one day left;
issues with no assignee;
issues with no weight (the weight represents the estimated days to finish the issue).
An automatic script scheduled to run once daily at 23h UTC from Monday to Friday decreases the expectation days (weight) by one for issues with the kb::doing label except if:
the issue has only one day left;
the team member is marked as AFK (away from keyboard) in internal NuNet Calendar.
Developers review the message posted in the #status-update Slack channel before the critical chain daily meeting. If their name is mentioned, it indicates that they need to take action, such as assigning an issue to themselves, setting the weight for an issue, moving an issue to review, and so forth.
If developers need to change the weight of their issues, they should do so directly in GitLab, also adding a comment explaining the motivation. If the issue belongs to a work package in the critical chain, the work package owner should be copied on the comment, as this will impact the project buffer. The same process applies when creating new issues.
Once a week, the work package owner should review the work package weight that represents the Estimated Time To Completion (ETTC), which is automatically updated by the pipeline at 23h UTC based on all open issues within the work package.
During the review, the work package owner should:
Link any new issues to the work package if they are not already linked.
Analyze whether new issues need to be created and create them as necessary.
Manually run the pipeline if any updates are made that may impact the ETTC.
Evaluate if the ETTC represents the time required to complete the work package and inform the milestone owner.
Last updated: 2024-11-21 22:06:58.976296 File source:
At NuNet, we’ve adopted Critical Chain Project Management (CCPM), a that emphasizes resource availability and to ensure timely and efficient project completion. The next sections give an overview of the key concepts of CCPM applied in NuNet.
The critical chain is the longest sequence of dependent tasks in a project, considering both task dependencies and resource constraints. Unlike the critical path, which only considers task dependencies, the critical chain also accounts for the availability of resources required to perform tasks, often making it longer than the critical path. In NuNet, a is used to monitor each project. Tasks highlighted in red represent the critical chain and determine the overall project duration. Non-critical tasks are represented in blue.
In traditional methods, task durations are usually estimated conservatively to include safety margins. Critical Chain Project Management (CCPM), however, uses optimistic estimates and places safety margins into buffers instead. The project buffer is a time buffer placed at the end of the critical chain to protect the project completion date from delays. A feeding buffer is placed where non-critical tasks feed into the critical chain, protecting the critical chain from delays in these feeding paths. The health of the project is monitored by observing buffer consumption. If buffers are being consumed faster than planned, it signals potential delays, allowing project managers to take corrective actions before the project is endangered.
CCPM focuses on ensuring that resources are not over-committed and are available when required for critical tasks. The approach encourages multi-tasking reduction, ensuring that resources can concentrate on one task at a time for better efficiency.
In CCPM, a is a visual tool used to monitor the overall health of multiple projects within a portfolio. It tracks the progress of each project by comparing buffer consumption (the time or resources used up compared to what was allocated) against project completion percentage. The chart typically uses a color-coded system of green, yellow, and red zones to indicate whether a project is on track, at risk, or in critical condition respectively. By visualizing the status of all projects in a single chart, the portfolio fever chart helps managers quickly identify which projects need attention and prioritize resources accordingly, ensuring that the entire portfolio remains on course for successful completion.
Last updated: 2024-11-21 22:07:00.056688 File source:
Considering our remote setup and the Open Source nature of our project, written communication is like the lifeblood or oxygen of our globally distributed team. Without it, we can’t function efficiently, let alone integrate a network of global Open Source contributors. Without strong and asynchronous communication, we will struggle with duplicate work, dependencies, conflicts, and misunderstandings.
To ensure our success, every engineering team member, whether on the critical team or not, should adhere to a set of core principles. These principles are designed to promote effective communication, streamline workflows, and maintain high-quality standards across our distributed team. Please find the aforementioned principles in the following subpages.
We expect mandatory attendance for the milestone technical owner and individuals directly or indirectly involved in critical chain issues. It is optional for other developers unless their attendance is directly requested by a team member on a critical chain AND/OR in case of not providing an async update in a WIP GitLab issue.
Why is this important? Critical chain issues are crucial as they essentially make or break the milestone. Sharing daily progress and blockers with the team and technical leadership is vital. Therefore, if you’re working on a critical chain issue directly or indirectly, you must attend a synchronous daily meeting.
All tech team members need to update their work-in-progress GitLab issues with a comment every day. If no comments are submitted, it’s assumed that no progress has been made, and your presence in the daily meeting is required, regardless of whether the issue is on the critical chain or not.
Why is this important? Imagine NuNet with 100 software engineers and twice as many OS community developers. You find an interesting issue that someone else has been working on, but there’s no information on what’s been done or what needs to be completed. You end up reverse engineering their code. It would be much more efficient if they had left an update with a to-do list in the comments. Remember, communication fuels us forward more efficiently.
Considering the Open Source nature of our project, NuNet needs GitLab as the main communication platform for all tech team members, both internal and external (OS developers).
Why is it important? Otherwise, communication, the oxygen fueling NuNet Platform success, gets trapped and siloed. Avoid technical discussions in Slack or DMs to prevent siloed communication. This ensures transparency and accessibility for everyone, especially for the external Open Source Contributors.
Everyone on the team should always have an issue assigned to them. It’s each team member’s responsibility to assign themselves an issue. If you don’t have an issue or have finished one, pick a new one from the backlog and inform Janaina via comment. If more technical context is required, reach out to Kabir, Dagim, or Janaina via GitLab comments for increased visibility.
Why is this important? Picture the development process with numerous OS contributors. As a milestone or WP owner, you’re leading Mainnet integration with Cardano. Imagine 20 developers finishing their issues simultaneously and asking you what to work on next. Instead of reviewing the contributions, you spend your morning assigning issues top-down. You don’t feel like going on holidays because you’re constantly worried the backlog won’t move forward with the same velocity. Not the nicest feeling, is it?
Now, imagine the same scenario but with these 20 developers self-assigning issues from the backlog based on set priorities, their experience levels, and interests, and only reaching out for technical questions if needed. Now ask yourself: which option sounds more efficient and less frustrating? Which of these 20 developers would you prefer to work with? In which group do you see yourself thriving as a developer?
We aim for approximately 90% test coverage to ensure everything is tested and to facilitate quicker merges. Every MR must include unit tests for new functionalities or changes to existing functionalities. Otherwise, the MR will be rejected by default and pushed back to the developer to add unit tests.
There are five core principles we expect all engineering team members to follow for efficient coordination in our remote setup:
Attend daily meetings if you’re on the critical chain.
Submit daily technical progress updates on issues.
Use GitLab for all communication, updates, comments, and technical discussions.
Be proactive and self-assign issues based on the broader priorities in the milestone.
Contribute to our code quality by including unit tests in every MR.
And remember: I will communicate as much as possible because it’s the oxygen of a globally distributed company.
Last but not least, if you have any better ideas on how to ensure coordination and efficiency in our distributed setup and want to add or amend the dev process at NuNet, please be vocal and contribute! While we believe the five core principles above help us to be an efficient team, we’re open to continuous improvement and learning how to build things better. Submit your suggestions via merge requests to this file, indicating @janainasenna as reviewer.
Note: Refer to the to better understand some terms used in this section.
Last updated: 2024-11-21 22:07:00.306874 File source: link on GitLab
To scale MR reviews, a peer code review system is adopted. When opening an MR, the developer should ideally choose a peer reviewer based on:
familiarity with the requirements;
knowledge of the module or code;
relevant skills;
prior experience.
It is also possible to take advantage of different time zones by assigning default reviewers in regions like APAC, EMEA, and Brazil to ensure real-time coordination and faster development. This approach improves review quality, fosters mentoring relationships among developers, and boosts long-term development velocity.
When opening an MR, the creator must tag it with one of the following labels:
domain::core platform
domain::platform
domain::application
domain::documentation
domain::infrastructure
domain::testing
Additionally, use the Priority::High tag if the MR is blocking other developers.
If the code is not ready for review, it must be marked as Draft.
Peers must review MRs with three main focuses:
Functionality: Verify if the code meets the functional requirements outlined in the issue.
Code quality: Review for adherence to established standards, code quality, bugs, security vulnerabilities, duplication, performance, and maintainability.
Testing: Ensure tests for new functionalities are created with good coverage and quality. For bug fixes, ensure the unit test is updated to specifically cover the condition that was fixed.
In addition to peer reviews, some MRs will also undergo an architectural or conceptual review. This review can be requested by either the MR creator or the peer reviewer.
The approval process differs depending on the target branch:
An MR opened to the main branch requires approval from a reviewer on the development team.
An MR opened to a release branch requires approval from a reviewer and a member of the security team.
Each repository has an ultimate responsible for merging code, but this person will not conduct in-depth reviews of all MRs. Peer reviews will be managed by other developers, with the responsible person doing a final check before merging. Going forward, the responsible should only be assigned as a reviewer if it is expected an actively involvement in the review.
Mote: See this documentation for details related to the branching strategy.
The peer reviewer must analyze the status of each pipeline stage and, if approving an MR with warnings or failures in any stage, provide an explanation in a comment. For example, the reviewer can create a new issue to address the problem and link it in the comment.
Similarly, if a comment remains unresolved in the MR, a follow-up issue can be created, linked in the comment, and the MR can still be approved.
The reviewer must comment on the MR, even if it is just a "Looks Good To Me" (LGTM), to indicate that the changes have been reviewed and there are no objections or further comments.
The MR creator must promptly address any comments until the reviewer approves or closes the MR.
