Consider the following situation. What has just happened there? What would you advise Jeff to do? What tools can you use to turn such a situation around?
The team, all of its members, are attending the planning session of the last iteration of the release. It has been a rather stressful release, and Jeff, the Scrum Master, is trying to reflect to the team that your average velocity is 7 stories per sprint, and that committing to 12 stories will put the team in more stress and increased risk of getting enough scope done.
It is a painful experience for Jeff. On one hand he cannot tell the team what to do. He is expected to manage without authority. And it doesn’t work. He feels frustrated.
The meeting is about to close, and Jeff’s only consolation is that this six hour planning session will come to an end soon.
And then Noel, the team’s manager, comes in. Noel is taking a look at the sprint backlog, then taking a look at the remaining stories for the release, giving a harsh look, and turns to get back out of the room. But then he turns back and says: “look guys, I know it has been a stressful period for you. But in two weeks time the release must go out, and taking only 12 story points is no where near what our management expects from you. Please come up with creative ideas for delivering the remaining 6 stories for the release, and come back with a realistic plan ASAP”.
Noel walks out, and there is a nervous silence for one or two minutes. Then Erik, a senior programmer, says: “OK guys, you heard the man. This is no time for pampering and faffing about. Let’s order a pizza, and get our act together”.
Overwhelmed by the situation, and concerned by Noel’s response, Jeff plays along, knowing that the team is over-committing itself way beyond anything they’ve achieved in the past.
Let’s look at the facts first: The team is capable of delivering 7 story points on average, and has just committed to 18 story points.
Now let’s add some affecting factors: Being the last iteration of a release with a large scope as it is, experience shows that teams and individuals tend to make more mistakes (aka bugs), will experience more context-switches having to work on multiple concurrent requirements, even late-night pizzas can have a negative effect on productivity.
So how is it that the team is taking this much extra work, risking its ability to deliver adequate quality complete stuff?
As the title suggests, I am borrowing an explanation from domestic relationships. Here are some of the symptoms commonly experienced by individuals diagnosed as suffering from “Battered Person Syndrome“, according to Wikipedia:
[…] Battered Person Syndrome (BPS) […] consists of the following symptoms: (a) re-experiencing the battering as if it were recurring even when it is not, (b) attempts to avoid the psychological impact of battering by avoiding activities, people, and emotions, (c) hyperarousal or hypervigilance, (d) disrupted interpersonal relationships, (e) […], and (f) […].
[…]Additionally, repeated cycles of violence and reconciliation can result in the following beliefs and attitudes:
- The abused thinks that the violence was his or her fault.
- The abused has an inability to place the responsibility for the violence elsewhere.
- The abused fears for their life and/or the lives of their children (if present).
- The abused has an irrational belief that the abuser is omnipresent and omniscient.
The article goes on to describe the causes for this syndrome (emphasis added):
The syndrome develops in response to a three-stage cycle […]. First, tension builds in the relationship. Second, the abusive partner releases tension via violence while blaming the victim for having caused the violence. Third, the violent partner makes gestures of contrition. However, the partner does not find solutions to avoid another phase of tension building and release so the cycle repeats. The repetition of the violence despite the abuser’s attempts to “make nice” results in the abused partner feeling at fault for not preventing a repeat cycle of violence. However, since the victim is not at fault and the violence is internally driven by the abuser’s need to control, this self-blame results in feelings of helplessness rather than empowerment. The feeling of being both responsible for and helpless to stop the violence leads in turn to depression and passivity. This learned depression and passivity makes it difficult for the abused partner to marshal the resources and support system needed to leave.
Back to our software team, let’s review the scenario:
- It is the last iteration of the release – tension is building up to an already potentially explosive situation.
- The manager is demanding more scope. Make no mistake. The statement “…and taking only 12story points is no where near what our management expects from you” is blaming the team in a hi-tech socially accepted manner.
- The team is attempting to contrite: [t]his is no time for pampering and faffing about”. The added pizzas possibly make a subtle statement of how management is great.
- The expected result is the team failing, making way for additional tension, and repeating this cycle with greater force.
You may say to yourself now “Oh, great story, Ilan, and sound damn right familiar. Now tell us something we don’t know”.
The missing piece in this story, in my view, is who’s responsible? Or to be more precise, how come no one is responsible for resolving it?
The person responsible for making the team excel is, well, everyone involved. Clearly Noel, the manager, can expect himself to help the team take what’s reasonable for them to achieve, and, on the other hand, protect them from external pressure. Teammates can expect themselves to face empirical data and commit only to what they can responsibly deliver.
However, it seems that everyone involved is in denial of the vicious cycle that repeats itself time and again. Most likely Noel is unaware that he is blaming the team – for him, as Erik puts it, the team is acting like spoiled children in the face of the harsh reality.
The first step is to recognize that there is a blame-game going on. Once people involved will appreciate that they are laying-blame, and once they feel uncomfortable there, will it become possible to advance to a higher maturity stage. That is, when Noel and the team will begin to make justifications (“It is the end of the release, and there is nothing much to do now. This is no time for blaming, and we’ll look at the root causes later”) we can tell that the team has “moved up” one stage.
With the right support Noel and team will progress to feel shame about the situation, so later they can feel obliged to resolve it. With persistence, they will reach the 5% of teams and individuals that really become responsible for their work and lives.
So now that we have a possible tool to resolve this vicious cycle, we can learn how to use it. We can learn to identify the most influential dysfunction in the team, and to apply the right tools to reflect it, and to take actions to address it.
The question that remains is – who? Who in the above situation can use the right keys to unlock this entanglement? To stop the vicious cycle?
Of course, it would be best if Noel took control over the situation, rather than over the people. After all, you cannot manage people, you can lead people instead.
What about Jeff? The leader without authority? The Scrum Master? What were you done if you were in his place?
If you are the Jeff of your team, and would like to learn more how to stop vicious cycles like these, you are welcome to register for a Scrum Master Weekworkshop. You will learn and practice, in “lab conditions”, multiple ways to deal with complex team situations, and try them out. You will get a chance to practice with members of other organizations like yours, who are dealing with dilemmas like yours.
And if you have a specific dilemma or wish to respond to this blog post, please share your view in the comments, or contact me directly here.