CPS Retro - 09/04/2024

Participants

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 - 12/03/2024

Owner	Action Item	Notes
David Donnelly	To look at enabling access for CPS team on E code , tests and test env + collaboration with Ericsson *load tests teams is important	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	To talk to ETH regarding Delay in ETH Taking Deliveries; funtional OK, functional regression testing ; performance is where the delay , we are working to improve NCMP UCS in our design test env.	Collaboration has been better but still needs improvement in terms of testing a new release, for the uplifting of spring boot, PO has asked for 'green light' from E team if they are ready for a new release and once given CPS has created the release and ETH is now testing the current release
Toine Siebelink	Set Calendar for Regular Retros - Every second on site day - every 4 weeks.
Daniel Hanrahan	Need to train a performance second / third person in the team!	Halil is now also working on performance related items. Further training still needed
TEAM Toine Siebelink David McWeeney Lee Anjella Macabuhay Halil Cakal Gerard Nugent Sourabh Sourabh Sean Beirne Priyank Maheshwari Daniel Hanrahan Levente Csanyi	Resolve too many meetings	See Decisions on meetings
	Use Daniel’s idea on user story breakdown for DCM Async Datajobs Gerard Nugent & Daniel Hanrahan	Has not been implemented as much as DCM story has been blocked for planning
	ALWAYS COMMENT if you have looked at a code - do state you reviewed and no comments.	only 2 or 3 people has implemented saying they have 'looked at' the code or 'started looking at it' and will continue.. without giving any +1 or +2 not as much applicable since the last retro as there hasn't been too much commits up for review especially from team 1 action reinstated for team to keep remembering
	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.	not as applicable since last retro (holidays being a blocker)
	Discuss Definition of Done	See CPS Definition of Done (and FSA)
	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