Barriers between the team and the Product Owner can come in the form of the old “us vs them” mentality, a lack of following process (stories, conditions of satisfaction, poor tasking, lack of commitment, etc), a lack of understanding of what's being asked for, and good old fashioned lack of trust. The SM can help remove barriers by keeping some of the following in mind.
Ensure that the PO is part of the team. If the PO is treated or acts like someone not on the team, there won't be trust and willingness to interact in a positive and persistent way. The team (including the PO) needs to be able to check their egos at the door and be able to ask questions, challenge assumptions, accept ideas and differences, and at the end of the day remember that they are all shooting for the same thing - working software at the end of the sprint.
Emulate correct behavior. This applies to interpersonal behavior (being reasonable, inquisitive, respectful) as well as following team rules, culture, and accepted practice (except where that interferes with delivering working software at the end of the sprint).
Ensure that the team and the Product Owner are on the same page. Do this by asking questions of both sides, by checking assumptions, and facilitating regular and adhoc communication. Ensure that the schedule is followed and be proactive in anticipating events that might impact it (certain stakeholder must be there but can't be, technical limitations such as development or UAT environment issues, etc).
Ensure that the Product Owner is involved closely with the team on a daily basis. The PO should be attending the daily Scrum so that he can hear if there are impediments that require his attention (clarification of conditions of satisfaction or a story, priority decisions, etc). If possible, the PO should be co-located with the team so that they are building a relationship and learn how to deal with one another on a daily basis. Also, the PO can pair with programmers to develop/understand/clarify requirements as questions arise, not later when it's too late.
The ScrumMaster should take personal responsibility to own the process and the interaction between team and the PO. Whether by title or personal charisma, the SM needs to take personal responsibility and ownership for how the team and the PO behave together. This may be demonstrated by orchestrating adhoc meetings, helping keep things on an even keel when tensions right high, or encouraging dependency on each other. It should be done “covertly” in the sense that the SM is just helping to facilitate the relationship, not necessarily be present at every connection.
The ScrumMaster can be an abstraction layer between the team and external forces that get in the way. In some cases the SM may act as a barrier between forces that tend to impede progress. Many times there are multiple competing priorities that the PO is having to sift through to make the best decision for the customer. The SM can help by facilitating organizational or social change, helping the team to understand why the backlog may look like it does, or simply being there as a resource for the PO to take advantage of for bouncing ideas around or getting technical feedback.
Publicize the success of the team. The SM needs to publicly praise the good efforts of the team and the PO. Since the PO is the “single-wringable-neck” they need the support of the team, just like the team needs the support of the PO when their scope has to be reduced or when they push back on a feature request and ask for more design review. When the SM tells the organization of the success of the team and PO, trust is built in this delivery mechanism, which helps all parties be more engergized, motivated, and empowered.
Preserve openness and transparency between team and the PO. One of the foundation aspects of Agile is transparency. Agile brings out the good and bad, so keeping a commitment to respect between all parties is essential. This doesn't come overnight, but the SM can help bridge the gap by working to build a relationship with the PO and their stakeholders as well as the team. When issues seem to be running under the surface, the SM can ask questions (at the right time) about what is going on? He can help parties save face, but at the same time accept responsibility. This takes a willingness to be on the edge of conflict sometimes, but done well, can enable the team to build an open relationship with themselves and the organization.
Inspect and adapt. This is also part of the core of the Agile framework. The SM can help remove barriers by ensuring that the Agile inspection and adaptation process is followed as intended. It is also where the SM needs to ensure that follow up happens with retrospectives, with impediments, and with team productivity.
Push for continuous improvement of the process. The SM needs to remember that in most organizations, not every aspect of Agile will be implemented all at once, or done to the vanilla optimum that may be needed. The SM needs to have patience and ask the team and PO to grow at the pace they can readily absorb change. This will be faster or slower depending on the people and organization.
Help the team and PO to deliver the most value possible. Keep the team and PO focused, not on positions, but on objectives and purpose and goals. The goal is to deliver as much value as possible. When the team or the PO gets focused elsewhere, it becomes an impediment, no matter how cool or nifty it may seem. Keep the simple dictum, “a little better than before.”
Removing barriers is the core of the ScrumMaster's role. Learning how to be an expert at this will enable the team to do more than they could have done on their own. <><
Some of this discussion was taken from my linkedin q&a. Thank you to all those that contributed to that discussion.
Posts
