- Created by Vidhyadharan-ext, Vaishna, last modified by Bongiorno-ext, Alix on Mar 26, 2025
Β
ALB Events
Overview
This page shows all the recurring events/meeting that occur within the ALB perimeter.
Team Manager Events
| Event Name | Frequency | Organizer | Participants | Agenda | Outcome |
|---|---|---|---|---|---|
| Core Weekly Stand-Up | Weekly (Monday) | Roscetti, Nicolas |
|
| |
| Product Roadmap Checkpoint | Weekly (Wednesday) |
|
| ||
| Tech Roadmap Checkpoint | Weekly (Tuesday) |
| |||
| Process Roadmap Checkpoint | Weekly (Thursday) |
| |||
| PM per domain - LB Review: OKR high level, future HL requirements prio | Quaterly (1 hr) |
| |||
PM per domain - LB Update: OKR high level, future HL requirements prio | Quaterly (25 min) | COLEGRAVE, Vincent (optional) |
|
|
|
| PM/POs with all domains - Update with all the stakeholders on what we are working on | Quaterly (1hr) |
|
|
| |
| Vincent Colegrave | Monthly | Vincent Colegrave |
|
|
|
| Core Team Retro on-demand | On-demand |
|
| ||
| PM & PO Sync | Weekly | ||||
| LB Brainstorm Product Strategy | Weekly | Roscetti, Nicolas | Brainstorm about new ideas, product features, benchmark and value creation |
| |
| LB POs Sync | Weekly | ||||
| LB PM & PA Sync | Weekly |
|
|
Other Specific events
| Event Name | Frequency | Organizer | Participants | Agenda | Outcome |
|---|---|---|---|---|---|
| PM & Data Scientists | Weekly | Squads | Roadmap update, roadblocks and meeting prep | One daily team sync so we all what everyone is doing and if they need any assistance or have any blockers they need resolving. | |
| PO & Data Scientists | Bi-weekly | Stakeholder meetings | To set a plan for the sprint on what the team will work out and the goal they will accomplish. | ||
| Demo Meeting | Bi-weekly | Squads | Demo what has been done to stakeholders | ||
Training | Bi-weekly | Squads | To demonstrate to our stakeholders the work we have achieved and communicate any issues from reaching our goal | Be transparent to what the team has been working on during the sprint. | |
| PO & BA Sync | Weekly |
Data & DataLab Squads Scrum Events
| Event Name | Frequency | Organizer | Participants | Agenda | Outcome |
|---|---|---|---|---|---|
| Daily Stand-up | Daily | Squads + Archi + PM (option) | What did you do yesterday? What do you plan for today? Any blockers? Is there anything you need from the team? | One daily team sync so we all what everyone is doing and if they need any assistance or have any blockers they need resolving. | |
| Sprint planning | Bi-weekly | Squads + Archi + PM (option) | Close sprint, determine team velocity, identify planned leave of absence, define sprint goal. Start sprint | To set a plan for the sprint on what the team will work out and the goal they will accomplish. | |
| Refinement/Grooming | Bi-weekly | Squads + Archi + PM + Stakeholders | PO to present stories that need refining. Team to discuss and estimate story. Can be organized by topics + tech specific | Stories/tasks fully understood so they are ready to be taken into sprint. | |
Sprint reviews | Bi-weekly / Stakeholders | Squads + Archi + PM | To demonstrate to our stakeholders the work we have achieved and communicate any issues from reaching our goal | Be transparent to what the team has been working on during the sprint. | |
| Retrospective | Bi-weekly | Squads + Archi + PM (option) | Depending on Retro template the aim is to identify what went well this sprint, what didn't go well and how we can improve for future sprints. | Discuss what didn't work well and set a list of actions to help improve |
Labware Squad Events
| Event Name | Frequency | Organizer | Participants | Agenda | Outcome |
|---|---|---|---|---|---|
| Weekly Meeting | Weekly | Squads |
| Jira up-to-date | |
| Release Meeting | Bi-weekly | Squads | Review what will be delivered with Stakeholders and get feedback | List of feedback to release |
ALB Electronic Communication
Google Groups
To have access to all your google group: https://groups.google.com/my-groups
| Goal | Includes | |
|---|---|---|
| For the whole ALB Team | alb-team@solvay,com | ALB Stakeholders, operations, dev/scrum, product team |
| For LB Core Team | lb-core@syensqo.com | Core Team |
| For Data Squad | lb-data@syensqo.com | LB dev/scrum |
| For DataLab 2.0 Squad | lb-datalab@syensqo.com | LB dev/scrum |
| For ALB operations only | alb-ops@solvay,com | ALB operations - Digital champions and stakeholders |
Google Chats
| Goal | Includes | |
|---|---|---|
| For the whole ALB Team | alb-team@solvay,com | ALB Stakeholders, operations, dev/scrum, product team |
| For ALB product only | alb-product@solvay,com | ALB Product Manager and Product Owners |
| For Data Squad development only | alb-dev@solvay,com | ALB dev/scrum |
| For ALB operations only | alb-ops@solvay,com | ALB operations - Digital champions and stakeholders |
| For Ai Squad | alb-ai@solvay,com | AI squad |
https://mail.google.com/chat/u/0/#chat/space/AAAAoMqL4DY
Recurring Communications
| Name | Responsible | Participants | Frequency | Goal |
|---|---|---|---|---|
| Month#X ALB Update | Product Manager | ALB Product ALB Data ALB DatLab ALB Operational | Monthly |
|
| Month#X Product Delivery Update | Product Owner | ALB Product ALB Data ALB DatLab ALB Operational | Monthly |
ALB Design Process
Overview
Process Workflow
Epics & General Story
How to write an Epic and Story: link
A general story needs to be broken down into multiple stories so that we can identify the how.
In JIRA, this phase is called "Business Design".
The goal is to have one or a few Data Design Workshop to design the solution of a General Story.
ALB Processes
ALB Fill a Timesheet in Replicon
Overview
The goal to fill out Replicon is for the Project at all level to track cost vs budget.
Very important when it comes to show how well the project is doing and need to ask for additional budget for new projects or to extend scopes.
Y2024 Project codes for SCO
Capex: NSO-I24003.01.7.79.ISAL - IT12617-Lab Booster-INT
Opex: NSO.PX24004.ISAO - IT12617-Lab Booster-OTC
How to fill a Timesheet
Steps | Description | |
|---|---|---|
1 | Go to Replicon here | Home Page |
2 | Enter "Solvaycore", click Next |
|
3 | Click "Sign in with SAML" |
|
4 |
|
|
5 | ALWAYS select "Data (Migration, structure, ...)" Fill out all the hours with the right budget allocation: |
|
6 | If you are taking days off:
|
|
7 | To finalize the timesheet:
|
|
ALB Estimation Process
Story points callibration 29.11.2023

Guidelines
0.5 = +/- 2h of work
1 = +/- 1/2 day
2= less than a day
3= +/- 1-2 days
5= A few days (less than a week)
8= +/- 1 week
*11 points each per sprint (2 weeks for +/- 11 points)
| Standard | Hours | T-Shirt |
|---|---|---|
| 0 | 0 | |
| 1 | ||
| 0 | 0.5 | XS |
| 3 | ||
| 1 | 4 | S |
| 6 | ||
| 2 | 8 | M |
| 12 | ||
| 3 | 16 | L |
| 24 | ||
| 5 | 32 | XL |
| 8 | 40 | XXL |
To calculate the estimated velocity
Based on 11 points per sprint per developer
ALB Data Squad Process
ALB Data Squad - Design Process
Definition
The design thinking process helps translate business needs into detailed requirements.
It consists of a few steps that helps the team brainstorm together to ensure we answer our stakeholder needs and maximize the product value.
EPIC Design Process
This process is represented for the Data squad in the 2-Data Design board.
| Steps | Who? | Description | Output | Maturity |
|---|---|---|---|---|
| 1 - Unqualified Backlog |
|
|
| Implemented |
| 2. Design (Initiation Process) |
|
|
| |
| 3. Design Validation (Standardization) |
|
| ||
| 4. Business Design |
|
|
| In Progress |
| 5. Low Fidelity Design |
|
|
| In Progress |
| 6. Technical Design |
| During the refinement meeting, the squad evaluates the work and the feasibility |
| In Progress |
| 7. Ready for Development |
| Keeps reviewing and prioritizing the stories before it gets to the Sprint Backlog |
| Implemented |
STORY/TASK Design Process
| Steps | Who? | Description | Outputs | Maturity |
|---|---|---|---|---|
| 1 - Unqualified Backlog |
|
|
| Sitting in Backlog |
| 2 - Business Design |
|
|
| In Progress |
| 3 - Functional Design |
|
|
Note: ETL only use tasks and are linked to the DataViz Stories | In Progress |
| 4 - Technical Design |
|
|
NEED TO ADD USER JOURNEY, USE CASES, DOCUMENTATION | Implemented |
| 5 - Ready for Development |
|
|
| Implemented |
ALB Data Squad - Scrum Process
Sprint Overview
Each sprint last 2 weeks from Wednesday to Wednesday.
Scrum Events
- Sprint Planning
→ is the start of the new sprint.
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team (ELN specialist, data eng, data viz)
- Daily's
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team (ELN specialist, data eng, data viz)
- Sprint Review
π 1 per domain : Materials - Battery - Coatings
Required attendees:- Product owner/ Proxy's PO
- Scrum master
- All dev team (ELN specialist, data eng, data viz)
- Key stakeholders
- Sprint Retrospective
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team (ELN specialist, data eng, data viz)
- Refinement Sessions
π 1 per expertise : ELN - ETL - Data viz- Required attendees :
- Product owner/ Proxy's PO
- Scrum master
- Relevant dev team.
- Required attendees :
Sprint Workflow
As for now:
- DoD for an epic stops at PO Testing
- PO testing means...
Sprint Review major release
- Record
- Demo
- Key Stakeholder leads with PO and BA to take notes
ALB Data Squad - DoD - Definition of Done
Agreed DoD:
| Product Definition of done | |
| Mandatory Tasks done | |
| Development Completed | Sprint |
| Deployment Job Built | |
| Unit Tests Passing | |
| Technical Documentation Completed | |
| List of changed object completed | |
| Code Review Completed | |
| QA Testing Successfully Completed | |
| Deployment Validated | Production |
| Deployment Tests Successfully Completed | |
| Data available in the source | |
| PO Testing (DM Environment only) Successfully Completed | |
| Pre-prod Deployment Validated | |
| Pre-prod Deployment Tests Successfully Completed | |
| Production Deployment Validated | |
| Global Technical Documentation Updated |
ALB Data Squad - Testing Process
Overview
During a sprint, different type of testing helps validate a story that is supposed to be "done".
The Data Squad is conducting the following types of testing during a sprint:
- Unit Testing
- Peer Review - team has agreed to do PRs
- Integration Testing
- DE testing
- PO Testing (Product Owner Testing)
- UAT (User Acceptance Testing)
DE Testing
| ODS (data source - oriented, historize data, few cleansing (such as date format, special characters,...) | |||
| No | Role | To do | Requirement/Query |
| 1 | DataEng | Export a sampling test data from ELN to a gslide. AS-IS Stored in Gdrive / TO-BE: file to be linked in the EPIC description. | Be sure to have at least an entire experiment, including at least 2 samples. Be sure to be able to test all the business rules (such as having several measure to be able to make an average) |
| 2 | DataEng | Use the ELN test file, compare if we find the same nb of rows in the ODS. | in case of large number of rows. QUERY: SELECT COUNT(test_id),test_id FROM `prj-labbooster-coatings-dev.ODSV2.eln_emulsion_polymerization_freeze_thaw_resistance_tests_conso` GROUP BY test_id ORDER BY count(test_id) DESC |
| 3 | DataEng | For the mandatory fields, these musn't have any null. | PO to define the mandatory fields in stories. Add a flag in the Da knowledge document Data Mapping (Data Architect to Data Eng.) QUERY: SELECT columnname |
| 4 | DataEng | Systematically Flag the PK in the Data Knowledge Document | SELECT Count (distinct) |
| 5 | DataEng | Design first in genmymodel by the Data Architect and create table from the script generator (DA and DE) | integration test: |
| DM (product-oriented, should be consumable by Tableau, business rules are implemented) | |||
| No | Role | To do | Requirement/Query |
| 1 | DataEng / PO / Data Archi | Xls Mockup of Data shared between DA, DV and PO, in order to align the design and to be a base for PO testing at the end of ETL dev. (Alexia) Choose a few lines of keys (sample, experiment, cycle ...) Ideally the same keys that have been used on ODS https://docs.google.com/spreadsheets/d/1wbux4wRuV9by_qMHbTkZxZb_nJYQiNxFVoOQxUi-B2c/edit#gid=958619263 DA Knowledge Data mapping should be the source of rules description. | QUERY: for recursive calculation, ORDER BY the correct keys. When we define a unique key, check that is really unique. (COUNT , DISTINCT) check specific rules described in the DA knowledge file. (ex: complex calculation, replace null by "N/A",...) For the fields flagged as "mandatory", check if there are no null. Be careful of undesirable spaces (remaining at the beginning or the end, especially for foreign keys), double space (data cleaning good practices). For the fields flagged as "mandatory", check if there are no null |
| 2 | DataEng | compare the type described in the DA knowledge doc/Data Mapping and the Schema in BQ. | Check number of rows and compare to what is supposed to be according to ODS. |
| 3 | DataEng | Before Integration testing, empty the table and reload to be sure the rows will be generated by the last version of the job. | |
PO Testing
The sprint backlog, the list of work to be done during the sprint, is agreed upon the team and locked at the end of the sprint planning.
| Process | Output |
| Alexia, Claire described the business rules, and provide a test file mockup to Data Viz and Data Architect | Data Model draft agreed with DataViz |
| Data Archi design Data Model | |
| Data Archi translate business rules in technical rules | |
| DA validates with Data Viz the data model, helped by the mockup |
Active Sprint Board Process
- Tickets start in the column "To Do"
- Tickets move to "Under development" when a developer starts to work on a ticket
- Tickets move to "Integration testing". This last column is used by the dev teams to run some additional tests before pushing tickets to the "PO testing" column.
- Tickets move to "PO Testing" once the dev team feels to have met the criteria of acceptance of the ticket and DE testing is completed. The PO is invited to test it as soon as possible before the Sprint Review
- Tickets do not meet the AC, they go back to "Under development" or Tickets meet the AC and moves to "Done"
- Tickets move to UAT Testing in the Release board for stakeholders/super users to test and validate
- New Tickets can be created and prioritized by the PO for any additional work or unmet AC, a list of evolution/improvement
https://miro.com/app/board/uXjVPJKN5bs=/ duba3018 to move to Lucid Chart

PO Testing Process (Standard)
What?
The PO testing is focused on the technical/functional aspect of the ticket :
- Validate AC (Acceptance Criteria found in the description of the ticket)
- User Experience
How?
- The PO follows the High level guidelines/rules in ELN and Tableau (WIP) PO Testing
- The PO creates a copy of:
- ELN PO Testing Template (made by Claire)
- Tableau PO Testing (made by Justine)
- The PO conducts the tests and validate all the test Cases in the template and attach it to the tickets
β οΈ The comments should be related to the scope of the ticket, any evolution or new aspect should be added in the backlog and prioritize.
UAT testing
This testing is performed outside of the sprint and is performed by the users and is managed by the PO.
Userguide for PO testing ?
ELN
Coatings
1° Go to ELN test environment
2° Projects < M_CTS < Coatings testing cluster
![]()
Create a new experiment with the testable ELN templates.
ALB Data Squad - Release Process
Both GCP, Talent and Tableau are handled by DA&AI team.
Release to PPROD/PROD
1) ELN :
- Romain Fonta is autonomous on the push to PROD.
Here is a checklist of things to think about when releasing a spreadsheet :
2) Talend/ GCP
All releases should be planned head with DA&AI team. The CGI team is responsible for pushing Talent/GCP development to PROD (Gatekeeper).
To know more about the CAB, a slide deck is avalaible here
Condition to start the process :
- Successful UAT and sign-off from the business
- Documentation ready
- CAB approval (if applicable)
- Release date scheduled in the DA&AI wiki - Release Plan
All the code changes has to be deployed in the Dev and from Dev the DataOps team promotes the code to UAT. The reason behind not providing access to developers is "In Talend we don't have access on environment basis but as a whole. Providing the link below to raise a request for promoting the code to UAT for the first time :
The deployment won't take more than 15mins.
Useful documents :
PRE PORD AND PROD documentation:
DA&AI Release Management Handbook:
1) For major change:
Once the work is ready to be put in PROD, we need to get all the documentation ready for the data Ops team.
1/ Get the documentation on the relevant confluence page
2/ in //, the dev team and PO team update a slide deck (template available here)
3/ Create a ticket in ServiceOne



and based on that DataOps will create a ticket in HELIX BMC for the data ops (outside data squad) to put GCP in PRE-PROD.
- Responsible : PO or Mauricio
- Tasks : Fill all the required fields in the ticket process
4/ Once the ticket has been approved, the date of the CAB meeting is communicated (around 1-2 week after)
5/ Assisting the CAB meeting
- Responsible : PO and Mauricio
- Tasks : Present the slides
If Approval from the CAB,
6/ Data ops team will push to prod on a planned date.
7/ A appointed data eng will do a KT session to an appointed data ops
8/ Push to PROD by data ops team
2) For Minor/Standard change:
Useful information
- link to the checklist ?
- Where to put all the dev doc ?
- CAB chief
- Data ops lead ?
3) Tableau
Once workbooks are tested and validated by the PO(s) and key stakeholders, we can start the process of going into PROD π
PO2 FROZEN PERIOD
PO2 FROZEN PERIOD: Changes on the Spin-off date: REMINDER_ PO2 FROZEN PERIOD_ Changes on the Spin-off date.pdf
Release Management & PO2 Frozen periods 2023:
ALB Data Squad - DoR - Definition of Ready
- Stories contain description using INVEST model

- Acceptance Criteria listed
- UI/UX wireframes attached to story (where applicable)
- User stories estimated to fit into 1 sprint
- External dependencies resolved
ALB DataLab Squad Process
ALB DataLab Lesson Learned
Overview
Feedback experience with Vanenburg
Q4 DataLab Development
Statement of Work:
Design phase
- No Clear process from start-to-end from Li-Lian team / Not easy to understand the steps on how to work to get a team available
- We did not know from the start what was required to get a statement of work (we had to ask a few times, micro steps)
- We needed to have devs helping us with designing the scope for technical-feasibility purpose
- SOW quickly written, very high level compared to what I shared (Backlog, Architecture, User journeys/Use Cases) so we thought the SOW was a formality but developers were always saying it is not in the SOW but there is nothing detailed in the SOW (it feels like we have to babysit the whole process, escalate)
- Would rather have direct communication with Vanenburg
- Timezone makes it hard to work closely together between (India-Singapore-Europe-Canada)
- Communication is not clear and it doesn't go both ways. There is no replies to important e-mails in which the topics are: estimates, priorities, etc. We also started a google chat group to improve communication, but without significant success.
Boris:
- I didn't/we didn't know that they took 7 User Stories into development before we even started.
- Another thing is communication, we have an open channel, but they only started using it today.
- I've added them twice to jira with solvay emails that they obviously have but don't want/won't use.
- They have currently delivered the first increment so before escalation I would like to talk openly on the retro about these topics. It is the last attempt before the actual escalation.
ALB DataLab Squad - Design Process
Definition
The design process helps translate business needs into detailed requirements.
It consists of a few steps that helps the team brainstorm together to ensure we answer our stakeholder needs and maximize the product value.
Design Process
This process is represented for the Data squad in the 2-Data Design board.
| Steps | Who? | Description | Output | Maturity |
|---|---|---|---|---|
| 1 - Unqualified Backlog |
|
|
| Implemented |
| 2 - Business Design |
|
|
| In Progress |
| 3 - Functional Design |
|
|
| In Progress |
| 4 - Technical Design |
| During the refinement meeting, the squad evaluates the work and the feasibility |
| In Progress |
| 5 - Ready for Development |
| Keeps reviewing and prioritizing the stories before it gets to the Sprint Backlog |
| Implemented |
ALB DataLab Squad - DoD - Definition of Done
DoD Definition Workshop: https://miro.com/app/board/uXjVPBkF6Yo=/
Agreed DoD:
- Manual Test Cases - Test Report (No automation test)
- Business documentation on the wiki (ask for access)
- Technical documentation
- Delivered in PROD
- No impact on other features
- Acceptable performances
- Test case design
- Test execution report
- Wiki update
- More elaborated ticket will have less bugs/UI changes
- By default, dev is fully consistent with the mockups
ALB DataLab Squad - DoR - Definition of Ready
Agreed DoR:
- Stories contain description using INVEST model

- Acceptance Criteria listed
- UI/UX wireframes attached to story (where applicable)
- Story stories estimated to fit into 1 sprint
- External dependencies resolved
ALB DataLab Squad - Kanban Process
Kanban Overview :
Each cadence last 1 month.
Kanban Events
- Planning
π on going process
Required attendees :- Product owner
- Scrum master
- All dev team
- Daily's
πx1 / week
Required attendees :- Product owner
- Product manager
- Scrum master
- All dev team
- Review
π on-demand
Required attendees:- Product owner
- Scrum master
- All dev team
- Key stakeholders
- Retrospective
π on-demand after review meeting
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team
- Refinement Sessions
π on-demand- Required attendees :
- Product owner/ Proxy's PO
- Scrum master
- Relevant dev team.
- Required attendees :
Kanban Workflow
As for now:
- DoD for an epic stops at PO Testing
- PO testing means...
Review major release
- Record
- Demo
- Key Stakeholder leads with PO and BA to take notes
ALB AI Squad Kanban Process
Kanban Overview :
Each cadence last 1 month.
Kanban Events
- Planning
π once a month
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team
- Daily's
πdon't have it
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team
- Review
π on-demand
Required attendees:- Product owner/ Proxy's PO
- Scrum master
- All dev team
- Key stakeholders
- Retrospective
π on-demand
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team
- Refinement Sessions
π don't have it- Required attendees :
- Product owner/ Proxy's PO
- Scrum master
- Relevant dev team.
- Required attendees :
Kanban Workflow
As for now:
- DoD for an epic stops at PO Testing
- PO testing means...
Review major release
- Record
- Demo
- Key Stakeholder leads with PO and BA to take notes
ALB Onboarding New External Team member (Solvay Partners via TPA)
Overview
The goal of this page is to fully onboard new team members before that they arrive and the days following their arrivals.
Onboarding manual Template link: here
Before Arrival
The new team members need to be created within Solvay, there are 2 main steps to follow:
1st Step - Create the TPA & Solvay identities
The vendor/external/consultant company needs to be added to the Third-Party Access Registry in order to create the new team members under that Third-Party entity, to do so fill the following form:
- Service One > Catalog > Browse > IT Foundation > Virtualization > Third-Party Access (TPA) > Manage Company / Application / Desktop Pool
Before filling the request, make sure the Third-Party company does not already exist in this file - the file link is also in the request.
Choose: Third-Party Access (TPA) User Access Management / Other Request / Software Installation (Software installation option is available for TPA team usage only)
In parallel, another request can be submitted to create the new Team member identity:
- Service One > Catalog > Browse > On/Offboarding / Onboarding
Warning: The new team member will have a Solvay email address
2nd Step - Create a profile and grant tools access
24 hours after the 1st Step have been approved, to create a new user with all the necessary basic tools to connect go to:
- Service One > Catalog > Browse > On/Offboarding / Onboarding - IT Equipment & Access Request
Note that: the new team member is a "Contingent Worker", cannot have a Solvay laptop, a Solvay email address or access to SAP.
In parallel, fill generic request to ask for the those webapp access:
- JIRA - Submit a general request on service one & Scrum Master to add to project
- Wiki/Confluence - Submit a general request on service one & Scrum Master to add to space
- Miro/JAMBoard - Submit a general request on service one
- Menti & Lucid Chart full access
- Replicon - Ask Financial department to create new use in Replicon
3rd Step - Grant functional Access
List of mandatory ALB Google/Communication access
- To be added to the right ALB Google Group Mails
- Check if the new team members have been added to the right Google Shared Drive (should be done automatically since it using the ALB google group mails)
- Check if the new team members have been added to the right ALB Google Calendars (ALB Time-Off calendar mainly)
- Check if the new team members have been added to the right ALB Group Chats
ALB Product access (dev/test/prod):
- ELN
- Tableau
- DataLab
- AI tool
Manager to have a full detailed view on the new team members calendar to increase visibility
Managers to plan the new team member first week meetings as soon as Solvay Google email has been created:
- 1:1 with new team member to welcome them and present an overview of the role and team, onboarding plan and share the Google Doc Onboarding Manual Template - 2hrs
- Sync at the end of every end of day during the 1st week - 30min
- Plan weekly recurring meeting 1:1 with manager - 30min
- Add the new team member to all current recurring meetings
Communication with other team members for planning Subject Matter, tools and product onboarding
- Digital Champions/Project Coordinators - Why?
- POs/Proxy POs - What?
- Scrum Master - How?
Upon Arrival
- Onboarding meeting with Scrum Master to understand team processes.
- Onboarding meeting with PO/BA to understand the product.
ALB Scrum Master Tasks
Scrum Master RACI
Responsible (R):
- Updating Team section in the wiki: Roscetti, Nicolas
Onboarding and Offboarding team members: Roscetti, Nicolas
- Improve team performance
- Core Board with epic Feature, build a roadmap
- Lesson Learned in the wiki
- Upload Sprint Reports in Wiki
- Cleaned data velocity chart in this doc
- Facilitate Retrospectives and Sprint Planning (partially), miro board
Coaching the team members in self-management and cross-functionality;
Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
Causing the removal of impediments to the Scrum Team’s progress;
Helping find techniques for effective Product Goal definition and Product Backlog management;
Helping the Scrum Team understand the need for clear and concise Product Backlog items;
Helping establish empirical product planning for a complex environment;
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
Facilitating stakeholder collaboration as requested or needed.
Leading, training, and coaching the organization in its Scrum adoption;
Planning and advising Scrum implementations within the organization;
Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
Removing barriers between stakeholders and Scrum Teams.
Accountable (A):
- Establishing Scrum as defined in the Scrum Guide
- Ensuring everyone understands Scrum theory and practice, both within the Scrum Team and the organization.
- Scrum Team’s effectiveness
- Enabling the Scrum Team to improve its practices, within the Scrum framework.
Consulted (C):
- Collaboration with cross-functional teams, including researchers, scientists, developers, and product managers/owners
- for Requirement Analysis – Technical, Impact Analysis (High Level Estimations), Define Product Backlog, Prioritize Product Backlog, Create User Stories and System/QA Testing
Informed (I):
- Requirement Analysis – Business, Testing Process and Build Management.
ALB JIRA Issue Format Template
Overview
Portfolio Epic
Epic
Definition
An Epic is a large piece of increments that needs to be delivered within less than 4 sprints ideally (4 sprints = 8 weeks).
Epic Naming Format
ALB functional and non-functional Epic for the Data Squad has the following standardized format:
Market Acronym-Workflow-SubWorflow-ProductType-Extra Details
- Market Acronym: Agro (AG), Coatings (CTS), Batteries (BM) and Materials (MAT)
- Workflow: Type of test in a Lab (Biologics, Paint, Emulsion Polymerisation)
- SubWorkflow: Part of the workflow (Biologics-VMP)
- Extra Details: a part of the product like “Create a User”, “Fixes” etc.
Epic Template
Description (8 sections)
| Sections | Description | Example |
|---|---|---|
| Context /Why? | From the initiative context, tailor the context for the given epic with a more precise business value | |
| HL Business requirements / What? | ||
| HL User Story | As a user, I need to what in order to / so that goal to achieve. | |
| Future development (Out of Scope) | Link future development that is planned or discovered during development | |
| Risks (Technical, business risks if we do not do it, assumptions, unknowns) | Not sure about the direction (Spikes), business value, tight deadline, business impact | |
| KPIs (linked to OKRs) | Key indicators that will confirm or not OKRs | |
| Technical notes | ||
| Documentation link |
LB Roles and Responsibilities - RACI
Project Coordinator RACI
Responsible (R)
- ENFORCE the use of LB solutions to all listed users in this User List GSheet file
- INCREASE the adoption via any means listed in the process below
- Provide MONTHLY detailed analysis on how the adoption is enforced by UPDATING this ELN s/s Monitoring GSheet file
- Send a MONTHLY email to Patrick Moreau, Vincent Schanen, Vincent Colegrave, Laurianne Moity, Alexia Dubail, Claire Pellerin & Nicolas Roscetti by giving a summary update of how the adoption was enforced and improved with the previous file
- TRAIN R&I with LB solutions
- Create attractive Gslides for the training with LB solution content
- Provide detailed feedback to LB squads during scheduled meetings/Agile squads
- DOCUMENTED and UPDATED in this Recap Training Agro Users Gsheet
- Keep the R&I user list up-to-date in this User List GSheet file
- Confirm the list with R&I Managers
- Communicate each update with LB Service Owner (Prasanth) and Product Owners
- Must be an expert user of LB solutions. You know every features and limitations of the solutions very well to answer the users. If not sure, always ask POs before getting back to the users
Accountable (R)
- Provide features and bugs user requests to LB team
Processes
During Sprint Review
- Before meeting, make sure all the right users are invited
- Active Participation, open questions, make sure everybody gives feedbacks
- Gather and document feedback
- Exchange and challenge user feedbacks with Product owners after the meeting
ON-SITE, outside meetings - spontaneous conversations
- Write feedback in this Gsheet
- Action plan behind feedback:
- Build an action plan for every feedback with Laurianne or Alexia
Schedule and lead Training sessions
- Add PELLERIN, Claire to the trainings
- All users MUST be on calls and be trained (schedule additional meetings for users who could not make it)
- Camera MUST always be ON. Do NOT record the meeting otherwise cameras will be off
- Share screen to show the Gslide of the training - Personalized scenario/use case for each user on the call. No one should be lost or feel like the training is useless
- Dig to get feedback (outside trainings as well, weekly meeting), put a process in place - Need to know very well the app to know what is a possible new requirements from what already exists.
- Communicate back feedback to LB Team if LB squad members asked you to ask users specific questions
- Training doc to be documented (Doc
- Meeting notes: NV Agro & NV CTS (ONE Gdoc per training) Moutsinga-ext, Brenda Please update with the shared doc
- Recap Training Users Gsheet: NV Agro & NV CTS Moutsinga-ext, Brenda Please update with the shared doc
Follow adoption with the dashboard and the use of the ELN
- Conduct MONTHLY manual checks for each user in the ELN in this ELN s/s Monitoring GSheet file
- The goal is to know if they are using the ELN s/s template properly
- If not, have 1:1 meetings with every user to make them enter every past experiment through the ELN s/s without missing information. Adoption will increase!
Unable to render {include} The included page could not be found.
DT Project Coordinator
- Attend Sprint Review
- Before meeting, make sure all the right users are invited
- Active Participation, question
- Gather feedback
- Make sure everybody gives feedback
- Feedback collection on SITE
- Outside meeting feedback in the wiki in the product
- Action plan behind feedback:
- If you do not know, go to Laurianne or Alexia
- Ask if you do not know what to do
- Schedule and lead Training sessions:
- All users MUST be on calls and be trained
- Camera ON
- Share screen and structured presentation - Scenario/use case for each user on the call
- Dig to get feedback (outside trainings as well, weekly meeting), put a process in place - Need to know very well the app to know what is a possible new requirements from what already exists.
- Communicate feedback to LB Team and to the users when coming from LB
- Training doc to be documented (Doc & Gsheet), not only with attendee information but what happened in the meeting
- Follow adoption with the dashboard
- Check with user ON SITE why there are latex missing in the ELN
- Data quality: Too many blank cells in Tableau or s/s
RUN Process
DataLab Run process (Current Process - Temp)
The RUN team will be responsible for the following:
- Solve any issues to keep the application running as expected by the users or DT team
- Providing technical support to end-users as needed to resolve their issues.
- Maintain and update the knowledge base or documentation for the complex issues encountered.
Define the process for transitioning components to the support team:
- Once the build is ready to move the component to Production, they raise a request to the RUN team to move them to Production.
- Once the component is moved to Production, the Product Owner will contact the Service Owner to handover the maintenance of the component to the RUN team.
- Schedule KT sessions: The Service Owner will schedule the KT sessions for the BUILD team to share the documentation and provide knowledge transfer to the RUN team.
- The Hyper care period is 30 days after the component is delivered in Production during which the support responsibility is with the BUILD team. It can be reduced to 15 days if the delivered component is simple.
- The support team will assume ownership of the component and provide necessary maintenance and support services post the hyper care period.
- If the component requires further development or enhancements, the support team will coordinate with the build team.
Define the process for reporting and resolving issues:
- End-users will report any issues or problems to the support team through an established support channel ServiceOne. The user guide to report the issues for different markets are available in the below table:
| Market | DataLab Area | ServiceOne Guide link |
|---|---|---|
| Agro | DatAgrow | DatAgrow |
| Agro (Seed) | DataSeed | DataSeed |
| Coatings | DataCoat | DataCoat |
| Materials | DataSPP | DataSPP |
| Batteries | DataBat | DataBat |
- The Service Owner will prioritize issues based on severity and impact on business operations
- The reported issue is first investigated by the Service Owner and then assigned to concerned teams based on the component affected. The different teams that are associated with the support of the application are as below –
- Service Owner team - IS R&I Lab processes – DataLab
- WebApp team - IT Vanenburg GCP Apps
- Data team - IT Data & Analytics / IT Data Stellar Talend L3
- ELN team - IS R&I Lab Processes - ELN L2 (partner)
- CloudOps team - IT Vanenburg GCP Ops
- The support team will investigate the issues and work to resolve them as quickly as possible. If they need additional information, they reach out to the user directly or the Service Owner.
- If the issue cannot be resolved by the support team, they will escalate it to the build team to assist for further investigation and resolution.
- Update the end-user: Finally, it's important to update the end-user on the progress of their reported issue. This could include providing an estimated timeline for resolving the issue, or letting them know when the issue has been resolved.
LB - User access management
How to request ELN access?
Who must validate the access: in most cases R&I Lab Managers (note that ELN Hierarchy and roles is complex so in some specific cases, validators can be other roles), REY, Antoine
π Users don't request access to ALB spreadsheet/ ALB templates in particular, but to specific areas of Solvay ELN Hierarchy (it can be GBU folder, Trainee folder, Program Folder....) . For further information about the hierarchy, click here.
A ELN user access request is created via Service one (Here are the wiki links on how users should request access to ELN :
- Grant ELN Access for new comers
- Grant ELN Specific access rights
- Grant ELN Key-user rights
- ELN reactivation (of a deactivated account)
In this request, it MUST be indicated that the user needs ELN Spreadsheets licence (specific box in the Service one GForm).
2. ELN managed services team sends a validation email to the relevant persons (user, validator, ELN Service owner)
3.If the request is approved by the validator, access is granted and ELN managed services team sends a confirmation email to the relevant persons (user, validator, ELN Coordinator, ELN Service owner)
DataLab Acess
The details of the datalab access management is described in the following link.
GCP Project - Big Query and Google Cloud Storage
You can request an access to one or several GCP project environement.
- Go to Google Groups and in the "All Groups" tab, please search for labbooster.
- Depending on your function, please request an access on one or several of these groups. Dataviz is about visualisation of the data exposition layer (Data Mart), whereas developers will grant you modification permissions on the datasets and on Data Cloud Storage.
- In the "reason for joining", please describe:
- your function
- the GCP BigQuery projects (batteries, coatings, materials) and environments (DEV, TEST, PPROD, PROD) you are interested in
- the tasks you are supposed to perform (create tables, visualize data to check accuracy,...)
- The request will be validated by Roscetti, Nicolas and the owner of the group GNANA SEKAR, Prasanth will provide access to the GCP.
New deployment to GCP process [WIP]
Purpose/Audience
There is no clear process that must be followed for deploying a new application/solution to GCP.
The Lab Booster team has received different and at times contradicting information from and guidance on this topic from different parties, that has led to delays and confusion.
The process described in this document is intended to provide clarity on the required/correct process. This document is addressed to all members of Lab Booster projects as they should be aware of the process and may be called upon to participate in certain stages of the process.
Overview
The process consists of seven (7) high level steps:
- Product Architect works with Enterprise Architect to align on high level/logical architecture.
- Product Architect works with Data Architect to align on high level/logical data architecture, e.g. data design, schemas, data flows etc.
- Product Architect works with EBS (Cloud Ops) team to align on GCP Solution Architecture.
- Product Architect & Product Manager present Architecture Impact Analysis (AIA) to Architecture Review Board (ARB).
- Product Architect works with with Platform Architect and EBS team Solutions Architect to align on define detailed technical design, e.g. implementation plan, costs etc.
- Product Architect works with Security Architect to review security considerations for application/solution and gain approval to initiate implementation.
- Product Architect submits detailed request to EBS team to start implementation.
Architect roles
| Architect Types | Responsibilities | Who in LB |
|---|---|---|
| Enterprise |
| |
| Data |
| |
| Solution |
| TBA |
| Platform |
| |
| Product |
|
Step-by-step guide
Below is a detailed description of the steps mentioned above.
Step 1 - 1 Product Architect + 1 Enterprise Architect
| Stakeholders/Participants | Input | Output |
|---|---|---|
|
|
|
If feedback re:misalignment is provided by the Enterprise Architect, one or more follow-up sessions may be required to gain validation for moving to next phase of the process.
Step 2 - Product Architect + Data Architect
| Stakeholders/Participants | Input | Output |
|---|---|---|
|
|
|
Step 3 - Product Architect + EBS
| Stakeholders/Participants | Input | Output |
|---|---|---|
|
|
|
Step 4 - AIA Presentation
| Stakeholders/Participants | Input | Output |
|---|---|---|
|
|
|
If feedback re:misalignment is provided by the ARB, one or more follow-up sessions with Enterprise Architect and/or Data Architect and/or Cloud Ops team may be required to gain address feedback from ARB, as well as a follow-up presentation to the ARB in order to gain validation for moving to next phase of the process.
Step 5 - Product Architect + Platform Architect
| Stakeholders/Participants | Input | Output |
|---|---|---|
|
|
|
Step 6 - Product Architect + Security Architect
| Stakeholders/Participants | Input | Output |
|---|---|---|
|
|
|
If feedback re:misalignment is provided by the Security Architect, one or more follow-up sessions may be required with Platform Architect (and optionally Cloud Ops Team) to address security concerns in design, followed by a follow-up session with the Security Architect to gain validation for moving to next phase of the process.
Step 7 - Product Architect request submission
| Stakeholders/Participants | Input | Output |
|---|---|---|
|
|
|
Related articles
Error rendering macro 'contentbylabel'
parameters should not be empty
ALB DataLab Squad Process
ALB DataLab Lesson Learned
Overview
Feedback experience with Vanenburg
Q4 DataLab Development
Statement of Work:
Design phase
- No Clear process from start-to-end from Li-Lian team / Not easy to understand the steps on how to work to get a team available
- We did not know from the start what was required to get a statement of work (we had to ask a few times, micro steps)
- We needed to have devs helping us with designing the scope for technical-feasibility purpose
- SOW quickly written, very high level compared to what I shared (Backlog, Architecture, User journeys/Use Cases) so we thought the SOW was a formality but developers were always saying it is not in the SOW but there is nothing detailed in the SOW (it feels like we have to babysit the whole process, escalate)
- Would rather have direct communication with Vanenburg
- Timezone makes it hard to work closely together between (India-Singapore-Europe-Canada)
- Communication is not clear and it doesn't go both ways. There is no replies to important e-mails in which the topics are: estimates, priorities, etc. We also started a google chat group to improve communication, but without significant success.
Boris:
- I didn't/we didn't know that they took 7 User Stories into development before we even started.
- Another thing is communication, we have an open channel, but they only started using it today.
- I've added them twice to jira with solvay emails that they obviously have but don't want/won't use.
- They have currently delivered the first increment so before escalation I would like to talk openly on the retro about these topics. It is the last attempt before the actual escalation.
ALB DataLab Squad - Design Process
Definition
The design process helps translate business needs into detailed requirements.
It consists of a few steps that helps the team brainstorm together to ensure we answer our stakeholder needs and maximize the product value.
Design Process
This process is represented for the Data squad in the 2-Data Design board.
| Steps | Who? | Description | Output | Maturity |
|---|---|---|---|---|
| 1 - Unqualified Backlog |
|
|
| Implemented |
| 2 - Business Design |
|
|
| In Progress |
| 3 - Functional Design |
|
|
| In Progress |
| 4 - Technical Design |
| During the refinement meeting, the squad evaluates the work and the feasibility |
| In Progress |
| 5 - Ready for Development |
| Keeps reviewing and prioritizing the stories before it gets to the Sprint Backlog |
| Implemented |
ALB DataLab Squad - DoD - Definition of Done
DoD Definition Workshop: https://miro.com/app/board/uXjVPBkF6Yo=/
Agreed DoD:
- Manual Test Cases - Test Report (No automation test)
- Business documentation on the wiki (ask for access)
- Technical documentation
- Delivered in PROD
- No impact on other features
- Acceptable performances
- Test case design
- Test execution report
- Wiki update
- More elaborated ticket will have less bugs/UI changes
- By default, dev is fully consistent with the mockups
ALB DataLab Squad - DoR - Definition of Ready
Agreed DoR:
- Stories contain description using INVEST model

- Acceptance Criteria listed
- UI/UX wireframes attached to story (where applicable)
- Story stories estimated to fit into 1 sprint
- External dependencies resolved
ALB DataLab Squad - Kanban Process
Kanban Overview :
Each cadence last 1 month.
Kanban Events
- Planning
π on going process
Required attendees :- Product owner
- Scrum master
- All dev team
- Daily's
πx1 / week
Required attendees :- Product owner
- Product manager
- Scrum master
- All dev team
- Review
π on-demand
Required attendees:- Product owner
- Scrum master
- All dev team
- Key stakeholders
- Retrospective
π on-demand after review meeting
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team
- Refinement Sessions
π on-demand- Required attendees :
- Product owner/ Proxy's PO
- Scrum master
- Relevant dev team.
- Required attendees :
Kanban Workflow
As for now:
- DoD for an epic stops at PO Testing
- PO testing means...
Review major release
- Record
- Demo
- Key Stakeholder leads with PO and BA to take notes
ALB AI Squad Kanban Process
Kanban Overview :
Each cadence last 1 month.
Kanban Events
- Planning
π once a month
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team
- Daily's
πdon't have it
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team
- Review
π on-demand
Required attendees:- Product owner/ Proxy's PO
- Scrum master
- All dev team
- Key stakeholders
- Retrospective
π on-demand
Required attendees :- Product owner/ Proxy's PO
- Scrum master
- All dev team
- Refinement Sessions
π don't have it- Required attendees :
- Product owner/ Proxy's PO
- Scrum master
- Relevant dev team.
- Required attendees :
Kanban Workflow
As for now:
- DoD for an epic stops at PO Testing
- PO testing means...
Review major release
- Record
- Demo
- Key Stakeholder leads with PO and BA to take notes
ALB JIRA Issue Format Template
Overview
Portfolio Epic
Epic
Definition
An Epic is a large piece of increments that needs to be delivered within less than 4 sprints ideally (4 sprints = 8 weeks).
Epic Naming Format
ALB functional and non-functional Epic for the Data Squad has the following standardized format:
Market Acronym-Workflow-SubWorflow-ProductType-Extra Details
- Market Acronym: Agro (AG), Coatings (CTS), Batteries (BM) and Materials (MAT)
- Workflow: Type of test in a Lab (Biologics, Paint, Emulsion Polymerisation)
- SubWorkflow: Part of the workflow (Biologics-VMP)
- Extra Details: a part of the product like “Create a User”, “Fixes” etc.
Epic Template
Description (8 sections)
| Sections | Description | Example |
|---|---|---|
| Context /Why? | From the initiative context, tailor the context for the given epic with a more precise business value | |
| HL Business requirements / What? | ||
| HL User Story | As a user, I need to what in order to / so that goal to achieve. | |
| Future development (Out of Scope) | Link future development that is planned or discovered during development | |
| Risks (Technical, business risks if we do not do it, assumptions, unknowns) | Not sure about the direction (Spikes), business value, tight deadline, business impact | |
| KPIs (linked to OKRs) | Key indicators that will confirm or not OKRs | |
| Technical notes | ||
| Documentation link |
RUN Process
DataLab Run process (Current Process - Temp)
The RUN team will be responsible for the following:
- Solve any issues to keep the application running as expected by the users or DT team
- Providing technical support to end-users as needed to resolve their issues.
- Maintain and update the knowledge base or documentation for the complex issues encountered.
Define the process for transitioning components to the support team:
- Once the build is ready to move the component to Production, they raise a request to the RUN team to move them to Production.
- Once the component is moved to Production, the Product Owner will contact the Service Owner to handover the maintenance of the component to the RUN team.
- Schedule KT sessions: The Service Owner will schedule the KT sessions for the BUILD team to share the documentation and provide knowledge transfer to the RUN team.
- The Hyper care period is 30 days after the component is delivered in Production during which the support responsibility is with the BUILD team. It can be reduced to 15 days if the delivered component is simple.
- The support team will assume ownership of the component and provide necessary maintenance and support services post the hyper care period.
- If the component requires further development or enhancements, the support team will coordinate with the build team.
Define the process for reporting and resolving issues:
- End-users will report any issues or problems to the support team through an established support channel ServiceOne. The user guide to report the issues for different markets are available in the below table:
| Market | DataLab Area | ServiceOne Guide link |
|---|---|---|
| Agro | DatAgrow | DatAgrow |
| Agro (Seed) | DataSeed | DataSeed |
| Coatings | DataCoat | DataCoat |
| Materials | DataSPP | DataSPP |
| Batteries | DataBat | DataBat |
- The Service Owner will prioritize issues based on severity and impact on business operations
- The reported issue is first investigated by the Service Owner and then assigned to concerned teams based on the component affected. The different teams that are associated with the support of the application are as below –
- Service Owner team - IS R&I Lab processes – DataLab
- WebApp team - IT Vanenburg GCP Apps
- Data team - IT Data & Analytics / IT Data Stellar Talend L3
- ELN team - IS R&I Lab Processes - ELN L2 (partner)
- CloudOps team - IT Vanenburg GCP Ops
- The support team will investigate the issues and work to resolve them as quickly as possible. If they need additional information, they reach out to the user directly or the Service Owner.
- If the issue cannot be resolved by the support team, they will escalate it to the build team to assist for further investigation and resolution.
- Update the end-user: Finally, it's important to update the end-user on the progress of their reported issue. This could include providing an estimated timeline for resolving the issue, or letting them know when the issue has been resolved.
LB - User access management
How to request ELN access?
Who must validate the access: in most cases R&I Lab Managers (note that ELN Hierarchy and roles is complex so in some specific cases, validators can be other roles), REY, Antoine
π Users don't request access to ALB spreadsheet/ ALB templates in particular, but to specific areas of Solvay ELN Hierarchy (it can be GBU folder, Trainee folder, Program Folder....) . For further information about the hierarchy, click here.
A ELN user access request is created via Service one (Here are the wiki links on how users should request access to ELN :
- Grant ELN Access for new comers
- Grant ELN Specific access rights
- Grant ELN Key-user rights
- ELN reactivation (of a deactivated account)
In this request, it MUST be indicated that the user needs ELN Spreadsheets licence (specific box in the Service one GForm).
2. ELN managed services team sends a validation email to the relevant persons (user, validator, ELN Service owner)
3.If the request is approved by the validator, access is granted and ELN managed services team sends a confirmation email to the relevant persons (user, validator, ELN Coordinator, ELN Service owner)
DataLab Acess
The details of the datalab access management is described in the following link.
GCP Project - Big Query and Google Cloud Storage
You can request an access to one or several GCP project environement.
- Go to Google Groups and in the "All Groups" tab, please search for labbooster.
- Depending on your function, please request an access on one or several of these groups. Dataviz is about visualisation of the data exposition layer (Data Mart), whereas developers will grant you modification permissions on the datasets and on Data Cloud Storage.
- In the "reason for joining", please describe:
- your function
- the GCP BigQuery projects (batteries, coatings, materials) and environments (DEV, TEST, PPROD, PROD) you are interested in
- the tasks you are supposed to perform (create tables, visualize data to check accuracy,...)
- The request will be validated by Roscetti, Nicolas and the owner of the group GNANA SEKAR, Prasanth will provide access to the GCP.
- No labels



