Multiple projects, competing priorities, scarce resources, client feedback, and changes in requirements — if you’ve ever run a web development team or project, it’s likely that you’ve faced one (or all!) of these challenges. So how do you manage them?
At Howard Development & Consulting, we’ve taken the basic principles of Scrum and adapted them to how we work best. We’re a pretty small team, so the last thing we want to do is weigh ourselves down with process; but by using several of the techniques, we’ve found we can benefit from some structure while staying lean and nimble.
But what exactly is Scrum, why do development teams love to use it, and does it need to be adopted wholesale or can it be adapted to individual needs? In this article, we’ll discuss these questions using our experience as an example — and show you why we love Scrum.
What is Scrum?
In short, Scrum is a framework that is used to implement the Agile methodology of project management, which prioritizes interaction, delivering a working product, collaboration, and responding to change.
Or, in plain English, Andrew Littlefield explained the relationship between Agile and Scrum using this example on Trello’s blog:
“A good analogy would be the difference between a recipe and a diet. A vegetarian diet is a set of methods and practices based on principles and values. A recipe for chickpea tacos would be a framework you can use to implement your vegetarian diet.
This is similar to the relationship between Agile (the diet) and Scrum (the recipe you follow).”
And to extend Littlefield’s analogy further, the Scrum recipe is more like cooking than baking — that is, you can adjust and adapt it based on your personal preferences instead of having to follow it to the letter.
What Are the Components of Scrum?
The components of Scrum can be broken out into three groups — the people, parts, and events.
A Scrum team brings together all of the people working on a project together, with a few defined roles and responsibilities:
- The Product Owner, who is responsible for the delivery of the product and advocates on its behalf (as opposed to the client or the development team)
- The Scrum Master, who is responsible for making sure that the project and the process remain on track and that anything blocking another team member’s progress is managed
- The Team Members, which includes everyone else on the team and is generally comprised of the developers doing the day-to-day work
Next, there are a few parts (called artifacts) that every Scrum team uses to organize and plan their work:
- The Product Backlog is the list of all of the work that needs to be done on the project
- The Sprint Backlog is the list of all of the work that will be completed in the next sprint (see below)
- Both backlogs are comprised of individual Tasks, which can include new features, enhancements, bug fixes, tasks, or other work requirements and are listed in their order of priority from the top to the bottom
And because Scrum is a framework, there are a series of events (called ceremonies) that occur on a regular basis:
- The Sprint, which represents one time-boxed cycle of work and always runs for the same length of time (anywhere from one week to one month)
- The Sprint Planning meeting, where the entire team discusses the upcoming sprint and decides which work will be completed in it
- The Backlog Grooming, which is when the items in the project backlog are discussed, confirmed, and their priority negotiated
- The Demo, where the development team demos the work they’ve completed in the previous sprint
- The Retrospective, where the entire team discusses the previous sprint — what went well and what could be improved
- The Daily Stand-up, which is a very quick (usually 10-15 minutes, at most) meeting where each team member shares what they did the day before, what they’re doing that day, and if anything is blocking their progress (which the Scrum Master would help resolve)
Together, these form the basis of Scrum and can be expanded on or consolidated depending on your individual team, the scope of your project, or your preferred workflows. For example, we often combine the demo and retrospective into a single meeting rather than scheduling two separate meetings to cover them.
Ok, So Why Scrum?
Simply put, Scrum does two things very well:
- It empowers teams to be self-organizing, which lets them organize their tasks in the way that works best for them and relies on their expertise to do so (since our team is mostly made up of developers, we really like this part)
- It responds and adapts to change, which gives everyone regular input into the work being done (rather than everything being rigidly defined at the start of the project) and generally allows the development team to complete the work more quickly
And as a small (but growing!) development team, this allows us to work more closely with our clients and deliver projects more quickly and efficiently. Requirements are gathered, tasks are organized, work is completed and demonstrated, feedback is received, and the project (or product) is iterated on — all in each sprint!
How to Make Scrum Work For You
One of the great things about Scrum is that you can adopt its principles without necessarily following the entire framework to the letter. For example, we tend to scale how closely we follow the framework depending on the scope of the project we’re applying it to. In most cases, we combine the demo and retrospective into a single meeting and we usually have one team member play the roles of both the Product Owner and the Scrum Master. Finally, our daily stand-up meetings are done informally over Slack rather than in real-time.
For more information about how to adopt Scrum at your business, especially scaling it as you grow, check out Atlassian’s guide here. It’s a little comprehensive if you’re just getting started, but a valuable resource nonetheless.
To find out how Scrum works best for your team, you can apply one of its most essential principles — regular and frequent iteration. Try it out, gather feedback from the team, and adapt as you go by keeping what works and changing what doesn’t. Lather, rinse, repeat.
Getting started takes just a few simple steps:
- Bring your team together and assign the roles
- Build your product backlog with all of the known tasks that need to be completed
- Agree on the length of each sprint (we recommend starting with one-week sprints), then schedule the meetings
- Get to work!
