[BD-03] Project Retrospectives

2021-04-07

What went well?

  • ADRs for shared clarity

  • Regular syncs to review UX

  • Producing ADRs and PRs in draft form for early, fast feedback

  • ADRs help us reach agreement on complex topics that are difficult to talk about in a meeting and keep in your head

  • More granular tasks are very helpful; both for visibility and sanity

  • We now have much clearer scope for upcoming milestones.

  • Everyone seems to be on the same page regarding project handoff

    • Handoff meetings went well

 

What could be improved?

  • Communication got better, but still could focus more on doing daily async standups

  • It’s not always possible to know in advance if an ADR will be needed for a task, and injected ADRs get harder to review.

    • architectural decision vs “how this task will be done” is a distinction that we may want to make here.

    • For this project (distributed, blended), may want to make assumption that ADR is a good idea, or ask project team for feedback when ticket is started if ADR is warranted

      • Want to reduce code churn / throwing away code / changing midflight

    • @Awais Jibran (Deactivated) Make a list of all the ADRs on this project because they’re spread across multiple repos

      • Note: we have an ADR bot - can search for BD-03 wherever this bot posts (should catch most, but possibly not all, ADRs)

      • Repos: fe-app-discussions, fe-app-course-authoring, edx-platform, xblock-lti-consumer

  • Need to agree on a level of detail in UX tickets that everyone’s comfortable with; David may have had enough context to make-do with less detail, but I think we’re learning that more might be helpful for folks onboarding into the project. Not really a ‘problem’, but something I think we’ll learn/work through together.

    • Mainly worth a call-out here; an adjustment to process

    • Current Miro board has a lot going on, maybe this could be broken up a little more for clarity

    • @Jon F volunteering to make a separate Miro board - deliverables only (finalized designs)

  • Hard to get code reviewed sometimes, which is problematic if you’re working on a series of PRs that sorta depend on each other.

    • seems difficult in general at times having differing time allotment/commitment between teams (eg, one of TNL on call in a given week, conflicting OC sprints, etc.)

      • Coordinate scheduling better - communicate on-call, interrupts, vacations, as in advance as you can

      • OC works they have stuff for review on second Wednesday of sprint; keep in sync with edX team to make sure everyone knows that’s coming

    • Try to prioritize reviews when you can

    • Can be hard with timezones on a lot of things

      • Timing may be easier with Awais & team coming on the project

  • Frontend test coverage is lagging

  • Reviewing milestones frequently to make sure we’re on track

  • Code refactors can be hard to rebase around so should probably be done in smaller steps.

    • Hard with stacked pull requests on top of some refactors

    • Smaller changes make it easier to do the rebase

  • Focus on incremental, user-facing delivery

  • Churn around who is going to implement Paragon components

    • need to involve Product, Eng Mgrs in discussions

  • Meeting host needs to admit people from waiting room;

    • somehow even though I’m the meeting host so did I? Or did someone take over host somehow?

    • it thinks Steven is host/admin

What did we achieve? (for sharing, demos, or simple visibility)

  • Working LTI integrations on the sandbox instance.

  • Piazza, YellowDig and potentially other LTI tools will now work. Discourse can work with some caveats

  • Infrastructure is there to support other kinds of LTI tools in course tabs as well.

  • All major structural work in frontend-app-course-authoring is done or nearing completion… we should just be left with smaller things and polish.

2021-01-05

What went well?

  • Everyone was really nice and didn’t want to take this first bullet - so I did!

  • Sandbox / Stage visibility of various project areas is helpful (for now and future work review)

    • Great to have as a foundation

  • More detail to specific v1 / v1.1 milestones

  • Earlier discovery and detail for v1.1+ milestones

    • (not done, but more planning than we have had in the past for this project)

    • also helps with UX sequencing / discovery work for post v1.1

    • the original discovery was another way of arranging milestones, new milestones had shifted starting point

      • ^ this note might relate to the “Reducing churn / rework” item in “what could be improved” below.

  • Intra team collaboration! Daily status in Slack, more productive checkin meetings discussing architecture etc

    • meetings with agendas is a win!

    • more specific technical conversations also in meetings (with documentation / notes!)

    • this has also helped with accountability (along with ADRs, etc)

    • more collaborative + collective team feel now compared to before.

    • helpful daily updates + status + 1

  • Beginning to collaborate with UX

    • @David Joy (Deactivated) try to work closely with Ange & Jon to keep collaboration tight

What could be improved?

  • Continuing to improve clarity on who’s doing what, i.e., individual tasks, parts of the project, edX vs. OC, etc. Nothing specific here, but just something that feels like it could keep getting better.

  • Consensus (on edX side particularly) of build our own vs discourse

    • nb. task on board to do discovery/spike and decide once & for all

  • Reducing churn / rework on tasks for future milestones

    • (v1 / v1.1 had a fair amount of reworked PRs / ADRs etc that spanned several weeks/months)

    • Improved clarity on what’s in each milestone will help here

    • Kshitij: since I’ve done discovery on different parts of the platform, assumed that was the starting point - this caused issues b/c think people weren’t familiar with that approach

    • edX time constraints in Q1 should be lessened going into Q3

    • Process wise: concerning whether or not our general approach is correct this late into the project (build vs discourse)

  • A focus on delivering value to learners / educators by certain ~rough dates now that we have the infrastructure for various discussions platform areas in place

    • This wasn’t as possible / clear in the past but hopefully can be soon!

    • Agree - it still feels difficult to provide estimates/dates, even for the early milestones. Not 100% sure why.

    • How to get clarity - point estimates - otherwise feels difficult to provide any sort of ballpark dates (need to understand the commitment of your team)

      • don’t have a baseline

      • do we have the appetite to do this?

      • When we get to a milestone, write a doc about all our assumptions and estimate the # of hours or even tshirt sizes would help us

      • Write down in epic in Jira

    • Have VERY precise AC on tickets to help estimate

What did we achieve? (for sharing, demos, or simple visibility)

  • ADR completed

  • Base configuration model(s) merged.

  • List of milestones & tasks laid out in Jira

  • Agreement and clarity on many technical details and on early milestone technical scope

Decisions

Action Items

@Sarina Canelake (Do Not Use) (Deactivated) Agenda item for tomorrow: Look at 1.0 & 1.1 epics

Anything else you want to talk about? (parking lot)

2020-11-10

What went well?

  • Scoping milestone 1 down into something we all understood

    • Worked well when we correlated our milestones w/ what PRs needed to be merged

    • More cohesive discovery/milestones was useful

  • Collaboration with Discussions + LTI project to land course tab LTI work early on

  • Great ADRs - they really helped me understand what was going on quickly.

  • MFE build / view of course authoring + discussion apps exist and are helping clean up platform boundaries along the way

  • Increasing the frequency of the meetings allowed for closer loops and quicker+better feedback +1

    • Deep dive technical meetings was really helpful; @Kshitij Sobti was really good at leading discussions. This synchronous conversations were good. Unclear where this type of conversation should go outside of this meeting

  • Shift away from relying on initial discovery documents is helping to focus on milestones

    • Pattern: Be flexible as we dive into the project

    • Antipattern: edX should help review technical discovery documents up front

What could be improved?

  • Earlier ADRs

  • Clear definition of “blended”/roles: is edx just here to review/sign-off, or should we be allocate development capacity too?

    • Sarina: answer: edX allocates dev capacity to be more involved in the process

  • Clear milestones/delivery plan from the outset (product + eng)

    • More technical engagement up front

    • Templates/collateral could be improved upon. Format matters, could help a lot

    • Original document hasn’t changed since it was written; should we have revisited this document to answer questions/make it a living doc?

    • What does “ready for kickoff” means? Needs definition.

      • Don’t think we were at this point when we started

      • Kickoffs should assign discovery ownership, go through unanswered questions, figure out lines of communication, figure out jumping-off points

      • Milestone kickoffs (mentioned down-ballot)

    • Outset: no discussions MFE; now, 1/3 of the project.

      • Smaller scope at beginning and not exploding scope is important

      • Antipattern: “It’d be cool if…” “If we have time…”: needs more elaboration on if these are actual scope changes or just things we want

  • Detailed technical discovery happened in a sorta ad hoc way, from my perspective; felt like we had a lot of unanswered questions fairly late in the game

  • Better thought partnership from edX from project kickoff - we came up to speed kinda late

  • For every milestone (and definitely at the start of the project), have a meeting focused on going over the discovery, and brainstorming any issues.

  • Role clarity on blended expectations for edx technical leads + opencraft leads on project tracking / sequencing

    • Who should step up? edX giving some priorities is helpful; OC focused on getting a lot done simultaneously, which has lead to some far-off PRs being opened

  • The initial discoveries, should have been more thorough (on OpenCraft’s side)

  • edX review speed / timeliness on discovery documentation + plans for future work

    • Review speed has meant stacks of PRs building upon one another in backlog

      • Major rebases needed when base PRs needed changes

      • Makes things difficult to review when multiple reviews in flight

        • Idea: more granular PRs? to review serially to get things in

        • Idea: initially create the dependent PR be based against the "parent" PR, and then, if needed, you can re-point the PR against master/main

          • Can’t do on edx-platform b/c OC on fork

          • Could we do reviews in OC repo? Don’t see why not

    • edX struggled with prioritization of reviews vs many other in-flight projects (mostly internal)

      • always a re-ramp-up to get back into the project

    • edX engagement in first few months was lacking. Make sure we’re involved more thoroughly in every step

      • Originally had thought the 1000' view would be enough, but we’ve seen it not work well

      • Need to be involved in the code to a degree that we can be confident in releasing it to edx.org

      • Difficult to review - haven’t been able to get ahead of this

    • OC: not sure where to go next

      • ADRs have been helpful in development - forces a more clear definition. Helpful mental exercise

    • edX issue: multiple Jira tickets limits visibility of what’s actually going on (OSPR, BLENDED, TNL)

      • Need one canonical ticket - Kshitij recommends the TNL ticket; BLENDED just manages the ticket itself

  • limiting threads + active project scope to limit WIP and rewrites (related to clear milestones perhaps)

  • Fragmented/tons of documentation (particularly, in edX wiki) makes it hard to get up to speed

  • Better understanding of cross-project dependencies.

What did we achieve? (for sharing, demos, or simple visibility)

  • the initial working prototype for the new discussions app I’ve seen looks great

  • there is a demo (based on older code) of Piazza embedded in the course discussion tab

Decisions

Action Items

@Kshitij Sobti / @sburch (Deactivated) / @Piotr Surowiec Figure out proper branching moving forward (for big/stacked PRs)
@Sarina Canelake (Do Not Use) (Deactivated) figure out how to streamline tickets on Jira board (how do we track OC TNL tickets? What do we need our board to look like?)
@sburch (Deactivated) & @Kshitij Sobti & @Piotr Surowieccome up with a recommendation for how to handle TNL/BLENDED tickets in a sane way
@Sarina Canelake (Do Not Use) (Deactivated) & @David Joy (Deactivated) to work out BD-03 sharing time
@Sarina Canelake (Do Not Use) (Deactivated) / @Marco Morales (Deactivated) to plan Milestone 2 “kickoff” after doing M2 scoping
@Sarina Canelake (Do Not Use) (Deactivated) set up another retro

What’s next? (Nov/Dec goals)

Anything else you want to talk about? (parking lot)

  • Does current communication work for the team (#forums in Open edX slack, PR/BLENDED/TNL ticket comments, weekly checkins)?

    • Synchronous working well

    • Async not so much

      • Idea: have most comms on TNL tickets, and review on PRs themselves

      • Not use BLENDED tickets for communication

      • For decisions/posterity, record project decisions & important for posterity stuff in project pages in Confluence

    • How should edX surface TNL tickets assigned to OC so we don’t lose them?