My strategy has been to find another lead or senior level "counterpart" on the offshore team who I can delegate things to, who can then delegate things to the offshore team. Obviously you probably shouldn't just leave it all up to them, but especially for design/architecture related things, instead of having to communicate asynchronously with say 5 developers, it only has to be 1.
Even for architecture discussions I would try to have some time once per sprint where I woke up really early and discussed things with the offshore team to make sure they understood why decisions were made, what the business implications were (how their code tied into solving business problems), and ask for any feedback on designs.
We usually had 1.5hr overlap / day, but most of that time was spent in standup and user story refinement sessions.
If you can at all, I;d try to get the offshore team to be present for at least part of user story refinements. I've found it crucial for developers (especially offshore since they're asynchronous and can't just walk over or ping a business person) to understand the business requirements and ask clarifying questions. It's usually the developers first who figure out that certain business requirements either aren't feasible or will take too long to accomplish. And without having a good understanding of this up front, it's easy to find out halfway through the sprint on something that will be too big but you already committed to.
As far as getting more comfortable with "giving up the work", what I've found helpful is to go through each user story / or larger grouping of tasks and either do a design doc (sequence diagram, etc) or briefly pseudocode it out.
This accomplishes two things:
you get to still be involved with those pieces of work
you get to make sure those tasks are actually achievable by the developers on your team
Playing the "architect" role in that way has always proved to be very helpful for me, and the rest of the developers I may be delegating things to.
Lead Developer: Adobe Experience Manager.
Father of one.
Minnesota.
Occasionally write here: ahmedmusallam.com and there: https://blogs.perficientdigital.com/author/amusallam/
This sounds like a great middleground and the more I read your comment the more reasonable it sounds. Thank you! This is definately steering me in the right direction!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My strategy has been to find another lead or senior level "counterpart" on the offshore team who I can delegate things to, who can then delegate things to the offshore team. Obviously you probably shouldn't just leave it all up to them, but especially for design/architecture related things, instead of having to communicate asynchronously with say 5 developers, it only has to be 1.
Even for architecture discussions I would try to have some time once per sprint where I woke up really early and discussed things with the offshore team to make sure they understood why decisions were made, what the business implications were (how their code tied into solving business problems), and ask for any feedback on designs.
We usually had 1.5hr overlap / day, but most of that time was spent in standup and user story refinement sessions.
If you can at all, I;d try to get the offshore team to be present for at least part of user story refinements. I've found it crucial for developers (especially offshore since they're asynchronous and can't just walk over or ping a business person) to understand the business requirements and ask clarifying questions. It's usually the developers first who figure out that certain business requirements either aren't feasible or will take too long to accomplish. And without having a good understanding of this up front, it's easy to find out halfway through the sprint on something that will be too big but you already committed to.
As far as getting more comfortable with "giving up the work", what I've found helpful is to go through each user story / or larger grouping of tasks and either do a design doc (sequence diagram, etc) or briefly pseudocode it out.
This accomplishes two things:
Playing the "architect" role in that way has always proved to be very helpful for me, and the rest of the developers I may be delegating things to.
This sounds like a great middleground and the more I read your comment the more reasonable it sounds. Thank you! This is definately steering me in the right direction!