Agile to GitLab Terminology Mapping
Learn about how Agile terms map to GitLab terms.
Professional Services Delivery Methodology
Learn the processes and methodology that GitLab Professional Services uses to help ensure Customer Success.
What is the Professional Services Delivery Methodology (PSDM)
The Professional Services Delivery Methodology (PSDM) is the guiding light for Program and Project Delivery within GitLab. The goal is to ensure the PS Delivery team operates within a predictable time slice against the Project scope while ensuring we’re focused on Customer Success. This is done through GitLab.com as the SSOT, label guidelines for managing and reporting against progress, risk, iterations needed against our processes and enablement material, and fundamental Agile best practices.
Iteration 0
Iteration 0 includes the initial discovery and planning between the GitLab & Customer Project Team(s). This includes:
- EM>PS Delivery Transition
- Stakeholder Planning
- Customer Kickoff
- Discovery sessions with the Customer
To prepare and deliver Iteration 0, the PM will work with the GitLab Project team to review the timeline against the agreed upon scope and dependencies. This ensures we are gathering the right information and understanding the potential risks. Allowing us to show up to Iteration 0 more aligned with our Customers and prepared to deliver against a more predictable schedule.
Proper Iteration 0 preparedness allows us to address risk early and instills confidence with our Customers.
Managing a Project in GitLab
GitLab will be used as a project management and collaboration platform. We will be using the following features/terminology in GitLab defined below.
Please reference the following tips for GitLab best practices when navigating GitLab.
How to initially configure GitLab as a Project Management tool can be found here.
Project Management Mapping in GitLab
| PM Term | GitLab Definition |
|---|---|
| Group | This is the landing page for Customer the project. The single source of truth of Project Governance. |
| Projects | If an engagement has more than one Workstream (or SOW), we will track against more than one Project. CO activities will be tracked against the original project (SOW). |
| Boards | Typically organized by labels or scoped labels to keep the team on track together. Sometimes the GitLab/Customer team works to track against multiple Boards over Projects. |
| Epics | Generally from Workstreams or “Activities” from the SOW. |
| Issues | These are the atomic units of work that roll into the Epic. |
| Iterations | Time-boxed (generally) two-week events, that are reviewed during the Agile ceremonies. |
| Milestones | How we can track against the Project Phase |
| Labels | We use these in a variety of ways, but the most important ones are:
|
| Weight | Size or level of effort of the issue. See Good Estimation Techniques for assigning weight |
Reference here for additional clarity around mapping Agile terminology to GitLab.
Label Guidelines
Labels are the best way to generate reports around our Projects and sort according to the Project teams’ needs. The team is free to make labels as they see fit for Project reporting, but there are also current guidelines around label generation for internal use.
Currently, our CP (Customer Project) automation includes the following labels:
- SOW-# or PO# - helps the GitLab team search for Projects within the Professional service Group
- PM name - helps the GitLab team sort by PM name
- PSD workflow (for issue board management)
Labels used for Internal retro & RAID tracking/reporting can be found in “Reporting throughout the Iteration” below.
Iteration Scheduling
The iteration schedule and cadence is first introduced in Iteration 0, and is part of the Communication Plan that lives within the GitLab Customer Project (Group). It is important the Customer agrees to an Iteration Schedule as an output of the Customer Kickoff, but should be introduced & collaborated with the Customer as part of our Stakeholder Planning meeting.
There are five components within an Iteration schedule:
- Iteration Planning
- Iteration Review
- Daily Standup
- Backlog Refinement
- Retrospective
Iteration Planning & Review
The Program Manager / Project Manager provides strategy and direction for the project, which means he/she is responsible for providing the vision, product roadmap, release goals, and iteration goal. The Program Manager / Project Manager is expected to insert, re-prioritize, refine, or delete items from the product backlog; this can happen any time until the iteration scope is defined and committed to by the development team.
Please reference Backlog Management for guidance around estimation, backlog grooming, and other Iteration Planning preparation tips.
Reporting within the Iteration Schedule and Project
Who Updates What?
While the PM is expected to prepare for the various ceremonies, report on status, and work within Issues, the GitLab PSE (Professional Services Engineer) & TA (Technical Architect), along with the team members on the Customer side, are also expected to work within the planned issues (tasks) within the Project board.
Working asynchronously & remotely can be challenging. Ensuring the DRI within the issue is actively contributing to is crucial to the project’s velocity. It’s the best way the PM can protect the technical teams from distractions as well as make sure there is an effective status roll-up.
RAID & Internal/Customer Retrospective
The RAID, Internal Retrospective, and Customer Retrospective not only assist with the progression of a Project, but these records act as a mechanism to feed back into our Business Development, Customer Success tracking, and Team celebrations. Please reference here for more guidelines on how to manage these reports once a Project begins.
The Customer Retrospective guidelines can be found here.
Guidelines for PSDM
Applying the suggested PSDM with a full Iteration schedule is needed only when the Project exceeds 5 Iterations or when the engagement plans to exceed two months.
Please review the archetype definitions around what a “large” Customer looks like.
Please use the below as a guide, when planning for Iteration 0.
| Projects > 5 Iterations (~9 weeks, incl. iteration 0) | Projects < 5 Iterations | |
|---|---|---|
| Managed in GitLab as SSOT | x | x |
| Iteration 0 | x | x |
| Internal Retrospective tracking | x | x |
| RAID tracking | x | x |
| Backlog Refinement | x | Only as needed |
| Daily Standup | x (determined cadence with customer team) | Only if needed |
| Communication Plan | x | x |
| Iteration Planning | x | Only as needed |
| Iteration Review (status report) | x | Weekly Status at the minimum |
| In-project Retrospectives | x | Only if needed |
Archetype Definition
Learn about the key charateristics to classify the different Customer archetypes.
Backlog Management
Learn about scaling considerations when working with a Customer.
Definition of Done
Learn about the PS definition of done.
Definition of Ready
Learn about the definition of ready.
Delivery Checklists
Instructor Pre-Training and Post-Training Checklists
Discovery
Learn about the best practices of performing discovery sessions with a Customer.
GitLab Best Practices
Learn about GitLab best practices for engagements.
Good Estimation Techniques
Learn about how to better estimate development efforts.
Good User Stories
Learn how to write good user stories.
How to Use CP Automation to Manage Engagements
Learn about the CP process.
Iteration 0
Learn about the first step of a GitLab PS engagement with a customer.
Iteration 0 Fundamentals
Learn about the core pieces to iteration 0 of a GitLab PS engagement with a customer.
Iteration Planning per Service Offering
Learn about PS Transformational planning.
Iteration Scheduling
Learn about how to schedule iterations in a PS engagement.
Managing Risk, Project Wins, and Business Development
Learn about managing reports around project wins, Business Development Items, and Customer Stories.
Retrospectives
Learn about how to conduct retrospectives.
Last modified November 14, 2024: Fix broken external links (
ac0e3d5e)
