Development dependencies - Tips

Overview 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. 
  • 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) 

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