CPS Retro - 04/06/2024

[ 1 Participants ] [ 2 Retro Points ] [ 3 Retro Summary ] [ 3.1 Actions from last retro ] [ 3.2 What can we do better??? ] [ 3.3 Actions ] [ 3.4 Call outs ] [ 4 Next Retro Date: ]

Participants

@Toine Siebelink
@David McWeeney
@Lee Anjella Macabuhay
@Halil Cakal
@Gerard Nugent
@Sourabh Sourabh
@Seán Beirne
@Priyank Maheshwari
@Daniel Hanrahan
@David Donnelly
@Levente Csanyi

Retro Points

Some things to think about:

What did we do well, that if we don’t discuss we might forget?
What did we learn?
What should we do differently next time?
What still puzzles us?
Which tools or techniques proved to be useful? Which not?
What is our biggest impediment?
If we could change 1 thing, what would it be?
What caused the problems that we had recently?
Which things went smoothly? Which didn’t?

Retro Summary

Actions from last retro

See Actions: CPS Retro - 09/04/2024

Owner	Action Item	Notes	Team Rating

Owner	Action Item	Notes	Team Rating
@David Donnelly	To raise lack of access for CPS team on E code or environment	same as before: no access given yet but for the last performance bug , @Priyank Maheshwari were able to work and collaborate with the E team via screen sharing and for the given problem it has worked as a good solution
@David Donnelly	(Escalation) To communicate with E to define roles/responsibilities in terms of epics/stories/prioritization decision making .	needs to be followed up for the next retro	---
@Kolawole Adebisi-Adeolokun	Meeting/Workshop with E. to have an understanding and know their set up for tests KPI	Done - Team and E had a workshop to discuss this
@Daniel Hanrahan	Bug acceptance criteria meeting	Done
@Daniel Hanrahan	Cross team meeting on new way of implementing user story breakdown	needs to be followed up for the next retro	---
TEAM @Toine Siebelink @David McWeeney @Lee Anjella Macabuhay @Halil Cakal @Gerard Nugent @Sourabh Sourabh @Seán Beirne @Priyank Maheshwari @Daniel Hanrahan @Levente Csanyi	ALWAYS COMMENT if you have looked at a code - do state you reviewed and no comments.	This has been working fine as commits are reviewed early and quicker than before
	Pair Programming- call these as needed Be open to it, aware its an option Example - if lots of comments on a code review - call a pair programming session.	This has also been more used since last retro i.e. priyank and lee anjella for subscription
	Submitter should know the 3 reviewers on a review - and call the priority OK to ask people for code review - especially if urgent (i.e to get review same	Applied by team members and working very well

What went well???

What can we do better???

Actions

Owner	Action	Notes	Due Date

Owner	Action	Notes	Due Date
@David Donnelly	(Escalation) To communicate with E to define roles/responsibilities in terms of epics/stories/prioritization decision making .	Action from last retro	Next retro
@Daniel Hanrahan	Cross team meeting on new way of implementing user story breakdown	Action from last retro	Next retro
@Daniel Hanrahan	Clarify names on the tests (i.e. Integration tests) and create guidance for team		Next retro
TEAM @Toine Siebelink @David McWeeney @Lee Anjella Macabuhay @Halil Cakal @Gerard Nugent @Sourabh Sourabh @Seán Beirne @Priyank Maheshwari @Daniel Hanrahan @Levente Csanyi	On user stories - (E) be clear on acceptance criterias before starting especially when working with bugs use right level of Jira creation i.e. 'user stories' 'sub tasks' description on Gerrit for code reviews		Recurring
	On bugs - say 'NO' more often especially when there is not enough information!		Recurring
	On release notes - Update release notes with commits if possible Note to add it on acceptance criteria (if it makes sense)		Recurring

Call outs

Next Retro Date:

Jul 2, 2024