Scrum Methodology
The Scrum methodology was the first into the fray when software developers started looking for new ways to work. Scrum is the most popular Agile framework, which tends to make it the first stop on an Agile journey. Get started in Scrum with our guide to Scrum processes, roles, and ceremonies.
What is Scrum?
Scrum is an iterative approach to project management, which means it’s designed to deliver small things rapidly that can build up into something larger over time. Each iteration, known as a Sprint, lasts just a couple of weeks. The team who is responsible for actually doing the work gets to decide how much they’ll commit to getting done during the Sprint, and no one should change or reprioritize their workload once they’ve made that commitment.
At the end of every Sprint the team should have produced something that could be released to their audience, although it doesn’t have to be.
Scrum emphasizes rapid releases in order to learn what works. Using iterations through Scrum lets us do that faster, and with less risk, than traditional project management methodologies that require an enormous amount of up front planning.
One of Scrum’s originators, Jeff Sutherland, describes the approach this way:
“At its root, Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want?”
The concept at the core of Scrum, like most Agile project management, is simple, but over many years and innumerable implementations it’s become more complex. There may be a lot of moving parts, but don’t let Scrum’s complexity mask its power. You can get more done in less time with this system, provided you get it (mostly) right.
Whitepaper: How to Become an Agile Agency
Whitepaper: Agile Marketing for Creative Teams
Scrum roles
A primary feature of the Scrum methodology are clearly defined roles that help set clear expectations and allow the Scrum team to operate more efficiently. These Scrum roles include the Scrum Master, the Product Owner, and the Developer.
Scrum Master
Generally, Scrum Masters are the people who are responsible for helping a Scrum team stay true to the principles and practices of the Scrum methodology. Scrum Masters facilitate meetings, remove any impediments that are keeping people from being productive, and guide team members into a deeper understanding of Scrum. They’re expected to have a thorough understanding of all things Scrum, as well as maintain strong interpersonal connections to the team.
Product Owner
The Product Owner role got its name from development, because those teams build actual software products. If the Scrum Master is in charge of the Scrum process, the Product Owner is responsible for making sure that process is applied to the right work at the right time.
A good Product Owner understands the “who” and “why” behind the work the team is doing. They communicate constantly with stakeholders and customers, ensuring that the team is delivering work that matters to users and produces value for the business.
Product Owners are a little like managers, but in Scrum there’s a much stronger emphasis placed on their connection to users than any seniority they might have in the organization.
Developer
The Scrum Master and Product Owner are, traditionally, the only differentiated roles on a Scrum team. Every other team member shares the same title: Developer.
Ideally each team member should be cross-functional, which means they have a broad skill set that enables them to contribute to all phases of a project. This value arose from a common development problem, which was having a surplus of employees writing code, and far fewer who were able to test it.
In addition to being cross-functional, Scrum teams are typically flat—managers and directors are rare. They’re also designed to be self-organizing, which means they choose the work they do and identify the best way to get it done. The business, in conjunction with the Product Owner, decides what work needs to be done, but the team decides how to make it happen.
Scrum ceremonies
Each Scrum ceremony has a special role in helping guide Scrum work, and each team member has a responsibility in the four Scrum ceremonies.
Sprint planning
During the start of each Sprint, the entire team gets together to decide how much they can achieve. They take a look at the backlog, a constantly prioritized list of work that the Product Owner and external stakeholders have agreed the team should tackle, and pull items from the top of the list.
Once the team has chosen its workload for the next couple of weeks, projects are broken down into tasks, and each task is assigned to a team member. As you might imagine, Sprint planning can take a while. Plan to devote at least an hour for each week of your Sprint, meaning a two-week Sprint requires a two-hour Planning meeting.
Once this meeting is over, your entire team should know exactly what’s expected of them for the duration of the Sprint. Ideally this will be articulated in a clearly defined Sprint Goal for the team, but at the very least project goals and deadlines should have been identified.
Daily stand-up
During the Sprint, team members need to regularly check in with one another so progress, or lack thereof, becomes clear as early as possible. After all, if you’re trying to complete multiple projects in just a week or two, you can’t wait three days to find out someone has gone completely off track or been delayed by external factors.
We keep the lines of communication open with a meeting called the daily stand-up meeting. The team stands to facilitate speed, and each team member shares only three things:
- What they did yesterday.
- What they plan to do today.
- Any blocks that are in their way.
Stand-up is a very brief ceremony—you should be in and out in 15 minutes or less. Scrum Masters may need to keep chatty team members on track. This is one of the main reasons that Scrum is challenging on large teams: it takes way longer than 15 minutes for a team of 20 to give their updates.
Sprint review
Once the Sprint is over, it’s time for some showing off. Known as the Sprint Review, this is the time when you show stakeholders, and any other interested parties, what you accomplished during the Sprint.
Developers demonstrate the working software or features they’ve completed, and marketers may demo content, social media, email campaigns, or anything else they’ve released. If something goes out early in the Sprint, you may even have preliminary success data to share.
Be prepared for constructive feedback in this meeting, which you may need to incorporate into the backlog on the spot, but it’s not a time for Q&A or approval.
Finished work should have been reviewed, approved, and released before Sprint Review. This meeting is an opportunity for more people to get insight into what marketing actually does, which will (hopefully) expand the impact of your work across the organization.
Retrospective
While anyone who’s interested can attend a Sprint Review, the Sprint Retrospective is for the Scrum team only. The Scrum Master typically attends, but the Product Owner comes only if they are involved in the day-to-day work of the team.
Retrospectives are moments of introspection for the team. Here they reflect on what went well and what went wrong during the Sprint, with an eye to improving their team and Agile workflow for the next Sprint.
Young Scrum teams sometimes turn Retrospectives into hour-long blame games, so you may want to post the Retrospective Prime Directive in the room to remind them of the meeting’s purpose:
Retrospective Prime Directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Be sure to document what comes up at your Retrospective and ask for volunteers to put action items into practice. There’s nothing more frustrating than talking about the same problems at every Retrospective because continuous process improvement has fallen by the wayside.
Ebook: 3 Winning Strategies for IT Project Success
On-Demand: Four Steps to Streamline Marketing Workflow
3 ways to implement Scrum
If you’re feeling totally overwhelmed by all of this information, you’re not alone. Tackling a Scrum implementation can be daunting, which is why so many people bring in Scrum coaches and consultants to help.
But a full-scale transformation is just one way to put Scrum to work on your team. You can also try pilot programs to get your feet wet and prove that the Scrum approach works before committing to a massive, department-wide roll out.
Scrum pilot projects
One option is to use Scrum on a single project within your department. Campaigns that are naturally iterative, meaning you already release them in small pieces over time, will be your best candidates.
Existing, recurring projects that have their own backlog can yield major gains in a short period of time after a Scrum implementation, and don’t usually require the whole team.
Scrum pilot teams
Pilot projects may naturally come with pilot teams, but that’s not always the case. If you have a few excited departments or teams who want to take responsibility for an Agile rollout, let them!
Form an Agile team within your existing department, and make sure they have a nice robust backlog to work from. Allow them to report back to the rest of the team regularly and share their lessons.
Pilot teams can be a powerful yet lightweight way to test how Scrum will (or won’t) work in your particular organization.
Full scrum transformation
Of course, the final option is to jump into the deep end and adopt Scrum for an entire department at once. If you choose this option, I strongly recommend having an expert of one form or another to help you.
You can send one or two team members to formal Scrum training, and they can act as Scrum Masters and subject matter experts for the team. Or you can retain a professional Agile coach or trainer to guide you.
Having these dedicated resources will smooth your path to adoption, and, particularly if you go with a trainer, will help you avoid common missteps.
Learn more: Implementing Agile at scale
Don’t fear the Scrum police
People who have practiced Scrum for years still find ways to improve and adjust, so don’t stress about knowing everything before you get started.
Don’t worry that the Scrum police are going to write you up if you miss a step or forget a ceremony. Take the first step, and do your best to make the second iteration a little bit better. Some teams have also found success combining the best of Scrum with Kanban with the hybrid methodology, Scrumban. What matters most is about your methodology is that it works for your team.