From the decade that brought us the Selfie, Throwback Thursday, and Manic Pixie Dream Girls, here is another prolific concept born of the early 2000’s: Agile. Agile methodology today is one of the most popular and talked-about project management styles amongst software development teams. And it’s increasingly being adopted by a variety of other functions.
What the heck is it, who uses it, and is it right for your team? Like a well-outlined Bro Code, adopting this 2000’s 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 Agile can be applied to many types of teams and projects, and should not be thought of as limited to engineers or software development projects only.**
They also came up with twelve principals (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 principals.
One of the easiest analogies we can use to explain this relationship would be the relation between a diet and a recipe. A diet, such as a vegetarian diet, dictates what is okay to eat or not okay 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 is 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 laid out in the Agile Manifesto hadn’t been part of a formal creed before the 2000’s, the ideas contained weren’t new, even for the time. In fact, they originated out of techniques popularized by Japanese companies like Toyota, Fuji, and Honda in the 70’s and 80’s.
In the mid-90’s, these exceptional Japanese companies particularly inspired two men, Jeff Sutherland and Ken Schwaber. Standard workflow styles at the time like the Waterfall Model and other predictive methodologies weren’t cutting it for software developers. Software was delivered slowly, teams weren’t able to adapt quickly to new changes or requests, and 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 for themselves. “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 well-recognized amongst engineering teams, but a variety of teams across industries have come to 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 towards the bottom. You can use a house without a painted door. You don’t even have a house without a foundation.
As business goals, market conditions, customer needs, and available technology evolve over time, new items are inserted into the backlog and organized according to the 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 allows teams to remain flexible while consistently producing meaningful features faster than other project management models.
Scrum Teams consist 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. These two-week periods of focused work are referred to 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.
One of the best features of Scrum is that there isn’t any special equipment or training needed 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 get started on creating the backlog and organizing your tasks. While your backlog is technically never “complete,” you can create the version that makes 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 are entirely self-organized.)
Schedule your Daily Stand-Up. Add a 15-minute block to everyone’s calendar at the same time each morning to discuss three questions:
- What did you work on yesterday?
- What will you work on today?
- 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’s 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 streamline. Before you know it, you’ll be a well-oiled Scrum machine!