Your introduction to agile and Scrum

From the decade that brought us the Selfie, Throwback Thursday, and Manic Pixie Dream Girls, here is another prolific concept born in the early 2000s: Agile. Agile methodology today is one of the most popular and talked-about project management styles amongst software development teams. And a variety of other functions are increasingly adopting it.

What the heck is it, who uses it, and is it right for your team? Like a well-outlined Bro Code, adopting this 2000s approach can save your team time, money, and maybe even a little heartbreak. We’ll explore exactly how here.

First things first: What is Agile?

It all started with a group of 17 techies wanting to figure out the best way to approach software development. They met up in Snowbird, Utah, and together they produced a joint collection of values and principles today referred to as the Agile Manifesto. (Fancy, right?)

As far as manifestos are concerned, it’s actually pretty short and to the point:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

**It is important to note that you can apply Agile to many types of teams and projects. You should not think it’s only for engineers or software development projects.**

They also came up with twelve principles (which, again, at first, seem specific to software development but can be adapted quite easily).

So which part is Scrum?

People often use “Scrum” and “Agile” interchangeably, especially if they haven’t started using the methodology for themselves yet. However, there is an important distinction. Agile acts as a defined set of values and principles, while Scrum is a specific framework of action in line with Agile principles.

One of the easiest analogies we can use to explain this relationship would be the relationship between a diet and a recipe. A diet, such as a vegetarian diet, dictates what is okay to eat or not okay to eat (carrots: yay! horse: nay). A recipe, like for Spinach-Artichoke Deep-Dish Pizza, is an example of a framework you use to apply said principles of the diet. Agile, in this case, is the diet, and Scrum is just one of the most popular recipes.

Where did Agile and Scrum come from?

While the values and principles in the Agile Manifesto hadn’t been part of a formal creed before the 2000s, the ideas weren’t new, even for the time. In fact, they originated out of techniques popularized by Japanese companies. Companies like Toyota, Fuji, and Honda in the ’70s and ’80s.

In the mid-’90s, these exceptional Japanese companies particularly inspired two men, Jeff Sutherland and Ken Schwaber. At the time, standard workflow styles, like the Waterfall Model and other predictive methodologies, weren’t cutting it for software developers. Teams were delivering software slowly and weren’t able to adapt quickly to new changes or requests. Consequently, projects often went way over budget. Sutherland and Schwaber admired the more adaptive and efficient models these Japanese companies followed and decided they would create a similar framework. “Scrum” was born.

Sutherland and Schwaber went on to be two of the 17 software development leaders who eventually created the Agile Manifesto. And Schwaber founded both the Agile Alliance and the Scrum Alliance, two nonprofit organizations committed to advancing Agile and Scrum principles and practices.

Scrum has spread like wildfire ever since, claiming software development teams around the world in its path.

Who can use Scrum?

Scrum is infamous amongst engineering teams, but various teams across industries also love the Scrum way.

From manufacturing and marketing to operations and education, businesses of all kinds have used Scrum practices successfully. As long as your projects involve a concrete product, Scrum can work for you.

Understanding the framework

Whether you’re using a whiteboard and sticky notes or a cloud-based collaboration tool like Nulab’s Backlog, the basic workings of Scrum are simple to learn and require little to get going. But they can be difficult to perfect.

Everything naturally centers around the product. Using an ordered list of features and tasks, referred to as a “backlog,” this list is continuously prioritized and re-prioritized to keep the most important to-do’s listed in descending order.

The list is prioritized based on the usefulness each item has to the end user. If you were going to build a house, building a foundation would be at the top of the list, while painting the front door red would probably go toward the bottom. You can use a house without a painted door. You don’t even have a house without a foundation.

Business goals, market conditions, customer needs, and available technology evolve over time. As this happens, they’ll insert new items into the backlog and organize them according to their relative importance to the end user.

The backlog can be a tricky monster to tame, which is why you need a designated Product Owner in charge of prioritization as well as feature approval. It’s the Product Owners job to manage the backlog in a way that best serves the end-users.

The dynamic nature and adaptability of this backlog are what allow teams to remain flexible while consistently producing meaningful features faster than other project management models.

Scrum Teams consist of two more roles in addition to the Product Owner: the (Development) Team and the Scrum Master.

Every two weeks, Scrum Teams tackle a new chunk off the top of the backlog. We refer to these two-week periods of focused work as “Sprints.”

Every morning during a Sprint, the Scrum Team meets for 15 min to discuss any updates and self-organize for the day (there’s no delegating in Scrum; all team members self-organize their work). This brief, daily meeting is often called a Daily Scrum or Daily Stand-Up because they are often held standing. (Standing meetings tend to keep employees more alert and engaged while reinforcing the short nature of these daily updates.)

The Scrum Master is responsible for guiding, coaching, teaching, and assisting the Scrum Team along the way towards proper understanding and use of Scrum.

At the end of each Sprint, the group holds a review, called a Retrospective, to discuss ways to improve the next one. Frequent Retrospectives allow the team to identify problems and iterate processes quickly.

How to start

One of the best features of Scrum is that you don’t need any special equipment or training to try it. The hardest part is learning the jargon and holding yourself and your team stringently to the rules and guidelines that make Scrum work.

All you need to run your first Scrum Sprint is the following:

Download the Definitive Guide to Scrum straight from the creators themselves. Pass it out to your team, and make sure everyone understands it.

Decide who your Scrum Master and Product Owner are. The Scrum Master should do a little extra research to prepare.

The Product Owner should create the backlog and organize your tasks. While your backlog is technically never “complete,” you can create the version that makes the most sense today.

Begin your Sprint Planning. First, decide your Sprint length (you don’t have to do two weeks, but keep it under a month.) The team then determines what tasks to include in the Sprint and who will be responsible for them. (Remember, Scrum members organize everything for themselves).

Schedule your Daily Stand-Up. Add a 15-minute block to everyone’s calendar at the same time each morning to discuss three questions:

1. What did you work on yesterday?
2. What will you work on today?
3. Is there anything blocking you from doing your work today that you need help with?

Get to work! Everyone on the team should focus on the tasks they accepted and prepare to discuss their progress at the next Daily Stand-Up.

Review the work. At the end of the Sprint, your team should review the work accomplished and present completed tasks to the group.

Hold a Retrospective to review the process. The Retrospective meeting is where your team examines how the actual workflow went and suggests ways to make it more efficient next time.

Deliver to your end-user. One of the most unique and advantageous aspects of Scrum is the fact that you’re delivering work and receiving feedback often. If your user never sees the product until the very end, you delay opportunities for quick improvements and key insights into your customer. When you do deliver, you will have a much muddier picture of which features are a success and which ones aren’t, not to mention you’ll waste a lot of time on things that it turns out your customers don’t like that could have easily been avoided had you been using Scrum properly.

Repeat. Update your backlog, pick more tasks from the top, and repeat the process again and again. Over time, you will see your backlog grow and refine and your processes streamlined. Before you know it, you’ll be a true Scrum machine!

Scrum in remote work

With the rising popularity of working remotely, holding a daily or weekly Scrum meeting has become more important than ever. Scrum masters must keep on their feet to stay on top of everything in a remote setting. But fortunately, what was started in the 2000s has been nearly perfected to get work done in the ’20s.

Holding this meeting will allow all team members to stay on the same page, even when it’s tempting to get buried in your own tasks at hand, overlooking many aspects of the Scrum Manifesto. During these stand-ups, team members can see what their colleagues are finishing and see how that fits into their own work.

The ability to still perform Scrum remotely opens up the industry as to who can work where and when. And the right Agile project management tools help, too.

This post was originally published on September 26, 2016, and updated most recently on January 29, 2021.