2018-12-07 Team Lead Meeting Notes

Owned by Wesley Brown
Last updated: Dec 07, 2018
3 min read

Attendees

Discussion Points

  • Gap Retrospective Meeting Update
    • Going Well
      • Teams have learned and are utilizing the VR dev process
        • Sam: We should ensure that our documentation reflects the current process
      • Teams have gained familiarity with the microservice arch
      • Teams are helping each other
      • A lot of high-value, high-quality work has been completed!
    • Improvements
      • Suggestion to update the Showcase meeting
        • Ashraf: Link work to the product roadmap, more focus on features rather than specific tickets
          • Showcase the progress on a feature
        • Sebastian: Provide more context for work that is being done, how is this getting us closer to our product goals
        • Clay:
          • Team-specific showcases. Other teams can join but focus is for the specific team
          • Each team provide an overall summary
        • Sam: Interested in the team-specific showcase, will get feedback from team
        • Craig: Why are we doing the showcase? Is it to list the work that is done or something else?
          • What is the value for the different roles that are involved
        • Wes: Worry about team-specific showcases causing us to become more siloed
          • Sebastian: Like to hear about what the whole community is working on
        • Clay: Keep current showcase time but only have each team leader join for the whole thing
        • Wes: Focus on high-level for showcase
          • Ashraf: Leave it up to team leads to decide what to showcase and allow for an opportunity for feedback from community
          • Sam: Ticket-level discussions can lead to important insights and requires teams to spend the time to fully think through work. Applies some level of ownership to the person/group showcasing the work
      • Can be difficult to keep the longer-term goals in mind when working on 2 week sprints
      • Are Story Points the best way to capture our work?
        • Would it be easier/better to log actual hours spent on the ticket?
          • Craig/Sam: To granular
          • Sebastian: Story points are not really meant to track work, not sure of another alternative
          • Ashraf: Not perfect but not sure what is better. Learn how to utilize SP's and accurately represent work done
          • Craig: Significant management and community involvement and testing/qa etc are not reflected in SP's. Ensuring that this work is somehow included in the messaging to the consumers of this data
            • Ashraf: There are other KPI's which show our work
      • Looking to get a more consistent velocity
        • Two causes:
          1. Current tickets/usage are not reflecting actual work done
          2. Team resources can fluctuate and result in less work in a given sprint
      • Streamline the dev process
        • Current expectations may require too much overhead
  • 3.5 Testing/Release Update/ Other tasks for teams

Mind the Gap (Sam):

  • 3.5 Testing
  • Designing/Writing tickets for 3.6 work
  • Splitting requisitions for multiple suppliers

Parrot (Sebastian):

  • 3.5 Regression Testing
  • Releasing RCs
  • Adding more functional tests in free time

Ona (Craig/Clay): 

  • 3.5 Testing
  • 3.6 scoping, waiting for feedback based on discussions

JSI (Ashraf):

  • Update tickets for 3.5 release
  • Complete remaining tickets
  • 3.5 Testing
    • Creation of tickets for bugs found during testing
  • Shipment file import... has it been tested?
    • Core features are complete but edge cases are not yet complete
    • Sam: Joanna has been involved in testing and so this work has been included for 3.5

Action Items

  • Wesley Brown to gather feedback from teams (start with Craig?) regarding working with API and services
  • Sebastian Brudziński, Sam Im (Deactivated), Ashraf, Craig Appl (Unlicensed) add code freeze tasks to the next sprint as we are working in the sprint. We know that this will impact velocity for this sprint, but that's ok.
  • Ashraf will follow-up with Wes on the identified risks and mitigation strategies
  • Wesley Brown to review current dev process documentation and update according to current expectations/process
  • Wesley Brown to push discussion about velocity and dev process to later team lead meeting.
  • Sam Im (Deactivated) after the release is done, then Sam will send out a release retrospective survey

OpenLMIS: the global initiative for powerful LMIS software