Accountability demands that expectations have been set
In my previous post about accountability there was an implication that for someone to be held accountable expectations must be clearly set and there must be a commitment to meet or exceed those expectations.
Without clear expectations it is unclear to me how one could be held accountable since the accountability is a direct reference to those expectations. As an example, a Product Owner is accountable, responsible to use the terminology in the Scrum Guide, for managing the Product Backlog. In the Scrum Guide there are five bullet points that detail that responsibility. For the Product Owner to be held accountable for proper management of the Product Backlog the Product Owner and the business, often read the Product Owner's direct manager, must have a shared understanding of what that expectation means. The Product Owner must understand that their role entails making a commitment to meet or exceed those expectations or they are in the wrong role.
When discussing expectations it is a good idea to use multiple modes of communication. I prefer to discuss expectations verbally, preferably in-person, while referring to written documentation that I share with the other parties in the conversation. This multi-modal communication helps to reduce miscommunication. I find it also helps to ensure that both myself and the other people are clear on what my expectations. This multi-modal style of communication can also help reduce ambiguity, or highlight ambiguity that need to be addressed.
Scrum teams have expectations of the team members. As a team is forming it is advisable to clearly stated the expectations and make sure that they are understood and agreed to by all members of the Scrum Team. When an expectations is not met by a team member it is essential that this is gently, but firmly, pointed out. Avoiding this conversation lowers the team's standards, because it lowers the team's expectations. This is not always an easy conversation but it is a necessary one. The Product Owner and Scrum Master will often need to model this behavior, of gently pointing out when team expectations are not met, so that the rest of the team learns that this behavior is expected. Expecting team members to do this is always a team expectation on a high performing team.
A high performing Scrum Team has unambiguous expectations of the team members that everyone understands, commits to, and will point out when a teammate fails to meet one or more of the team's expectations. Building a team that behaves like this is hard, but well worth the effort.
Stay Agile.
Without clear expectations it is unclear to me how one could be held accountable since the accountability is a direct reference to those expectations. As an example, a Product Owner is accountable, responsible to use the terminology in the Scrum Guide, for managing the Product Backlog. In the Scrum Guide there are five bullet points that detail that responsibility. For the Product Owner to be held accountable for proper management of the Product Backlog the Product Owner and the business, often read the Product Owner's direct manager, must have a shared understanding of what that expectation means. The Product Owner must understand that their role entails making a commitment to meet or exceed those expectations or they are in the wrong role.
When discussing expectations it is a good idea to use multiple modes of communication. I prefer to discuss expectations verbally, preferably in-person, while referring to written documentation that I share with the other parties in the conversation. This multi-modal communication helps to reduce miscommunication. I find it also helps to ensure that both myself and the other people are clear on what my expectations. This multi-modal style of communication can also help reduce ambiguity, or highlight ambiguity that need to be addressed.
Scrum teams have expectations of the team members. As a team is forming it is advisable to clearly stated the expectations and make sure that they are understood and agreed to by all members of the Scrum Team. When an expectations is not met by a team member it is essential that this is gently, but firmly, pointed out. Avoiding this conversation lowers the team's standards, because it lowers the team's expectations. This is not always an easy conversation but it is a necessary one. The Product Owner and Scrum Master will often need to model this behavior, of gently pointing out when team expectations are not met, so that the rest of the team learns that this behavior is expected. Expecting team members to do this is always a team expectation on a high performing team.
A high performing Scrum Team has unambiguous expectations of the team members that everyone understands, commits to, and will point out when a teammate fails to meet one or more of the team's expectations. Building a team that behaves like this is hard, but well worth the effort.
Stay Agile.
Comments
Post a Comment