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

  1. Click on "add row "

  2. Click "Select Project"

  3. Type "IT12193 Lab Booster"

  4. Click the arrow on the "Application Lab Booster" line 

5

ALWAYS select "Data (Migration, structure, ...)"

Fill out all the hours with the right budget allocation:
(If during the month you think you must go over the max time allocation, go to Roscetti, Nicolas )

  1. Go to Capex/Opex spreadsheet:

  2. Check your hours per day. Contact Lukasz if there are any discrepancies (days off etc.).

  3. Please don't modify Capex/Opex ratio.

  4. Capex and Opex hours will be calculated automatically for you.

  5. Report those hours in Replicon with the proper code.

6

If you are taking days off:

  • Look for "Solvay's Generic Project"

    • Non Working Hours

7

To finalize the timesheet:

  • Click the "Submit for Approval" for approval

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)

StandardHoursT-Shirt
00

1
00.5XS

3
14S

6
28M

12
316L

24
532XL
840XXL

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.  

StepsWho?DescriptionOutputMaturity
1 - Unqualified Backlog
  1. Product Manager
  • Draft Epic Feature
  • From AODOCS
  • Context Why
  • HL User Story (As a ..., I want ... to) in what
  • Out of Scope (shared with PO)
  • Technical Notes (shared with PO)
  • HL User Journey
Implemented
2. Design (Initiation Process)
  1. Product Manager
  2. Process Analyst
  • Fill out the rest of the fields in the Epic Feature
  • WSJF
  • Job Sizing
  • Update Score Card Link

3. Design Validation (Standardization)
  1. Process Analyst
  • Standardize R&I


4. Business Design
  1. Product Owner
  • 1st round of stakeholder interviews to gather needs

  • They break down functional stories in a set of small prioritized requirements

  • Product owner works on HL estimates based on impact and effort with squad

  • Acceptance Criteria in the What
  • Out of Scope (shared with PM)
  • Technical Notes (shared with PM)
  • Job Sizing (Estimation)
  • KPIs
  • Prioritized several Stories
  • Finalize User Journey
  • Update Product Catalog
In Progress
5. Low Fidelity Design
  1. UI/UX Designers
  2. Key stakeholders
  3. Data Architect
  4. Product Owner
  5. Business Analyst
  6. Solution Architect
  • UI/UX designers build zoning screens (basic wireframes) and UX architecture (HL navigation)
  • The data architect builds data mapping/schema?

  • UI/UX designers design wireframes/mockups and test their design with their users
  • Data mapping attached to each story
  • Wireframes
  • Access policy
  • Detailed User Journey/Use Cases
In Progress
6. Technical Design
  1. DataLab Squad
During the refinement meeting, the squad evaluates the work and the feasibility 
  • Stories ready
  • Stories estimated
In Progress
7. Ready for Development
  1. Product Owner
Keeps reviewing and prioritizing the stories before it gets to the Sprint Backlog
  • Backlog/Stories always prioritized and up-to-date
Implemented


STORY/TASK Design Process

StepsWho?DescriptionOutputsMaturity
1 - Unqualified Backlog
  1. Product Owner
  2. Business Analyst
  • Creates functional stories and collects high level information from stakeholders
  • Draft - unprioritized stories
  • Detailed Epic (Scope, KPIs, etc.)
  • Bunch of Stories
    • Title
      • User Story (As a ..., I want ... to) - Optional
Sitting in Backlog
2 - Business Design
  1. Product Owner
  2. Business Analyst
  • They break down functional stories in a set of small prioritized requirements 
  • Prioritized several small issues
  • Acceptance Criteria
In Progress
3 - Functional Design
  1. Key stakeholders
  2. Data Architect
  3. Domain Experts/Devs
  4. Product Owner
  5. Business Analyst
  • They add very detailed/data specs stakeholder. The data architect builds data mapping/schema

  • Set of HL standardized tasks are drafted by Domain Experts or Devs
  • Data mapping attached to each story - Data Architect Accountable/responsible
  • HL tasks ready - Optional

Note: ETL only use tasks and are linked to the DataViz Stories
ETL tasks are under ETL Epics 

In Progress
4 - Technical Design
  1. Data Squad
  • During the refinement meeting, the squad evaluates the work and the feasibility

  •  Non-functional specific tasks drafted and split
  • Stories ready and estimated
  • Specific tasks ready and estimated

NEED TO ADD USER JOURNEY, USE CASES, DOCUMENTATION
NEED TO ADD PRODUCT MANAGEMENT PROCESS

Implemented
5 - Ready for Development
  1. Product Owner
  • Keeps reviewing and prioritizing the stories before it gets to the Sprint Backlog
  • Backlog/Stories always prioritized in the Product Backlog and up-to-date
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.

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

DoD gSheet:

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,...)
NoRoleTo doRequirement/Query
1DataEngExport 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)
2DataEngUse 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
3DataEngFor 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
4DataEngSystematically Flag the PK in the Data Knowledge DocumentSELECT Count (distinct)
5DataEngDesign first in genmymodel by the Data Architect and create table from the script generator (DA and DE)

integration test:
be sure that we have text values in strings

DM
(product-oriented, should be consumable by Tableau, business rules are implemented)
NoRoleTo doRequirement/Query
1DataEng / PO / Data ArchiXls 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
2DataEngcompare 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.
3DataEngBefore 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.


ProcessOutput


Alexia, Claire described the business rules, and provide a test file mockup to Data Viz and Data ArchitectData 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


  1. Tickets start in the column "To Do" 
  2. Tickets move to "Under development" when a developer starts to work on a ticket
  3. 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.
  4. 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
  5. Tickets do not meet the AC, they go back to "Under development" or Tickets meet the AC and moves to "Done"
  6. Tickets move to UAT Testing in the Release board for stakeholders/super users to test and validate
    1. 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?

  1. The PO follows the High level guidelines/rules in ELN and Tableau (WIP) PO Testing 
  2. The PO creates a copy of:
    1. ELN PO Testing Template (made by Claire)
    2. Tableau PO Testing (made by Justine)
  3. 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

The Data Squad is working on 3 "products": ELN, GCP/Talent, Tableau which leads to 3 different process for releasing.  
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 : 

Template 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

Agreed DoR:
  • 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.  

StepsWho?DescriptionOutputMaturity
1 - Unqualified Backlog
  1. Product Owner
  • Creates functional stories and collects high level information from stakeholders
  • Draft - unprioritized stories
  • Detailed Epic (Scope, KPIs, etc.)
  • Bunch of Stories
    • Title
      • User Story (As a ..., I want ... to) Optional
Implemented
2 - Business Design
  1. Business Analyst
  2. Product Owner
  3. UI/UX Designers
  • 1st round of stakeholder interviews to gather needs

  • They break down functional stories in a set of small prioritized requirements

  • Product owner works on HL estimates based on impact and effort with squad

  • UI/UX designers build zoning screens (basic wireframes) and UX architecture (HL navigation)
  • Prioritized several small issues
  • Well defined acceptance Criteria
  • HL Epic estimates
  • Draft User Journey/Use Cases
  • Zoning screens
In Progress
3 - Functional Design
  1. UI/UX Designers
  2. Key stakeholders
  3. Data Architect
  4. Product Owner
  5. Business Analyst
  6. Solution Architect
  • The PO, BA and/or UI/UX designers conducts 2nd round interviews to add very detailed/data specs from stakeholders

  • The data architect builds data mapping/schema

  • UI/UX designers design wireframes/mockups and test their design with their users
  • Data mapping attached to each story
  • Wireframes and mockups
  • Access policy
  • Detailed User Journey/Use Cases
In Progress
4 - Technical Design
  1. Data Squad
During the refinement meeting, the squad evaluates the work and the feasibility 
  • Stories ready
  • Stories estimated
In Progress
5 - Ready for Development
  1. Product Owner
Keeps reviewing and prioritizing the stories before it gets to the Sprint Backlog
  • Backlog/Stories always prioritized and up-to-date
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.

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.

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:

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:

  1. JIRA - Submit a general request on service one & Scrum Master to add to project 
  2. Wiki/Confluence - Submit a general request on service one & Scrum Master to add to space
  3. Miro/JAMBoard - Submit a general request on service one
  4. Menti & Lucid Chart  full access
  5. Replicon - Ask Financial department to create new use in Replicon 

3rd Step - Grant functional Access


List of mandatory ALB Google/Communication access

  1. To be added to the right ALB Google Group Mails
  2. 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)
  3. Check if the new team members have been added to the right ALB Google Calendars (ALB Time-Off calendar mainly)
  4. 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: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 
  2. Sync at the end of every end of day during the 1st week - 30min
  3. Plan weekly recurring meeting 1:1 with manager - 30min
  4. Add the new team member to all current recurring meetings

Communication with other team members for planning Subject Matter, tools and product onboarding

  1. Digital Champions/Project Coordinators - Why?
  2.  POs/Proxy POs - What?
  3. Scrum Master - How?

Upon Arrival


  1. Onboarding meeting with Scrum Master to understand team processes.
  2. 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)

SectionsDescriptionExample
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 StoryAs 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

Miro link: https://miro.com/app/board/uXjVP3CeiiY=/

Team RACI


Technical Roles 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
  • 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

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)

This page describes the RUN process for the LabBooster/DataLab applications.

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:
MarketDataLab AreaServiceOne Guide link
AgroDatAgrowDatAgrow
Agro (Seed)DataSeedDataSeed
CoatingsDataCoatDataCoat
MaterialsDataSPPDataSPP
BatteriesDataBatDataBat
  • 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 :

    1. Grant ELN Access for new comers
    2. Grant ELN Specific access rights
    3. Grant ELN Key-user rights
    4. 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. 

  1. Go to Google Groups and in the "All Groups" tab, please search for labbooster.
  2. 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.
  3. In the "reason for joining", please describe:
    1. your function
    2. the GCP BigQuery projects (batteries, coatings, materials) and environments (DEV, TEST, PPROD, PROD) you are interested in 
    3. the tasks you are supposed to perform (create tables, visualize data to check accuracy,...) 
  4. 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:

  1. Product Architect works with Enterprise Architect to align on high level/logical architecture.
  2. Product Architect works with Data Architect to align on high level/logical data architecture, e.g. data design, schemas, data flows etc.
  3. Product Architect works with EBS (Cloud Ops) team to align on GCP Solution Architecture.
  4. Product Architect & Product Manager present Architecture Impact Analysis (AIA) to Architecture Review Board (ARB).
  5. 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.
  6. Product Architect works with Security Architect to review security considerations for application/solution and gain approval to initiate implementation.
  7. Product Architect submits detailed request to EBS team to start implementation.


Architect roles


Architect TypesResponsibilitiesWho in LB
Enterprise
  • Ensure alignment with Enterprise standards and objectives
  • Provide Architecture Review Board approval for proposed architecture

Francois Garang 

Data
  • Provide guidance on data architecture design and data management
  • Ensure alignment with data strategy standards and objectives

JOAO PAULO FONSECA 

Solution
  • Provide architecture design to meet implementation needs of application/solution
  • Provide guidance on GCP services/tools and Solvay shared services to use for deployment
  • Ensure alignment with Cloud standards and objectives
TBA
Platform
  • Provide overall architectural approval
  • Assist in creating detailed technical architecture for application/solution
  • Ensure best practices adoption and re-use of shared services/components/templates
  • Assist in defining operational OKRs and KPIs
Alexandre Mathe 2 
Product
  • Work closely with product team members to inform and educate them on technology options, and their pros/cons, that could meet the business requirements of the application/solution to be deployed 
  • Draft technical requirements of application/solution to be deployed and present to all interested parties as required
  • Provide logical architecture design for proposed deployment
  • Coordinate with stakeholders and affected teams during all steps of the process
  • Collate, update and consolidate all information and artefacts required or generated by each step of the process
  • Oversee implementation/deployment of application/solution and assist in resolving problems or re-designing the architecture as and if needed

KRONTIRAS-ext, Pavlos 

Step-by-step guide

Below is a detailed description of the steps mentioned above.


Step 1 - 1 Product Architect + 1 Enterprise Architect

Stakeholders/ParticipantsInputOutput
  • Product Architect [Pavlos Krontiras]
  • Enterprise Architect [Francois Garang]
  • Project/Application/Solution high level functionality
  • Project/Application/Solution business logic & flows
  • Project/Application/Solution high level overview of expected services and tools for implementation
  • Validation to move into next phase of process
  • [Optional] Feedback re: misalignment with EA standards along with guidance and recommendations to gain alignment

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/ParticipantsInputOutput
  • Product Architect [Pavlos Krontiras]
  • Data Architect [Sébastien Ladouce / João Fonseca]
  • Project/Application/Solution input data sources
  • Project/Application/Solution data requirements
  • Project/Application/Solution business logic & flows
  • Data Architecture design 1st DRAFT
  • Validation to move into next phase of process


Step 3 - Product Architect + EBS

Stakeholders/ParticipantsInputOutput
  • Product Architect [Pavlos Krontiras]
  • Cloud Ops team [Alexander Henry Tejasukmana / Darren Ong / Li-Lian Tan]
  • Project/Application/Solution high level functionality
  • Project/Application/Solution business logic & flows
  • Project/Application/Solution high level overview of expected services and tools for implementation
  • Data Architecture Design
  • GCP Solution Architecture design 1st DRAFT
  • Validation to move into next phase of process


Step 4 - AIA Presentation

Stakeholders/ParticipantsInputOutput
  • Product Architect [Pavlos Krontiras]
  • Product Manager [Nicolas Roscetti]
  • Architecture Review Board
  • 1st Draft Data Architecture design
  • 1st Draft GCP Solution Architecture Design
  • Architecture Impact Analysis
  • Validation & approval for project implementation
  • Validation to move into next phase of process
  • [Optional] Feedback re: misalignment on level of detail or level of completeness along with guidance and recommendations to gain alignment

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/ParticipantsInputOutput
  • Product Architect [Pavlos Krontiras]
  • Cloud Ops team [Alexander Henry Tejasukmana / Darren Ong / Li-Lian Tan]
  • Platform Architect [Alexandre Mathé]
  • 1st Draft Data Architecture design
  • 1st Draft GCP Solution Architecture design
  • Detailed technical design
  • High level project cost estimates
  • High level project implementation plan
  • Validation to proceed with implementation request


Step 6 - Product Architect + Security Architect

Stakeholders/ParticipantsInputOutput
  • Product Architect [Pavlos Krontiras]
  • Security Architect [Fadi Bechara]
  • Detailed technical design
  • Validation to move into next phase of process
  • [Optional] Feedback re: misalignment with security standards along with guidance and recommendations to gain alignment

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/ParticipantsInputOutput
  • Product Architect [Pavlos Krontiras]
  • Cloud Ops team [Alexander Henry Tejasukmana / Darren Ong / Li-Lian Tan]
  • Vanenburg
  • Detailed technical design
  • SOW or other commercial approval for implementation work
  • Implementation kickoff
  • Detailed implementation plan




Error rendering macro 'contentbylabel'

parameters should not be empty

  • No labels