-
Notifications
You must be signed in to change notification settings - Fork 23
Management Approach
This page outlines the management strategies and approaches used to govern the develop of the software and management of the ecosystem. Contributors are expected to adhere to the guidelines established in these documents to ensure effective and efficient management of the software and ecosystem.
Projects within the Open FinAL ecosystem rely on Agile management principles from the Scrum framework for teamwork and the scaled agile framework (SAFe) for cross-team collaboration. The ecosystem is also supported by other common management practices.
The Scrum framework provides a team-level management approach with specific roles and "rituals" (i.e., meetings). The core elements we adopt from the Scrum framework include:
- Appointing a Product Owner for each team
- Appointing a Scrum Master for each team
- Appointing a Technical Mentor for each team (useful for mentorship in classroom software projects)
- Managing a Product Backlog and Sprint Backlog
- Holding Sprint Planning meetings bi-weekly (2-week sprints)
- Holding Daily Scrums as appropriate for context (i.e., on project days in class projects)
- Sprint Review Meetings are replaced by class-level System Demos
- Holding Sprint Retrospective meetings to identify areas for continuous improvement
For a review of the basics of team management using Scrum, visit Scrum.org or view the Scrum Guide.
The SAFe framework provides a multi-team approach to Agile management. SAFe also consists of a series of specific roles, but with more governance elements. The core elements we adopt from SAFe include:
- Appointing a Product Manager (PM) (one per class or for every 50-100 people) to work with Product Owners
- Appointing a Release Train Engineer (RTE) to work with the Product Owner and Scrum Masters
- Appointing a Systems Architect (SA) to work with the PM, RTE, and team technical mentors
- Holding System Demos (i.e., joint Sprint Review meetings) with all teams and key stakeholders
- Holding leadership retrospectives with PM, RTE, SA, SMs, and POs to ensure continuous improvement of class operations
- Developing a product vision and strategic roadmaps to guide long-term development priorities
- Planning increments (i.e., one semester) for features/enablers/stories (i.e., increment planning)
- Maintaining cadence across teams through shared scheduling of Scrum rituals
- Synchronizing planning and work across teams to facilitate cross-team support
- Utilizing communities of practice for deeper collaboration across teams
For a review of the basics of SAFe, please visit the interactive framework in SAFe Studio.
A RACI matrix (Responsible, Accountable, Consulted, Informed) describes how different activities should be managed. Please download and review the RACI Matrix for class projects carefully to understand your role.
This document can be amended with approval of the faculty advisor, but members should follow the guidance in the matrix.
The following Agile ceremonies should be held throughout the semester.
Before a Sprint Planning Meeting the Product Owner and Scrum Master should:
- Meet to break down epics into detailed tasks with clear acceptance criteria for the upcoming sprint.
- The Scrum Master will enter the tasks into the project management software backlog.
- The Product Owner will prioritize the tasks in the backlog.
The Scrum Master leads the Sprint Planning Meeting with the team at the beginning of each sprint. The following occurs during the Spring Planning Meeting:
- The Scrum Master does the following for each task in the backlog:
- Reviews the task with the team a verifies that the task and acceptance criteria are clear and that no acceptance criteria are missing
- Engages the team in planning poker or a similar estimation technique to identify how complex the task is
- Assigns a person or pair to complete the task
- The team verifies that the assigned work appears completable before the sprint deadline
- The Scrum Master updates the task assignments in the project management software
The Scrum Master should lead a daily scrum meeting on all project workdays, except for days when holding a Sprint Planning Meeting. This should be a short meeting of less than 10 minutes. Follow the Scrum Meeting Minutes Template to help you run and document these meetings.
At the end of each sprint, the team will hold a System Demo meeting with the faculty advisor and any other stakeholders that should be in attendance. Members from all teams should be present.
The Release Train Engineer runs the Systems Demo meeting. The following occurs during the meeting:
- The Product Manager provides updates, if any, on product vision and changes in product feature priorities.
- The Systems Architect provides updates, if any, on the architecture of the system.
- The Srum Masters take turns demoing the work their team completed during the sprint.
- During the meeting, the faculty advisor and stakeholders can ask questions and provide feedback to teams.
At the end of each sprint and after the System Demo, each team holds a Team Retrospective Meeting. The Scrum Master leads the retrospective meeting. Srcum Masters can use the Retrospective Meeting Minutes Template to help them run and document the meeting.
After each team completes their retrospective meeting, the Product Manager, Release Train Engineer, Systems Architect, and the Product Owners and Scrum Masters should meet for a Leadership Retrospective Meeting. The Release Train Engineer leads the leadership retrospective meeting. The meeting should focus on class-level concerns and cross-team collaboration. The Release Train Engineer can also use the Retrospective Meeting Minutes Template to help them run and document the meeting.
Scrum Masters and the Release Train Engineer manage the implementation of the suggested changes.
Please be sure to read through the Best Coding Practices document before you start collaborating.
As you use git and GitHub to manage your contributions, follow the guidelines outlined in the Git Practices document. Remember to pull from main regularly to avoid code conflicts.
To ensure smooth handoff and future maintenance, all teams are expected to document their feature contributions/edits as they design and code them. Documentation should follow the documentation format in the documentation template (TODO: link template). All documentation should be contained within the documentation folder (TODO: link to the documentation folder).