Scrum is the most common term in the agile culture, yet a lot of people aren't aware that it was coined before "agile development".
The Agile Manifesto, introduced in 2001, describes principles for software development that were actually derived from a broad range of frameworks, like Scrum and Kanban.
The term 'Scrum' was first introduced by Takeuchi and Nonaka in 1986. They published a study in the Harvard Business Review which explained that empirical evidence suggests that small cross-functional teams produce the best results. They borrowed the name 'Scrum' from the game of rugby to stress the importance of teamwork to deal with a complex problem.
How does Scrum work?
The Scrum framework offers a set of practices that teams can use to break down complex problems into smaller chunks. It is famously simple to understand and difficult to master.
1. The Scrum process
It all starts with the "backlog", a list of specifications from the client or end users. Using input from all the stakeholders (anyone who has an interest in the results of your project), all the requirements are entered into the backlog as user stories. User stories explore requirements from your clients, and are usually written in this format:
As a <user/who>, I'd like to <goal/what> so that I can <purpose/why></purpose>
Each story is then broken down into tasks that are required to achieve the goal. A task is the work required from the developer's side to achieve the goal. These tasks are then prioritized and their efforts estimated to know how much can be taken on in the next sprint - a time period of 2 to 4 weeks. Once you plan the work for your next sprint, you can start working on it.
At the end of the sprint, you should have a working component. Whether it's a feature, enhancement or a UI revamp, it should be an independent functioning component.
2. Scrum meetings and why they're necessary
The agile culture places a lot of emphasis on communication playing a crucial role in getting the best out of a team. Healthy transparent communication boosts the morale of a team and brings them together. The meetings in the Scrum framework aim to facilitate exactly that.
Sprint planning meeting
Before a sprint starts, the entire team gathers to decide what they'll work on. Based on their previous sprint and the high priority items in the backlog, they plan what to do in the next one. Everyone takes a turn voting on the amount of effort required for a task, and this is repeated until everyone comes to a unanimous decision.
As the name goes, this meeting takes place every day during a sprint. It's called a "stand-up" because it's a concise meeting, usually done standing up. Each team member talks about what they've done in the past 24 hours, what they have planned for the next 24 hours, and if they're facing any challenges in their work.
Fun tip: In an effort to keep their daily stand-ups short, some software companies do plank meetings—that is, the person talking holds a plank position!
At the end of the sprint, this meeting is held to review the end product. The team gets feedback from the stakeholders and decides if it needs to go for a second iteration.
This meeting is also held at the end of a sprint. It's held to discuss the agile practices of the team, the challenges they faced, and what could be improved in the next sprint.
Fun tip: One way to make sure your retrospectives don't get repetitive is to #tweet-your-sprint. Ask every member to capture the last sprint in 140 characters using @mention, hashtags, and retweets. It's a fun way to identify the underlying themes and figure out areas for improvement.
3. Who's who: Scrum roles
They are the coach and mentor for the team. The scrum master doesn't make decisions. Instead, they act as a catalyst to help the team understand agile practices and follow them. They enable the team to learn from their own experiences, almost like a spiritual guru in the agile sense.
They protect the team from management and ensure that they don't compromise on agility when the pressure is on. In a self-organizing team, conflicts are bound to arise and it's the responsibility of the scrum master to resolve all conflicts without taking sides. They also conduct agile meetings and ensure a good relationship between the product owner and the team, as well as with others outside it. A scrum master doesn't have to know how to code, but some amount of technical knowledge does help when you're managing a team of developers.
This person is a key stakeholder with a vision for the product. They make all the major decisions and prioritize the next set of features for the team to work on. They should ideally have a sound understanding of the market, the end user, the business, and what the product owner wants to build.
By taking on the responsibility, the product owner dons many hats—business strategist, market analyst, and of course, project manager. They are seen as a representative of the stakeholders, and they handle the Return on Investment (ROI) for the product, so they command a lot of authority in the team.
The scrum team:
The development team is responsible for building the final product. Passionate, intelligent people with the right guidance can create beautiful things. It's important that the scrum team is made up of people who are inquisitive, like challenges, and are always looking to learn something new. Aside from intelligence, it's also important that the members trust and respect each other. Peer feedback is an important part of Scrum, and you can't take your teammate's criticism in the right spirit if you don't trust them.
4. To sum up
Essentially, the scrum framework presents practices to break down complex problems using simple methods. It quickly rose to fame because of its simplistic brilliance and applicability to all kinds of work, not just software development.
Scrum aims to induce a heuristic attitude towards problem-solving. It advocates a trial-and-error approach to tackle unpredictability. It is founded on the concept that knowledge comes from experience and that decisions should be made based on what is known.
Autonomy, fluidity, and evolution are core tenets of Scrum. A fluid hierarchy equips teams to make autonomous decisions that they will own up to and do work that they are invested in, creating an environment that's constantly learning and evolving.
Benefits of Scrum
- Higher product quality
- Reduced time to market
- Higher team morale
- Higher customer satisfaction
- Increased collaboration and ownership
- More relevant metrics
- Increased project visibility
- Reduced risk
Successful implementations of Scrum
1. Spotify An elegant agile implementation
When Spotify launched their first music player in 2008, they were a scrum company.
They operate in cross-functional autonomous teams called squads. They created their own framework to scale Scrum when they expanded. With giants like Google, Amazon and Apple as competitors, they needed a conspicuous advantage to stay relevant in the market and their success can be directly attributed to their agile-driven culture.
2. SEMRush Agile marketing done right
"With markets that can change in a minute, a 1 year marketing strategy is not going to cut it," says Olga, Head of Global Markting at SEMRush as she talks about how agile marketing really turned the tables for her organization. Marketing is done in small autonomous teams who are encouraged to try small experiments instead of large gambles. Scrum allows marketing teams to experiment rapidly, testing and learning on the go. They have gotten as close to a purely flat structure as they can, exemplified by their leadership only defining their goals and their teams having complete control over their execution.
Marketers love the freedom to express their creativity. Obliterating hierarchy adds a sense of ownership to their work, making them more invested in what they do. With agile marketing, the year-over-year average revenue from new markets was greater than 90% and SEMRush gained 500,000 users in just 8 months.
3. Zoho - Zia Our AI assistant building platform
Outside of software development and marketing, Scrum is best suited for experimentation or researching new technology. The trial-and-error approach of Scrum fits perfectly with the high uncertainty that comes with research. When we began working on our AI assistant-building platform, Zia, we found that running sprints helped us decide the viability of a feature—what worked, and what didn't. Planning our sprints also gave each team member a vision of what they were working towards and what needed to be done before the launch, instead of just moving from one task to another.
With Scrum, we also found that over time our team grew to be in sync, with a sound understanding of how each person worked and an appreciation of what each of them brought to the table.
Why do you need a Scrum tool?
Scrum teams follow an inspect-and-adapt approach. That is, they try things, measure them, and learn from them to make better decisions in the future. This implies that measuring your work is a critical part of learning from it.
You often find that teams begin with sticky notes for their first scrum project. As they transition to more teams and take on more projects, they naturally lean towards a more streamlined tool to manage their work.
Scrum software merely facilitates the framework. An online backlog and Scrum board is more accessible and functional than one on the wall. Regular updates ensure that everyone stays in the loop. Reports indicate your progress and help you predict your performance in the next sprint. They also lend visibility of your work to your stakeholders. Timesheets help you measure the time you spend on each task.
An ideal scrum software offers all these features on one platform as a complete functional solution.
What makes Zoho Sprints the best Scrum tool?
A comprehensive solution doesn't have to come with bulky user manuals, training sessions or an unnecessarily long set up time. We invested a lot of time in making our user interface intuitive and our user experience seamless, while not compromising on functionality.
An indispensable part of the agile process is change. That includes the process itself. So customization is great, but you need to be able to adapt if you're going to keep tweaking your process after every retrospective. We understand that your tool needs to be flexible.
We kept all of that in mind as we developed Zoho Sprints, a lightweight, flexible tool that can be used equally well by teams large and small, by industries IT and non-IT, and seasoned sprinters along with beginners.