Beroenden mellan projektgrupper verkar svårt att hantera (det kan vara ett lokalt problem, men jag väljer att låtsas att det är mer allmängiltigt).
Även om små, sammanhållna och seriella projekt verkar vara en ganska populär strategi kan jag ganska sällan i min roll som tjurig utvecklare styra hur projektportföljen ska förvaltas. Däremot har jag en del chanser att påverka hur arbetet fortlider när projekten väl är igång.
Fowler presenterar en intressant modell där SOA-tjänster utvecklas i open source-stil, så att team i beroendeställning kan agera patch-bidragsgivare till en tjänst de är beroende av.
Jag tror inte det här behöver vara specifikt för SOA-sfären, utan snarare att projekt som använder tjänsteorienterade arkitekturer kanske karakteriseras av en viss storlek och flera parallellt aktiva team. Det vill säga; alla projekt över en viss storlek (mer än ett team) skulle kunna koka ihop något i den här stilen oavsett vilken arkitekturstil de råkar använda.
Fowlers vårdnadshavarmodell har mekanismer för att provocera fram kommunikation mellan två team i ett beroendeförhållande och det skulle man kunna spinna vidare på.
Exempelvis, genom att så länge det finns ett beroende i någon riktning kräva en aktiv representant på varandras dagliga stå-möten. Det borde stimulera teamen att hålla varandra uppdaterade på sina respektive behov och planer.
Eller genom att arrangera utbyte mellan teamen så att teamet i beroendeställning får en representant som kan arbeta med deras behov i deras kontext. På så sätt ökar man chanserna dramatiskt att rätt problem löses på rätt sätt.
Ett fokus på kommunikation och samarbete torde kunna mildra problembilden väsentligt.
Grundlig eftertanke 
Jag gillar tanken på att ha ”intern open source”. Jag försökte förespråka det lite grann hos en kund för några år sedan utan att få gehör, tyvärr. Det skulle kunna lösa en hel del knutar relaterade till interna beroenden.
Hos samma kund så förekom det med viss regelbundenhet att olika projekt som upptäckte tillkortakommanden i mer centrala (men egenutvecklade) komponenter, istället för att lägga en change request på den centrala komponenten började utveckla mer eller mindre komplicerade workarounds, enbart av det skälet att man då visste vilka resurser man lade ned på problemet, istället för att gå den osäkra vägen och vänta på en lösning från ett annat projekt. Det ledde givetvis till att flera projekt riskerade att ägna resurser på att lösa samma problem.
Hade man här arbetat lite mer i open source-anda, så skulle man kunna låta projektet som upptäckte problemet lägga in resurserna för att arbeta fram en lösning (samma resurser som de ändå använde för en workaround som sannolikt riskerade bli mer komplicerad än den ”riktiga” lösningen), samtidigt som flera andra projekt skulle kunna dra nytta av det. Det skulle ju givetvis vara till gagn för företaget i ett större perspektiv, men det är ett perspektiv som jag tyvärr ofta tycker saknas inom projekt- eller produktteam.
Jepp, helt klart.
Glöm dock inte att kommunikationen är vital, risken är att om projektet som upptäckte problemet löser det, måste det göras om på ett eller annat sätt innan det accepteras i mottagande kodbas.
För att undvika dubbelarbete är det alltid bra om lösningen godkänns, granskas och stöds av mottagande team.
Och ibland saknas kompetensen i teamet med problemet, då kan utbyte av olika slag vara en hållbarare lösning.