A Team with fear cannot do Agile or Scrum, but fear can be handled with Agile and Scrum
an unpleasant often strong emotion caused by anticipation or awareness of danger
— Merriam-Webster’s Dictionary
As a basic human emotion, fear is evolutionarily designed to help us survive. It prepares our bodies for a fight-or-flight-response and is considered to be key to human survival. Fear is not hard-wired though: fear can also be learned.
This basic evolutionary need for fear seems very unnecessary in many work environments. At first sight, there should be no reason for a fight-or-flight-response in any office job. Nevertheless, you will find various incarnations of fear-based or fear-related issues, from fear of failure to burnout or worse.
A company’s or department’s management style as well as other relations between people can contribute significantly to fear. Fear-based management can be unwittingly applied, but you may find it more often than wanted.
But what is the relation to Scrum?
There are behavioral patterns which manifest themselves in daily interactions and indicate fear. Fear might not be the right classification in all cases but it helps to describe the emotions involved. These patterns might surface in Scrum Events. Depending on the strength of the emotion, you may see them more often even in between those Events.
A very good example is when the Development Team members are avoiding estimations and making excuses (“too big”, “don’t know how”). While this is valid in many situations, a repeating pattern thereof might indicate an attempt to deal with fear.
Additionally, the Team might add many Spikes to the Backlog, sometimes also during the Sprint Planning, as an attempt to define everything before starting the implementation.
The communication of the Team can also be taken as an indicator. For one, the presence of destructive communication patterns, e.g. by
applying criticism in a destructive way ( e.g. consecutive “but”s), resulting in stalled communication and potentially no result at the end of a meeting or Scrum Event or blaming as a more visible destructive communication pattern, targeting other Scrum Team members or outside parties.
For another, no communication can be a pattern as well, resulting in stalled communication, not allowing to come to any result.
Also, any kind of CYA activity indicates fear.
These are just some scenarios you might observe in a Scrum or Agile environment, all indicating fear-like emotions.
Agile mandates a (Scrum) Team of motivated individuals (principle № 4). The Team should be motivated to create customer value, applying technical excellence and good design.
Utilizing Maslow’s Hierarchy of Needs helps understanding motivation. This theory defines five stages of needs: physiological needs like food or health, safety needs like financial or personal security, social needs like friends and relationships, esteem needs like prestige or recognition, and finally self-actualization needs like achieving one’s potential. These stages form a hierarchy, requiring the lower stages to be satisfied before needs on a higher stage can be addressed.
Mapping Agile’s “motivated individuals” to this model, this motivation can be linked to social needs, esteem needs and self-actualization needs. Satisfying an individual’s self-actualization needs is desirable both from a personal as well as a Team’s point of view as this sparks the energy you want in a Scrum Team.
Fear reduces motivation. Depending on what kind of fear it is, it reduces the motivation at the stage of the corresponding needs. Publicly addressing a person’s failure counters esteem needs as well as social needs. Fearing for your job counters your safety needs.
As according to this model, needs at lower stages have to be satisfied before needs at a higher stage can be addressed, a fear that reduces motivation at a lower stage eradicates any potential motivation at a higher stage. So if you fear for your job, no accomplishment would have a motivating effect. Fear in a work environment usually acts as demotivator for esteem needs, social needs or safety needs, making it impossible to satisfy any self-actualization needs. Thus my conclusion:
A Team with fear cannot do Scrum or Agile. Period.
Mismatches in expectations and conflicts arising from it are a cause for negative emotions. Stakeholders or Product Owners might have different expectations of the result of the story, the efforts the story requires, or the quality of what was created. This potentially results in a rejection of esteem needs, sometimes even safety needs. Team members might have different expectations when it comes to individual contributions or quality, thus potentially withholding social needs. Not to forget, everyone has their own expectation of the results they’re producing. Not satisfying their own expectations might also cause denial of their own esteem needs.
As shown, a mismatch of expectations by different parties and the reaction on it has a high potential to cause negative experiences.
Furthermore, fear-like emotions can be the result of fear-based management. To be frank: this management style or behavior completely contradicts the principles of Agile and Scrum.
The incidents that lead to these emotions are not necessarily within the current team or work-setup. Every person has their own history, thus experiences in a previous job or department will impact their behaviors and reactions in the next — and thereby also impact other team members.
It takes 12 positive customer experiences to negate the poor impression left behind from one unresolved, bad experience.
— Business Insider
In a greenfield situation, every Scrum Team member has to help to create an environment in which it’s safe to fail. For one, this is needed to avoid negative emotions to grow. For another, it is needed to create learnings and positive emotions. Scrum embraces learning and positive emotions.
In any grown environment, you potentially have to do more. Fear needs to be identified and actively addressed — maybe even overcompensated. In order to negate an existing negative experience, the Scrum Team members have to work together to create corresponding positive ones. The Scrum Master naturally plays an important role to identify issues and coach the Team while the Product Owner channels external feedback.
Some options are to explicitly create failsafe environments for stories, doing spikes (sensibly 😃), as well as individual coaching. But actually, there are already established ways to do this in Scrum: The Scrum Events.
In the Sprint Planning, uncertainties and fear can be communicated. This allows solving or mitigating them when the Development Team plans how a Story is done, as well as building safety nets. Safety nets can be additional features, (non)functional constraints, checkpoints during development to spawn re-evaluations based on learnings as well as discussing potential consequences.
The Daily Scrum can be a checkpoint to initiate re-evaluations — either by an individual or by Team members observing an issue. It’s the Event to discuss impediments and initiate their resolution and using it as such can address fear.
In the Sprint Review, the Product Owner can praise the work accomplished — and should do so. As any impediments should have been addressed in or as a result of the Daily Scrum, there should be nothing surprising to the Product Owner and stakeholders, thus the Team can focus on what was achieved or learned.
Last but not least, the Sprint Retrospective is the main Event to create positive experiences from any issue that occurred. Use it 😃
In conclusion, the collaboration in and outside of Scrum Events by all Team members, involving the Product Owner, provides the opportunity to create positive and learning experiences out of every incident, thus avoiding fear-like emotions. This allows everyone in the Team to grow and your customers to benefit from it.
“If we don’t get it done by end of the month, we have to close down”.
— unknown manager
Of course, there are urgent situations that impact the future of a project or a company, there are deadlines and there might be a need for crunch time — all having a high stress potential on their own as well as potentially caused by Team Members, Product Owners, the organisation’s management, … . It’s also not uncommon that this stress goes along leads to negative emotions, thus: fear.
Although a Team with fear cannot do Agile or Scrum, these situations can be handled with Agile and Scrum. Both define everything that is needed for it: welcoming changing requirements, the collaboration of business and development, self-organization, openness, respect, and courage. Fear is no part of it.
Using Agile and Scrum, the Team becomes part of the solution, not part of the problem (frankly, they most likely aren’t anyhow). Just to give some ideas: explain the situation and constraints, involve the Team in finding a solution. And if crunch time is required: find a way to make it acceptable, beneficial, and maybe even fun for everyone while developing a way back to a sustainable pace.
This should by no means declare management with deadlines and overtime acceptable or opportune, it just shows ways other than creating fear to deal with them. By having the team tackle these challenges together and in a decent manner, the effects are even better. And they can be utterly motivating. It creates a level of collaboration and trust you can’t buy.
A Team with fear cannot do Scrum or Agile, it’s actually contradictory: A Scrum Team needs an environment in which they are allowed to fail and learn to be effective. Despite allowing an environment to fail and learn, Agile and Scrum are fit to handle stressful situations. Their principles and values just offer better ways to deal with them.