So you’ve decided to go Agile. Great choice! Using Scrum can help bring you and your team into peak performance mode. But wait a minute — you start doing your homework, and you read in Jeff and J.J. Sutherland’s Scrum book that this framework was created “as a faster, more reliable, more effective way to create software.” If you are like me, your next thought is, “Uh oh, I’m not a developer. I guess this isn’t for me…”. However, don’t put down that Scrum book just yet. Scrum is not just for developers.
Truthfully, though Scrum was originally created for software development, its basic principles and practices can be applied to nearly any type of work across an array of markets and disciplines. With a little creativity and a solid understanding of the fundamentals, you can make Scrum work for you and your team, no matter what you may be trying to accomplish.
When Alley first transitioned to using dedicated Scrum teams, members of the operations and marketing departments (aka, non-developers) were left in limbo. We watched the development-focused teams around us change, adapt, and improve in their new structure while we continued using the same old methods. We quickly saw the success of these new rituals,, and decided we wanted in on Scrum. The Marketing and Operations Scrum Team (MOps for short) was born.
Redefining a product
In The Scrum Guide, there’s a lot of emphasis on the idea of creating a “product,” including research, development, release planning, etc. One of the first mental hurdles MOps had to clear was conceptualizing how Scrum would work for us when we don’t have traditional customers or create a traditional product. The answer? We had to redefine who our “customers” are and what “product” meant to our team.
Development teams can get to the end of a Sprint and have a functioning website or application to show for it. But what’s your “product” when your team’s focus is marketing or day-to-day operations? The answer can be a log of things, but they all have one trait in common: They provide value. For example, if we focus our Sprint efforts on an upcoming marketing conference: Our product becomes a well-planned event with scheduled talks, arranged travel logistics, and a release plan of social media content. Maybe our Sprint will focus on operations or HR initiatives: Our product becomes a new employee’s completed equipment setup or an insurance plan that has been reviewed, decided on, and implemented for the company.
The key here is to avoid getting bogged down by language. Recognize the value in your work, even when it doesn’t always result in the kind of tangible, shippable product that software developers would deliver.
Goal-setting
Another challenge we faced was figuring out how to operate as a Scrum Team when our members come from different focus areas of the company. MOps combines operations, human resources, marketing, and development operations — a diverse group of practice areas, to say the least. Sprint Goals are an important tool that helps align a team’s focus during a Sprint. For a development-focused team, a goal might look something like “deliver a working recirculation module for our customer’s website.” For a mixed team like ours, however, it may not be as straightforward to set that kind of singular goal.
This is an area where creativity comes into play. You may want to set multiple goals to cover some of the big-ticket items you’ll tackle in your Sprint Backlog. Or you may want to use a wider lens for your Sprint Goal by developing a theme that can be applied to multiple types of tasks. For example, a goal might revolve around a new internal tool – “We need to build an internal tracking tool, document how to use it in our handbook, and make it visible to everyone in the company via an email blast.” In that scenario, all team members collaborate around a single product using their particular expertise to deliver value to our customers. Who are our customers, you ask? They are the rest of the Alley team!
One wonderful outcome of having a team with varying focus areas is that such collaboration quickly leads to cross-functionality, a key quality of a highly functioning Scrum Team. Grouping people from different disciplines may seem counterintuitive, but it results in a much larger pool of knowledge. That, in turn, leads to higher efficiency and more stable teams.
We’re all developers
When you first implement Scrum on a team, taking in the roles, responsibilities, and events that make Scrum what it is can be a bit overwhelming. In learning all of the details, don’t miss the forest for the trees. As The Scrum Guide notes, “Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.” By its nature, this framework is flexible and adaptable to many situations, whether you’re making software, operations decisions, or dinner for your family.
The great thing about the rituals that make Scrum work (including Sprints, Daily Scrum, Backlog Refinement, Demos, and Retrospectives) is that they’re not designed solely to make a product but also to give structure to your team and the work you’re doing. Therefore, this framework is easy to apply to any kind of work. The events and practices of Scrum provide opportunities for collaboration, reliable ways to raise issues, and dedicated time to focus on improvements — needs that all teams have and should be addressing.
Don’t fall into the trap of thinking that you can’t do Scrum without a development team or software to deliver. The roles that make up a Scrum Team are not development-specific. A Product Owner still has the same job to do, whether the Product Backlog consists of bug fixes or household chores. The Scrum Master’s job will always be to support the team and remove impediments to completing work, regardless of what kind of work the team is doing. The Development Team need not be made up of software developers because we already know that value can be delivered in many different ways, as detailed above.
Scrum is a fantastic framework for all types of people doing all types of work, so feel confident in your decision to implement it! “Developers” can be marketers, contractors, accountants, or a great many other things. All you need to do is ask what kind of “developers” are on your team.
Want to learn more about implementing Scrum on your team? Check out these Four Tips for Setting Team Norms