Page Comparison

Overview 

Status
subtle true colour Yellow title

In Progress

A development dependency (for purposes of this page) is when a development effort requires requirements/work/support from more than one team. As FOLIO continues to grow, it is important that we have a common understanding for how to handle such dependencies. The key to successful handling of dependencies - Communicate as early and often as possible.

Dependency scenarios 

• Changing workflow (Example: ) 
• Shared apps/workflow (Example: )  
• Shared backlog (Example: ) 
• Require development from another team (Example: ) 
• Developing in a module that is owned by another team (Example: )  
• Developing in a module where multiple teams contribute code (Example: ) 
• New development team (Example: ) 
• Integration (Example: )

Best Practices for handling dependencies successfully

Still vetting/refining requirement.

•  No change to current process for validating requirements AND so assume (if applicable) that requirements have been reviewed and refined with respective SIG(s)
•  PO (with a dependency) > Please talk with the PO(s) that own the module/app/workflow. Provide the following details 
  •  High level overview of the change 
    •  Provide a link to the Jira feature/user story/bug that documents the requirement(s) and user expectation(s)
  •  Recommended timing for this action: as soon as you have an understanding of the requirement and ideally before release scope definition deadline. 
•  Outcome
  •  Agreed upon next steps including who owns writing or implementing requirement and timing 
  •  Agreement to peer review requirements to ensure alignment
  •  Communicate <-> Collaborate.... Communicate <-> Collaborate

Team with dependency is planning/preparing for release to implement 

•  PO and Dev lead (with a dependency) > Please talk with the PO(s)/Dev lead(s) that own the module/app/workflow. Provide the following details. 
  •  High level overview of the change High The module owner team gives a high level introduction of the module/suite of modules for the developers who is to start working in these existing modules
  •  High level overview of the change
    
    •  Provide a link to the Jira feature/user story/bug that documents the requirement(s) and user expectation(s)
    •  Technical design 
  •  Recommended timing for this action: as soon as you have an understanding of the requirement and ideally before release scope definition deadline. 
•  Outcome
  •  Technical design and approach alignment
  •  Development efforts per team including timing for when dependencies will be ready 
  •  Testing approach (including QA test coverage) 
  •  PR reviews alignment
  •  Definition of done alignment 
  •  Document agreements and implementation/testing plan
  •  Communicate <-> Collaborate.... Communicate <-> Collaborate

During development and testing 

•  Jira epic/feature should link to all dependencies 
•  Recurring meetings between POs/QAs/Dev leads to check-in regarding development and testing progress. 
•  Attend applicable development ceremony activity (e.g. daily stand-up, sprint demo, etc.)
•  POs/QAs responsible for module/app to participate in PO/QA/SME verification at the end of each applicable sprint.  
•   Communicate <-> Collaborate.... Communicate <-> Collaborate

Before Bugfest

•  e2e testing has been done before Bugfest (at least 2 weeks) 
•  Demo has been done that includes applicable SMEs/POs/QAs/Devs to ensure alignment (at least 3-4 weeks before Bugfest) 
•  Communicate <-> Collaborate.... Communicate <-> Collaborate

Ideas for communicating across multiple teams (please add your thoughts) 

•  Dedicated slack Slack channel for more complex dependency management management, or the SIG slack channels 
•  Wiki page(or meeting notes) that is the source of truth and includes a decision log (when applicable)