One of my best agile experiences was with a fully remote development team based in Gdansk, Poland. I was in London as the Technical Business Analyst alongside the Product Owner.
We met up in person once per month, sharing the plane trips back and forth, and a decent headset made daily Skype calls very easy to have, even in a noisy office.
We collaborated much better than some co-located teams Iโve worked in previously, focusing our efforts on writing well defined user stories and conducting frequent backlog refinement sessions, usually several times per week but always in advance of each sprint planning session. Clear definitions for story โreadyโ and โdoneโ really helped as well.
Unsurprisingly, the user stories were really well understood by the time a developer picked them up, and it was incredibly rare for work to become unexpectedly blocked or delayed.
One drawback of local development is the temptation not to write really good user stories and the temptation not to hold regular backlog refinement sessions. โWe are too busy writing codeโ is the most commonly used excuse. What happens then is each time a story is picked up for development, there is a hope and a prayer that no unexpected show-stoppers emerge to break the sprint goal and trigger the need to down tools and re-plan. Good remote development demands a diligence that ensures this never occurs.
Working effectively in a distributed team is definitely possible, and this experience taught me a heap of valuable practices I still use in remote setups or face-to-face settings. Best of all, the product we built was fantastic.