Scrum may seem like it was built for the software development world, but its benefits go way beyond developers. Businesses are starting to realize that if they want to keep up with the pace of innovation, they need to change the way they work outside of development. And that involves Scrum.
“Companies can no longer work in a predictable annual cycle,” said Kreisler Ng, senior manager of agile delivery services at cPrime, an agile consulting firm. “Annual planning, assuming that the plans work, trying to predict that plan, and trying to control it is the wrong way to run business.”
It’s not just competition forcing this change; people simply don’t want to work in that way anymore, according to Matt Schenck, head of enterprise advocates for Atlassian, an enterprise software company. “It’s almost impossible to hire really good technical talent who [aren’t] able to work in [an agile] way. People are keenly aware of what happens in a waterfall methodology, and they don’t want to do it in their day-to-day job,” he said.
(Related: Test automation is on the rise)
Scrum is a lightweight approach to doing complex work in small increments. It allows teams to work together in small groups and deliver something in a short amount of time. “There is just enough of a framework there to allow people to collaborate around delivering the right thing in short cycles, and room to evolve into what makes sense in a particular context,” said Richard Lawrence, agile trainer and coach for Agile For All, an agile training and certification provider.
This way of working is not limited to the software development world, and it was never intended to be dominated by software developers, according to Mike Beedle, founder and CEO of Enterprise Scrum, a Scrum training, mentoring, coaching and consulting provider.
“Scrum is not a software development method. It never was,” he said. “Scrum is a management method. It is just a way to manage in a way that you are constantly inspecting and adapting. Where can you do that? In marketing, in compliance, in human resources, in finance, and throughout your organization.”
Beedle coined the term “enterprise Scrum” almost 20 years ago. According to him, enterprise Scrum is “a co-evolutionary, empirical, subsumption-based management framework to deliver the most business value in the shortest amount of time while balancing the benefits for all people involved, based on an abstraction, generalization, extension and parameterization of Scrum for generic, business, technique-pluggable, and scaled management purposes.”
Scrum creators Ken Schwaber and Jeff Sutherland created the community website ScrumGuides.org in 2014 to give organizations a definitive place for Scrum knowledge. ScrumGuides.org was a collaborative effort from the Scrum Alliance, Scrum.org and Scrum Inc.
“Scrum is a process framework that has been used to manage complex product development since the early 1990s,” they wrote on ScrumGuides.org. “Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.”
For years Beedle has been telling businesses this is a better way of working, but it wasn’t until recently they started to catch on. This is due to the fact that we are headed into the fourth Industrial Revolution, the innovation revolution, and with every Industrial Revolution comes a management revolution, he explained. Scrum will fuel that revolution.
“Times have changed. If you don’t make the right decisions, if you don’t implement the right technologies, if you don’t innovate fast enough, you are done. You will disappear,” said Beedle. “Your competitors in your industry are disrupting the industry, so you are either on the disrupting wave or you will be shattered by the disruption wave.”
Scaling Scrum in the organization
Traditionally, businesses have worked in a linear process where they did extensive upfront planning, then spent months to deliver a working product. Scrum transforms that way of working by creating cross-functional teams that work together in an iterative way toward the same goal. It changes the entire business, leadership, culture, mindset, projects, programs, innovation, and architecture.
“How does that scale? That scales with a lot of consideration and thought going into the process of how the company truly operates,” said Atlassian’s Schenck. “From there…you can start to map tools to it.
The first thing to understand is that Scrum simply works, Schenck explained. What doesn’t work is when the business says it needs to build something in 18 months, and then hopes it comes through on time, in budget and within scope. What does work is having a short-term commitment that can work within two weeks with smaller teams having to rely on themselves to get things delivered, he explained.
“Once you start to see that success take place and start to see it take place in multiple teams, then there is a notion of, ‘Okay how do we actually corral this and get better enterprise success?’ ” said Schenck.
Unfortunately, he explained, there is no out-of-the-box solution or right way to go about enterprise Scrum. “The same way your teams don’t do things in the same way within your organization, organizations aren’t going to do things in the same way,” he explained.
It starts with a willingness to working in a different way, according to Peter Green, agile transformation trainer and coach for Agile For All. “There isn’t any structural thing that needs to be in place; it is just a desire to work in a different way.”
Green explains that Scrum is both a product development framework as well as an organizational friction revealer. The organization needs to understand that Scrum will reveal issues along the way and suggest how it can take action.
“Scrum reveals issues, and people don’t always want to deal with them,” added Agile for All’s Lawrence. “Sometimes they blame Scrum for it rather than seeing that it was really just a mirror that showed them how they were working already.”
Green and Lawrence tend to stay away from the term “scaling Scrum” because it implies it has to start in software development when it doesn’t. The important thing is having the right mindset and understanding you will have to manage unpredictable work. “If you have a leader who has the mindset that everything is predictable, and now [they] are just going to add some Scrum to that they are probably not going to be very successful using it because that is the wrong paradigm.”
Companies can begin to get value within their existing structures by prioritizing their work in short cycles, doing retrospectives, and using some of the mechanics of Scrum, Lawrence explained. But in order to get the real breakthrough of Scrum, leaders have to decide how far they want to go. “Do they actually want to try to build a cross-functional team that includes a variety of skills? Or do they want to stick with the existing structure and just practice the basic framework?” he said.
In addition to executive leadership buy-in, middle management also has to get on board, according to cPrime’s Ng. Middle management’s way of working changes dramatically because they are no longer the command and control, he said. They instead become more of a coach empowering the teams and setting goals for them instead of dictating things to them and holding people accountable. The alignment of what the business wants to get out of Scrum and how it is changing the way things work needs to be understood by everyone in the company.
“What you don’t want is some optimizations of people. We want them all aligned and in agreement of what the common goal you are trying to achieve,” said Ng.
Enterprise Scrum’s Beedle adds that you cannot change into something you don’t understand.
A good idea is to carve out a piece of the organization and start your agile efforts there instead of going agile all at once, according to Sutherland, co-creator of Scrum and CEO of Scrum Inc. However, if an organization chooses to do so, it needs to understand that waterfall and agile are like two different operating systems, and in order for agile to really work, the organization needs to implement a completely separate leadership team and set of rules, Sutherland explained.
Atlassian’s Schenck recommends pairing alike teams together. Making sure their sprints and releases are aligned, and that they accept the same definition of “done,” takes practice and experimentation, he explained. “Find a way to manage Scrum for you at the team level. Make sure your teams are actually working in the right way,” he said.
“If your teams are doing Scrum in a way that is not actually successful, then keep tinkering there before you actually go and scale it upwards.”
cPrime tackles scaling through a new approach that involves coaching, training and tools. Its Software Services Lifecycle Management solution is designed to align business value with software services; integrate teams, process and technology software services; establish an advisor to manage the software services; bring in specialized technical experts; and create focused success metrics.
“It is not just the coaching side; it is holistically everything,” said cPrime’s Ng. “It is the process. It is the people. It is the mindset. It is giving them the tools to act out this mindset. That is how we approach scaling agile.”
Don’t choose tools too soon
Beware of the tools you choose, Lawrence warns. Choosing a tool too soon can end up dictating the process instead of having the team decide what works for them. “We suggest the simplest possible tools that you can use to support figuring out how you are going to work as a team early on,” he said.
Ng suggests tools have transparency and real-time data, but not an overload of data. Organizations need to be able to see the right data at the right time.
Ng believes frameworks like the Scaled Agile Framework (SAFe) can make it easier to adopt Scrum in large, complex organizations. “It is a set of common patterns that have been learned and developed through the years, so it is a starting point,” he said.
However Atlassian’s Schenck says it is important to understand that it takes effort to get SAFe to work the right way, and there are some inconsistencies.
Scrum Inc.’s Sutherland adds that SAFe is like training wheels for some businesses, but it does not address structuring the organization because cultural problems are hard to tackle. He says SAFe does not reduce the time to market enough.
“Its lead-case study is like 30% reduction in time to market,” said Sutherland. “That is an indication of an agile implementation not working. If you don’t get twice the work done in half the time, then there is something wrong with what you are doing.”
Sutherland also warns about approaches that have been “cooked up.” According to him, there are a few good ideas other organizations have come up with, but a lot of it is useless. “This whole thing about enterprise Scrum is problematic because [organizations] that have never done it before try to come up with frameworks that really stabilize the old organization and have no mechanisms for actually evolving the organization into an agile organization,” he said.
A key indicator of whether or not Scrum is working can be found in this question: Are they able to get their teams to deliver a shippable product at the end of the sprint? If not, then Scrum isn’t working, Sutherland explained.
Organizations need to figure out what their quarterly key performance indicators or objectives are, map them across the organization so everyone understands the goals, and then determine if they are headed down the right track, according to Ng.
The elements of Scrum
There are three roles when it comes to Scrum: the Scrum Master, product owner, and development team. According to Agile For All’s Lawrence, each role should translate smoothly outside of the realm of software development.
The Scrum Master is the most unique and difficult role organizations have to deal with, according to Agile For All’s Green. He explains that many businesses think the Scrum Master is similar to a project manager, so they just declare project managers to be Scrum Masters. The Scrum Master, however, refers to the coach: a facilitator role that helps teams, and prevents and removes roadblocks to their work.
The product owner identifies what is most important for the team to work on. He or she also manages the product backlog.
The development team refers to the people building the product. “When you see the word ‘developer’ in Scrum literature, it means product developer, not in the sense of a programmer,” said Green. “You could be a developer in the Scrum sense, and the way you contribute to the team is as a tester or UX designer. You can have developers on a marketing team and never do software development.”
The model for a Scrum team is between five to nine people delivering a product, whether it is marketing campaigns or software features. For those five to nine people, there is one product owner, one Scrum Master, and one team, according to Agile For All’s Lawrence.
There are also different elements and practices of Scrum that the enterprise brings into its workflows. For instance, ceremonies are one of the first things that get introduced. Ceremonies include sprint planning meetings, sprint review meetings and sprint retrospective meetings. “This gives you a good time to understand what is coming down the pipeline and what you need to go work on,” said Atlassian’s Schenck.
Then there are daily standup meetings. These are important because for teams that are distributed because you can implement a daily time where people come together and talk about what is important, according to Schenck.
“A lot of times we have meetings for the sake of meetings within enterprises,” he said. “If you are doing Scrum effectively, it is one of the first times that meetings by their definitions are supposed to be no BS, and the fact that there is no BS is very refreshing for all parties involved.”
Another element is just breaking down the work. “There are all these patterns that you see that all these teams are adopting, and it all goes back to iterative development: Thinking in short-term cycles, thinking fast, delivering fast with good quality, and then readjusting and planning,” said cPrime’s Ng.
Then there are burndown charts for monitoring sprint status; Scrum boards for planning and reporting; and product backlogs for features, bug fixes and non-functional requirements.
Enterprise Scrum’s Beedle notes that many of these elements focus on software development, but you can take the terminology and make it friendly to management. For instance, a product backlog is a value list, and a product owner is a business owner, he explained.
What remains the same when you take Scrum outside of development and into the organization is the ability to see further down the line. “They have the luxury of short-term planning. They are able to say, ‘Let’s commit to a smaller chunk of work, do that really well, finish it all the way, and then establish what we need to work on next,’ ” said Atlassian’s Schenck.
The history of Scrum
While Scrum is largely viewed as a software development methodology, it’s actually not derived from software. In 1986, The Harvard Business Review published “The New New Product Development Game.” According to Scrum Inc.’s Sutherland, that is where the term “Scrum” came from.
The report talks about how companies were taking new product development approaches to keep up with the fast-moving commercial world. Because of the way the teams were working closely together, the reporters said it reminded them of rugby, and therefore Scrum was born.
“Under the holistic or rugby approach, the phases overlap considerably, which enables the group to absorb the vibration or ‘noise’ generated throughout the development process,” according to the report. “When a bottleneck appears, the level of noise obviously increases. But the process does not come to a sudden halt; the team manages to push itself forward.”
According to Sutherland, Scrum has really derived from hardware. “The fact that a lot of people think it just arose in software shows they don’t understand the history and how it works.”
The different flavors of agile
Scrum is just one form of agile. The agile methodology has been in practice for decades, with the Agile Manifesto coming about in 2001. Since then, many organizations have taken different approaches to agile depending on what works for their business. According to Agile For All’s Lawrence, there are three dominant agile methodologies businesses turn to: Scrum, Kanban and Extreme Programming (XP).
XP is a prescriptive method with rules intended to improve work and responsiveness. However, XP is limited to software development. Scrum sits in the middle, and prescribes things about team structures and meetings. Kanban specifies almost nothing other than visualizing work and managing cycle times, according to Lawrence.
The organization will fall into a certain methodology depending on what the business calls for. “I find Scrum to be a sweet spot of just enough structure to be able to get started, make progress and iterate what works in your context, especially outside of software development, because it is diagnostic about what you are doing and how you do it,” said Lawrence.
However, if the team is doing unpredictable work where they can’t say if they can be done in the next two weeks, then Kanban might be a better approach because it allows them to visualize work and limits what is going on at any time, according to Agile For All’s Green.
Ng says sometimes businesses will have to mix both Scrum and Kanban. “You can mix them both depending on the type of work. If the team is doing feature work, they are probably more focused on Scrum. But if it is an environment that is highly unpredictable or they are troubleshooting tickets or a bug-squashing team, they may do more Kanban. It really doesn’t matter. It just depends on the work, and as long as the dependencies are hit across the team, that is fine,” he said.
However, if they want to change a business process, deliver shippable products in short cycles, and keep pace with competitors, Sutherland says there is no other approach that is going to scale with velocity for them than Scrum.
