Adapting Scrum to Agency Work

“Don’t let perfect stand in the way of good.”

A coworker reminded me of this idea the other day, and it got me thinking about how my views on strict adherence to the Scrum framework have changed over the past few years I’ve been at Phase2.

Before I continue, let me take a moment to point out that although we sometimes use “Agile” and “Scrum” interchangeably, they’re not quite the same. Scrum authors Ken Schwaber and Jeff Sutherland describe their creation as “a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.”

The key word there is framework. While the heart of Agile methodology is a commitment to continuous improvement and adaptation, Scrum adds a framework around those core values to help get work done. (Fun fact: Agile doesn’t actually suggest a set of ceremonies or artifacts.)

At times, Scrum may seem like it mandates a set of rigid rules. Even the terms “ceremony” and “artifact” seem a little scary!

However, we need to have the right perspective on Scrum—the process is there to serve us, not the other way around.

Before I came to Phase2, the company I worked for offered a cloud-based lending platform. Financial institutions could log in and see the progress of loan applications and repayments, while internal underwriters could crunch the numbers to see if applicants qualified. As you can imagine, we were constantly improving the platform—that process never ended. In that environment, devout adherence to Scrum worked well as we constantly iterated and improved upon the platform.

However, in an agency setting, we often need to be more flexible. Our projects vary in scope and duration. Sometimes our project teams are very large, with several developers, while other times, there might be one or two. And despite our best efforts, we’ve had clients who are very new to an Agile approach, not to mention the Scrum framework.

The great news is that Scrum is built around adaptation and continuous improvement, as you’ll recall. Here are some ways that I’ve seen Phase2 adapt the Scrum framework.

Team

Generally the Scrum role of product owner is analogous to Phase2’s product manager position. But often, product managers may also fill the Scrum Master role—fulfilling the duties of promoting and supporting Scrum principles. This may be more common on smaller project teams. But as long as there’s someone who functions as a Scrum advocate, we can blur the lines a bit.

Events

The Scrum Guide’s first listed event is the Daily Scrum, which should be held—you guessed it—on a daily basis. But depending on factors like team size and geographic location, this isn’t always optimal. If it works to have the Daily Scrum (which we sometimes call “stand up”) three times a week, or have a couple of virtual check-ins, that’s perfectly acceptable.

During the Sprint Review (or “demo,” as we often refer to it), the Scrum Guide suggests that the development team demonstrates the work completed during the sprint. However, at Phase2, it’s often the product manager who shows off the new features to the Scrum team and invited stakeholders. As long as the developers can answer any technical questions, this is one rule that can easily be broken.

Believe it or not, Backlog Refinement (formerly known as “grooming”) isn’t overly defined in Scrum, so there’s a lot of wiggle room here. As long as it happens, don’t worry too much about how it happens. Sometimes, it can be done during sprint planning, making sure that tickets are fully understood and assigned a level of effort before they’re moved into an upcoming sprint. You can also have a dedicated refinement meeting—I’ve even seen separate meetings for frontend and backend tickets. The frequency is also dependent on the needs of your specific project and team.

Artifacts

As laid out in the Scrum Guide, “the Sprint Backlog is a plan by and for the developers.” But often, the product manager will lead creating the sprint backlog so that the developers can maximize the time spent actually building. I often have a set of proposed tickets to move into an upcoming sprint, and look to the developers to validate my choices.

If the amount of work in a sprint needs to be adjusted, the development team and product owner consult about potential changes, according to the Scrum Guide. But the one who actually initiates the discussion doesn’t really matter.

As long as we adhere to the Scrum values—commitment, focus, openness, respect, and courage—we can tweak the framework to better work for our projects.

We hope you enjoyed reading the Phase2 blog! Please subscribe below for regular updates and industry insights.