A Deep Dive into Trekkers Project Workflow
Our primary organizational goal at Trekkers is to develop software using the best industry practices we learn from workshops, lab assignments, and our project experiences. When building Trek, we aimed to adopt Agile values and principles effectively in our project workflow.
The CPSC 455 course, titled "Applied Industry Practices," emphasizes industry practices. However, being Agile is not about merely adopting the most popular industry practices but about embracing practices that support our principles and values. Simply following the most popular "Agile" practices doesn't make us an Agile development team. We strive to be more than just another shop that claims to be Agile.
Manifesto for Agile Software Development:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In our development journey, we have chosen to follow Agile principles because they align with our commitment to continuous improvement, collaboration, and delivering value to our users. Our adaptation of Scrum reflects our dedication to these principles, the Trekkers Code, and our desire to create an effective and efficient workflow that supports our project goals.
Our Version of Scrum
Our version of Scrum aims to be as Agile as possible while meeting all project requirements and learning objectives.
Weekly Sprint Schedule
Individual (non-Trekkers) Course Assignments and Deadlines are italicized
| Day | Schedule |
|---|---|
| Sunday | Start of Sprint Meeting @ 10:00 AM Bi-weekly Formal Scrum due @ 10:00 pm |
| Monday | Bi-Weekly Individual Assignments Due @ 10:00 PM |
| Tuesday | |
| Wednesday | |
| Thursday | Mid-Sprint Check-in Meeting @ 5:00 PM Planning for next sprint or WIP Progress presentation. |
| Friday | Bi-Weekly Individual Workshop Survey Due on 11:59 PM |
| Saturday | End of Sprint (Push @ 10:00 AM) Sprint Review: Read other members' scrum reports. |
- Our sprint begins on Sunday @ 10:00 AM and ends on Saturday @ 10:00 AM.
- During the Start of Sprint Meeting we review our scrum report (Sprint Review) on what we have accomplished in the past sprint, and formalize new sprint goals.
- During the Mid-Sprint Check-in Meeting (happens during Labs), we do a brief check-in on the progress of our sprints.
- Based on our progress, we do some planning for what we should do on the next sprint
- On weeks where there are Workshop Presentations, we do planning for presentations, writing documentations, etc.
- Every Saturday @ 10:00 AM is the End of Sprint. Everything should be pushed by then.
- By noon, every completed issues that have not been closed yet should be closed.
- By noon, everyone should complete a very brief scrum report. We use these weekly internal scrum reports for bi-weekly external (submittable) scrum reports.
Meeting Agenda Template
Our Scrum meetings are structured on agile principles of communication, interaction, and collaboration. We have structured a meeting agenda flexible template that lets us stay focused on reviewing sprints and internal demos, while letting us plan for our next sprint.
Our meeting agenda template exists as a GitHub issues template (screenshots below).
GitHub Issues for Project Management
We decided not to use GitHub Projects because we couldn't adjust the visibility settings of the project board. We wanted to create a collaborative environment where team members could actively update their progress without it being publicly visible to other classmates.
Instead, we are using GitHub Issues as our main platform for project management. Our belief is that with effective scrum meetings, the utilization of GitHub Issues can facilitate clear communication and tracking of tasks and promote Agility. Here's how we leverage GitHub Issues in our workflow:
Creating Issues
Mostly after each scrum meeting, every task, bug, or feature is logged as an issue. This ensures that all work items are tracked and nothing is missed. Issues are tagged with appropriate labels (e.g., frontend, backend, bug, documentation) to categorize and prioritize them effectively.
Assigning Issues
During the scrum meetings, each issue is assigned to a specific team member based on their expertise and current workload. We use GitHub's assignee feature to make sure responsibilities are clear.
Tracking Progress:
Issues are updated regularly with comments and status updates. We use Discord as our primary platform for communication, including discussions of issues. Our Discord consists of channels for each type of work (frontend, backend, documentation, etc). We associate branches with issues using GitHub's branch linking feature, which makes peer-review easier.
Sprint Planning and Closing Issues
At the start of each sprint, we create, review, and prioritize issues. High-priority tasks are marked with the "PRIORITY" tag. During the End of Sprint, we review all closed issues. We use the scrum meeting agenda (as an issue), where we link the closed issues for discussions.
Continuous Integration and Deployment
To ensure the quality and stability of our software, we have set up continuous integration and deployment (CI/CD) pipelines:
Automated Testing
Every push to the repository's "progress" branch triggers automated tests. This helps us catch issues early in the development cycle. We aim to maintain a high code coverage to ensure the robustness of our application.
Code Reviews
All code changes are submitted through pull requests (PRs). PRs must pass automated tests and be reviewed by at least one other team member before being merged. This practice helps us maintain code quality and fosters knowledge sharing within the team.
Continuous Deployment
Once a PR is approved and merged, our CI/CD pipeline automatically deploys the latest code to our private staging environment. We perform final checks in the staging environment before promoting changes to the released demo environment along with release notes published on our website.
Our Workflow is Evolving
By adhering to Agile principles and customizing our workflow to fit our team's needs, we strive to deliver high-quality software efficiently. Our structured yet flexible approach to Scrum, combined with the effective use of GitHub Issues and CI/CD pipelines, enables us to stay organized, collaborative, and adaptive. We continuously seek to improve our processes and deliver value through iterative development and frequent feedback during scrum meetings and workshop design reviews.
Our workflow is constantly evolving as we learn and adapt. We are committed to refining our practices, incorporating new insights, and staying responsive to the changing needs of our project and team. This continuous evolution helps us stay agile and ensures that we can meet our goals effectively.
We hope that our detailed project workflow provides insight into how we manage our development process and can serve as our own reference for our future development journeys.