Get certified - Transform your world of work today


Mainstreaming of Scrum and the Challenges of Popularity

How to adopt the Agile framework for maximum benefit

11 July 2016

In the last decade, Agile software development, especially Scrum, has gone from being at the cutting edge, practiced almost exclusively by early adopters in the software community, to more or less mainstream implementation by software and non-software teams. Unfortunately, with any mass adoption of an idea, there is a diffusion of the original message as the concept travels outward — the idea becomes diluted, or mixed with other ideas until you have various mutations of the original.

Through mainstreaming, Agile has become similarly diffused over time. I am a longtime ScrumMaster and coach, and these days I see a fair amount of backlash from teams complaining that Scrum doesn’t work for them, or work at all. When I dig deeper into these complaints, I find that what is being practiced and dismissed has become so diffused from the original framework that it cannot really be called Scrum.

My recent encounter with a well-known New York agency provides a good case study of many of the problems I see when Scrum is introduced and implemented in a diffused or mutated state. I was approached by this company to work as a coach for its software development team. The project leaders felt that they were not seeing the benefits that were promised by the Scrum community, and some in management questioned the merit of an adaptive or empirical approach over a plan-driven one (so-called Waterfall). The management was particularly frustrated because they had put a lot money into adopting Scrum, going so far as to send the entire development team of 18 people to become trained and Scrum certified. The managers bitterly complained that now they effectively had 18 ScrumMasters, and yet their production rate was dismal.

Project management told me that the biggest problem was that the work committed to each sprint was not completed and was carried over from iteration to iteration. The team routinely missed delivery dates, or they were forced to work unreasonable hours because they were in danger of missing promised delivery dates. Release planning was a game of chance because they had little confidence in their delivery pipeline. Their releases were the stuff of a developer’s nightmare — full of panic, angry demonstrations, and chaos for days before and after a big deployment.

The development team told me that even during a “normal” sprint, they were constantly anxious about being pulled off of their sprint work and put to work on unplanned items. Then, at the end of the sprint, they were left with much of their sprint work incomplete. I should also mention that though the entire team was certified through Scrum training, they did not have a formal ScrumMaster role; there were only team members and their product owner. Another big variance from the recommended Scrum framework was that they did not have a Daily Scrum. They explained that spending 15 minutes each day to align with each other was “disruptive,” even though this was trivial compared to the hours they lost each day on unplanned new work.

Scrum is incredibly lightweight, but it does have a few requirements. The three roles (team, ScrumMaster, and product owner) and four ceremonies (planning, daily stand-up, review, and retrospective) are all required. Eliminating the ScrumMaster role is not a viable solution; without the buffering role of the ScrumMaster, a team is open to any and all interruptions. This team had no one removing or escalating impediments on their behalf; they were interruption driven and without focus. Second, doing away with the daily stand-up not only takes away the opportunity to get aligned with each other and raise problems to the ScrumMaster; it also takes away the generative properties of the stand-up. More likely than not, daily stand-ups end with smaller breakout sessions between team members, leading to pair programming and collaborative problem-solving; this is one of real purposes of the Daily Scrum.

Another variance from the recommended Scrum framework was this team’s size; at 18 persons, it was twice the size of the maximum number of people recommended. Scrum works well when the team is small enough so that timely decisions can be made, and large enough so that all the skills necessary for building out the product are represented in the team. With so many people, this team was often paralyzed by even small decisions, and they struggled to think of themselves as a cohesive unit.

The report I made to this company was that what was being practiced was too diffused from the original framework to be called Scrum. And you cannot expect to reap all the benefits if you are doing something very different. I noted while talking to many of the stakeholders that they took Agility to mean being able to make change direction anytime, without any cost. I think this is a poor understanding of sprint economy. Yes, Agile was formulated to embrace change, but the sprint — the heartbeat of Scrum &mdash will be impacted if unplanned changes are introduced. A mature Scrum team can deal with high levels of unplanned activity by committing to a smaller work batch. But this team was too large and poorly structured to become self-organized enough to make good planning decisions.

The structural problems I saw with team — size, ceremonies, and roles — are easily fixed; this was not the big problem. Their real issue was that they were at odds culturally. Management wanted to control processes, and wanted to have the team fit perfectly into those processes. A true Scrum adoption requires a shift in control — the process should be owned by the team. But that doesn’t mean that management just walks away; they are responsible forcreating the environment, and exercising subtle control so that the team can fully take ownership of the process. This kind of maturing in Agility, evolution to the highest levels of fluidity, is a long-term process. You need a cultural investment, and you need time to build up experience as a team, none of which comes suddenly or from a shortcut. There isn’t a shortcut.

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 (1 ratings)


Tim Baffa, CSM, 7/20/2016 4:36:15 PM
Leza, a frequent analogy I use is that of a steel-link chain.

The chain is very flexible (agile), and can be altered in just about any way desired. However, the actual links (sprints) are solid and inflexible.

We cannot adjust the chain direction within a link, only at the point where one link ends and joins another link.

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