The reverse side of Agile - parsing other people's mistakes

"Stupid learns from his mistakes, smart from strangers."

Good day to all. In this article, I intend to parse the errors that occurred and are thoroughly described in the topic The reverse side of Agile . This is by no means holywar, much less any blame. I am only interested in dissecting these questions from the side of the study and partially restoring the good name of SCRUM.

Questions and answers. All is short.

Before we move on to analyzing situations and trying to find the right solutions, and I believe that in almost any situation you can find it and even more so apply it (sometimes it is 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 certified SCRUM master program SCRUM.org'a. 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. What the fuck are you forgetting? - I have my own selfish goals: I am now preparing for PSM level II certification, and to confirm the second level, I need to disassemble the cases, and not thoughtlessly click on the correct answers, referring to the SCRUM Guide. Therefore, such cases for me are a golden storehouse (and if someone is interested, send me your cases, I’ll try to dissect them, well, or a cry for help and I’ll go look for her).

So, if you sorted out all the questions, let's get started.

Introduce the patient.

At one point, the company management decided to try a new-fashioned development methodology for Russia. Agile (Scrum) was selected, a scrum master was hired to 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 (hereinafter referred to as SM) is a good and logical step, because sometimes there are attempts to prepare SCRUM on your often specific understanding. I hope the experience of a person in this area was, because doing SCRUM from scratch is not an easy task, although judging by the further contents of the original article, I strongly doubt it. But for now, let us leave his competence in question.

  
  
• Let’s touch on the management Wishlist: improving speed and quality is good, what developers spend time on is past and not to SCRUM. This is a regular time-tracking, not described in any way in the SCRUM Guide and can be used for any methodology, whether it is KonBan, Waterfall or other RUPs.

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

• Just the task of SCRUM'a - maintaining creativity, interest and a good atmosphere. The main nuance is to learn how to apply it correctly and not to change the basic rules, because if in a well-functioning mechanism you replace one part with a completely different one, not suitable in size or function, you get one big nothing from the whole mechanism.

At first, after the introduction of the new-fangled Scrum, everyone rejoiced at its logic 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 certain sprints, at the end of the sprint we do a retrospective (we look at what we did and what went wrong) and loop this process.

• Here is the first serious mistake - getting a user story from managers. From all the text that I read in the original topic, I did not find 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 so far we will limit ourselves to these. Those. PO is 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 RO, which aggregates all Wishlist / Visions \ feedbacks from all interested parties, processes this list and brings it to the team, and the RO must have one and only one (!) For the SCRUM team, and not a bunch of managers, because it will turn out like in that fable of Krylov:

When there is no agreement in the comrades,
Their deed will not go smoothly,
And it will not come out of it, only flour.

• The next caveat is the lack of a fact of assessment. Maybe the author of the article forgot to indicate, or maybe it just wasn’t, but the team should give its assessment of a particular User Story. If the assessment was given by someone else, not the Development Team (everywhere further DT), then this will be a pain / sadness and in general this should not be done. The postulate must be respected, who performs the task, he gives an assessment. Not the manager Vasya, but the whole DT.

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

• At that moment, SM was supposed to enter the game and send all managers on foot erotic journeyto protect developers (DT) from managerial lawlessness. The desire of management is understandable and applicable: to evaluate, measure, save money (not all managers are doing this, there’s no getting around it). But in this case, SM had to intervene in the matter, taking the whole blow on himself, explaining to everyone what the team was doing, what it was doing and why they should not be touched. Well, if any particularly zealous manager sneaks into the room to DT, then drive him with pissed rags. Yes, I foresee objections: “Man, are these managers, who will say a word against them, not to mention rags?”, But everything is quite simple, SM must agree in advance with TOP \ MegATOP and other large managers that they don’t touch the team and work through it. Actually, this is one of the responsibilities of SM'a - to implement SCRUM in the organization and implement it correctly, and not a blunder.and sat gamal in tanks?

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

• One DT - 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 a better mix to make SCRUMBan, and yes, there’s nothing wrong with it interestingly, I’ll tell you how to do it and implement plus any different chernukha ). Those. when there are a lot of requests from many projects, it already smacks of support and it’s better to leave SCRUM. Plus, where was SM (ahhhh?), Why didn't you protect DT? Did he know exactly SCRUM? Was you ready to implement it? Had experience? To this paragraph, I already doubt the positive answers to these questions a little more than completely.

Only tasks (User Story), coming from managers, began to be performed, the developers did not have time for any inconspicuous, but useful activity.

• There was no PO, SCRUM was incorrectly implemented - hence the severe pain. If there was one (!) PO that was responsible for managing the Project \ Product Backlog, and not a herd of rabid managers, then everything would be simpler (Yes, he would have to argue with managers and be unloved by them, but what to do? he has one in some realities. Then everyone would get used to it and reconcile.)

It got to the point that when the bug was found somewhere on the production, the developers could not repair it, because it takes a task to write off time there. And the developers themselves were inundated with their tasks. Tasks began to be prioritized. Managers began to conflict among themselves, trying to assign their userStory the highest priority, because they have obligations to customers and no one cares about the busy developers.

• I repeat if I say that there is no PO and SM is an asshole and is this 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 end results of what needs to be done. And it should be framed in such a way that Vasya \ Petya \ 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 DT members understand correctly and there are no misunderstandings. 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 flies into them, and DT cut off from the world and fit them tea / coffee / cookies / courtesans.

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

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

  When the values ​​of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values ​​as they work with the Scrum events, roles and artifacts. Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people
  

According to SCRUM, people are the foundation. Although, what I praise him here is that people are the foundation everywhere for any manager and for any process \ approach \ methodology. If there is no brain, if managers think of a sciatica, 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'm wrong, but as my intuition tells me it had a place to be - the assessment for User Story was considered a commitment, and the developers were in overtime to their ears. Guessed?

• It would seem that this is somehow a little 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 are not taken into account, then this is a subject of bargaining between DT and PO, but do not "die, but do it". And indeed there is the concept of forecast, if you pay attention, the SCRUM Guide does not describe the methods of estimation and units of measurement. All these watches, poker and other sizes of underpants, appeared as local extensions that "took root". But in the first scam they simply are not. Thus, if the forecast failed, then in the framework of 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 fixes for errors are described in the article, but below I will collect a short summary:

1. RO and SM should and should be involved in the process according to their responsibilities.
2. RO must work directly with stakeholders. DT should only fulfill the vision of the RO according to the backlog of the project and not communicate with the managers at all, except for clarifying questions and receiving feedback in the framework of the review.
3. SM should not be for show, not because it’s fashionable / youth, not for dough, but for setting up the process, because without a competent SM, the whole process will go to waste. In particular, in this situation, he had to initiate the creation of a RO role, then teach him how to work with backlog, DT, and external managers. Also, in the first couple, look so that he does not mess up and the managers do not exert an undue influence on him.
   Then work with the team, receiving feedback from it and eliminating what prevents the team: whether it be 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 so much that the next guy came and introduced a super-duper priority because he needs it.

Epilogue

Why did I react to this article, sometimes losing the thread of logical narration and slipping into reasoning - because I probably got burned because SCRUM is often misunderstood. As a result, this will lead to someone saying: "% username%, you know SCRUM - shit, juicer and fascism. We will not introduce it." and as a result, everyone will lose something.
In the initial topic, huge problems in the organization of the process itself are clearly visible, for which they scored \ put \ substitute_to_options. SCRUM has nothing to do with it. With the right approach, he’s just a bead and in general

I can state this with full confidence of the person who did SCRUM from scratch, changed SCRUM, mixed it with Kanban, used it successfully with Fixed Price (!) Projects.
Yes, the transition to it is aggressive, innovations are always, perhaps, unexpected and sick, but if it is properly presented, 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 they sing, but this inapplicability lies in different factors: budget, restrictions, the need to use a different process. But, its inapplicability cannot be attributed to crooked hands. Crooked hands are crooked hands, they can expel everything, not just SCRUM.

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