Document best practices for cross-domain-area collaboration
Follow-up from #3 (closed), related to the following four discussions:
In summary, we missed a deliverable because we only found out once the merge request made it to maintainer review that the approach that we had taken, that had been recommended by a domain expert before development started, did not actually fit well in the existing architecture. We had interpreted the recommendation by the domain expert as “this is the definitive way to go, so build it and we’ll sign off on it” rather than “I think this will work, but we won’t know for sure until we give it a try, so let’s talk about it more once we have some code in front of us”.
To prevent this from happening again or to other teams in the future, @fjsanpedro's suggested in #3 (comment 107185235) that when we have issues that involve an other team's domain, we should involve at least two people from the other team in the discussion of the issue. This way, we'd make sure we don’t accidentally treat one domain expert’s recommendation as the whole team’s recommendation, and prevent surprise when the recommended implementation is rejected by a different domain expert down the line.
Now that we have a cross-functional team for each DevOps stage, we are going to run into situations where one team wants to build a feature that requires them to make some amount of changes in another team's domain more and more.
I think we should start documenting best practices for collaboration like this, so we can all learn from the mistakes of those that came before us.
@fjsanpedro Would you like to make a start on this? I'm not quite sure yet where in the handbook it should go, but I'm sure you'll be able to find a place :) I think we can start with the recommendation discussed here, and leave expanding the section to the rest of the company.
/cc @jramsay @pslaughter @grzesiek @ayufan because you were involved in the situation in question in one way or another