The reverse side of Agile - sorting out other people's mistakes

"Stupid learns from his mistakes, clever to others."

Good day to all. In this article I intend to make out the mistakes that occurred and are thoroughly described in the topic Reverse side of Agile . It is in no way holywar, much less any blame. I am only interested in analyzing these questions from the research side and partially restoring the good name of SCRUM.

Questions and answers. All is short.

Before we proceed to the analysis of situations and attempts to find the right solutions, and I believe that in almost any situation you can find it and even more apply it (sometimes through very painful), I would like to answer a few questions that may arise from the reader.

1. Who are you to talk about SCRUM and analyze errors? - I am a certified SCRUM master under the SCRUM.org program. Now PSM level I. Yes, I received a certificate recently, but I have been practicing and preparing this methodology (framework;)) for the past 5 years, if not more, both from scratch and changing existing ones.

   
   
2. You here ** all that you forgot? - I have my own mercenary goals: I am preparing now for PSM level II certification, and to confirm the second level, I need to sort out the cases, and not thoughtlessly click on the correct answers, referring to the SCRUM Guide. Therefore, for me, such cases are a golden fount (and even if it will be interesting to someone, send me your cases, I will try to dissect them, well, or scream for help and go look for it).

So, if you have dealt with all the questions, let's proceed.

Bring in the patient.

At one point, the company's management decided to try a new-fashioned development methodology for Russia. Agile (Scrum) was selected, a scrum master was hired by the company, all developments were transferred to TargetProcess. From the point of view of management, this was done in order to improve the speed and quality of development, as well as to gain an understanding of what developers spend time on.

• Hiring a SCRUM master (everywhere further SM) is a good and logical step, because sometimes there are attempts to prepare SCRUM on its often specific understanding. I hope the person has experience in this area, because to make SCRUM from scratch, the occupation is far from simple, although, judging by the further content of the original article, I strongly doubt it. But for now, let's leave his competence in question.

  
  
• Let us talk about the management hotel: improving speed and quality — well, what developers spend time on is past and not to SCRUM. This is the usual time-tracking, not described in any way in the SCRUM Guide and can be used for any methodology, be it KonBan, Waterfall or other RUPs.

Of course, I understand perfectly well that times are changing, and earlier, perhaps, the development of a project was something like creativity. Now it is a streamlined business process whose goal is to make money. But brought to apotheosis, this process can suppress in developers craving for creativity and interest in the development of the project.

• Just the task of SCRUM is to maintain creativity, interest and good atmosphere. The main nuance is to learn how to apply it correctly and not to change the basic rules, since if in a well-established mechanism to replace one part with a completely different one, which is unsuitable either in size or in function, then one large nothing will come out of the whole mechanism.

At first, after the introduction of the new-fashioned Skram, everyone rejoiced at its consistency and external simplicity. Everything is clear, we divide the development process into sprints, we get user-story managers (tasks, what to do), we include them in some sprints, at the end of the sprint we do a retrospective (we look what we have done and what went wrong) and we loop through this process.

• Here and the first serious mistake - getting a user-story from managers. From all the text I read in the original topic, I did not find any mention of the role of Product Owner (everywhere further RO). Who is the RO - the person responsible for the final vision, development of the project and management of the project backlog, he still has a number of responsibilities, but for now we will limit ourselves to these. Those. PO - the first deterrent barrier from the entire herd of managers living in the open spaces of your office. So it should look and work.

The team has a PO, which aggregates all the wishes / visions / feedbacks from all interested parties, processes this list and conveys it to the team and the RO should be one and only one (!) For the SCRUM team, and not a bunch of managers, because it turns out in that Krylov fable:

When there is no agreement in comrades,
Well, their business will not do,
And it will not work out of him, only flour.

• The next nuance is the lack of assessment. Maybe the author of the article forgot to specify, and maybe it just did not exist, but the team should give its assessment on this or that User Story. If the assessment is given by someone else, not by the Development Team (everywhere further DT), then it will be a pain / sadness and in general this cannot be done. The postulate must be observed, who performs the task, he gives an assessment. Not manager Vasya, but the whole DT.

Management began to convert tasks during their execution and of course into cost. Here, as usual, a misunderstanding immediately arose between management and developers. How can transferring a project from Symfony 2.6 to Symfony 3.0 take almost a week to the developer, because this is just an upgrade from one version to another? Perhaps, from the business point of view, the development department always looks like lazy employees, who are good if they could work three times and, preferably, five times faster to reduce development costs and increase its speed.

• It was at this point that SM was to enter the game and send all managers on an erotic foot journey to protect developers (DT) from managerial lawlessness. The desire of management is clear and applicable: to evaluate, measure, save money (not all managers are doing this, well, there is no getting away from it). But in this case, SM had to intervene in the case, taking the whole blow upon himself, explaining to everyone what the team is doing, what it does and why they should not be touched. Well, if any particularly zealous manager sneaks into the room to DT, then drive him with pissing rags. Yes, I anticipate objections: “Man, etozh managers, who will say a word against them, not to mention rags?”, But everything is simple enough, SM should agree with TOP / MegTOP and other big managers in advance that they don’t touch the team and work through it. Actually, this is one of SM's responsibilities - to implement SCRUM in an organization and implement it correctly, and not just a blooper. Immediately, judging by all the SM, he got rid of the problem and sat in the gamil of the tanchiki?

But, from the point of view of the developers, a slightly different picture emerged, the developers were not deprived of work anyway, working on three to five projects in parallel each time, as pressure from the management and report for each hour of working time appeared. Questions began to arise in the spirit of "why did you spend the whole day developing or testing this one"?

• One DT is one PO and preferably one project (or necessarily one Product Backlog), or you need to seriously change the process, change the methodology from pure SCRUM to Kanban (or even better, mix SCRUMBan, and yes, there’s nothing to worry about if Interesting, I will tell you how to do it and introduce it, plus any different chernukha ). Those. when there are many requests from many projects, this already smacks of support, and here it is better to leave SCRUM. Plus, where was SM (aaaouu?), Why didn't you defend DT? Did he really know SCRUM? Was it ready to implement it? Had experience? To this paragraph, I doubt the positive answers to these questions a little more than completely.

Began to perform only tasks (User Story), coming from managers, on any imperceptible, but useful activity of the developers did not remain.

• There was no PO, SCRUM is incorrectly implemented - hence the severe pain. If there was one (!) PO who was responsible for managing Project \ Product Backlog and not a herd of rabid managers, then everything would be simpler (Yes, he would have to fight with managers and be unloved, but what to do? Fate he has this in some realities. It would later all get used and resigned.)

It got to the point that when a bug was found somewhere in the production, the developers could not fix it, because this requires a task to write time there. And the developers themselves were inundated with their tasks. Tasks began to assign priorities. Managers began to clash with each other, trying to assign their userStory top priority, because they have obligations to customers and no one cares about the employment of developers.

• I repeat if I say that there is no PO and SM asshole and this is the main problem? In fact, the Backlog item (in our case User Story) is a necessary artifact, someone will say that this is a tribute to formalism, but here I dare to object - no. This is a description, understanding and vision of the final results of what needs to be done. And it should be arranged in such a way that Vasya \ Peter \ Cthulhu from DT - everyone understood what needed to be done and could explain this to PO and SM. Why explain to them if they already know? Then, to see that the DT members understand correctly and there is no ambiguity. According to the recommendations, everything is simple, put PO and SM'a on the front line of defense of DT, so that all the poop flew into them, and cut off DT from the world and fit tea / coffee / cookies / courtesans to them.

Methodology Scrum, which turns the development process into a pipeline, does not take into account primarily human relationships in a team, does not take into account the fact that some things in a company can be done only because of the enthusiasm of employees, and cannot be wrapped in UserStory.

• Framework, Bro. Not a methodology, not once. It takes into account human relationships. This is one of the main goals of SCRUM and is based on these relationships. Why I decided so, but that's why (a piece was torn out from the SCRUM Guide):
  

  It is not a problem to make it true. The Scrum Team. It is a great success. Scrum Team. The Scrum Team Everyone focuses on the Scrum Team. The Scrum Team. Scrum Team Independent People
  

According to SCRUM, people are the basis. Although, what I praise him here is that people have a basis everywhere in any manager and in any process / approach / methodology. If there is no brain, if managers think with a seat, then everything is bad.

Dear Keks650 , I can even try to supplement your article, I think you forgot to mention one serious factor that greatly influenced the whole team and the whole process. Maybe I will be mistaken, but as my intuition tells me it was the place to be - the rating for User Story was considered as a commitment, and the developers were sitting in overtime at the very ears. I guess?

• It would seem that this is somehow insignificant commitment or forecast. What is the difference in the stump? And the difference is really huge. In the SCRUM Guide there is no such thing as a commitment to deadlines. If the task was evaluated incorrectly \ incorrectly or all factors were not taken into account, then this is a bargaining thing between DT and PO, but not "die, but do it". And in general there is the concept of a forecast, if you pay attention, the SCRUM Guide does not describe the methods of evaluation and the unit of measurement. All of these watches, poker and other sizes of underwear, appeared as local extensions that "got accustomed." But they are simply not in the first-century. Thus, if the forecast failed, then within Retro, DT should consider what \ why and how to fix it so that this does not happen again. And if SCRUM is implemented normally, then there are no problems with this.

Posthumous epicrisis.

I believe that the patient was not saved, so let's summarize.
In principle, all the error fixes are described in the article, but below I will compile a short summary:

1. RO and SM should be and should be involved in the process according to their responsibilities.
2. RO should work directly with stakeholders. DT should only fulfill the RO vision according to the backlog of the project and not communicate with the managers at all, except for clarifying questions and receiving feedback within the review.
3. SM should not be for show, not because it is fashionable \ youth, not for drinking the dough, but for setting up the process, since Without a competent SM, the whole process will go to ashes. In particular, in this situation, he had to initiate the creation of the RO role, then teach him how to work with backlogs, DT and external managers. Also in the first couple to look so that he does not mess up and managers have not had an undue influence on him.
   Then work with the team, receiving feedback from it and eliminating what the team is interfering with: whether it is a draft in the room or some particularly annoying and zealous manager.
4. The RO should have a well-developed and prioritized Project Backlog, with a clear definition of priorities, and not the next guy who came in and introduced a super duper priority because he needs it.

Epilogue

Why did I react to the article like that, in some places losing the thread of logical narration and slipping into arguments - because I got burned, perhaps because SCRUM hayat very often did not understand. As a result, this will cause someone to say: "%% username, you know SCRUM - shit, juicer and fascism. We will not introduce it." and as a result, everyone will lose something.
In the original topic, one can clearly see the enormous problems in the organization of the process itself, upon which they scored / laid down \ substitute_on_sight. SCRUM just nothing to do with. With the right approach, he is just a buzhechka and generally

This I can state with complete confidence the person who made the SCRUM from scratch, changed the SCRUM, mixed it with Kanban, used it successfully with the Fixed Price (!) Projects.
Yes, the transition to it is aggressive, innovations are always, perhaps, unexpected and sick, but if it is presented correctly, it will work very well.

PS - I do not call that SCRUM is a panacea for everything. Sometimes it happens that it is not applicable, no matter what asanas are sung to him, but this inapplicability lies in different factors: budget, restrictions, the need to apply a different process. But, its inapplicability cannot be attributed to curved hands. Curved hands - these are curved hands, they can expel everything, not only SCRUM.

Almost all of my reasoning intersects with the SCRUM Guide . I highly recommend to study carefully and work actively with this document, and not blindly follow whose crooked opinion.