Super Nurse Shared Retros

Date

Meeting Notes

Action Items:

Date

Meeting Notes

Action Items:

10/9/2023:
MVP Launch Retro 10/9/2023

Alyssa’s summary below - team will add comments to each group directly on the Retro board.

Group 1 - lack of critical resources/empowerment:

  • Should have had this sort of thing months ahead of time

  • Money shouldn’t be an issue like it was - if we want this done, we need those resources provided to us

  • Could we have done this in smaller chunks?

    • Not really because of all the dependencies

    • The way the project was setup didn’t allow for that really (not ideal)

    • Next time - work across teams (Eng/PM) to see what we can split out and release in increments

    • Hopefully will be easier going forward

  • Devs not having a voice at the decision table - received tasks vs problems and allowed creative/effective decision-making

Group 2 - splitting teams:

  • No feedback during call - hopefully folks will add comments to the retro board

Group 3 - regression testing:

  • We spent a lot of time manually QAing

  • It would have been helpful to come up with a plan for how we could take that process and automate it (as much as we can)

  • We know manual testing is still important - want to try and cut down on that time

  • Create QA ticket along with the BE & FE ticket that walks through the automation process for that specific functionality

  • This can be expensive in the long run

  • Communication/documentation/view of expected functionality will help

    • Relates to the communication group later

Group 4 - communication gaps:

  • Keeping threads on conversations makes things so much easier to look through and prevents messages to get buried

  • Mockup/requirement changes caused rework and delays in start time

  • Missed communication outside of the war room group vs the rest of the group, decisions/communications happening in smaller groups/DM’s vs everyone having the same understanding

  • Need to focus on key players having communication lines between other departments as opposed to having too many side convos with different decisions being made

  • We had large teams, and recently really large meetings, which didn’t allow for some of those smaller/in depth conversations

  • Use standup as a time to share this important information to the group - make sure to focus on what everyone else is saying vs just your feedback

    • Proper standup format: What are you doing today? What did I do yesterday? What are my blockers?

    • Not to spend time updating the board - though we kind of did this toward the end of the project, but this should not be the standard going forward

  • Jira comments & updating ticket details are key

    • Make sure to use them to request feedback/direction, sharing decisions, etc.

    • Ensure Jira is the source of truth & includes all necessary information so anyone that views the ticket knows what expectations are, what’s required, etc.

  • Allow flexibility between teams to function the best for them as long as final decisions are tracked the same way

Group 5 - deployment to production:

  • No feedback during call - hopefully folks will add comments to the retro board

  • Info from Christian:

    • BE: Integration to Stable > triggers deployment to Staging >

    • FE: ““ > deploys Staging automatically > requires you to click a button and it triggers the FE deployment

    • Magento: not ideal - needs work

  • Working with ECM team to improve Terraform

  • Don’t need Mangento locally to preview profile views - work with Christian if you have questions on how to do this

  • Discuss decoupling Magento/Craft outside of this call

Group 6 - lack of autonomy:

  • Devs not having a voice at the decision table - received tasks vs problems and allowed creative/effective decision-making

  • Not able to share feedback on a better solution - needing to do things one way right now

  • Constraints kind of forced us to “have to do things this way” even if there were more efficient options - time crunch didn’t allow for this

Group 7 - access issues:

  • Discuss with ECM/DevOps on what everyone needs and ensure they have it as soon as possible so they’re not delayed

  • Are things broken? Discuss further outside of this call..

  • Group based access that allows for permissions to be added ahead of start date, ensure they’re accurate, etc. so no has to figure out they don’t have what they need and need to request it

  • Revisit permissions and determine if some need to be taken away and some need to be added

Group 8 - hot fix process:

  • Good call out on this - planning doc being worked on right now

  • Changing branching strategy to allow automated deployments as necessary

    • Pull down from whatever environment, submit fix, etc.

  • Current process is everything on staging ends up going out - not ideal

  • Unfortunately we ran into crazy late night work which resulted in getting code out as much as possible and not giving time to review every single thing ahead of time

  • This shouldn’t happen in the future

We should have tested Segment:

  • Needed a stronger touchpoint with data team

Code quality and defensive coding practices:

  • Rushed to get things out the door

  • Commends in group 8 above

  • Had to decrease code standards in order to allow tickets to not get caught in the workflow

  • Christian/Ashley/Adam to discuss if/how we need to put them back

Commits should have associated tickets for tracking:

  • Not individual Jira tickets for each commit, but each commit should be linked to the related Jira ticket

  • Commit name should include “SUP-____”

  • Revisit Bitbucket commits and determine requirements, workflows, etc.

Group 9 - data security concerns:

  • Conversation needed with InfoSec to determine what we can/should be providing

  • Sean’s had requests for data and we need to know what expectations are

  • Matt, Brandy & Raymond are meeting with SysMan to discuss this

  • Deidentified data, should people have access, etc.?

Visualizations within Jira tickets:

  • Bold, colors, bullets, etc.

  • Workflow changes: testing instructions required before moving tickets into to do so they don’t start work before all expectations are called out

  • Paperwork is part of our jobs - necessary to keep everyone in the loop and ensure understanding across the board

Ensure everyone understands what team they are part of going forward

10/4/2023:
Fist to Five & Retro 10/4/2023

 

9/5/2023:
Fist to Five & Retro 9/5/2023

  • Async feedback

  • Will discuss as a team during 9/11/2023 Retro

 

Review previous action items:

 

7/25/2023

Notes in Miro
Includes Sprint 14:
7/12/2023-7/25/2023

Fist-to-five - unanimously 2:

Still have a lot to cover from the automation piece, requiring refactoring as code changes, testing, etc.
Automation may not technically prevent us from launching, but it's struggling to get off the ground, and will really helpful once we have it - will push us through quicker
Potential for missing bugs given fully manual testing
Requesting requirement/UI updates part way through development as questions/concerns arise
A lot of manual file changing as reqs change (i.e address format)
BE changes cause FE changes
What refactoring can/should wait?
Refactoring now vs. later - NEED PM REVIEW FIRST:
BE changes are happening to fix dependencies, so they're not really unavoidable right now
Bri & Sean pulled cards out of the initial launch
Anytime we know BE refactoring work is required, pull in smaller groups (EM/PM, specific Devs, etc.) to determine next steps

Next steps in alerting PM:

PR's (top priority):

Distribution of work on PTO:

UX may not update Figma files if PM descopes:

Process standards still being worked on:

FE Devs us QA instead of locally?

Segment setup needed from ECM:

Staging environment:

Fetch QA token:

6/26/2023: Q3 Quarterly Planning Week

Shared components - need improvements:

As details emerge, update Jira to reflect necessary updates: