How to avoid possible mistakes when switching to Scrum?

Many companies are now restructuring their business processes to work according to the Scrum methodology. But only a few really work according to Scrum. How to set up the right Scrum and not slip into a kargo-cult? Let's find out together with Arthur Neck - Managing Partner of Kaiten, accredited Kanban-trainer and consultant on Agile, Scrum and classical project management.

What kind of projects Scrum is best suited for

Let's first outline a situation where Scrum is not a good fit:

• If your business has been running for a long time, a lot of processes are already in place.

• Or you have a lot of dependencies between departments within the company, and one small group cannot realize the whole startup cycle - from idea to product launch.

• If, for example, development has to be agreed upon at the board of directors, which takes place every six months. Then all the benefits of Scrum are canceled out: the main bonuses of using this method are quick knowledge of what the client needs and what products are missing on the market.

And Scrum is ideal when you launch a new product and there is a lot of uncertainty - you don't know how the market will react to the launch of such a product, and, accordingly, you need to get feedback from the market and customers constantly. At the same time, you have a permanent team that is ready to work on the product from idea to release.

Implementing Scrum in the work of your company: where to start?

The first and most important thing at the initial stage: the role of product owner should appear in the team. The product owner makes a product backlog (a list of work tasks arranged in order of priority). Where development will start, what first hypotheses you will test, what the product budget will be, the composition of the first releases - all this will be formulated by the product owner.

To approve the team composition, Feature Team Adoption Map is used - this tool allows you to visually understand who will be needed to implement the backlog by functionality (how many frontenders, backenders, UI/UX designers, etc.). Once the profile of specialists to implement the product is clear, you can start building the team.

And here it is worth mentioning the second important participant after the product owner - Scrum master. This specialist makes sure that the Scrum methodology is followed in the team. He teaches the Scrum framework and also takes on the roles of facilitator and coach. Scrum-master tells about the roles in Scrum, areas of responsibility, activities, and why they are necessary, and also conducts all the necessary activities: daily, reviews, sprints.

At the very beginning of work on the product there is a Kickoff session: the first part of which is a basic immersion course in Scrum (what are the roles, activities, artifacts). The second part is a discussion of the product and the initial backlog of the first sprint.

What mistakes can be encountered when implementing Scrum and how to avoid them

Scrum is formally very easy to get up and running, but difficult to maintain in the full functionality of this framework. You can misinterpret roles, conduct activities, build artifacts that are around Scrum. All of this overlaps, and in fact you get a very different Scrum process. So, about the major mistakes that are better not to make:

1) One of the global mistakes is to create a Scrum cargo cult on the basis of an existing unit. When we formally decided to work according to Scrum, but in fact nothing has changed at the deep level, except for the names. For example: let's take an existing manager and call him a product owner; let's think who can fulfill the role of Scrum-master from the existing specialists - for example, a tester. And "let's start working according to Scrum"! That is to formally adopt the structure of the framework, to repeat its basic framework, but not its deep essence.

The same applies to tools. For example, you can call a task tracker with 50 columns with different stages of work a Scrum board. And the format of a Scrum board is always the same: backlog/sprint-backlog/in progress/ready. It's done to maximize tight communication. And as soon as you slice additional "functional wells" within your Scrum team - it's a kargo-cult. That is, when work stages are sliced depending on the roles of the participants (analytics, development, testing, security, etc.) - this is fundamentally wrong, with this approach you don't realize the Scrum process.

2) Separation within a team, multiple teams. After all, Scrum is based on cross-functionality of the team: you should all work together to solve each task on the way of product realization. That is, when working according to the Scrum methodology, the whole team first conducts analytics, then does development and design, agreeing among themselves how it will all fit together. It is important for each team member to interact with the client and understand their pains. There should not be a transfer of tasks between different departments, there should not be several Scrum teams from different departments. Scrum-team is cross-functional and self-enclosed to realize the customer's needs.

3) Mistakes in the course of events: for example, starting a daily meeting with a report for a certain period - what we did. And according to Scrum methodology, a daily meeting is a re-planning point for the next day, when the team re-negotiates what is to be done.

4) Mistakes in customer interaction. For example, at the initial stage, when the team is just forming, not asking for feedback from the client is a grave mistake. It is necessary to conduct development in close contact with the client: conduct in-depth interviews, constantly show the product at various stages of readiness to get feedback and adjust the direction of work.

There is another common mistake in communication with the client: when you conduct a sprint review and just report on the work done to the executives. A sprint review is a point of communication between three types of roles:

1. the development team, which is responsible for quality;

2. the customer with their needs;

3. the business that is investing in the team.

And, ideally, they at the sprint review meet, evaluate the product change and plan the steps to take next. It's the agreements that are important, not just a progress report. Understanding how much the current functionality closes the client's objectives and what is the next step to take. Feedback from the client at every step is important. A big misconception is that the team itself knows better what the market needs. Only in close cooperation with the client of each team member is a truly marketable product born.

5) Lack of value for the client at every stage. When you decide, for example, to work out the perfect architecture. And for the first 5 sprints the team "cooks" within itself, develops this architecture without feedback from the client. Here you get a "waterfall model" instead of Scrum. When working according to Scrum, architecture elements are built at the moment of development, not as a separate stage. And at each stage it is important to deliver a certain value to the client. Not to think out the architecture "for centuries", but to model values flexibly, based on the interests of the client.

6) The team moves without purpose. When your product-officer throws some tasks and the goal of the sprint is just to accomplish those tasks. And you should always keep in mind what business result is behind these tasks. In Scrum, the goal of the sprint is always related to the main goal of the product. The focus should always be the result for the business.

7) Lack of a stable permanent team. When at the startup stage there were some people, then after a quarter you moved some participants to another project - this is unacceptable according to Scrum methodology. The team in Scrum is a constant, without which it is impossible to analyze processes. When the team is "out of sync", the productivity and predictability of the result is lost. Because a lot of time is lost on the co-tuning of new team members.

8) Mistakes at the release increment stage. It is important to take into account the definition of done - a set of criteria that allow you to understand whether what was the goal of development has been done. It is necessary to agree at the initial stage what is a working product and working increment - to work out the criteria of product readiness so that the client can start using it and it can be presented on the market. Otherwise, it can happen that the development team has formally finished its work, but in fact "the product is not ready yet, it is not ready yet, it is a bit raw, we need to test it".

What bonuses will the business get from applying Scrum?

1) Understanding what kind of product the market needs. You begin to understand what hypotheses work, how the market is organized in general, in order to compete effectively in it. And whoever is the first to come out with a product in demand, "skims the cream" and gets material benefits.

2) A cohesive and effective team that can work productively for results. Each team member understands the market and business values, each member is self-organized and productive due to cross-functionality.

3) Fast time to market of product launch: this is the time from the beginning of idea development to its final realization, when you sell it to the customer.