Today it is an imperative to be able to quickly build and deliver innovative and advanced software products not only to keep the business growing, but simply functioning just above the tide. The business virtually always demands the increments of the products to be delivered as soon as possible for many obvious reasons. In order to do that software development companies can use an old as dirt concept of outsourcing a part of the work to contractors.
Nowadays there are several well explored and safe ways on how not to fail with subcontracting software development. One of them – R&D augmentation in nearshoring model was well described in the other article you might read – Nearshoring – more opportunities for your business.
Complementary to this article it is very important to mention a role which fits greatly to this business model – Proxy Product Owner.
Proxy Product Owner is often described as a SCRUM antipattern. The main reason is that the Product Owner is defined as a single accountable person for the product and the Proxy PO – PO tandem is not defined by SCRUM. Still “Don’t let the turkeys get you down”, because while running a software development of a complex product and using multiple, often distributed development teams, the Product Owner is frequently exposed to significant vulnerabilities and it is especially visible for the R&D augmentation in nearshoring model.
Why Proxy Product Owner is even needed?
In order to deliver software products fast and in top quality the development teams needs to be driven mainly via precise, fine ordered and always up-to-date product backlog. For a Product Owner that might be a challenge since this is a sole person responsible for a product and multiple development teams can work on the product in a remote locations. There are several typical symptoms which shows that the development team might not perform at the top of their capacity, here are the few important one.
Product Owner is not available for the development team – “I can’t do the Planning/Refinement/Retrospective/Review now, I am on the meeting, it’s important”. I bet it is! The Product Owner is very often involved in many discussions, a number of time difficult one. Generally there are multiple stakeholders in the organization, one more dominant then other. The Product Owner needs to negotiate the priorities and budget, clarify requirements and advocate for the product features, implemented as stakeholders and users asses the results. Those are all very important and time consuming activities and the development team needs their Product Owner. There are number cases when a Product Owner might use some help in working on the backlog with the development team. This also means responding to the team member’s questions without unnecessary delays. It all depends on the case, but very often introducing a Proxy Product Owner will benefit to keep the work rhythm and raise velocity in delivering the product increments. Proxy PO can work closely with the team, ensuring the product backlog is clear and well-ordered and all agile ceremonies are conducted properly to elevate to the most the effectiveness of the agile process and keep at the top the product quality and the value.
Product Owner is not collaborating well in agile with the development team. Sometimes the organization didn’t adopt agile yet and it needs to develop, iterate or maintain a product, especially software. Then software development team knows that agile approach will be the most effective in achieving success. Still the person accountable for the product will be designated from within the organization, which is not familiar with agile approach yet. This has some bright sides, the Manager (let’s call him that for convenience) has very good knowledge of the business case, she/he controls the budget and has already trust and confidence of the organization. On the other hand the software development team needs a Product Owner, who can participate in agile workflow (Planning, Retrospective, Refinement, Review) and knows the agile principals and culture. Proxy Product owner will help the Manager to take her/his part as a Product Owner. Remember dear reader, educating oneself and gaining experience is necessary to be a successful PO. The Manager can be very good PO but until then, the Proxy PO is a fine piece of workable solution, which will be successful when implemented properly.
Communication and Collaboration
While working in a distributed environment this is the most important point which lies underneath of all problems and it makes a challenge to maintain effective and instant communication within the distributed teams. First of all the Product Owner should strive for a communication strategy to have an overlap time between the different time zones. Still this might not be enough because the most effective channels of communication are white boarding and face to face communication. Live video conference and screen sharing might be sufficient but it may not be possible to use one at any time, whenever a problem occurs. In order to mitigate the risk of unnecessary delays and improve overall collaboration it can be beneficial to introduce a Proxy Product owner, ideally co-located with the development team or at least with very broad time zone overlap with the team. This can improve responsiveness to the questions and issues which are constantly occurring through the whole development process.
Different work culture and language
In a global, distributed environment the team members or even whole teams can originate from a different cultures. Some of the cultural norms might be not well suited at the first glance to the modern agile engineering approach. For example taking the requirements without asking any questions or raising an objections simply because the PO appears higher in the hierarchy, despite the fact that it clearly gives no value to the product is wrong in the context of agile values. First of all there should be a common awareness of cultural differences among team to help communicate and understand each other productively. This can be achieved by multiple means and one of the more effective is setting up the Proxy Product Owner who on one hand shares the agile engineering values and on the other hand is understands the team members values.
How Proxy Product Owner can help in nearshoring model?
Distributed agile engineering clearly needs more team effort and ownership than co-located project team in adapting to the agile practices. Having Proxy Product owner at offshore/near-shore is very useful for the development team members to clarify requirements and get their query answered immediately during their day time. Proxy PO (PPO) has to mirror the PO as much as possible to avoid any conflict and differences on delivery expectations. Clear demarcation of roles/responsibilities between PO & PPO. At the end of the day this tandem has to serve the one goal which is very distinctly stated in the Scrum Guide – “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” If introducing a Proxy PO is what it takes to maximize the product values, it is definitely worth giving a try.