It is no coincidence that one of Scrum’s core values is courage. To successfully implement Scrum we must overcome a range of different fears. It is important to be fearful of fear as it inevitably leads to diminished innovation, the fostering of a ‘blame game’ culture as well as ‘paralysis analysis’ when every action the team takes is scrutinized to avoid mistakes and the ‘whipping stick’ that follows. In part 1, I wrote about the fear of change in Scrum. In part 2 of this 3 part blog series I tackle another of the big fears when implementing Scrum – the fear of exposure.
Fear of Exposure in Scrum
Some developers just like to be left alone in a corner to focus on what they are working on (for better or worse) and can become quite defensive about perceived regular inspections of what they are working on. The problem for these ‘closed book’ developers is the fact that Scrum is all about regular inspections – not to spy of course but to identify waste and misguided ‘progress’.
Of course these inspection ceremonies such as the daily scrums, sprint reviews and retrospectives may also uncover those individuals (and I use that word on purpose) that genuinely don’t wish to do the right thing for the team. These few ‘bad eggs’ are often the ones who are most afraid of exposure as the rug that they have been using to cover up poor quality, lazy ‘work’ is dramatically pulled out from under them.
Feel Free to be Exposed in Scrum
Growing up in Australia we are taught very early on how dangerous sun exposure can be. Stay out too long and you will be nursing red, painful skin for several days. That being said, let’s not be too tough on our source of life as staying out for a short, disciplined period of time can lead to a nice, healthy glow and an important dose of vitamin D.
Scrum’s focus on regular inspection of both the product and the process is all about gaining the glow and avoiding the burn. It is much easier to take care of tanned skin as opposed to red raw, burnt skin. This is exactly the same as software. If we can detect issues early and often, there will be less painful surprises later on that require significant nursing and attention.
I find that when framed in that way, team members (who genuinely wish to do the right thing) will embrace these ceremonies even if they have a natural inclination to stay in a corner with headphones on.
Have you had to deal with a fear of exposure in your organization or team? How did you tackle it? Did you manage to overcome it? Let me know what happened and how you handled it by leaving a comment below.
—————————————————————————————————————————————————
If you liked this article you can:
Or you can share it:

Hi Ilan,
Great article and I’m enjoying this series of posts that you’ve got going. I can relate to this article. Scrum has been working well for my organization but we kept having one team that didn’t want to come on board. We finally got them on board and we found 2 developers who seemed to suffer from a fear of exposure.
One of the devs took on the fact that the regular inspections were helpful because when he was stuck on something and he could call out for help. He mentioned that having a licence to have someone else inspect his work was a good thing. Previously, he was scared to put up his hand and ask for help because he didn’t want to look like he wasn’t good at his job.
The other developer who was opposed to Scrum never quite came around. He was more into hiding his work under the ‘rug’ that you mention. I now know why he was so against it. Needless to say, it didn’t work out and we parted ways.
Nice article.
Thanks for the feedback and for sharing your experiences Greg