In this final part of his new blog series, Alasdair Smith, Software Craftsperson at Codurance, looked at you can overcome your fears.  Don't miss out on part one and part two.

Time to deal with it

Solving this is neither a mystery nor a quick fix. It takes time and attention, but I promise it is relatively straightforward and the benefits are considerable. I will, however, confess that tackling this problem as a consultant requires significantly less courage than as an individual employed within the organisation. As a consultant, I have the privilege of being paid to be (respectfully) opinionated and outspoken. Thus, if I turn to someone and say "I feel it may be better for us to change our approach to sprint planning entirely," I can do it with the full confidence of someone who is being paid to do so. Attempting to do the same as an employee is far more daunting, but also far more rewarding if done with care and consideration. In addition, the following discussion is easier to do from a position of seniority or leadership. However, it can absolutely be effective as a junior (more so in fact) but it may feel slightly "bold". Again, this can be an immensely rewarding task if conducted with the same care and consideration.

Let's now look at how we may choose to solve the above issues and I think you will see a pattern start to emerge.

The Junior

I'm scared that I won't be able to do the job.

Consider for a minute how Fear is operating in this statement. Probably, Fear in this case is leveraging the individuals need for job security. Additionally, Fear is likely to be pulling on this individual's need for validation and affirmation. I will also emphasise that all of these needs are completely reasonable and normal needs for an individual to have. Certainly having these needs does not indicate that you are unreasonably insecure or flawed. Simply a human being.

In this case, dissipating the fear is an exercise in communication of expectations. As a senior or lead I would find a time and place to spend time getting to know this individual and discussing your expectations of them. Consider how you might demonstrate that you understand their position and have been in their shoes. Show real empathy for their position.

To address their need for job security you might consider a little trick: show your own vulnerability by publicly expressing that you need to improve in some aspect of your own role. By doing this confidently and without fear of repercussion you demonstrate that needing to improve is an expected part of the job and not a cause for dismissal. You might consider demonstrating this expectation for personal development further by involving yourself in their work via pairing. Consider it an opportunity to understand their strengths and weaknesses and give them the tools to improve. Encourage them to see you as an advocate for their progression.

The impact of doing these simple things for a junior member of the team is significant. Where before you had a nervous and unpredictable member of the team to worry about you will now have a highly motivated and engaged individual ready and willing to tackle any problem with a positive professional outlook. What's more these actions will likely resonate deeply with this individual and they will be a perpetuator of this same attitude you have instilled in them. Thus you've turned a liability into a positive force for you and your team. All for the cost of a conversation each week and some pairing sessions. That's something anyone can find the time for.

The Team Lead

I'm scared of speaking my mind in case I offend my boss.

Again, consider the underlying cause for the above statement. It is likely this individual fears speaking up because of repercussions they might feel as a result of offending their boss. Possibly they are concerned, speaking their mind may negatively affect their job security or opportunity for career progression. Maybe there is simply a dislike of conflict in any form. Just as with the Junior case study above, these concerns are very real and very valid.

It is common to think that a Team/Tech Lead should be a leader figure who supports the rest of the team and doesn't need any form of support themselves. The reality couldn't be further from the truth. From my experience a Team/Tech Lead is an individual who needs to be "supported" the most. I put "supported" in quotes because it is a very different form of support from that required by a member of the team who isn't playing a leadership role. "Support" for a leader looks much more like a demonstration of belief and confidence in their decisions and approach. The members of the team support their leader by standing behind their choices and following their leadership.

So, how might a member of the team help a Team Lead to feel confident enough to stand-up and make the decisions/choices needed for the team to progress? Well, in its simplest form one might make a conscious effort to publicly express their support for their Lead. Although, this may seem a little obvious and vaguely patronising if not done in a considered way. Alternatively, if you are aware that there is a decision that needs to be made by your Lead which could be a matter for contention, then it might be possible for you, as a member of the team, to "pave the way" for that conversation and act as a catalyst for that discussion to take place.

As an example of how the above might look, let's consider the following situation:

A team has come together to deliver a new phase of an existing product. Apart from the Team lead the development team has no prior experience with the product. From the first sprint planning session, it is clear that the entire backlog has been pre-defined and estimated without the development team's involvement (apart from the Team Lead). When asked about this the Team Lead explained that the key stakeholder disliked having the full team involved in estimation because it slows the process down and gives "less favourable estimate values” for their client.

After a couple of sprints it became clear to the development team that the existing estimates were not appropriate representations of the workload that team could shift. As a result, the development team is feeling excessive pressure to deliver at a pace which is un-maintainable. Furthermore, the Team Lead is a bottleneck for all delivery efforts because he is the individual with prior experience and thus all the members of the team are starting to look to them for resolution of technical issues/choices.

After a few weeks working like this the general feeling among the members of the development team is that the tickets need to be estimated as part of a refinement process (a ceremony that doesn't not currently exist) so that the team can actually work towards reasonable deadlines given their lack of experience with the project. The Team Lead agrees that this change would benefit the entire team. The team has a retro coming up at the end of the current sprint and would like to bring this issue up for discussion.

Given the situation above (one I have had first hand experience with) the members of the team might decide to encourage the discussion by proactively expressing their need for the change ahead of the Team Lead as part of the upcoming retrospective. Of course, this requires the members of the team to feel safe enough in retrospect to be able to speak their mind. If that isn't the case, then the entire team needs to start building that safety from the ground up (a discussion for another blog post perhaps). However, provided the necessary groundwork has been done to establish this safety, then the team should feel confident enough to make this kind of statement without fear of repercussions.

Something as simple as this can have a powerful effect for the Team Lead. If a member of the team who is not in a leadership role can stand-up and express their needs, then the Lead has a vehicle to drive a positive dialogue arguing for that change. Without that team member's public expression of the difficulties they face the Lead may have to give anecdotal evidence to support the need for change which can be disregarded as assumption when scrutinised by stakeholders. Thus, representing the problem for the Lead to get behind and address means that the problem can be seen as being objectively considered by the Lead as part of their responsibilities. The Lead cannot be seen to be "causing trouble" or "creating unnecessary conflict" because the problem has real representation by a member of the team.

If we analyse the above proposed series of events in a little deeper then we see a very simple (but powerful) demonstration of support for a Team Lead takes place.

• The team expresses dissatisfaction with the existing process.
• The Team Lead agrees that a change needs to be made and proposes a solution.
• The team then, both implicitly and explicitly, agrees with the Lead's proposed course of action.

The result is a public display of support for the Team Lead that reinforces their position as a decision maker focused on supporting the development team for the betterment of the project. The fear of speaking out because of any repercussions is dissipated because there is alignment within the team about the problem, the problem is publicly expressed by the team and so the Lead can be seen as addressing this as part of their responsibilities as a leader. Although this seems exceedingly obvious when written down, I can't express how many times I have seen an apathetic team unknowingly undermine a Team Lead because they themselves don't believe that change can be affected by their leader.

If you have been paying attention you might notice the above paragraph presents a catch-22 problem. An apathetic team may not outwardly express support for their Lead because historically the Lead hasn't demonstrated any ability to affect change. The Lead doesn't feel able to speak up for the team's needs because the Lead doesn't feel they have the support from the team to affect change. It's a classic chicken and egg situation.

In truth, as a consultant, it is far easier to see this problem and address it. However, I have been able to resolve this very situation in the past by encouraging the Lead to tackle the problem head-on. The Lead may choose to face this problem initially with a couple of trusted individuals and literally ask them for their support. In return, the Lead will actively seek to consult with these individuals to try to understand their needs better and represent them during retrospectives. From this a symbiotic relationship form. This relationship then becomes a template for other members of the team to start to emulate and benefit from.

In summary

Tackling the impact of Fear on a development team is both simple and hard. It requires the ability to reflect not only on how you yourself are being manipulated by Fear but also the team as a whole. From that reflection you then need to leverage your capacity for empathy and apply it to your team members. Using empathy as our guide, we can begin to analyse the symptoms demonstrated by individuals affected by Fear to get to the root of the problem (e.g. The need for validation and affirmation). Finally, by understanding the root of the problem we can identify creative ways to dissipate the effects of Fear by supporting the various members of the team with their struggles.

All of this can seem very obvious and simple when written down and, in truth, the way in which you address Fear itself can be trivial. The real challenge is in the identification of Fear in the first place. It can be too easy for us to focus on the symptoms of Fear instead of the root problem and unfortunately addressing symptoms rarely serves to improve the situation. I hope that this article demonstrates the flow that one can follow to start to improve a fear driven team for the benefit of the people as well as the project. I am sure with a little bit of patience and perseverance you can be a positive force for change. Good luck, have fun.