Key Points

• Scrum is a great choice for any business, regardless of the industry.
• Getting your team on the ground floor with nomenclature and jargon surrounding Scrum is going to be one of your most difficult tasks in successful implementation.
• Your first goal should be an easily attainable project to get your Scrum teams used to the workflow of the approach.

Applying Scrum to non-software industries is a lot easier than you think. The most recent edition of the Scrum Guide has even prepared the approach for integration into other business sectors. As such, there has never been a better time for adapting and ultimately using Scrum in a non-software setting.

With that in mind, let’s dive in and look at some practical strategies for adopting Agile and Scrum in a non-software setting. We’ll look at some basic things you need to know, and how to best implement those to make the best of your organization’s chances at success.

Preparation

Any journey you take is going to have its first steps. For Scrum in a non-software setting, this is going to come down to introducing the concepts and nomenclature behind it. Scrum is a drastic change from many business methodologies, focusing on things like people rather than the processes behind the work.

Further, if you’ve got a team rather entrenched in the way things are done currently, then taking the steps to implement Scrum can be met with some resistance. At this point, before you’ve put down any sort of foundation of Scrum, you need to engage in good change management philosophies. This will help ease the transition and get leadership buying into the methodology early on.

Demystifying the Terminology

Scrum has quite a few phrases and words unique to it. As someone with a background in tech, there is nothing more difficult to get used to than jargon. So, this is the prime time for some educational training. Go over the definitions of things like Product, Artifacts, Sprints, Backlogs, and Done. These have vastly different definitions than you might expect, so it only stands to reason that you need to invest some time in defining them.

Get Leadership on Board

Any management approach, business philosophy, and so forth is fundamentally useless without your top-level leaders on board. Schedule meetings and explain the why behind the change. Scrum in a non-software setting is a flexible and powerful means of accomplishing goals, and when you align this to your strategic goals in the long term, you’re setting up the means for future success.

Leadership is incredibly important to have on board early. As these are the individuals who are going to guide the process and aid in implementation, you want everyone to be all in on the process in the first place.

Forming a Scrum Team

With the educational foundation out of the way, you’re ready to start getting to the bread and butter of Scrum: the Scrum team. Scrum teams should be kept small, with no more than 9 members per team. It is better to have multiple smaller teams with cross-functional members than to try and cram double the amount to get the work done. Ultimately, you’ll find larger teams are hindered by their sheer size when projects get underway.

Keep it small, it just works better that way. Additionally, this is a great time to start promoting self-reliance and self-management for the teams you organize, which we’ll touch on further.

Organizing a Cross-Functional Team

The first step of any Scrum project is the formation of a team. While keeping in the same department is fine and dandy, you want cross-functional teams. This gives differing perspectives, drawing upon unique experiences, and aids in getting the work done. Scrum teams should be self-reliant, as mentioned previously, so this is a vital time to make sure your teams know how that works.

They should have all the materials, tools, and resources necessary to guide and complete work. Anything less is essentially a failing of senior leadership. Accounting for the teams’ needs is going to have some growing pains, but better to do this now than to struggle with the implementation months or years down the line.

Define Roles

Scrum has different roles, much like any business approach might. Defining these roles and appointing individuals to them is going to be a trial by fire for Scrum. You aren’t venturing off solely into the deep end, however. Any team trying Scrum for the first time should focus on a practice project to get used to the workflow.

Scrum teams have three major roles to keep in mind:

• Product Owner: The individual responsible for overseeing the product and making sure work is being completed to ship out. Product owners are in charge of the Product Backlog, an itemized list of all tasks that must be accomplished before the project can be considered finished.
• Scrum Master: A Scrum master isn’t a senior manager necessarily, but is more akin to a Six Sigma Champion. This is someone well-versed in practicing Scrum, who can guide and coach teams to hew more closely to the principles and philosophy behind Scrum.
• Development Team: Despite the name, the development team doesn’t have to write a line of code. Instead, it is easier to think of this as the team doing all of the actual work needed on a project. In a cross-functional setting, this can include people from research departments, human resources, and even marketing to make sure you’re getting the best chances for your product’s success.

With the roles defined and people appointed, you’re ready to start creating a Product Backlog for your first true project.

Create a Backlog

Any Scrum project, regardless of it it’s in a non-software setting, is going to have a Product Backlog. This is all of the tasks and processes that need to be accomplished before a product can be considered finished in the first place. Get all the members of your team together to discuss the various components needed to complete a project.

From there, the Product Owner should take the time to prioritize items. Not everything is going to be massively important to the success of a project. When the items are ranked and categorized, you can further break them down into manageable chunks. These chunks, or tasks, are essentially decomposing complex tasks and processes into simpler, easier-to-accomplish items in your Backlog.

Sprints

With your team in place and a Product Backlog ready, it’s time to get to work. Scrum is defined by the use of Sprints, or short-duration projects intended to complete an item on the Product Backlog. These tasks rarely last longer than a month on the upper end, with a week or two being more common for the average Sprint.

Sprints are the building blocks of any Scrum project, and something that will be a common sight as you get more accustomed to the practice. There are a few twists on the usual tasks with Sprints, as you’ll see.

Sprint Planning

Every Sprint is going to have a Sprint Planning session behind it. This is where your team sits down and discusses what is realistically achievable over a short period. Each team is going to have a different capacity and workflow, and that’s fine. Scrum in non-software settings isn’t about uniformity, but more about results.

Planning sets down the groundwork for the expectations and progress needed to complete a Sprint, and will become a common tool for your teams as time goes on.

Daily Scrums

Scrum, or stand-up meetings, is a regular part of the Scrum way of doing things. These are daily meetings that weigh in at maybe 15 to 30 minutes on the top end and let teams discuss what they’re doing and how they’re progressing. This has a few different benefits. Daily meetings on progress help to inform the Product Owner of how things are going, allowing them to plan and accommodate other items on the Backlog as needed.

Additionally, these daily meetings are going to be instrumental in setting the tempo for future projects. When you have teams regularly reporting on the work they’re doing, you’re setting the expectations for a team to ultimately achieve success.

Reviews and Retrospectives

Scrum, like Six Sigma, is a discipline built upon learning from the past. You’re gathering data, and you’re applying that to the next project. In the future, when you’ve completed your first Scrum project, it’ll be time for a retrospective. This is a highly instructive event, so make sure you’re documenting all the steps. A retrospective is a teardown of the work done, and will look at bottlenecks and pain points.

You aren’t asking yourself what went wrong, however. You’re looking at how you can improve things to minimize issues in the future.

Continuous Improvement

Scrum is a lot like many of the other disciplines we’ve covered in the past. You’re building toward a better tomorrow by improving your outputs today. Continuous improvement is one of those buzzwords that gets bandied about in many organizations, but this is your opportunity to build on that.

Visualizing Work

Visualizing the work is one of the most valuable tools you’ve got available in Scrum. The use of something like a Kanban Board isn’t just relegated to coders, but something you can leverage in a non-software industry as well. Whether you’re aiming for a digital or physical board, this is a great way to show the items on a Backlog and act upon them.

Metrics and Progress

Understanding the progress a team is making has a few different benefits. Tracking progress isn’t entirely necessary, but can be useful. It can improve team morale while also giving a snapshot into what is being done in a project. As far as metrics, that’ll be down to your industry of choice. However, defining what Done means in your new Scrum projects is going to be key for the future.

Building Culture

An organization is only as strong as the culture at its core. It informs its ethos, goals, and ultimate vision when it comes to the products and services on offer. With Scrum at the heart of your organization, you have a chance to build a culture centered around continuous improvement. This can be a boon for any organization, especially if you haven’t been able to get everyone on the same page in terms of strategic goals.

Other Useful Tools and Concepts

Looking for something else to go with your morning coffee? You might want to take a closer look at the function of Gemba Walks for process improvement. These are one of the many valuable tools available in Lean, and can be applied to just about any industry you can imagine.

Additionally, you might want to take a closer look at the Scrum Guide. Our recent article on the document demystifies some of the nomenclature and gets you on your way to a better understanding of the inner workings of the Scrum way of doing things.

Conclusion

Scrum for non-software industries is likely to be more common over the coming years. This flexible, people-first approach is well-suited for just about any industry and is worth doing the groundwork to get implemented now.

The image featured at the top of this post is ©Net Vector/Shutterstock.com.