Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Making Scrum Stick: Overcoming Anxiety And Fear

Making Scrum Stick: Overcoming Anxiety And Fear


“The key to change is to let go of fear” – Rosanne Cash

Changing anything often invokes fear in people; it is something new and, as such, we don’t know what is involved. We are naturally skeptical of the unknown and, of course, there is always a chance we might not be very good at it, or even worse, might look silly while trying. While a team can grab on to something as simple and effective as Scrum quite quickly, all the associated changes that spring up as a result can cause significant worries. There are some very common broad issues that I warn people to look out for when adopting Scrum in an organization as well as a whole host of nuances that will almost inevitably crop up at some time as well.

I share a few of them in this article so that you can be prepared for them or, perhaps, not feel too bad that you are experiencing them yourself – they are common.

That’s Not The Way We Do Things Around Here

“Change is like heaven: Everyone wants to go there, but nobody wants to die” – Carly Fiorina

When I heard Carly use this phrase she accompanied it with the statement that when most people think of change they think that everyone else needs to change to be a little bit more like them. When using Scrum properly in an organization, it requires pretty much everyone to change the way they work.

There are a lot more opportunities to hide in a waterfall project and this can be attractive. The good news is that, from a business perspective, we are less concerned with what each individual contributes and more interested in the effectiveness of the team.

The team will naturally be interested in what the individuals are contributing and I have to say I was expecting a “Survivor” style trend with teams “voting off” the weaker members so the team doesn’t get dragged down. I have, however, been pleasantly surprised with what I have seen in practice over the last 10 years. The vast majority of Scrum teams that I have seen have favored a supportive approach to lift up the weaker team members rather than boot them off the team. Now of course, if there are other agendas present this will have a major influence on the team.

A common fear I see is that of the super-specialist. The “hero developers” are often fearful of Scrum because it is much more important for the team to succeed rather than the individual. A Scrum team realizes that by having super-specialists in any particular discipline, we are increasing risks in the project and, longer term, in the organization. In Scrum, we would much rather deliver something that the business or our customers need rather than what the people and skills we have enable us to deliver.

This doesn’t mean, however, that we want all Scrum team members to become homogeneous, interchangeable resources (a terrible word to describe people anyway); far from it. We still want people to follow their passions and develop their interest areas and skill levels; the difference being we want more generalizing specialists that allow us to be more cross-functional. When they realize this, most people acknowledge they cannot be quite so self-indulgent and grasp the opportunity to broaden their skill set.

Bringing in HR early (in the initial training sessions is a good idea) can help with this fear as they can assist in re-structuring policies to better support the change while reassuring people of their importance and incorporating their personal desires. HR should also be included to help conquer team fear, and issues with Scrum’s demands for greater communication, feedback and interaction. Often people in an organization haven’t received any training in simple things like giving and receiving feedback or dealing with conflict – both essential ingredients in a successful, high-performing, self-organizing team.

From a Product Owner perspective, Scrum requires them to make early and regular difficult decisions on priorities – what items from the Product Backlog should we do now and later? In a traditional project environment, these decisions can be deferred and not judged until very late as they only come together near the end of the project. In Scrum, we are asking Product Owners to make these calls every Sprint which is scary but actually, in practice, makes these decisions a lot easier as the worst that can happen is they make the wrong decision for a Sprint – they can change it in a month.

Strangely enough, relatively few people are fearful of being ScrumMasters, despite it being a role that combines a lot of responsibility with no authority. People are most fearful of this role when they are selected for it and either have a poor understanding of what is involved or are not clear on how it is different to their previous role.

What About The Project Managers?

This question comes up time and again and is met with great puzzlement by many – how does Scrum work without a project manager? Someone to take charge, look at the bigger picture, act as the translator/middle man. It is true there is no project manager role in Scrum; this doesn’t mean, however, that there is no project management. The traditional responsibilities of the project manager are shared across the three Scrum roles (and some of them are no longer necessary). I have seen companies deal with this in many ways and at the two extremes are:

  1. Call your project managers ScrumMasters.
  2. Fire all of your project managers.

I would recommend neither of these. Of course, some project managers will make excellent ScrumMasters (read Stacia Broderick’s lightbulb moment for a great example of the transition process) but, of course, some will make terrible ScrumMasters. Those that are unable to let go of their illusion of control over a team will never allow the team to flourish and realize its potential. However, although you should probably expect some people to walk away from a Scrum organization, project managers are still valuable in most organizations and great change agents and impediment removers. Some even make great Product Owners. Project managers should not fear Scrum although it is entirely understandable at first. Indeed, when I changed role from Project Manager to ScrumMaster my initial feeling was that I was not needed but that was not the case; I was just needed in a different way. I cannot recommend strongly enough to any project managers out there to try and do themselves out of a job by building up a self-organizing Scrum team.

What About My Plan?

“Fear has a large shadow, but he himself is small” – Ruth Gendler

Another big barrier to teams making the jump to agile is the lack of the comforting predictive plan whereby we plan out the uncertainty in a project, plot the path, determine the end date and the cost then produce the nice reports along the way. Funnily enough whenever I ask the question “but are those plans ever right?” I always get a negative response. Yet we place so much faith in them and they absolutely have to be there because it would be too scary to proceed without one.

The good news is that a Scrum project will come up with a baseline view of how much the project will cost and when it is likely to be finished. The only difference is that we are very explicit right from the start that this is wrong and we will make it better as soon as we start working on it. There is an amazing feeling of relief when we can become comfortable with uncertainty and a freedom to actually discover what is needed at the appropriate time. We can also avoid the many technical successes of the past – a project that has “met the requirements” but doesn’t do what we need – because, instead of relentlessly following the pre-defined plan we will adapt our projects to the inevitably changing conditions.

Progress reports are a lot easier to deal with on a Scrum project as well because we can see, tangibly, what we have produced every Sprint. Most of the reporting structure we have in projects is to deal with the uncertainty of the plan and the fact that so much time will elapse before we can objectively assess progress that we need regular reports to keep our comfort factor.

Get some help

Doug Shimp recently tweeted “if you think it is expensive to hire a professional to do the job, wait until you hire an amateur…get a trainer/coach” and he has a point. Getting somebody in who has been there and seen it before not only helps you avoid some pretty costly mistakes but also provides a great deal of confidence for your teams – it’s suddenly not quite so scary for them. Again, a good coach will do themselves out of a job as quickly as possible by sharing their knowledge and helping people learn from their own mistakes and the coaches experiences. There is sometimes a fear that we don’t want other people (especially outsiders) to see our dirty laundry but it’s OK to ask for help and, the chances are the coaches have made the same mistakes you are making right now.

Take your time

There is almost never an absolute drop-dead timeframe by which a Scrum change must be successfully embedded and, depending on the size and culture of your organization, this is likely to take years (seriously…years!) so be prepared to take your time. Don’t rush it but equally keeping a change going for that long takes dedication as momentum can easily drop off after the early enthusiasm wears off. Keep celebrating successes and setting yourself new challenges, explicitly stating the benefits of achieving them. This is the best way to keep it going along with planning for succession. The management who initially sponsor the change to Scrum will likely be gone or in a different role by the time it finishes so plan for succession before it is needed; make sure there is a seamless handover so no momentum is lost.


Scrum is a massive change for everyone in the team and, eventually, the organization. All change invokes fear and recognizing and then discussing those fears goes a long way to mitigating and removing them. Sometimes having an experienced coach there who has seen it all before can make a big difference. The only way you can get anyone to change is to explain how this change will be beneficial for them – you cannot buy commitment, only compliance – but the good news is there are benefits from Scrum for everyone and it is absolutely OK to take your time on the journey.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Right on the money

    by Maritza van den Heuvel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm the PO of a team that is fairly new at scrum. After an initial attempt at implementing scrum last year was ditched to reach a crazy deadline last year, we restarted the process in January this year.

    Eight months down the line, we have the process down and we're starting to grapple with the very real issue of the organizational change that is needed for us to become really good at scrum. And with that has come some very real resistance from key team members who realize that they're being challenged to break out of their hero mind set.

    This post neatly summarized this challenge, and the fact that we can only move forward to the next level if we successfully address the fears and anxiety. Thank you!

  • heresy

    by phloid domino,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, I am about to commit heresey: I don't believe in Scrum, or Agile.

    In theory it all sounds great; in fact I was enthused when first learning about various Agile approaches. Had long been aware of how broken the traditional methods were.

    But, as the author states, "When using Scrum properly in an organization, it requires pretty much everyone to change the way they work." The same can be said of most Agile disciplines/methods.

    And guess who won't change the way they work? That's right, the suits. The so called 'upper' management types, whose primary qualifications seem to be the ability to look at a calendar and to be rude to their 'subordinates'.

    I've seen managers, directors, vp's etc talk talk talk about process improvement, some 'embracing' Agile, XP, Scrum, etc, and then it becomes clear that what they really mean is: faster schedules, more overtime, more micromanagement, under a new name.

    After 40 years in software development, I've sadly concluded that only regulation can save it. Every aspect of the development process needs to be regulated to strict quality standards.

    This includes engineers, but like true engineers in other fields (mechanical, civil, etc), real objective standards are needed, and if an engineer won't sign off on something, it simply can not be 'shipped'.

    The deep disease in the software field of 'aggressive' schedules MUST stop. Quality matters more than speed.

    Speaking of quality, a long time ago I heard it put this way:

    Quality is like oats. If you want fresh clean oats, you pay the price. If you're willing to settle for oats that have been through the horse once, that comes cheaper.

  • Amen brother!

    by Kurt Nielsen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This a great summary of the issues at hand. No doubt several of your points will find their way into my work. I have worked with Scrum for 5 years now and am a Scrum Trainer and coach. I have seen people and organizations fail and succeed.

    I would like to add my five cents worth of comment.

    I believe I can go into a team in an organization and get them to use and benefit from Scrum, unless there are deep personality issues or lack of commitment in the team. I can't make the inmates in the prisons here make more road signs using Scrum.

    But that is at the tactical level, where people produce stuff that matters and is visible. Where it becomes really difficult is when you want to take it to the strategical level and get the whole organization to work the agile way.

    Now you meet administrators and financial people, whose deliverables are somewhat harder to identify, hence often based on following procedures, rules and "the way we do it here". An individual's sense of value (and sometimes compensation) can be built totally on following procedures. They are also older and we all generally do get less flexible with age.

    The greatest single obstacle I have come across is that upper management cannot give up the illusion of "following a plan" (that is a detailed task oriented plan). It simply rocks their whole world-view, that is what they have been taught at business colleges, that is what they have done for 30 years. To their mind if a project team fails to come up with this detailed plan, it can only mean that they are lazy or incompetent, "Pull yourselves together guys".

    I have tried to challenge such people by saying that their insistence on a detailed task-oriented plan is the same as saying "From now on, we choose to ignore any new information that is discovered" or its corollary: "we know right now all there is to know about this subject/project".

    Sometimes this provokes change, sometimes it is a lost case.

  • Re: heresy

    by Geoff Watts,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for your comment and I'm sorry to hear that but it's not something I can personally subscribe to. Admittedly these changes take time and there will undoubtedly be people to whom Scrum will be a threat. Some companies will not have the heart to tackle this but the good news is that I have seen some organisations actively deal with this.

    I've heard Ken Schwaber and others say that while successfully adopting Scrum you should expect about a 20% turnover in staff and I have also heard Craig Larman compare the transition to a whole generation of medical professionals dying off for a new "understanding" of treatment to really take hold, even though it's widely accepted the new way is better. I don't think anything that drastic needs to happen (and neither does Craig!) and I'm also convinced that regulation is not the answer.

    I'm completely with you on the 'aggressive' schedules issues and the inevitable drop in quality it leads to. This then descends into a negative spiral of distrust and contracts instead of collaboration and honesty. Regulation, to me at least, is another example of this distrust and reverting to CYA tactics so this is somewhere I don't personally want to go. People are the answer...

    There is hope!


  • Re: Amen brother!

    by Geoff Watts,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for your comments and kind words Kurt

    You are right - the less ingrained our habits are, the easier they are to change. Some 30-year "veterans" (as they call themselves) often refer to themselves in a similar context to alcoholics. They are constantly reminding themselves of what they are trying to avoid, knowing that they could slip back at any time.

    There are now a growing number of people who don't have that history and their habits are agile - the more of these people there are, the easier it becomes for the rest to get on and stay on the wagon. It takes time though

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p