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: 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
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 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: 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
|
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?
- Doing this work takes longer now, but should save us time post-launch
- Only one more ticket that should require big changes/refactoring before MVP launch
- Refactoring now vs. later - NEED PM REVIEW FIRST:
- What's the LOE now vs. later
- Allows PM to decide on prioritization
- BE changes are happening to fix dependencies, so they're not really unavoidable right now
- Sean doesn't merge BE changes that would break FE until a FE ticket's created that fixes those issues
- Request: provide info on where changes are in PR (see GraphQL files)
- 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
- Sean pings FE channel when changes are required (keep doing that)
- Once amount of work is determined (ex: decent amount of work that will affect timing), bring up to PM
Next steps in alerting PM: - Determine BE & FE impact
- What is the LOE/scope increase
- Reach out to PM to discuss priority
PR's (top priority): - Need FE help - they take a really long time
- Christian is no longer a PR approver - who else can we add?
- "Rotation" meaning communication between default reviewers to ensure folks aren't duplicating effort on reviewing the same tickets unnecessarily
- Reduce size of PR's if possible
- FE/BE sync - call out PR & have separate call to walk through and hopefully review quicker
Distribution of work on PTO: - Chat with PM to cover work if needed
- Share info with other Devs in case questions come up
UX may not update Figma files if PM descopes: - We'll make sure Jira is update and is the source of truth - responsibility on PM to denote changes in testing instructions
Process standards still being worked on: FE Devs us QA instead of locally? - Quick FE changes directly to QA?
- No "garbage" data
- Allows for different viewpoints
- Technical Roadshow: go over similarities
- Zaengle doesn't have access to some apps
- If they can't, definitely need to need to point to QA
- Sounds like they should be able to without this - need to follow-up with Christian
Segment setup needed from ECM: - Henry, Lakshmi & Surya to talk to Jose about the
Staging environment: - Lack of data causing instability
- Maybe use Staging like a "test" for now until we go live, then ensure Staging has accurate/clean data
Fetch QA token: - No real emails sent out - impossible to fetch right now
- Setup local email? Mailtrap (Christian has more info - looking into setting up)
| - Alyssa: Share fist-to-five info with leadership & determine next steps
- Team: Make sure to alert PM so they can determine priority when
- BE/FE changes will impact each other
- Scope/LOE changes
- Devs: Determine how to handle PR priority
- EM’s/Devs/QA: Determine process for distribution of work when on PTO
- Zach & Isaac: Process standard documentation
- ECM: Segment setup (do we have a ticket # to follow?)
- Team: What are we doing about the Staging environment for now?
- Christian: Mailtrap setup?
|
6/26/2023: Q3 Quarterly Planning Week  | Shared components - need improvements: - Be more vocal about recognizing shared component opportunities during refinement/design review
- When creating a component that may be shared, call it out for feedback to ensure flexibility
- Jasmine’s doc will call our pre-existing components
- Once Storybook is implemented, this should replace that
- More granular breakdown of design into more component-based views
- Look at components from library instead of using part of one and having to make others
- Call out in FE Slack channel to see if component has been worked on before starting a new one
- Communication before/during work has helped
As details emerge, update Jira to reflect necessary updates: - Testing instructions needed/changed? AC accurate? Impediment/blocker?
- Devs to ensure testing details are up-to-date
- Only PO should update AC
- Link tickets & add comments with detailed information
- More info is better
| - Blue dot to go back to Tuesday/Thursday in-person DSU
- Cross-team Retro once/month (start on 7/25)
|
