Iteration 0 Fundamentals
Team Mobilization
- Align on team norms and working agreements.
- Orient the team on roles and responsibilities.
- Agree on working cadences.
- Align on vision, scope, and goals for your specific team.
Working Agreements
As a PMO organization, we assemble micro teams on a consistent basis, with both internal GitLab and external GitLab partners.
When a delivery team comes together for a new project, a short ritual is held to agree to working norms; ultimately fostering a positive working relationship that translates to successful project delivery and enhanced interpersonal, working relationships.
This falls in line with several of our GitLab values and promotes Psychological Safety. The following link documents GitLab’s view of Psychological Safety.
Why working agreements?
Working agreements install ownership and agency, contributing to:
- stronger team cohesion and collaboration.
- increased productivity.
- early identification of project issues through regular communication.
- better communication and transparency.
- better work-life balance.
Project team consists of Professional Services Engineers, Technical Architects, and Program/Project Managers. Making the implicit explicit promotes a connected experience among team members and builds psychological safety.
Working agreements are NOT be a tool to gauge performance. They are ONLY intended to help the team work together.
Example Working Agreements
- We assume positive intent and acknowledge that throughout the entire project, each team member will do the best they can, given their experience level and perspective.
- We agree to make our work transparent to our colleagues and customers using GitLab Collaboration Project and collaboration tools.
- Mark yourself as “away” when not available, with expected return time.
- We will update issue status and time tracking daily.
- Core collaboration hours: 10:00 AM - 4:00 PM EST; no expectation of response outside working hours.
- We acknowledge GitLab’s preference for Asynchronous Communication. This is NOT a directive to define working hours, only an FYI to your teammates.
- We honor our commitments to our teammates and to our customers. If we commit to doing something, we follow through within expected timelines.
- We understand that working agreements are not authoritative, but fluid and open to change when necessary.
Engagement Planning
Starts at the EM>PS Delivery Transition and continues through the Stakeholder Planning Meeting & Customer Kickoff. Throughout Iteration 0, work to continuously…
- Refine and prioritize project backlog (user stories and acceptance criteria - two iterations).
- Slot issues into an initial release plan (inital planning & design).
- Define Definition of Done (DoD) and, if needed, the Definition of Ready (DoR).
- Understand constraints, impediments and risks for your specific team.
Setup of Technical and Business Foundation
- Identify key risks and dependencies based on initial backlog and tools.
- Design data and business architectures and CI/CD pipeline to support desired functionality.
- Define and implement engineering best practices to enable DevSecOps.
Prep for Production Readiness
- Identify key risks and dependencies based on initial backlog and tools.
- Design data and business architectures and CI/CD pipeline to support desired functionality.
89cf89ed)
