Implementing Scrum: Challenges

implementing scrum
implementing scrum

Organizations that want to make a move to Agile will need to fully understand what is Agile and what challenges are likely to appear on the road to implementing SCRUM. There are a lot of examples where Agile implementations have gone awry and it is costly on so many levels. Implementing SCRUM is not that easy and it requires a lot of preparation, from technical aspects like, tools, techniques and processes to a whole new way of thinking related to managing projects.

Note: I have used several books and white papers for research and while the links will take you to a particular resource, you may or may not have to pay to see that resource, depending on the copyright terms of that particular resource.

I have done a some research into which challenge are most likely to appear when implementing SCRUM and this what I have discovered:

Implementing Scrum Challenges

Changing role of managers

In the traditional approaches to project management managers were in control. They decided what is to be done and when needs to be done. Scrum on the other hand emphasizes team autonomy. Here the manager role is very different, and managers need to learn and adapt how they behave in a Scrum environment. Changing a manager’s mindset requires time.

“One of the problems is that managers have to understand the difference of managing people, as opposed to leading people. In Scrum the manager needs to listen to the team and help them remove impediments”.

Sutherland, J.

The Scrum Master acts as a manager and his tasks are leading the team and protecting it from problems and impediments as soon as they arise.This task is crucial for the Scrum process because:

“If a defect or a problem is not addressed immediately after it is identified, rework will accumulate and it will be difficult to deliver a sprint with high quality and maintain a high velocity”.

Sutherland, J., Jakobsen, C. R.

Furthermore the Scrum Master has to enforce the Scrum laws and focus on improving communication among the development team. This is critical as if not done properly and the team has too much freedom they can easily return to their old ways of doing work.

“The self-organized team nature of Scrum immediately surfaces negative outcomes from lack of trust, fear of conflict, lack of commitment and accountability, and inattention to results. The Scrum Master must identify and clarify these impediments and then work with the team and Management to remove them.”

Altman, I, Sutherland, J.

Implementing Scrum inside an organization will need upper management support. If there is no support then the Scrum implementation could face an impeding doom. Lack of training and resources could lead to unmotivated employees and that could easily translate into a failed attempt to implement Scrum.

Scrum creates very little documentation so management has the power to enforce the production of documentation by using the command and control structure from old methodologies. This obviously conflicts with one of the most important values of Agile.

Scrum teams must be able to figure out how to accomplish their work, but if they are instructed, they aren’t free to work the best way possible. This is a very important change in the manager role, this constant pushing and controlling instead of letting the team self-organize.

Team Autonomy

Implementing SCRUM at the team level will usually imply that three different types of autonomy must be established: Individual autonomy, internal autonomy and external autonomy.

Individual autonomy is the range of freedom a team member has in doing his tasks, internal autonomy is the degree to which the team share decision power, and external autonomy is the influence from outside the development team that can affect teams activities.

The most important type of autonomy is internal. Here the team is responsible for the result of the Sprint. The team must be committed to the project tasks, there must be a high level of transparency when it comes to impediments, and meetings must be taken seriously.

If this doesn’t occur than individual autonomy can appear. Here team members will focus on their own tasks and fail to report problems to the Scrum Manager and can result in a dysfunctional team. This is an issue that has been discussed in depth by Abrahamsson, P. and Marchenko,  and by Altman, I, Sutherland, J. in their respective work. Team meetings should be respected and penalties for absentees must be enforced.

“For Scrum to work, you must have trust, openness to conflict, commitment, accountability, and attention to results on a team”.

Granvik, B., Sutherland, J.

Scrum teams must be cross-functional and team members that are specialized are not desirable. This is because of the lack of cross-training. Specialization plays the main role in problems regarding self-management. In the past developers used to work alone and focus on themselves rather than the team. This propagated a lack of commitment towards the team objectives. This mainly was caused by specialization where the team members didn’t want to commit to other work and make decisions based on that. If a team member is handling multiple projects goals and needs can conflict and can negatively affect the ability of a team to self-manage.

Redundancy, known as backup, is the capability of a team member to take over someone else’s tasks when it is required. In practice this needs team members to have interdisciplinary skills. Over specialization leads to a lack of redundancy, thus reducing the team flexibility. Redundancy is viewed as an important requirement for self-organization.

Communication is very important and required when implementing Scrum. The Daily Scum Meetings improve communication so they are highly regarded. Lack of proper communication can lead to duplicate work being done. Also frequent communication with the customer to get feedback is very important. Ideally the Scrum team should be in the same working location and have allocated an open space working environment.

As for the external autonomy: the sprint backlog is immovable, managers don’t have the power to ask the team to change priorities. New ideas can be added on to the sprint backlog if they are worth it and don’t disrupt the flow of the work. Otherwise they will be added to the backlog and used in future sprints.

Clear backlogs

Having a busy backlog can influence productivity in a negative way. Focus should be put on developers knowing what they are required to do and work preparation. This leads to the need of clear and complete backlogs. In order to check the status of a backlog a checklist can be used and improper content removed as soon as possible.

“User stories should be compete, have acceptance criteria, and the usability tested before added to a sprint. User stories must be properly defined, prioritized and ready before the Sprint starts.”

Sutherland, J.

If one of the developers doesn’t comprehend the objective of the project, it will affect his productivity. It is believed critical that a good communication with the customer should be established. Backlog items must be prioritized starting with the items that add the most value to the product. Also there is the risk that other stakeholders or the Product Owner assume they own the Backlog and fail to properly prioritize the items that are considered important for the product development or the business.

Most of the time customers fail to know what they really want thus leading to changing requirements. Building the product that adds the most value to the client organization is paramount and having an active communication channel open is required.

Work items should be defined consistently throughout the project. Estimates for task completion should be tracked for better future estimation. Making use of a Scrum Board helps obtain an overview of the Sprint Status. Usually a Scrum Board contains at least three columns, possibly more: Product Backlog, Sprint Backlog, Work In progress and Tasks done.

Coaching and learning

Most of the times coaching as an activity has been underestimated.

“Agile master or agile coach is an essential role during agile adopting process in any organization”.

A team member who doesn’t know the Scrum rules can easily go back to old habits. Teaching Scrum techniques and implementing SCRUM mentality should be a continuous process. Also an experienced coach should attend during the transition to help disseminate the values of Scrum and answer all questions regarding the entire process.

This survey done among Scrum Masters after implementing SCRUM in their organizations uncovered the following:

  • “Take your time, it takes time to get used to Scrum, it won’t all change overnight”.
  • “Prepare for constant learning and do not read the manuals like a bible”.

This clearly states that every team is different and Scrum implementations are never the same.

Changing programming and project management habits is hard and it will take time and it is dependent on the level of commitment to change and training. Getting outside coaches and training the Product Owners is also important and it will actively contribute to implementing SCRUM successfully.

A misinterpretation of agile implementation can often lead to problems. Fast adoption and over enthusiasm for agile methods are often the factors of failure. Also a productivity drop can occur when implementing Scrum. Possible causes for this are: lack of commitment to change, believe that the new methodology fits the organization.

Team members must give constant feedback to each other in order to improve their quality of work. This plays a crucial role and requires transparency and openness. Very often problems are not reported because the team member views them as personal or they don’t trust the Scrum Master. Problems that are not fixed or handled properly could lead to the team stopping reporting them. Continuous learning process always takes time and if pressure if high this will in term affect learning.


Sprints usually are 4 weeks long. Teams should stick to the Sprint Backlog during the Sprint. Changes to the Sprint Backlog are allowed only in exceptional cases (productivity must not be affected). During the planning meetings backlogs can be altered then the sprint backlog is fixed. This can sometimes cause a perception that inflexibility is present, because changes cannot happen instantly. Managers often are skeptical about this inflexibility but this is one of the core values of Scrum and must be upheld.

The way productivity is measured must be carefully chosen as it will influence the way people preform in their work.Overcommitting to a certain outcome is dangerous and unrealistic and it can cause real productivity problems. This builds up pressure and quality might have to suffer.

Over-commitment is a bad habit. If someone is pressured to commit to an outcome that is not realistic, this can cause serious problems in productivity. Work pressure is high and quality might be at risk. Meanwhile if bug fixing or maintenance takes too long this can also reduce productivity.

Resistance to change

Several studies show that resistance to change is one of the most important factors in the adoption of Scrum.

“The problems are mainly caused by resistance to, or over-enthusiasm for, agile practices within a software development team”

Moe, N. B., Dyba, T., Dingsoyr, T.

Abrupt change in the organization’s development structure can cause resistance.

Testing is highly regarded in Scrum, so testers can be reticent because of the amount of work they have to do. Managers are uncomfortable with the amount of project documentation resulted. Planning and costing cannot be estimated properly due to changing requirement. Projects are unrestricted, thus accepting a method that produces more uncertainty if really hard.

In comparison with PRINCE2 environment the adoption of Scrum feels risky. It brings a feeling of uncertainty because of the lack of requirements stated from the outset. Having specialized individuals makes less of a difference as Scrum requires cross-functionality across the team. This differences create resistance when adopting Scrum method.

Quality and testing

Scrum has short iterations named Sprints. Their goal is to create the most business value for the client as possible and as quickly as possible. This conflicts with the need for long term quality, and quality requirements are overlooked so that the time schedule can be reached. If the quality criteria isn’t respected there will be quality issues because testing is not done properly. Testing should be done continuously, developers should test at the same time they are coding and automated builds and deployment are a critical part of agile and must be used. Furthermore practices like pair programming, continuous integration and test driven development are hard to implement.

Defects can delay releases, make code difficult to maintain and change in the face of changing requirement. Overcommitting can lead to a low quality product. If completing the sprint backlog is in danger than testing and code refactoring can be dropped or it will lead to late delivery which is not accepted.

Documentation needs to be clear and complete as work is frequently passed from one developer to another and a failure to do that can cause productivity problems.


Want to find out more about SCRUM or PRINCE2, or how the two can work together check these resources out.

Are you implementing SCRUM? or  Maybe just thinking about it, please let us know what you think about the article. Post your comment below.

Image courtesy of Freepik


Please enter your comment!
Please enter your name here