Off-shoring in current market is a global economic and strategic need. Building Agile Offshore teams across boundaries and time zones is a different ball game. It has its fair share of challenges to work with. I shared few of those challenges and a possible approach to take in my earlier articles.
1. How to Address People and Communication Challenges
2.Distributed Agile:10 Best Practices of Successful Teams
3. Distributed Scrum: A Day In The Life Of A Distributed Team
You need to make few changes along your way to your normal routine to make it work. One challenge I often see is integration of offshore team with onshore team and to project/business vision.
Lack of proximity to business is a big challenge. You could address this by making people travel, meet face to face, video conferencing etc. Your Product Owner may be very flexible, takes part in every daily stand-up, he is there during his core hours and ready to stretch some times. Let’s assume you have all of this, but still not having business representative at your disposal is an inhibitor to offshore team success.
How do we address this?
Creating a proxy business representative i.e Proxy Product Owner can be a secret sauce to address this gap.
- Assign an offshore team member preferably with business analysis skills as proxy product owner. This person is responsible for comprehending requirements and knows reasoning behind current prioritization of requirements.
- He works with offshore team to convey and clarify business requirements during offshore team core hours.
- He works very closely with product owner and meets face-to-face periodically(say once a quarter).
- If you have distributed team with less or no overlapping hours, PO proxy becomes very important. He will present stories to the team during sprint planning and for all practical reasons this person becomes product owner to local team.
This is also a big risk to the team as it may lead to some miscommunication. There could be instances where-in PO proxy may not be aware of big picture and hence unable to answer team questions with authority.
Backlog grooming or refinement session can address this. Scrum teams must have this meeting as part of their scrum ceremonies. In this session, entire team, product owner and proxy product owner come together to discuss new and upcoming requirements of product backlog. This gives offshore team to hear and connect with actual product owner directly.
Two anti-patterns to watch for…..
- I see often, MAKING Under-powered, Indecisive person as PO Proxy for offshore team. This will create more confusion, conflicts and miscommunication. This eventually leads to slowdown in decision making and a decrease in productivity and morale. Watch-out for this pattern. [pullquote]Just calling business analyst as Proxy product owner is not a solution. Proxy PO is given free hands to make decisions.[/pullquote]
- Second anti-pattern which is observed is supplementing low bandwidth busy Product Owner with a so called Proxy PO to help him. This is solving a wrong problem. You need to balance actual product owner time at the first place.
Concluding thoughts…
Going for Proxy PO has some risks. It adds up another extra layer in decision making which is not ideal.
I favor going for proxy PO for addressing vast time zone differences. Additionally, having business person on offshore side, helps in building big picture, domain expertise, alignment towards business vision and also makes wonders to offshore team confidence and morale. Offshore teams work as business partner rather than implementation partner.
Please share your story of how are you managing lack of business proximity issue with offshore teams?
You seem to be addressing the most common issue that teams are facing with Agile implementations. Talking specifically about a Product Owner not being collocated with the team, I would like to share my experiences on 2 projects and how we overcame the remote Product Owner problem.
In the first project which was an Agile transformation project for the world’s largest logistics client, we started off with training the business SMEs to be Product Owners. We started off with basic training and then got into story writing workshops. These future Product Owners were joined by Business Analysts from the development team in India to become the proxy Product Owners on the project. Pretty similar to what you mentioned in your article. The Proxy Product Owners would act as a bridge between the development team in India and the Product Owners (SMEs) in the US. The proxy POs had an added responsibility of conducting backlog grooming sessions with the POs and also writing user stories.
In the second (my current) project, the teams do not have the luxury of Business Analysts so the Scrum Masters and leads spent some percentage of their time to align with the Product Owners through:
– Weekly PO sync meeting where the team demos WIP functionality being developed in the current sprint to ensure that the team is headed in the right direction. The team also captures questions/clarifications on Wiki on a regular basis so that discussions can happen during the PO syncup
– Weekly backlog grooming as part of the look ahead activity where the Scrum Masters and leads connect with the POs on a weekly basis to groom the backlog and agree on the functionalities to be developed in the upcoming sprint(s). We use a tool called Trello to track tasks and run this meeting as a weekly scrum
– The team uses Wiki extensively to communicate various project topics with the Product Owner
These techniques have helped my teams shorten the distance between the POs and the teams and helped ensure same level of understanding and collaboration.
@Nirmaljeet.
Thanks for sharing your thoughts here. They are great ideas and good to see you have tried it successfully. Backlog grooming is very important to entire team as it not just helps in look-ahead planning, but also gives entire team to interact directly with PO if he is elusive during sprint planning.
Good info Avienaash. In my previous team we faced a similar situation where the product owner was client. He was too busy in his business engagements and was not able to devote much time to address team queries. We implemented a solution of creating an ‘Issue Log’ of queries and Scrum Master (I) took a lead in having meeting twice a week with PO to discuss these issues.
Having said that, I personally believe that a PO is very important role in scrum process. Business must understand importance of this role. Having a part time PO or Proxy PO does not solve the real problem.
Agree. Having Proxy PO is a workaround in this situation. Clients need to understand why it is important for him to share time with people and not just money.
I know I am late but, still thought no harm sharing the views. I agree that on the face of it having a proxy product owner does look like a viable option which can give good results but, having said that I feel that it adds an extra layer and some information might be lost in transition or interpreted differently. More over sometimes the proxy product owner does not have decision making authority and that only delays the proceeding. Also having a proxy might create a mind set for the product owner that he is not always required there is someone to take care on his behalf and might take away the opportunity for the offshore team members to meet the product owner.
I would rather push for the weekly backlog grooming meeting via video conference if possible [doesn’t have to be too long an hour or hour and half]