More and more teams are thinking about flexible methodologies and techniques, because the waterfall model, with certain changes, introduces too many restrictions. The environment changes frequently, and you need to be able to adapt to these changes. True, there is a problem with Agile - it is very difficult to switch to it, this is a whole philosophy that implies a global change in the team's thinking. But if you really want to try flexible management, you can implement Scrum. It is based on the principles of Agile, but it is easier and faster to switch to it.
Scrum's Origin
In a 1986 article for the Harvard Business Review, Japanese academics Ikujiro Nonaka and Hirotaka Takeuchi reported that projects with small multidisciplinary teams systematically produced better results. They called it the "rugby approach". In 1991, in the book Unholy Problems, Righteous Solutions, the approach was first referred to by the rugby term "scrum".
But Scrum, in more or less the form that we know now, appeared later - in 1995, Ken Schwaber and Jeff Sutherland first presented the methodology at the OOPSLA conference. Over the next years, they continued to work on Scrum. Now this is a detailed methodology, according to which there is its own manual (The Scrum Guide), and a bunch of books, and even a couple of accrediting companies: Scrum Alliance and Scrum.org.
What is the idea of Scrum
Scrum is a methodology (framework) for managing development. Well, or rather, most often it is used in development, but it can be used in any team work. As a methodology, Scrum is a set of recommendations for organizing workflows, without any step-by-step instructions. The set of recommendations is very strict - if something is accidentally or intentionally missed, it will no longer be Scrum.
According to Scrum, a small team of 3 to 9 people should work on the project (if you have a larger team, you will have to break it into several small ones). The team works without breaks, in short iterations (sprints) lasting 1–4 weeks. At the end of each sprint, the team must create something of value for the customer. That is, the work is not just divided into iterations. Each iteration should make sense and be useful.
How Scrum Works
If you look deeper (not as deep as possible - one article is not enough for this, there are too many subtleties), in addition to the iterative approach, Scrum also has specific entities: events, roles, and artifacts. In general, there are a lot of them, but I will focus on the most important ones.
Roles
So, the so-called scrum team is working on the project. It consists of developers (as well as marketers, designers, and any other specialists that are needed in the project) and people who take on special roles: the product owner (Product Owner) and scrum master.
The product owner is responsible for the overall list of tasks (product backlog) and the consistency of the team, interacts with the customer and defines the requirements. And while the team may have a voice on certain issues, it is the product owner who makes all the decisions, prioritizes tasks, gives advice, etc. The product owner is always alone so that chaos does not arise due to conflicting instructions.
The Scrum Master is a kind of Scrum guru. He knows the methodology best of all, teaches the intricacies of the processes to the rest of the team members and responsible for the team's compliance with scrum rules. Like the Product Owner, the Scrum Master strives to maximize team productivity.
The team is responsible for implementing the tasks from the sprint backlog. A great scrum team determines by itself which tasks need to be done exactly within the sprint so that its value is higher. As usual in Agile, team members share their knowledge with each other so that you can reduce the likelihood of someone else's mistakes. Together with the product owner, the team creates a work plan for each sprint.
Artifacts
Scrum also has three entities called artifacts:
- product backlog - a list of tasks that a team must do to improve a product or create a new one. Backlog content and task priorities, as I said, are the responsibility of the product owner;
- sprint backlog - a list of tasks that the team should complete within the sprint;
- the goal of the sprint is, in fact, what the scrum team is striving for, for which it will work on tasks from the sprint backlog. It is also called an increment.
Actions
Scrum is based on sprints, but there are several other important events associated with them, without which Scrum is not Scrum.
It all starts with creating a backlog. The product owner communicates with the customer and the team, collects a list of requirements for the product, and then, based on it, draws up a list of tasks. This list of tasks needs to be stored somewhere, and a project management system with the ability to create kanban boards is usually a great way to do this. For example, WEEEK.
Then, when the overall pool of tasks is clear, the team meets with the scrum master and plans the sprint - sets goals and decides which tasks from the backlog will help achieve them.
During the sprint, every day team members hold small meetings (stand-ups) where they talk about what they did yesterday, what they are going to do today, and what might get in the way. This transparency helps to detect any problem in a timely manner.
When the sprint ends, the entire team, including the scrum master and product owner, reviews the sprint, reviews the results, and finalizes the backlog.
After the sprint review, the team does a retrospective - sorts out what worked and what went wrong, and thinks about what can be improved in the next sprint. Without negativity, with a real desire to change something.
Pros of Scrum
Scrum project management with all these daily stand-ups looks like total control from the outside, but the methodology has its advantages:
- the technique is suitable for small companies;
- a minimum of unnecessary bureaucracy and unnecessary documentation;
- employees are listened to, so they are satisfied and motivated;
- the customer will receive a product that the audience will like, because it is designed with feedback in mind.
Cons of Scrum
There are a lot of downsides too. In addition to the problems with carefully following all the rituals (creating a backlog, rallies, etc.), there are also:
- a scrum team needs professionals, and it can be difficult to assemble a cohesive team (even a small one) from them;
- not everyone has Scrum experience - it takes time and money to train them;
- for all the meticulousness with which the scrum team seems to approach planning, it is very difficult to avoid mistakes in it.
Who is Scrum for?
Now Scrum has spread beyond software development - it is used in marketing, business, education, and much more. The easiest way to delineate the scope of Scrum is at the goal level. Scrum can be used to develop products and regularly update them, as well as search for new solutions and technologies. And not only in work, but also in personal affairs. Even the preparation of borscht can be organized according to Scrum.
Join Telegram chat