11 steps of Scrum

99% of those dissatisfied with the results of their project believe they know who's to blame. Business owners blame lazy contractors, business analysts blame stupid customers, developers blame clueless managers, etc. Who's right? Everyone's wrong. Each of us thinks that only he knows how to react objectively to the situation, and the behavior of the others is motivated only by their personal qualities. Generally speaking, that's not true — everyone has their reasons.

It's silly to blame. Do not look for bad people, look for harmful systems — systems that provoke the creation of bad processes and reward bad work. Scrum is a framework that helps teams work together. Instead of looking for the guilty, it tries to investigate the root cause of the mistake and fix it.

At the heart of Scrum lies a simple idea — whenever a project is started, there's nothing that prevents you from regularly checking on progress and consistently finding out:

• Can your team handle the tasks;
• Are the project moving in the right direction;
• Is your team building exactly what customers really want?

The process described by Jeff Sutherland is called "check and adapt". In other words, at any appropriate moment and as often as possible, you should interrupt the work, review what has already been done, and find out if everything is done correctly, what needs to be done, and how to do it better.

How to do that? The author of Scrum offers a list of 11 items.

Jeff Sutherland names the product owner not the main investor, but a specialist, professional who has the vision of what your team is going to do/create/achieve. He makes the final decisions, is always available to the team, and is ready to answer questions. He is the one who takes into account the risks and benefits: what needs to be done, what can be done to get the most out of the product, and what will inspire the whole team. It is the owner of the product who is responsible for OODA cycle(an acronym for observation, orientation, decision making, action).

This concept was created by military pilot John Boyd. Somewhere in the sky over North Korea, work on OODA principles has helped the wider revision of the F-86 to gain superiority of the more advanced maneuverability and weapons of the MIG-15. The owner of the OODA cycle is able to get into the enemy's decision-making cycle. So what is it?

Observe means to see the situation clearly as events unfold. And somehow put those events in the data. Boyd recommends going beyond your own self — to see the bigger picture, not just from your own perspective.

Orient means not only the place where you are but the different situations you can see — a menu of possibilities you create for yourself. So, here you transform the results from the first step, you understand and analyze them and make a plan for the next steps.

Decide — this is where you choose a solution from the options based on the plan that was developed in the orient phase.

Act — speaks for itself.

Then the cycle repeats — you need to start observing again — the results of your own actions, the actions of your opponents, competitors, or the market reaction. Then set a new plan or goal where you need to go and choose the way you want to achieve that goal, and act on that plan.

The Scrum methodology, with the addition of the concept of "increment of work" or "sprint" to this model, allows the Product Owner to see what value this increment adds to the product and how customers respond to it. Based on the information received, he can change the objectives or their priorities for the next sprint. In this way, a continuous feedback loop is established, which speeds up the process of innovation and adaptation and allows the Product Owner to measure the value added.

Who are these people who can do the job? The professionals in the team must have all the skills and knowledge necessary to bring the owner's idea of a product to life. The gold standard of a scrum must have 3 to 9 people in one cross-functional team. I think the ideal size for 6 people including Scrum Master is big enough to provide adequate skill sets but small enough to cooperate easily.

Basic attributes of the team:

• motivation to create a product;
• ability to create a product;
• autonomy, freedom to do their job as the team thinks best;
• focus on the customer and his needs;

It's crucial that someone ask difficult questions. You need a character like Shakespeare's wise jester. It's a person who keeps an eye on the project, makes sure that all the daily meetings of the scrum take place, and helps the team to remove obstacles. Most often, the scrum master is the project manager. But it's always not a very good idea to combine the scrum master with the product owner, they have different responsibilities, and conflicts of interest may arise.

Product backlog is a list of absolutely all product requirements sorted by their priorities. A backlog exists and evolves throughout the whole life of the product, which serves as a guide for the team. A product backlog is the only and unambiguous concept of "everything that a team can do by priority".

There can only be one product backlog. This means that the product owner must make priority decisions based on the full range of tasks. The product owner must talk to all involved people in order to provide full feedback and to display all customer requirements and expectations on the backlog.

It is very important that the team members who will perform the tasks from the backlog can estimate how much effort these tasks will take. From the scrum's point of view, this meeting is called Grooming. These meetings are held at the beginning of each sprint so that the team knows exactly what to do with the subsequent sprint.

Team members have to look at each task and determine:

1. Whether it is realistic to achieve at all.
2. Is there enough information to complete the task?
3. Are the description and requirements understandable enough to be evaluated?
4. Is there general understanding of what kinds of standards and criteria it has to meet in order to be completed?
5. Does it add real value to the final product?

It must be possible to estimate each task so the team can measure its speed and performance. Do not estimate backlog tasks in hours or money — people are not doing it well. Estimate in relative size(aka T-short estimates): "small", "medium", "large". Or use the Fibonacci sequence and assign each task a number of points: 1, 2, 3, 5, 8, 13, 21. Of course, nothing will be exactly five, or eight, or thirteen, but by applying for these numbers, you can collect opinions on the scale of the task in such a way that everyone uses one abstract system of measurement. This way the team will quickly reach an agreement. But you can also measure the task in time units: hours, days, weeks. Take a look at my note about [how to measure time] (https://luminousmen.com/post/how-to-estimate-time). It turns out that a collective evaluation of a task gives much more accurate results than an individual one, and can raise some important questions for the product owner.

A sprint is a time span during which a team creates at least a minimally functioning increment of the product. It can then be shown to the customer immediately. Each sprint is preceded by a meeting where the team, the scrum master, and the product owner plan tasks for the sprint, this meeting is called "Planning" or "Sprint planning".

Sprints should always have a fixed duration, which should be less than one month. Typically choose sprints of one or two weeks in length (questionable, but for me, it works best). The team goes from the top of the backlog and estimates the number of tasks that can be completed for the next sprint. If a team has already done a couple of sprints, it should take into account the number of points that were in the last sprint. Scrum master and the team may try to increase the number of points taken in each sprint but it should be reasonable.

Sprint planning is another opportunity for the product owner and the team to ensure that everyone understands exactly how to implement the assigned tasks. At this meeting, everyone must agree on the goal of the sprint and determine what is to be done for the sprint.

New tasks no longer can be added to the ongoing sprint.

It's all about building the right system. It is necessary to give people freedom, respect, and the right to do their own thing. The heads of organizations where everything is kept secret do not want ordinary employees, leading specialists, even managers close to the top of the hierarchy — to know what is happening now, what has already been done, and in what time frame. Any information and knowledge are not exchangeable because hidden information is the only guarantee of their power (at least, they think so). They only pursue their own interests, which most often do not help the product or company.

Here we deal with the type of thinking responsible for such a phenomenon as a management failure, which has become widespread. The transparency of all actions and processes ensures that the goal is reached as soon as possible.

In scrum the most common way to achieve this is to have a scrum board with columns "To do" or "Backlog", "In Process" and "Done". The stickers are the requirements to be implemented, the team moves the stickers from one column to another as they are executed.

Another way to make the work transparent is to create a [Burn down chart] (https://en.wikipedia.org/wiki/Burn_down_chart). On one axis, the number of points that the team took in this sprint is placed, on the other axis, the number of days. Every day the Scrum master calculates the number of points for the completed tasks and reflects this on the chart. Ideally, by the end of the sprint, this chart should correspond to zero.

By the way, another plus of transparency is that the team members can see the number of each other's tasks and quickly help those who are behind in achieving the common goal of the sprint.

It's the pulse of the entire scrum process. Every day at the same time no more than fifteen minutes the team and the scrum master meet and give answers to three simple questions:

• What did you do yesterday to help the team finish the sprint?
• What will you do today to help the team finish the sprint?
• What are the obstacles and problems that prevent you from doing so?

That's all. Every day. If it takes more than fifteen minutes, you're doing something wrong. The point of these meetings is that the whole team knows exactly what task is at what stage on the current sprint.

Will all the tasks will be completed on time? Is it possible to help other team members overcome obstacles? Nobody is assigning tasks — the team is independent and decides everything on its own. Nobody writes detailed reports to management, it makes no sense.

This is an open meeting where the team demonstrates what was done during the sprint. At this meeting, the entire team is represented with the product owner, the scrum master, the team, and any interested parties: the customer, management representatives, stakeholders, potential consumers. The team must only demonstrate what meets the definition of "done" (these are the criteria that determine the degree of readiness of the item from the backlog - this definition must be described and agreed upon by the team). What is completely and finally ready. It can be a completely finished product or an individual finished function.

Not everything that was planned was done? It means that too many tasks have been selected for this sprint.

After the team has shown what they have done for the sprint and what can be handed to the customer for feedback, everyone sits down and discusses the sprint. What went well? What could be done better? What was completely wrong? What improvement can be implemented by the team immediately?

In order for the meeting to be effective, the Scrum master and the team need to create an atmosphere of trust and show the necessary emotional maturity. The main thing is to remember that you don't judge anyone but to discuss the process. Why did this happen? Why did we miss it? What could have speeded up the work process?

It's especially important that people feel like a team and take responsibility for all actions and their results. The whole team is looking for solutions. The members of the team must have some psychological impact so that their discussions are focused on solving the problem, not on finding the guilty. It is absolutely unacceptable that even one member of the team is forced to take a defensive position — every member of the group should hear and understand each other.

By the end of the meeting, the team and Scrum Master should agree on improvements to be implemented in the next sprint.

The most important thing in this methodology is customer orientation. The customer must get what he wants, on time and with minimal effort. Unlike the linear (waterfall) approach, when the project was originally planned "from" and "to", and the result is somewhere "at the end of the way", this method allows you to get a working product in a short time with minimal costs. Of course, it does not yet have all the necessary characteristics, but it can already be used. Further, in the course of the project, the team receives feedback from the customer, on the basis of which increment in functionality and improvement of the product is carried out.

The main feature of Scrum is flexibility. This methodology allows the team and business to react quickly to changes in requirements and quickly adapt the product to them.

At the implementation of Scrum difficulties can arise. Firstly, the active participation of the customer in the project is expected. Secondly, well-coordinated teamwork is essential.

...a tool to control people(yes, I heard it from the developers, even managers(!)). Of course, it's not, it's more productive to work less. Agile methodologies are risk control, not the control of each other.

...complex framework. Go to http://agilemanifesto.org/ and read 4 values, just 4 statements. And that's it.

... unclear requirements, because they may change with the development of the product. That is not true, the requirements must be clear enough to be defined as user stories or product backlog items for the team to implement.

...only for software development. Many industries can benefit from this structure even by achieving personal goals.

Agile methodology is like a gradient descent in the development process. Every iteration you are doing small step by the negative gradient— one step towards the goal. Check out the talk:

Additional materials

• 5 False Hopes of Scrum and How to Fix Them
• The Epic Guide to Agile