by Kelsey Locotos
So you’ve made the decision to start working with agile. Great choice! You’ve decided to use Scrum to get yourself and your team into peak performance mode, and now you are really rolling. 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.
Truthfully, though Scrum was originally created for developing software, its basic principles and practices can be applied to nearly any type of work across a vast 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.
As the People and Operations Coordinator at Alley and a newly certified Scrum Master, I have firsthand experience with the less publicized uses of Scrum. When Alley transitioned to using dedicated Scrum teams earlier this year, I and a few other non-developers in our company were left in a sort of 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, however, and decided we wanted in on Scrum. The Marketing and Operations team (MOps for short) was born.
Redefining a Product
In The Scrum Guide, a lot of emphasis is put on the idea of creating a “product”, including research, development, release planning, etc. One of the first mental hurdles we had to clear as a team was conceptualizing how Scrum would work for us when our team doesn’t have customers and doesn’t create a product. The answer ended up being that we had to redefine who our “customers” are and what a “product” is for our team.
Development teams can get to the end of a sprint and have a functioning website or application, but how do you define a “product” when your team is focusing on marketing initiatives or day-to-day operations of a company? The answer can be a lot of different 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. Or 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 not to get bogged down by language. Recognize the value in the work you are completing, 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 how to operate a Scrum team when its members were brought together from different areas of the company. My team combines operations, human resources, marketing, and tools — a diverse group of people, to say the least. Sprint goals are an important tool that help 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 such as 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 for your sprint that can be applied to multiple types of tasks. For example, a sprint goal might be “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 members of the team collaborate to get a single product out the door to our customer (our coworkers), as opposed to working on individual products.
One wonderful outcome of having a team with varying areas of focus 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 to share among teammates. That in turn leads to higher efficiency and more stable teams.
We’re All Developers
When you’re first implementing 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 stand-ups, 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. This framework is therefore 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 and 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 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 tool 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 one question: What kind of “developers” are on your team?
Originally published at alley.co on November 29, 2018.
