The words we use, and the tone in which we use them, can either nurture or hinder the growth of Scrum teams. This is especially true for teams that are new to Scrum or that may be transitioning into a new Agile methodology.
To understand how what you say can have an impact on your team, let's dig a little deeper and review what Scrum is all about. According to TechTarget, Scrum is defined as “a framework for project management that emphasizes teamwork, accountability and iterative progress toward a well-defined goal.” Communication is an important part of this process, via team meetings or events involving face-to-face communication, or video or audio conference calls on teams that have remote team members. The purpose of these events is to provide structure within each sprint.
First, the team meets before the sprint begins, to plan what they will work on (sprint planning). Throughout the sprint, team members meet each day to provide updates on sprint work (standups). At the end of each sprint, the team meets to discuss how the sprint went (sprint retrospective).
In these meetings, there are opportunities for dialogue between team members. Ideally, the dialogue is positive and constructive. When it is not, it can be detrimental and harmful to the maturation of the team.
The Blame Game
Regardless of the intent or context of the things we say to one another, the tone is usually the first thing that is noticed. As a result, we instinctively tend to respond to the tone and not the context of what was communicated.
Tone is vital when effectively communicating with peers on a Scrum team, especially when things don’t go as well as planned. When a failure occurs, whether it is missed deadlines or critical bugs that slip into production, our first instinct is to determine the reason why. If we are not careful, this can often lead to placing the blame on others. It’s easy to forget that we should be functioning as a team and we may end up blaming individuals for a failure when actually that weight falls on the team as a whole.
Blaming other team members for failing on a project can destroy trust between individuals, which will inevitably ruin relationships. Think about what blame does: when a person is criticized, especially publicly, it brings on feelings of shame and humiliation. These feelings may cause an individual to doubt themselves or doubt their team members. Being blamed can destroy a person's confidence, which plays a huge role in how productive they can be. Like the flu, blaming is also contagious and has a tendency to spread.
Take the following example: Asking another member of the team, “Why didn’t you get that work done?” versus “Why weren’t we able to get this work done?”
When someone is blamed and isolated from the team, they immediately respond in one of two ways: they become defensive and look for someone else to pass the blame to, or they shut down and emotionally put up a wall that blocks communication.
As a result, the growth and maturity of a team can be hindered. Team members will be less willing to take on tasks, for fear of being blamed. Finger pointing within a team degrades the trust between individuals, and less trust leads to less communication. Team members may be less likely to collaborate which slows the efficiency of the team.
Team Mindset
Being part of a Scrum team involves holding yourself and each other accountable. This should not be confused with placing all the responsibility on one person. The Scrum Guide states that “Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person.” Developers are responsible for more than just writing code, quality assurance (QA) analysts are responsible for more than just testing, and the same goes for other roles on the team.
For example, when involved in the early stages of development, a QA analyst can raise questions about features and functionality. Asking these questions helps flesh out functionality and design issues that may have slipped under the radar. This is one way that QA can contribute to the team outside of testing. Having this team mindset, versus an individualistic mindset, is important to the team and project success.
The following are a few examples of the benefit of a team-driven mindset.
Example 1
Let's say you are in a daily stand up and a developer gives the following update:
“Yesterday I lost a lot of valuable time trying to figure out what the business analyst or product owner wants us to implement. The documents they provided aren’t very clear and lack the detail we need before work can start.”
Notice how this dialogue points the finger at the business analyst and product owner, as if the documentation provided is a burden for the developers and that “they” should do better at providing clearer documentation.
Now, let's see what a more Scrum-friendly update could be:
Dev: “Yesterday I spent some time looking over the acceptance criteria for the upcoming stories. There are a few things that I could use some clarification on, so I’ll set aside some time today to talk about them with the BA and PO. Maybe if we discuss these things together we can develop a clear understanding that will allow us to start implementing some of these tickets.”
The second version still highlights the issue, but it doesn't point fingers. It also references a solution and plan of action to resolve the issue as a team, with the developer and other team members working together, as opposed to placing blame for a lack of detail. As a result, the business analyst or product owner will learn how to provide better documentation for the developers, and won't feel singled out.
Example 2
During a retrospective the QA analyst gives the following feedback:
“One thing that went wrong in this past sprint was the developers waited until the last minute before any the tickets were ready for QA. As a result some things did not make it through testing which is why we did not complete all our sprint goals.”
Compare the above statement with a statement that addresses the same concern but does not point a finger at an individual or group:
“In the last sprint, some features were delayed because development took longer than we anticipated and we ran out of time to test. I think we could have spent a little more time discussing the details of the tickets that we committed to. In this next sprint, perhaps we should take the time to discuss in detail what it will take to implement and test each story. If we have a clearer understanding of the ticket we are picking up, that may prevent us from over-committing on sprint work.”
Observe how the second version still states that there was an issue of the team not reaching sprint goals, but doesn't point the blame at the developers. It instead describes what the issue was and also provides a solution that involves everyone.
As a result, the developers are aware of the need for more caution in estimating how long it will take to implement things to allow for adequate QA testing. During the next sprint planning, hopefully everyone will be open and involved with discussing how much effort will be required in implementing and testing each story before they decide to commit to it.
It’s important to be conscious of the way we speak and communicate with teammates on an Agile team. There is no development team, QA team, or business team; everyone collectively makes up one Scrum/Agile Team. If one person stumbles, we all stumble. Great communication and following Agile best practices are a major stepping stone to becoming a successful, mature Agile team.
