Core Platform - Retrospective / Action Plan

Core Platform Retro board: https://easyretro.io/publicboard/RafsurmL5WV1R3DtSGoLA8qCC5q1/ce67b86f-c511-47e4-a812-a95ea665af73

You can add cards in advance and we will review on the next retro

Action PlanNotes
November Retro 
  • Engage operators, dev ops, security team  to conversation and get feedback from them to decide which improvements can be done. Jakub Skoczen / Dilshod_Khusanov  organize this conversation


  • Come up with long term objectives for the next release and later discuss on TL. Julian can provide and input. Jakub Skoczen  will create document to provide Objectives


September Retro
  • Update User story for Improving documentation for working with scratch env -

Steve Ellis

Done
  • Create User Story for Creating jenkins job to allow for platform complete deployment to scratch - 

Steve Ellis

Ongoing. I didn't create a user story but the dev ops people are actively working on improving the Jenkins pipelines to build the scratch environments.
  • Add this part to the US about creating jenkins job for platform complete Consider creating a rancher/k8s reference environment for platform complete - Steve Ellis

  • Create User Story "Improve folio-helm repo with better container defaults for ram and cpu" - Steve Ellis

Done - This has been covered in RANCHER-59 - Getting issue details... STATUS .

  • document experience of running Karate tests against rancher env  and share/demo this for other dev teams - Steve Ellis
Done
July Retro
keep doing this
  • Emphasize one more time to management and stakeholders that CP team has not enough resources to accomplish  tasks. OL took a lot of time but still not done. We can't commit to anything with this set up - Jakub Skoczen

keep doing
June Retro
keep doing
keep doing
keep doing
April Retro
  • Hanna Hulevich Email to Anton and ask about progress with test  env 

  • Jakub SkoczenTalk to  devOps about creating snapshot env for CP team only and grand CP with all required perms
we did not need this for R2. wait for Abdu to create env (Hanna check with Abdu)
keep doing

keep doing
keep doing
February Retrospective


keep doing
keep doing
keep doing
2020

Retro board link - Sprint 56: https://funretro.io/publicboard/DEeWRRqubCaQXm7WfKdjSZfC3wK2/-LYC7zUogkzCb1L-kjlT

Retro board link - Sprint 57: https://funretro.io/publicboard/DEeWRRqubCaQXm7WfKdjSZfC3wK2/-LZEjgi7I9h-MaMVbKvy

Retro board link - Sprint 59: https://funretro.io/publicboard/uhS7lurEs9WACO0ZcntIKkeLqUq1/-La1-uNe83Y7e7s0DpVp?pageId=14459935

Retro board link - Sprint 64: https://funretro.io/publicboard/uhS7lurEs9WACO0ZcntIKkeLqUq1/-LeqW9y38TmHZ22UOOaj

Retro board link - Sprint 69: https://funretro.io/publicboard/uhS7lurEs9WACO0ZcntIKkeLqUq1/de9a18bd-dfc0-406d-95d8-8db4040b6106 

  • Add detailed acceptance criteria before story estimation

  • Keep meetings as short as possible

  •  Groom stories before sprint starts

  • Organize grooming backlog in streams (Devops/Backend/Common)
Not effective
  • Form working groups about particular tickets outside of stand-ups

  • Verify that issue is not blocked when including in the sprint

  • Try not to add stories in the middle of the sprint

  • Reserve some bandwidth to operational issues

  • Become familiar with the ticket before grooming.
Effective
  • Conduct two grooming sessions for Devs and DevOps.
Not effective
  • Limit discussion for 1 ticket to 10 minutes during the grooming.

Check with the team if we are going to spend more time on it after 10 minutes

  • If we groom a story and there is not enough description - we move it into the DRAFT status and don't pick up into the sprint.

  • On standup inform the team (+ creator of the story) when more description is needed.

All big features should start with an investigation.
Then it should be discussed with a group of engineers.
The feature should be 'drived' be someone.
We should have a special event in order to discuss a big solution. Raise a request for such an event during the daily scrum.


Set up times to review spikes / new infrastructure. Either synchronous or start PRs early for review.


Each spike should have some outcome: a document, PoC and it should be reviewed by the team.