It’s been almost 20 years since the term “enterprise Scrum” was coined, but despite the years of practice, organizations still don’t quite understand what it is or how to implement it.

“There are a lot of users out there doing the technique, but unfortunately there is a large percentage that still doesn’t understand what it is and what it means for management,” said Mike Beedle, CEO of Enterprise Scrum Inc., an organization that provides training, mentoring, coaching and consultants for implementing enterprise Scrum.

(Related: How Scrum fits into enterprises)

The misunderstandings boil down to middle management, developers and roles.

The problem is that while upper management and development teams have been given a place in enterprise Scrum, middle management has until now been overlooked. “One thing that is very clear is that the middle management section has not been told anything about how to use Scrum, or how to profit from Scrum,” Beedle said. “We haven’t told middle management exactly what their role is in enterprise Scrum.”

This can cause confusion and failure when attempting to transition to enterprise Scrum because middle management acts as a liaison between upper management and development teams, and their role in enterprise Scrum is crucial to making sure all sides of the organization are changing together, according to Beedle. Without middle management, the transformation of upper management and development teams becomes disparate, and one side could revert to the old ways of doing things.

“In a world that changes so much, our management techniques are made to manage without change,” said Beedle. “So while the world changes so much, we don’t have a technique to manage rapid change, and that is where enterprise Scrum comes in. It is a technique to manage change within software development and outside of software development.”

But the misunderstanding about the methodology doesn’t end with management. One of the biggest misconceptions about enterprise Scrum is that organizations think it is solely used to increase productivity, according to Beedle. “Higher productivity is always nice, but you can actually optimize anything you want,” he said.

“You can optimize quality of service, you can optimize customer satisfaction, you can optimize cost reduction. You can really optimize any variable that is important to you.”

When it comes to developers, there is a misperception that Scrum is only for them rather than “a change in the system that involves everybody in the group creating a product, from product managers to UI designers to users to senior managers to developers and testers,” said Craig Larman, co-creator of Large-Scaled Scrum (LeSS), a framework designed to handle large-scale Scrum adoption.

And then there is confusion about what the principles of Scrum mean in terms of roles, according to Lawdan Shojaee, CEO of Axosoft, an agile project-management company. “While Scrum adopts the agile principles of people over process, those people are free to determine different requirements for different projects and even put strict processes into place,” she said.

“The traditional roles of software developers, testers, product owners and Scrum masters are all important. What Scrum brings to the table on the team roles is that they all have a big say in the what, how and when.”

It is important to understand all these aspects before an organization can be truly successful in scaling Scrum, according to Jon Terry, COO of LeanKit.

“Good people do amazing things when they can work together in a healthy environment toward a well understood goal,” he said.

Succeeding with enterprise Scrum
Once there is a clear understanding of what scaling Scrum means, organizations can move onto how they can successfully transition to it.

“The challenge now is to take the benefits and extend them past pilot projects and integrate the teams into a coherent approach,” said Terry. “A company can’t really get the full benefits of Scrum—even if all of its technology teams are practicing Scrum—if they haven’t linked those teams together and integrated the team-level approach with broader portfolio and financial control processes of the company.”

The key is to start small and grow success, according to Enterprise Scrum’s Beedle. Organizations should be prepared to take time to work out kinks and really understand it before introducing it to the entire company.

“You have to prove you can do it, and you can do it well,” he said. “Build success gradually; don’t transform the whole organization. Instead, transform one team at a time successfully, and through the retrospective and refinement process, analyze what are the best options for the organization.”

Don’t expect those options to be a silver bullet. According to Caleb Brown, agile coach for CollabNet, one of the biggest reasons organizations don’t succeed with enterprise Scrum is because they expect it to be a magical process that makes all their problems disappear. “It works because it’s a very disciplined way to approach work so that you can better identify and attempt to fix issues and improve how you work because failure is no longer so expensive,” he said.

And since there is no one-size-fits-all approach to scaling Scrum, it takes an understanding of a business’ unique system to decide where to start with its transformation. “Software development is an inherently complex and highly variable domain,” said Larman. “There isn’t any system or framework that’s going to magically make it easy.”

Instead of trying to take a pure Scrum approach, organizations should adopt hybrid techniques, according to LeanKit’s Terry. “Scaling up agility can’t just be scaling up Scrum. It will necessarily be a hybrid of Scrum, Kanban, DevOps and—let’s be honest—waterfall,” he said.

“We really think that a hybrid approach guided by a framework like SAFe is a major success factor versus implementing a pure-play approach and trying to adapt at the team level without an overarching road map.”

Although adopting a hybrid Scrum strategy is going to be easier than a pure Scrum approach, according to Axosoft’s Shojaee, it is still going to be a challenge because organizations will be used to a traditional paradigm. But, instead of running away from the unknown, organizations should embrace it, she said.

“When a team switches methodologies and starts to adopt Scrum, they will lose whatever project visibility they had—at least in the short term,” she said. “For larger enterprises, this can be crippling, and therefore the natural reaction is to pull back and do things the way they have always been done. For such organization, the best path is to start small: convert one or two teams to Scrum, wait until project visibility returns for those teams, then expand.”

And while there are no silver bullets, and tools aren’t going to magically transform an organization, they can help. “Providing burndown charts and dashboards that can be put into a development environment to keep the team in sync is another way to get better results,” said Shojaee.

The difference between enterprise Scrum and large-scale Scrum
Another area of confusion in Scrum is the different terminologies thrown around to describe it. “Enterprise Scrum” is often used to describe the extension of Scrum for business purposes, but the creators of LeSS believe that the term “scaling Scrum” is more appropriate for organizations looking at a large-scale software-intensive adoption of the methodology.

“The term ‘scaling Scrum’ is indeed a great general term for the family of extensions and variations of Scrum for scaling,” said LeSS’ Larman. “LeSS is scaling Scrum applied to large-scale product development with many teams on one product. Enterprise Scrum includes the application of Scrum outside of software development in other areas of the enterprise such as a marketing group adopting Scrum for a marketing project.”

LeanKit’s Terry added that when talking about enterprise anything, it is important to clarify what you mean by “enterprise.” “For some people that just means scaling Scrum beyond a few teams. But there’s a very different situation when the company in question is 500 versus 5,000,” he said.

To help organizations facilitate large-scale Scrum, Larman, along with Bas Vodde, created the LeSS framework for scaling agile development. “Standard Scrum is defined for a one-team product group; it doesn’t define or explain how to make Scrum work effectively when there are four or 44 teams working together on one common product,” said Larman.

“LeSS is a proven system for scaling Scrum to these large multi-team cases, and LeSS looks at Scrum and for each element asks ‘Why is it there?’ followed by ‘If we have more than one team, how can we achieve the same purposes on a larger scale?’ And then LeSS answers those questions with the simplest solution possible.”

Similar to enterprise Scrum, LeSS is not a silver-bullet solution: It takes time to successfully transition, and it requires education and top-down and bottom-up support.

“The goal is to learn to create the right solution that will make the most impact with the least costs,” Larman said.

In addition to LeSS, Ken Schwaber, co-creator of Scrum, recently introduced the Nexus framework for large-scale Scrum.

Nexus is the exoskeleton of scale Scrum that extends the basic Scrum framework and promotes best industry practices while removing dependencies and complexities, according to Schwaber. It is designed to help teams maximize productivity, rapidly build software, detect anomalies in productivity, and provide best Scrum practices. And for organizations looking to use the Nexus framework to scale beyond three to 10 teams, there is the Nexus+ framework.

“We’ve structured an uber Scrum,” Schwaber said in a video. “It is Scrum…except it now has artifacts and roles and some events that support a larger number of Scrum teams interoperating; and it’s got some practices in it about those teams working their product backlog to reduce the dependencies, changing the team members so they have more cohesion and less coupling, and working the software so the technical debt doesn’t kill them as they trip over each other in the software itself.

“This is a set of prescriptions of how to do [the] very hard work of taking a large number of people and making them effective and efficient, especially in the Scrum context where every bit of inefficiencies is glaringly obvious.”

Looking into the next 20 years
Enterprise Scrum’s Beedle believes that although it’s been 20 years and organizations still don’t fully understand it, Scrum is the future, and those who don’t adopt it won’t be around 20 years from now, he said.

“I am going to go out on a limb and say, unless there is something that does the same thing that enterprise Scrum does such as more agile management, we will see techniques like this be dominant because it is the only way we can cope with an ever-changing world,” he said.

Beedle added that when historians look back at this period, they are going to call it the Innovation Revolution. “Similar to the Industrial Revolution, where if you don’t innovate you will die,” he said.

Historians will see that successful companies tried to please the customer, adapted better, innovated faster, and stopped focusing on the bottom line, and that success will be because of Scrum, according to Beedle. “This style of management is here to stay forever—as long as the world keeps changing faster and faster,” he said.

CollabNet’s Brown agrees that Scrum is here for the long haul. “Agile isn’t just some weird fad; it’s how modern software development organizations succeed, and there is enough evidence now that it can no longer be denied,” he said.

“The question coming out of failed adoption is no longer, ‘Why did Scrum fail us?’ The question is, ‘What did we do wrong?’ ”

In addition, LeanKit’s Terry says there is a renewed focus in the Scrum community on figuring out how to best scale Scrum, and in the future we will see frameworks incorporating Scrum in their own ways.

The definition of enterprise Scrum
Jeff Sutherland, co-inventor of Scrum, and Beedle coined the term “enterprise Scrum” in 1995. According to Beedle, enterprise Scrum is “a business-oriented, scalable, general empirical management and execution framework. It can help manage with more agility any business process, including company management, strategy, marketing, sales, product development, software development, basic research, compliance management, business process redesign, entrepreneurship and startups, etc.”

Important roles to have in enterprise Scrum
Everyone on an enterprise Scrum team is just as important as the next person, but there are three significant roles necessary for a successful Scrum team:

Product Owner: Every Scrum instance requires a product owner or business owner, according to Beedle, “Business owners are business leaders. These are people that know the industry, they know the competition, they know the platform, and they make a to-do list of the best things to do in a situation.”

Scrum Master: The Scrum Master is responsible for the entire Scrum process, according to Beedle. They must ensure the team understands the principles of Scrum, and are implementing it the correct way. A Scrum Master should be able to take on the roles of a coach, mentor or project manager when necessary.

Developers: According to Jon Terry, COO of LeanKit, the term “developer” doesn’t necessary mean a programmer. “It means the people who cooperate to develop the solution and can be programmers, designers, [database administrators], testers, etc.—or even totally different skills if the solution isn’t software,” he said.

“The key is that the team includes a cross-functional mix of most of the skills needed to solve the problem most of the time. You probably can’t afford to have dedicated team members to fit all skill types just in case they are needed. But the team should be self-sufficient—let’s say, 80% of the time.”