In this session we will share a simple framework that can help deal with the problem that hurts most development teams that are geographically distributed the misalignment of understanding of what to build. We will cover how this misalignment of understanding is exacerbated by the cultural and contextual differences. The time-zone difference is only a small part of this challenge. From our experience of working with distributed teams for last 15 years or so, across 150+ client engagements across US and India, we observed that some teams seem to sail thru this problem almost effortlessly, while most other teams seem to constantly struggle with this issue.
Based on our experience across these 150+ client engagements, we have come to conclude that one-size-fits-all approach (e.g. insisting on ATDD/BDD or requiring PM/PO role with dev team in India) to this problem is not workable. There are no universal best practices. Instead, we have gleaned a few common patterns that help. We will share the patterns we have seen and how this pattern recognition can significantly improve the odds of getting this train on track and keeping it on track.
1. Recognize the dominant reasons for the early mismatch/derailment. We need to objectively assess the client-side product team’s ability and willingness to provide detailed enough software requirements, and we need to categorically assess industry/problem-domain familiarity of India based dev team. Do this as a deliberate exercise right in the beginning.
2. Based on this assessment, define the role of Product Manager, Product Owner, and Proxy Product Owner (we will describe this new role) in the right geographic location with product team in US or with the Dev team in India. Again, insist on filling this role explicitly.
3. Re-calibrate this set-up every time there is a significant change of product scope on US side, or there is new team on India side, or there is any executive leadership change on either side.