SCRUM flexible methodology — what is it and why you need it

Agile approach in working with IT projects has replaced the standard "waterfall" development, which involved following a strict approved plan. A flexible project management system that can quickly respond to changes and adapt to changing requirements has proven to be much more effective in the nascent field of technology entrepreneurship. Well, Scrum as a project management method with its work in short sprints and adjustment to changing requirements has become a logical continuation and development of the Agile principles.

Alright, so what does rugby have to do with it? And what does the word Scrum mean? Scrum is a rugby term: it is a scrum of players that is appointed by the referee to restart play after a rule violation. During this action, the players of both teams line up in a circle, tightly clasped with their hands.

So with this kind of battle Japanese scientists, Ikujiro Nonaki and Hirotaki Takeuchi compared the work of small IT teams that were intensively developing a project and received better results. Later on, this term was used by Jeff Sutherland and Ken Schwaber, the creators of the method. While developing a new methodology for working with IT projects, they watched the work of military special forces and rugby players. Scrum has become a great metaphor for cohesion and teamwork, the very element that IT departments lacked for success.

Today, Scrum is not only about agile software and application development; The Scrum method has spread much further, now it underlies the work of most startups, and it is successfully implemented in the work of business organizations, government agencies and even non-profit foundations. The very essence of the Scrum method is working in short sprints and quickly reacting to changes has become a great tool in the new ever-changing reality.

The main objective is the result for the client. The client has to receive the product according to their goals and requirements on time, whatever the circumstances.

Working in sprints. The team works in short iterations (1—3 weeks): the tasks are set specifically for each sprint, and at the end of it, the client is presented with a completed version (part) of the product.

Flexibility and adaptability. Scrum management is built in the way to quickly and effectively react to any changes: the product is tested after each sprint, the backlog is always updated and the team discusses the product on daily.

Consistent teamwork. One of the strongest aspects of the methodology is solid team communication: each day starts with a short meet-up on the product. At the beginning of the sprint, the whole team and the product owner discuss the plan for this iteration and at the end, wrap up the conclusions. Scrum is a cross-functional team that is one organism that works to reach the goal.

One sprint, one task. In addition, the team is working on only one product. After all, if new tasks start to appear with such an intensity of communication and the frequency of changes, everything will end in chaos. 

Team versatility. The team consists of specialists with different skills, covering all the issues necessary for the development of a new product. We can say that in Scrum, the team is an autonomous combat unit, entirely responsible for the product.

Agile is a specific approach to the development of IT products, which is realized in the Agile manifesto. We can say that this is some kind of ideology and Scrum is a working tool, based on this ideology.

Kanban is another project methodology, which has similar principles to Agile. The main ideas of Kanban are visualizing all processes and finding balance in the team’s work. Also, there are some differences with Scrum: there are no “three main roles” (the client, the scrum-master and the team), and no sprints, since the work on the project is divided into project work stages. Nevertheless, many Kanban tools are used in Scrum: for example, desks with sticky notes that are moved from one column to another when the task is completed. There is even a Scrumban, a hybrid methodology that includes the main principles of both Scrum and Kanban.

In your work on the product, you can use Agile, Scrum and Kanban principles: the main thing is that there is no duplication of functions and conflicting instructions, and the team always clearly understands what they’re doing. After all, all this was invented to make it simple, understandable and effective!

Scrum is built on three roles who manage the work on the product: only with their full cooperation and thoughtful work they will achieve the result.

Product owner. The product owner is a “bridge” between the product and the user. They understand market fit, where the product will be launched, and user demands. Thus, it is the product owner who directs the team: manages priorities, defines how important the tasks are, accepts and tests the new product version after another sprint.

The product owner is responsible for creating the product’s backlog, a journal containing all the important information about the product and all the working processes done on the product. During the sprint, the product owner works with the team: they participate in meet-ups, exchange information and give instructions to the team.

Usually, this role is played by the client’s representative, and if the team is developing an internal product for the company, then it is someone from the top management. In a startup with a small team, the functions of the client are performed by the CEO (but the roles of the client and the Scrum master must be separated).

Scrum-master. From this very specialist, it depends on how effective the work will be in accordance with the Scrum methodology. The Scrum Master coordinates the process of teamwork and the use of Scrum tools. Even before the start of the first sprint, the scrum-master trains the product owner and the entire development team to work according to the Scrum principles, and then launches and controls the entire process.

The Scrum Master moderates all meetups and product meetings, ensures that the team always has the necessary resources, captures ideas and suggestions, and acts as a mediator in case of disputes and discussions within the team. Team cohesion also depends on its actions. At the same time, it is important for the Scrum Master to know the limits in the moderation process in order not to turn into an “overseer” or an ordinary manager, giving the team maximum autonomy. As you can see, the job is not easy at all, so that's why experienced Scrum masters are worth a fortune!

Team. The team is a single organism that moves towards the goal of the sprint and is responsible for the development of the product. It is more convenient to have a small team. And you can't say it better than Jeff Bezos: the team must have so many people to share 2 pizzas among them. The second important criterion for a team is cross-functionality, it must include all the specialists needed to develop the product. Turning to external expertise should be minimized since it will greatly slow down the work process.

Not coincidentally, the Scrum game element, where all the players are “linked”, became the name of this methodology: during the sprint, everyone in the team is tightly linked to each other. They help each other, close problem areas, exchange tasks, as they take responsibility for the release of the product on time. Working in such an autonomous product team provides a lot of opportunities, but the requirements for employees participating in the sprint are high. They must be proactive, responsible, able to independently find solutions to problems; but at the same time, they have to be team players, have empathy and a kind of "feeling of the friendly elbow." The “swan, crayfish and pike” simply won't be able to work using the Scrum methodology!

Using scrum-artifacts. The three essential artefacts (documents), which build up the scrum approach to managing product:

• Backlog (journal) of the product.

• Backlog (journal) of the sprint.

• Sprint schedule.

These artefacts are live working documents, where people constantly fix any changes and new input data.

Working with the sprint backlog. The sprint backlog is developed jointly by the entire triad of the product (product owner, scrum-master, team) at the kickoff meeting at the start of the sprint. From the product backlog (a document prepared by the product owner), the team selects the product features which they will have to work on in the sprint. The sprint backlog includes a list of tasks and milestones. The sprint schedule is also masterminded here, based on the developed backlog.

Regular meetups. This approach presupposes short daily meetups about the product. Don’t be afraid of the word “daily”: these aren’t those senseless and merciless meetings, that everybody hates. Meetups last not more than 15—20 minutes and they’re always held at the beginning of the day. Scrum-master is responsible for the meetup being constructive: if there are any discussions or “flooding”, they return the conversation to the topic. There are no discussions, brainstorms or arguments during the meetups and there shouldn’t be any. The goal of the meetup is to exchange information about current affairs. For this, each team member answers three questions:

• What is done since the last meetup?

• What will be done today?

• What are the obstacles to achieving the goals?

If there appear any obstacles in work, the Scrum-master’s task is to eliminate them (possibly, with the help of the product owner). The product owner tracks whether the product development is going in the right direction: by participating in the meetups, the product owner is able to guide the team in the right direction.

Supervising the task completion. The task of the scrum-master is to visualize the process of working on tasks so that the whole team can see it at any time. Basically, a kanban board is used for this (sometimes it’s called a Scrum board), on which tasks are marked with colourful stickers. Tasks are moved to one of three columns: "To Do", "In Progress", "Done".

Task adjustment. What if a team member realizes they are not meeting their deadlines? He promptly informs the Scrum-master about this so that he can reallocate the tasks. It also happens the other way around: if the team has completed the tasks for the day earlier, the Scrum-master can provide additional tasks from the sprint backlog. There is also an "emergency stop" of the sprint, but it is used extremely rarely: in the event of unforeseen external circumstances, significant changes on the part of the client, and etc. In such a situation, the team can stop the sprint and wait for further instructions.

Results’ analysis. The result of the sprint must always be a product that can be demonstrated to the client: a demo version of the product or its individual functions. During the final sprint meeting, the completed product is checked against the backlog, the results are noted, as well as, the next sprint is discussed.

Finish reading this article, gather a team and start a sprint? Not quite like that. The most important “zero” step, which Scrum management methodology requires is to figure out how Scrum actually works. Learn on your own or find a good Scrum-master, who will teach the team

There is a lot of complaining about the Scrum method on the Internet: “The meetups take too much time”, “All we got, in the end, is chaos”, “We didn’t succeed”. This happens due to ignorance of the Scrum essential and tips of its usage.

It may seem that the Scrum principles are simple and clear but when doing the real job, especially the first few sprints, there are always troubles and misunderstandings. Thus, in this adventure, there must be a person who’s familiar with these difficulties and knows what to do.

What are the stages of building up work on the product according to Scrum methodology?

1. Gather the team. Don’t forget that the team must cover the product development needs or simply be cross-functional. Besides, it is better to make sure that team members are aware of the nuances of working with the methodology, are sufficiently disciplined and ready to independently find solutions without waiting for instructions from above.

2. Choose the scrum-master. The key competence of a Scrum Master is his practical experience. If for some reason you cannot find such a specialist, then you should find the method expert who can at least advise you in a difficult moment.

3. Choose the product owner. An important thing to mention is that all the members have to know how to work (and agree to work) by Scrum method before launching the work process: not only the team members and the Scrum-master but the product owner too. Everything should be agreed “on-the-go”: during the sprint, the involvement of the product owner in the process and the opportunity to be in constant dialogue with the team are very important.

4. Create the product backlog. The product owner is responsible for creating the product backlog. The team of developers must familiarize themselves with it beforehand to make sure that the requirements are clear and the information is sufficient. Further, the general list of tasks is divided by sprints.

5. Plan and start the sprint. The duration of a sprint is individual, but on average a sprint lasts no more than 30 days and no less than 7 days. A rule from the creators of the methodology: the more unknown data, the shorter the sprint should be. Each sprint starts with a general discussion meeting, where the sprint backlog is determined and tasks are distributed. It is important to remember that nothing can be added to the scope of work during a sprint: only the team itself can change the sprint backlog.

6. Hold meetups. Daily short meetings are necessary to exchange information and get an overall picture of the sprint’s progress. And the scrum-master’s task is to make the exchange of information constructive, fast and clear.

7. React to changes. One of the principles inherited from the Agile philosophy is that the final product is above all. And to do this, it is important to quickly respond to anything that might interfere with meeting deadlines.

8. Summarize the sprint. In a sprint meeting, the team demonstrates a working version to the product owner. The product owner can invite other interested parties from his side. Also, during this meeting, the Scrum Master analyzes the collaboration with the team during the sprint.

The main advantages that Scrum technology gives to the project:

• Flexibility and fast adaptability to new metrics.

• A possibility to change product requirements, even to the extent of conducting a pivot.

• Meeting deadlines.

• Effective usage of the team’s resources.

• The cohesiveness of the client and the team.

• Constant information exchange.

• Swift reaction to any changes.

What are the possible disadvantages of Scrum?

• The team has to be taught how to use the method.

• It is difficult to find the right specialists for the team.

• It’s super hard to find an experienced Scrum-master.

• There is a risk of turning daily meetups into long senseless meetings (without proper moderation).

• One team won’t be able to work on several products at once.

The essentials that Scrum gives is the ability to work quickly and efficiently on a product in an environment of great uncertainty, ahead of competitors and large corporations. That’s why the Scrum development methodology is a great tool for the startup industry, where the first version of a product can go through many pivots and may look completely different in the end.

The main thing is to predetermine why you need Scrum for your product: not mindlessly copy all the "tricks" of the method, but implement them gradually, starting with training of the whole team and carefully analyze the process. Then the Scrum management method will be a powerful tool in order to lead the team to the desired goal.

Good luck with your work!