Get best of the week

What is the hidden meaning of the authors in the SCRUM Guide. Part 1. About the process

Talk about magic and unicorns SCRUM-a?

image

It is no secret that many tried to implement SCRUM in their homes, but not everyone succeeds, and many do not understand where the magic can come from.

Immediately agree, the only manual for SCRUM is Scrum Guides , it changes and updates, therefore I advise you to re-read it regularly.

This series of articles will not replace the reading of the manual, but will be an addition to the guide with some personal additions of the author.

And we will probably start with what is written on the last page of the manual:

Scrum's roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.

(Scrum roles, events, artifacts and rules are unchanged . And although the introduction of only parts of Scrum is possible, the result will not be Scrum.)

What does this tell me about, which already has a callus on the forehead from the rake that we were attacking, after 4 transformations in the company.

About that - if we want to get A95 gasoline, then we probably need to strictly adhere to production standards, heat the oil in the ratification column to a strictly defined temperature, take the vapors at a certain height, add components not “by eye”, but observe the last point his mother! technological process. In order for the final result to be A95, and not some kind of body weight that will ruin your car.

But why? Why, a typical (classic) manager, who suddenly decided to implement SCRUM at home, believes that the “technological process" is not in his company. His people are different, their hands are different or their legs, the code is written in the wrong place? And in general, it seems that I do not care about all 30 years of the evolution of managerial approaches. There are a million reasons to invent your bicycle for the first time in a million, and then proudly write about it on a hub, or even write a book about your “black scrum” . By popularizing that “bodyagie”, through the pain and tears of the developers, destroyed the established classical process with which the company had lived for several decades before, and as a result, it did not work.

// SCRUM is - simple to understand


So that's what I mean. What could be simpler than SCRUM: do planning, spend five minutes in the morning, and after 2 weeks collect everyone and let them show the result (usually no longer needed), and wait for the product, which brings money, joy and pride to everyone! Simply? Let's implement, say managers!

This “hook” usually comes across young and not experienced, because experienced (readers) already know that it is not so simple.

// SCRUM is - difficult to master


Do you know what Jeff and Ken hid in these 19 pages of the guide? One simple truth is that the more a manager / manager / supervisor “hyper cares” about his team, the worse the team with self-organization, the worse the result of their work.

Everyone knows that the bad (with which the team is degrading) manager is:

  • cannot delegate
  • he distributes the work himself, he accepts the result
  • daily monitors
  • It requires constant reporting, documentation, filling in time shields (presence schedules)
  • doesn't trust the team
  • imposes its decisions

(I hope no one recognized myself here)

This is the same “hyper concern”, or is it the feeling of “elder”, “parent”, “most responsible”, “I only need it”.

With a command, this necessarily does bad magic:

  • the team loses the ability to think. (You manager stop philosophizing here, but just tell me what to do)
  • the team works on tasks, not the result, sometimes "pretending" to be active. (We do task 1, task 2, task 3, and the product has fallen, let the admins / devops understand.)
  • the team is busy reporting, documentation, but not work. (I write reports half a day on Monday and Friday, I don’t do tasks.)
  • the team resists any innovation. (What are the auto tests? Let's get the task done.)

It is not strange, but SCRUM just “limits” the team from such “hyper control” by the “senior parent”.

Need proof? Keep it all according to the Scrum Guide:

Standup, only for the development team!


Every Scrum master knows that as soon as the “manager” arrives, even the “our friend” Product owner, the stand-up instantly turns into a “status report”. The team will no longer discuss what to do with it to achieve the goals of the sprint, but suddenly they begin to “dance in front of the elder” to tell what I did and how well done I am in all the details. And believe me, this immediately takes much more than 15 minutes, and the saddest thing is that it is an absolutely useless waste of time for all team members.

In the guide, it’s not for nothing that it is written -
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meetin

(Daily Scrum is an internal meeting of the Development Team. If there is
there is someone else, the Scrum master makes sure that they do not interfere with the meeting)

But the former managers, who usually become the Product Owner in the new process, hate it when they are not invited to stand-ups. And the first thing that breaks down in the SCRUM technological process is that all stand-ups visit it, because “control is above all”.

At meetings with Product Owner, the team has no more than 10% of the time, and not more than a minute


(I mean those on which PO is present, the team can always turn to PO if they need it)

Because for a 2-week sprint, these are strictly regulated 3 meetings:

  • 4 hours maximum on Sprint planing
  • maximum 2 on Sprint rewiew
  • and 1.5 hours Sprint retro

And that's all, in 2 weeks the Product Owner, according to the regulations, has only 7.5 hours, at which there is absolutely no time for “control”. The remaining 90% of the time the team works on the goal of sprinting. (But did you consider how much your team really can code?)

In reality, of course, our former “manager” will not tolerate this, and will break this “mess” with a couple of intermediate reports and rallies .

The team should implement the needs of the customer, not the personal goals of the Product Owner.


Because nowhere is it written that the Product Owner must write the requirements for the product itself, but it is written what to prioritize and make them understandable to everyone.

A good Scrum master knows that in order to ensure "transparency", it is imperative to invite User Story clients whose priority is to meet with the team. Establish direct communication with the client. Because given the promise to the client, oh how much motivate the team.

3 principles of SCRUM: Transparency, Research, Adaptation

But what sane "manager" will allow? It turns out that the ego “managerial truth” is being questioned, this is the team’s chance to “negotiate” and break all plans for career growth and the capture of the universe.

No, SCRUM is a terrible dream for a classical manager, and people used to living in “processes”.

Therefore, they usually try to break this entire SCRUM process, add more control, less transparency, and no adaptation, development.

As a summary: The best way to bury SCRUM is to appoint Product Owner, former projects, or your own managers.

  • PO, not a leader.
  • PO must be a person with unique abilities - to see the stacker where others do not see him.
  • PO must understand where more and where less money / values ​​and prioritize.
  • PO should be able to bring the stacker to the team, where the team itself will already sell its product.

and further
— ? , Scrum , , .

Let good people read good articles :)

More articles:


All Articles