Get certified - Transform your world of work today


Why So Many Companies Struggle with the Scrum Framework

The top 10 challenges

2 November 2017

Zoran Vujkov

According to the Scrum Guide, “Scrum is lightweight, simple to understand, difficult to master.”

According to Scrum creators, “Scrum does not contain redundant rules or practices. As such, for it to work as intended, it must be implemented holistically. Partially adopting Scrum is equal to not adopting it at all.”

Ken Schwaber once said, “Scrum is like chess. You either play it as its rules state, or you don’t.”

So why do so many companies struggle with using the Scrum framework? Here are the top 10 challenges, based on my experience.

1. Company culture

When a company adopts Scrum, some of its practices are inconsistent with the existing company’s culture. In response, the company tries to change Scrum so that it is consistent and better aligns with the organizational culture.

Ken Schwaber illustrates this point clearly: “I ask someone if they use Scrum. They respond, ‘Yes, we use Scrum, but our manager believes that we will fail if he doesn’t tell us what to do, so we are told what to do and how to do it.’” In these companies, team self-organization does not occur. Instead of trying to change Scrum, companies should address the challenges that Scrum framework presents.

2. Scrum as a silver bullet

Some companies expect that the Scrum framework has an answer for every problem they experience. The Scrum framework has a small number of rules used to bind the events, roles, and artifacts that govern the relationships and interactions among them. When rules are not stated, Scrum users figure out what to do using the inspect-and-adapt mechanisms of Scrum’s empirical nature. This realization can be painful for many companies — Scrum is not a problem-solving framework; it is a problem-finding framework. Scrum exposes dysfunctions and waste that prevent companies from reaching their true potential. It is important for companies to address these dysfunctions as soon as they are discovered.

3. Scrum principles

Leaders neither understand nor accept the following Scrum principles, as defined by Ken Schwaber and Jeff Sutherland:
  • Effective software development is best implemented via an empirical rather than planned process.
  • Once organizational impediments are removed, a self-organizing and self-managing team will naturally deliver better software than would otherwise be the case.
  • A team can deliver the most valuable software within a prescribed time and budget, and yet the team can’t definitively predict the exact functionality of what will be delivered.
Acceptance is important, because these principles imply potentially significant change to the company that chooses to adopt Scrum.

4. Requirements

Poorly written or understood user stories and acceptance criteria, expansive user stories, dependent user stories, and user stories not ready to be worked on significantly reduce the team’s velocity. This challenge was important enough to update the Scrum Guide to include the concept of ready. The Scrum Guide recommends that the Scrum Team agree on a common Definition of Ready and that only ready user stories go into a sprint backlog. The goal of the product backlog refinement is to assure a ready state for user stories targeted for the next sprint. Requirements that are ready increase a team’s velocity.

5. Definition of Done

Many Scrum Teams have software that is not “done” at the end of the sprint. One of the main reasons is related to a poor, undefined, or unclear Definition of Done (DoD). Typically, these Scrum Teams lack engineering practices (e.g., review code, automated integration testing, unit testing, continuous integration, etc.). As a consequence, these Scrum Teams create bad code and accumulate technical debt, which reduces the team’s velocity. DoD should not only include different engineering practices but also integration testing and continuous integration. The key is to contain bugs within a sprint by fixing them immediately, because that will increase the team’s velocity.

6. Dysfunctional leadership

Loading too many projects that are bigger than development’s capacity causes constant context switching. Symptoms of dysfunctional leadership include:
  • Every requirement is considered a “must have”
  • Features are more important than building in quality
  • Lack of Agile understanding
  • Fear of change
  • No testing
  • No continuous integration
Leaders must set the direction and provide challenging goals for teams, trust people, get involved, help teams do great work, encourage collaboration and communication beyond silos, and identify and remove impediments. By doing these things, they will increase the team’s velocity.

7. Poor Agile coaching

No Agile coach or poor Agile coaching generates the following results:
  • Developers not acting as a team
  • Silos and specialization
  • No continuous improvements or inertia
  • Pretending to be Agile
  • A culture that is a hybrid between Agile and Waterfall
  • No customer collaboration
  • No working software at the end of sprint
  • No flexible response to change
Companies shouldn’t start the Agile journey without the support of a good, experienced coach. A coach must perform the following practices:
  • Conducts the initial Agile assessment and creates an improvement backlog, which will be used as a reference point for further improvements
  • Helps the ScrumMaster, product owner (PO), and development team in ensuring that Agile is understood and enacted
  • Helps with scaling
  • Facilitates the organizational Agile transformation and measures improvement continuously

8. Scrum events

Scrum Teams either don’t run all Scrum events or understand the benefits of each Scrum event. The Scrum framework has four formal Scrum events.

Below are the benefits of each event:
  • Sprint planning – Increases the team’s confidence that they will deliver what they forecasted
  • Daily Scrum – Optimizes the probability that the development team will meet the sprint goal by getting together daily to self-organize and synchronize their work
  • Sprint review – Gathers customers’ feedback and provides a chance to review the remaining product backlog
  • Sprint retrospective – Supports the team’s continuous improvement
As you can see, it is important for a Scrum Team to understand the benefits of Scrum events, which are necessary in supporting the inspect-and-adapt mechanisms of Scrum’s empirical nature.

9. Lack of visibility

Transparency has a significant impact on building trust between development and business. Transparency is an important pillar of any empirical process, including the Scrum framework. Scrum is about enabling the best possible flow throughout the team. By using a Scrum board, the team can increase visibility; better self-organize around a given goal; and better focus on eliminating pointless waste, such as multitasking, half-built software, and defects.

10. Scrum roles

Lots of companies misunderstand the Scrum roles and try to combine them with the existing roles. The PO is responsible for maximizing the value of the product and optimizing the value of the work of the development team. To do that, the PO must have domain knowledge, understand Scrum, be available to the team, have authority over the product backlog, and be accountable for the value delivered per story point. When companies combine the PO and the business analyst role, the PO usually has no authority and passion about the product, which ultimately has bearing on what the value team delivers.

The ScrumMaster (SM) is responsible for ensuring that Scrum is understood and enacted. The SM is a servant-leader for the Scrum Team and leads without authority. When companies combine the ScrumMaster and the team leader role, they give the SM too much authority, which affects the team’s self-organization.

The development team is a long-living, cross-functional, and self-organizing team that does the work of delivering a potentially shippable increment of a “done” product at the end of each sprint. Lots of companies try to run with a component team instead. Component teams can’t have a done product increment at the end of sprint because of dependencies on other component teams and the integration that happens at the end. Companies must understand Scrum roles and apply them as intended.

In my opinion, it’s necessary to address these challenges, because they prevent companies from becoming Agile.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 5 (16 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up