While the Agility is visible in the behavior of the team members, it needs to be fostered by the environment in which the teams operate. Unless the team is provided with the right eco-system, agility cannot thrive. While the senior leadership of the organization is responsible for promoting agility, it is the first line of leadership which influences the success of the agile transformation, most! They are the ones who work closely with the team on the day-to-day basis and shape the team behavior. The roles like Product Owner and Scrum Master need to be acutely aware of what true agility is and promote it consciously. While establishing agility in the team is primarily responsibility of the Scrum Master (SM), actions of the PO can help the SM in that effort. In this blog, we will look at the influence a Product Owner (PO) has on the team’s agility and what s/he should or should not do. It is broadly organized in two sections – “Do’s for Product Owners” and “Don’ts”.
- Do’s for Product Owners
- Be mindful of the cost of change
Customer satisfaction is the ultimate aim of the Agile teams and to ensure that they welcome changing requirements. While this is true, we also have to take into account that change has its own cost, in terms of effort and impact on team’s motivation when the same code needs to be changed multiple times. While the change needs to be allowed, there should be conscious attempt at reducing the cost of change and this responsibility squarely rests with the Product Owner. The PO should get deeper into the customer’s needs, understand the value desired and articulate it to the product team. When there is insufficient clarity and the PO feels that the customer needs to see something to gain better clarity, s/he should use prototyping to get customer feedback and then undertake code development. When some development is necessary, try to take the MVP (Minimum Viable Product) route and get the feedback for the full-blown development ahead.
- Maintain continuous flow of value to customer
Agile teams desire to maintain the continuous flow of value to customers. This is where POs make a critical difference. After the PO has presented the MVP (Minimum Viable Product) to the customers and got feedback on it, s/he should define the minimum set of functions and features that need to be delivered which can make difference to the customer. This is called MMR (Minimum Marketable Release). Subsequent releases could add more functions and features and ensure continuous flow of value.
- Ensure smaller size of user stories
Key enabler of continuous flow of value is reasonably small sized user stories each delivering value. It could happen sometimes that the team is not able to deliver everything that they planned in a sprint. However, if they have well defined small sized user stories, whatever they complete, can be delivered. Since the higher priority stories are completed and delivered, customer will still have good value delivered to him.
- Demonstrate empathy
Empathy is the key enabler of a well-integrated, highly effective teams. Empathy is the ability to step into the shoes of another person and see the world from his/her eyes. All members of a team should feel empathy towards others. When there is a problem all team members should think on how they can help solve it and contribute to the solution as required. Purpose of the daily scrum meeting is to surface such problems and address them as a team. POs should actively participate in the daily meeting and contribute to addressing the impediments. Nothing is in the category of “my problem” or “their problem”! All problems are, “our problems” and “let’s solve them together”! POs should actively promote that thought.
- Promote Continuous improvement
POs should actively participate in the retrospectives and stick to usual guideline of not criticizing a person but to highlight a problem, seek inputs from the team to resolve it and help finalize an action plan. If PO has an action item from a retrospective session, work on it enthusiastically. Be open to the feedback and act on it appropriately.
- Enable positivity through positive strokes
POs should promote positivity in the team. When the team does something good, appreciate it wholeheartedly. Convey that appreciation to the customers and raise the level of their respect for the team. More they respect the team, more they will trust them and better will be relationship between organizations.
2. Don’ts for Product Owners
- Refrain from dictating the scope of an iteration
Product Owners are keen to keep their customers happy. Sometimes they get pressurized by the customers to deliver certain functions or features. In turn, they pass on that pressure to the development team. That’s an antipattern that can kill agility. PO should define the sprint goal, identify the User Stories needed to achieve that goal and define their prioritization. After that estimation and planning should be left to the team. S/he may be required to allow a story to be excluded from the iteration or prioritize one user story over the other but may not insist on the number of user stories that MUST be delivered in a sprint, come what may! Not only this does not work, it causes irreparable harm.
- You are not above the team
At times, I have seen product owners thinking of themselves as business people and differentiating themselves from the other team members. This is another antipattern. Product Owners should be well integrated with the team. All members of an agile team should feel a sense of belonging to the team and then only they can work towards the goals and the success of the team. If one member feels that he is different and thinks, “I will do my job; let others do theirs”, the team spirit suffers. Then the team will just not be agile. POs and rest of the team should be on the same side and not be in the confrontational positions.
- You are not the manager
Sometimes, I have observed POs asking for status in daily meetings and pushing for actions they feel are right. This is a strict No-No. PO may be a senior person but s/he has to understand that s/he is not managing the team. Agile team has to manage itself. POs may ask some good questions that force the team to identify the issues and address them. Do not force a solution. The team has to evolve the solution. That way alone they will own the solution and implement it.
To summarize, actions of a Product Owner can significantly supplement Scrum Master’s efforts in shaping up an agile team and positively influence the success of Agile Transformation of their organization.
