When top managers find out about SCRUM (or think about it once again), they often essentially abandon it, because they are not ready to work without a manager: he is not in scrum, this role is replaced by 2 roles: Product Owner and Scrum Master.

And the question sounds something like this: who should I complain to if the project fails?

Let’s try to answer it:

  1. SRUM is about the product, not the project. When using SCRUM for projects, this specificity is hidden by the Product Owner. By default, he is responsible.
  2. If you did the wrong thing, if you redid a lot or waited a long time for clarifications - contact the Product Owner.
  3. If there are problems in the team - people are fired, demotivated, there is no initiative, there is no transparency about what is happening (daily breaks, and even more sprints) - this is for the Scrum Master.
  4. If it turns out that a particular programmer does not pull and there is no training for him, then this is to the head of the department from which they took the programmer for the team. Yes, there is still a matrix subordination scheme (department head and project/team).
  5. If there is a mistake in the timing, then it is inevitable. Joke. It is necessary to analyze, look at the initial estimates, how much stock there was, where it went (new tasks, problems with personnel (layoffs and hiring), the level of errors, etc.). Usually the team evaluates tasks somewhere 1-2 sprints ahead. Therefore, the deadlines are again for the Product Owner (and his team - the architect, analysts, etc.).
  6. There is nothing about quality in Scrum itself. In particular, about design and technical policies. According to him, this is part of the DoD. In fact, someone has to do it: at the company, division, and/or project level. If you let it take its course, then the further along the development process, the more problems there will be (definition of a bad architecture).

And most importantly:

There is no need to wait for the failure of the project: you need to take a serious approach to the results of each sprint (and a sprint is preferably not 2 weeks or more, but one week). Scrum provides amazing transparency of the team’s work: assembly every sprint, velocity history, the opportunity to give feedback on the assembly, improvements in the work of the team, etc., but you can ignore all this and “wake up” only at the end, when there is no longer space to fix something. Don’t do that.

In other words, if there is a project, then the project manager remains. And he’s in demand. Another thing is that there is often a Technical Manager who is responsible for the technical aspects. In fact, something similar to the Product Owner / Scrum Master division: it is clear that the division is different, but it is clear that this is not something that did not exist before.