Platform Engineering Team
This is a living document intended to capture information about how the Platform Engineering Team operates. This includes the team mission, team culture as well as details about communication channels, and workflows.
Mission
The ICS Platform Engineering team's core mission is to provide an environment for members of the medical school community to do data science and informatics work. There are many teams spread across the university that have a need to perform tasks that require specific tooling such as a Python environment and access to sensitive data. Our team provides a platform to provide these tools via the WUSM Data Lake.
The team also provides support in creating and managing resources to facilitate other types of solution development work. For example, many research projects require 3rd party applications to be deployed within the Wash U environment. Our team provides support in creating the needed infrastructure and deployment process to reduce the burden on the study team.
Our primary customers are the Data Warehousing and Data Brokerage teams within I2DB. We support those teams by managing the WUSM Data Lake infrastructure and any additional infrastructure the teams need to complete their work. Other teams will also request our assistance in creating infrastructure and/or services to facilitate their projects and initiatives.
Collaboration
- Emphasize teamwork and collaboration across roles and departments.
- Encourage sharing of knowledge, experiences, and ideas among team members.
- Support each other and work together towards shared goals and objectives.
- Be open to constructive feedback and suggestions.
- Raise concerns or request assistance when feeling overwhelmed to prevent burnout and ensure team productivity.
Communication
- Regular and effective communication is essential to our success.
- Use appropriate communication channels to ensure appropriate stakeholders are informed and involved.
- I2DB Platform Engineering Group Chat
- Break out groups chats / teams calls for focused discussion
- Email for communication outside of the team, or when the thread should be documented
- High importance email, direct messages, and tagged messages in Teams are considered high priority and should be acknowledged ASAP.
- Email and teams messages within a group chat are considered normal priority and should be reviewed as time allows.
- OHIDS standard policy is to respond to customer emails/messages/requests within 24 business hours.
- Responding may be an acknowledgement of the message, and an ETA of when you can respond with additional information/assistance.
Agile Practices
The following sections provide details on various aspects of the team's agile practices. As a general rule, we are doing the least amount of effort to make the process work. We will try to not put more effort into process than value we will receive from it. It may be that we must take on more process as we grow, but it is important that we keep "red tape" and "busy work" to a minimum as we build our foundation.
With that in mind we have reduced the traditional number of agile ceremonies, and encourage team members to only add necessary details to their work items. These practices exist to make our lives easier and more efficient. If the process becomes a burden, we need to refactor.
Meetings
In order to respect the time of our team members, meetings should be as efficient as possible and held only when necessary. With this in mind, we have consolidated the typical Agile ceremonies into just the daily "stand-up" and a single meeting each sprint to handle backlog refinement, sprint planning, and retrospective.
Below are the common types of meetings our team will engage in and their purpose.
- Daily Sync Meetings
- 15 minute meeting to sync with team
- What are you working on?
- What are your roadblocks?
- Any discussion beyond this should move to breakout meeting
- Sprint Planning Meetings
- 1-2 hour meeting at the end of each sprint
- Focused on:
- Cleaning up backlog items
- Breaking down existing items
- Creating missing items
- Prioritizing user stories
- Adding items to next sprint
- Discuss any improvements to the process
- Breakout Meetings
- Ad-hoc meetings used to deep dive into roadblocks/questions that surface during sync meetings
- Should be minimum reasonable participants
- Should be 15 minutes or less
- Longer meetings should be scheduled as needed
- Working Sessions
- Ad-hoc or scheduled meetings with two or more team members that are driven by assigned work or requesting assistance
- These are the primary collaborative meetings for the team
- These can be longer meetings to allow time for the team to work through challenges, create documentation, and/or train other team members
Ticket Management
Team leads will manage Epics and Features within the backlog. New projects will have corresponding Epics or Features created. Epics will be loosely mapped to Projects within Tracking Time to provide guidance on how to log your time. Any questions regarding billing can be addressed with team leads as needed.
Each team member is responsible for managing their user stories and tasks in the backlog. If you need to create a user story that does not have an appropriate feature that can be assigned, please reach out to a team lead for assistance. For ease of use, a prefix should be added to the title of a user story to indicate what project it relates to. For example, a user story to onboard a team to Databricks would have a title like "DL: Onboard Team X". The prefix should be identifiable to other members of the team. This improves readability and context during Sync meetings.
The amount of detail that is added to a ticket is determined by the ticket owner, unless specifically requested by other team members. This means, each person should determine how best to use the work item. If it is helpful for you to add details, then please do. If it is unnecessary duplication, please do not feel that you must include it there as well. The primary goal of the ticket is to keep the team in sync and allow the project manager to plan the work and assist in coordinating efforts.
One important caveat is, the information required to complete the work must be documented somewhere that the rest of the team can easily access and make use of. This will be discussed further in the a later section, but it is an important callout that should be noted here.
Team members are encouraged to managed the priority of their own tickets as needed. Sprint planning provides an opportunity too review priorities as a team and schedule work accordingly.
Unplanned Work
- Work that was not added to the current sprint during sprint planning, but needs to be completed before the end of the current sprint.
- This should be avoided at all costs!
- When necessary, these work items should be added to the current sprint, but not assigned to a team member when they are created.
- During the next Sync meeting, the item will be discussed and assigned as needed.
Documentation
Documentation is one of our team's most valuable assets. It is the responsibility of all team members to assist in maintaining documentation in projects they are contributing to. We also encourage team members to actively contribute to all documentation by making edits, improvements, or additions.
The documentation for the team will be managed within the ics-documentation repository. Information on documentation structure and formatting can be found in this section: Documentation Structure.
While we build out the foundation of our documentation, we will not enforce strict pull request/review processes when contributing. However, this may change and adopt a more traditional lifecycle that includes pull requests before merging updates.
Continuous Learning
- Foster a culture of continuous learning and professional growth.
- Encourage team members to pursue relevant learning opportunities, training, and certifications.
- Encourage team members to get involved in projects that interest them to acquire new skills.
- Share useful resources, articles, and books to expand collective expertise.
Respect and Professionalism
- Treat all team members with respect, regardless of their roles or backgrounds.
- Encourage a supportive and inclusive environment where everyone feels valued and heard.
- Avoid blame and focus on problem-solving when issues arise.
- Maintain professionalism in all interactions, even during disagreements or conflicts.
Transparency
- Foster an environment of trust by being open and transparent with information and progress updates.
- Share relevant information about project status, challenges, and achievements with the team.
- Avoid hidden agendas or withholding information that may impact the team's ability to deliver effectively.