Treatment of "mechanical" Scrum. Part 3. Work SM

    As the name suggests, this is a continuation of a series of articles about roles in scrum ( part 1 and part 2 ). Today we consider the next role - scrum master . Paradoxically, the success of scrum depends largely on the scrum master. Therefore, I would like to again invoke the power of imagination and bring the metaphor ( disclaimer: an example should in no way offend anyone’s feelings ). There is a culture that has its own cult, its rites, there are ministers of this cult. Servants can be divided into different classes:

    • those who, with their culture, prefer to be one-on-one - hermits, hermits, enlightened;
    • those who have learned all the rules, found loopholes, understand what to do and how, and use the cult for personal gain, making profit from people, their fears and prejudices;
    • fanatics who are trying to implant their culture to the place and out of place. For whom, apart from their knowledge, everything else is heresy;
    • those who sincerely believe, feel and try to share, help and give this miracle to people; they tell and explain, listen and try to help.

    With Scrum and SMs, it seems to me, a very similar story happens. Try to look at the familiar SM through such a prism. What kind of SM would you like to work with?
    image
    Let's see what the alarming symptoms SM may have.

    Interaction with the product owner


    Symptom : SM does not work with grocery backlog. Completely leaves it to PO conscience. He expects the team to receive the backlog and its elements in the form they need without the participation of SM.
    What is bad : One of the tasks of SM is to build an effective and transparent process in which all participants are comfortable working. SM needs to keep track of all the scrum elements in order to be able to improve it, and the backlog of the product is a very important scrum artifact that cannot be ignored by the SM.
    How to treat: SM should agree with PO to work together on the backlog and understand the work of PO; analyze the process; suggest improvements; offer your help. SM should ask the team what expectations they have from the backlog, how to improve it. Collectively make decisions on how to improve the backlog, its elements, process and activities to interact with it, you can devote a separate retrospective to this. And to return to this question with a certain periodicity ( remember that the empirical process underlies scrum ).


    Symptom : SM does not listen to PO ideas / desires. He opposes himself to him. There is a sham war for influence. There is no constructive interaction between SM and PO.
    What is bad : I like the comparison of the scrum team with the family, this metaphor very often helps to understand and explain why you should do this and not otherwise ( Just transfer the situation to the family, ask the question: “What would you do in a family?”. Often you can find the path to the answer ). It is difficult to call a happy family where mother and father constantly quarrel, because children suffer from this very much ( IMPORTANT : SM and PO are not “parents” to the team). When there is no understanding and constructive interaction between SM and PO, the team will suffer: undercover games, sabotage of openness and transparency. If SM can not agree with the PO, it can not solve one of their most important tasks: " of The the Scrum to Master Master Helps everyone change for These Interactions to maximize the of value Created by the the Scrum Team. "
    How we treat: We need an experienced facilitator who would reveal the causes of the conflict in order to begin to improve the situation. The active team itself can begin to gather facts about the destructive effect of disagreements between SM and PO on the team’s results - simply by recording the working situations. And then in a retrospective, where both participants are present, to give these facts, discuss them and try to find solutions. If it is not possible to build a dialogue and it all comes down to finding the guilty, and not the solution, then you need to look for an external facilitator and escalate the problems outside the team.
    At the same time, it is important for the team not to take sides: “do not drag us into disputes, as agreed, so let us know about the decision”. This position will be an indicator of an existing problem for SM and PO.


    Teamwork


    Symptom : Scrum master does not “preach”: it does not explain the essence of the elements of scrum, does not conduct training, games, trainings that allow the team to better understand the scrum and become familiar with the agile culture. Does not explain and does not give the team answers to questions related to the process. Does not know the current level of acceptance and understanding of scrum team members.
    What is bad : If there are no regular team meetings where scrum is discussed, then understanding and faith in the framework go away. Any culture ( agile is not an exception ) requires reinforcement ( not to be confused with cargo culture), most likely the scheme will not work: have been trained, we know scrum, scrum took off. Over time, people accumulate experience, they have new questions that require attention, explanation. If you do not help people to understand, they will no longer live with these ideas, and will drown in problems and misunderstanding, ultimately will be disappointed.
    How to treat: SM, in the first place, has to learn all the time by itself, communicate with colleagues, read articles, attend meetings, conferences, etc. He should regularly share this knowledge with the / PO / team of his organization: conduct training and games illustrating the principles of agile / scrum. The team / company is developing, and it is necessary to provide relevant knowledge that meets current needs and demands. To realize these needs, you need to communicate more with people on the topic of processes and difficulties in work. SM should regularly conduct personal conversations with each team member in order to understand what are the expectations, problems, level of understanding of the scrum in the team. As in many ways, with regard to scrum, it is important to set the rhythm of activities for the development of agile culture and scrum within the team / company.


    Symptom : Partial SM, for example, in combination with another role. And he scrum-master, when there is at this time, in a residual principle.
    What is bad : If the SM does not completely surrender to the scrum development task in a team / company, but combines this with another activity, then all the results will most likely suffer. Being good SM is not easy, and if you do it in fragments, then the scrum is likely to degrade. For example: if a person combines the roles of a developer and SM, in case of problems with achieving the goal of a sprint, he will rather rush to do the tasks himself in order to achieve the goal. Is that bad! The most correct behavior of SM in this situation is to set up a team to achieve a result, develop a team, help it to become better.
    How to treat: If we are talking about the work of SM in a still immature team, then we need to try to find ways to free SM from any other job, except scrum-skill. This can be proposed as an experiment on several sprints, to understand what it gives the team. If the organization is on the way to test agile and scrum, this should give a green light. After the experiment, it is worthwhile for all interested parties to evaluate the results and make decisions about the fate of the scrum, the isolated SM and agile cultures in general.
    An SM that has grown a mature team, in which the bus factor is more than one and the work is done in the absence of SM, can afford to combine or work with the second team ( but not forgetting the first one, perhaps bringing up a substitute for it there ).


    Symptom : SM does not facilitate meetings and meetings. He can either pull the blanket over himself, "knows" all the answers, does not allow the team members to speak out. Either he does not “lead” meetings, he just gathers people, and then he lets everything go to chance.
    What is bad : If SM does not facilitate, it does not help to build effective communications ( between team members; communication with PO, stakeholders, etc .; holding meetings; etc.), then a lot of energy can be spent on communication, which could be spent on product development. Meetings may not reach the task assigned to them. Conflicts may arise due to misunderstanding. And from an effective decision-making tool, meetings are likely to turn into a source of stress. And SM domination at general meetings will demotivate the team and negatively affect initiative and self-organization.
    How to treat : SM should be able to facilitate. His task is to build open communications within the team; configure team interaction with the outside world; teach the team to hold useful meetings. The SM should recognize the need for this or that meeting, formulate the purpose and agenda of the meeting, set the duration in advance. During the meeting, you need to follow both the agenda and the selected timeframes, to interrupt discussions on abstract topics, for example: “we will definitely return to this topic later, it’s written down, and now let's continue the discussion of our current issue”. You can ask someone from the participants to assist in holding meetings ( or delegate part of the meeting to a team). At the end of each meeting, it is important to summarize and record the result. It is useful to introduce meeting assessment tools so that at the end participants will spend a few more seconds and give feedback ( we are building an empirical process where it can be useful ). All results should be conveyed to all interested parties at the end of the meeting, for example, by letter.


    Symptom : SM does not form a real scrum team from a group of people. Does not build trusting professional relationships, does not smooth corners.
    What is bad : the reluctance to communicate, conflicts, non-working atmosphere - adversely affect the results of the team. Solid teams give the best result, all other things being equal.
    How to treat : one of the important tasks of SM is to make a group of people a team, i.e. to grow a team and make it mature ( when SM stands apart and is moved ). To do this, you need to spend as much time with the team as possible, notice the conflicts so that they can be resolved and not allowed to develop, understand how communications are built ( if sitting next to each other do not speak, but write each other an email - this is alarming). SM should demonstrate real-life advantages of live communication over correspondence. He must get to the root causes of conflict and disagreement and help people negotiate with each other. A useful analysis tool is to build a communication graph ( set as vertices of each team member, and edges are every fact of communication ), analyzing it, you can look for weaknesses in communications ( for example, communication through one team member - he has a narrow neck ; or lack of communication between specific pairs of people). On its basis, it is possible to create situations for “leveling” communications in which you unite “uncommunicating” people; and vice versa, you exclude from certain situations a person in whom communication is closed. It is useful and interesting to follow the dynamics of the development of such a graph.


    Symptom : SM does not develop the team, does not offer constant changes, does not lead the team out of the comfort zone, does not support the initiatives, but is content with the current successes: “We are great! We are a team! ”
    Than bad : If SM is not the engine of change ( and development ), then most likely its team will degrade. Any participants in the process can push for changes, but this is not worth counting on. Without changes in an attempt to improve, the team will eventually lag behind the requirements. Agile is about the ability to quickly adapt to change.
    How to treat: SM should initiate changes, suggest trying new things in processes, tasks, implement engineering practices. You can not stay in a state of rest, you need to look for opportunities for improvement. To understand what changes are being made and what state they are in, you can increase transparency and visualize the process. Working with a team and developing it is the same job as creating a product. SM can start his own board on which he will place experiments, action items with retrospectives, initiatives, etc. The absence of changes on the board can be an indicator of SM stagnation. While working with the team for a long time, SM can blur his eyes, there is a threat to stop seeing opportunities for improvement, then you can either leave the team alone for a while (on the one hand, this is useful for SM, on the other hand, it is a good check on the maturity of the team, how they will behave in the absence of SM ), or ask for outside help, for example, to negotiate with the neighboring team SM for a while to help each other find growth points .


    Symptom : SM allows you to work not on scrum, calmly refers to sabotage. For example:
    "- yes, it seems like the sprint went without fakapov, let's not hold a retro, what to discuss then?
    - ok, we will hold it next time."
    Than bad: If SM does not uphold the purity and necessity of scrum in front of a team, PO, company, then it is unlikely that anyone else will do it. If the principles are not protected, then there is no sense of their importance and usefulness. SM is supposed to be very adaptive and loyal to any changes. Good SM doesn't say no, he says let's try. Let's make an experiment. ” But with respect to the principles of the scrum framework, you need to be persistent and clearly understand what artifacts, events, rituals, values ​​and other elements of scrum are and what they are for, what tasks they solve. The framework is being changed by already mature teams; at the stage of becoming a scrum, one should not give up slack and move away from the scrum guide ( violating one of the rules raises a reasonable question: why not break another? ).
    How to treat: one of the SM's objectives is to monitor the “cleanliness” of the scrum, and, until the team reaches maturity, it must put down all riots and sabotage aimed at the scrum. SM is useful to conduct exercises on the interaction with skeptics. It is good to find a savvy “skeptic,” for example, a colleague SM and do exercises with him: ask him to sabotage the scrum, and SM should parry. You need to be ready to answer questions, why do we conduct scrum events, what's wrong, if we miss one of the events, why do I ( a team member ) do something. If SM himself does not know the answers, then it is worth contacting the community, attending the training, read the literature.


    Symptom : SM issues orders to team members, behaves like a policy maker. This can happen if the role of the SM was given to the former line manager without explaining what should change in the work, approaches, and communications.
    What is bad : When SM senses power and begins to behave as a director-in-chief ( distribution of tasks, broadcasting at meetings, etc. ), it kills teamwork, demotivates people, and this is no longer a scrum. You can put an end to self-organization.
    How to treat: A good option is to send such an SM to a training session, where he will be told about the agile culture, will be given new tools for working with the team. Another more difficult option is for the team itself to try to change communication with SM: build a dialogue, take responsibility when making local decisions, and offer alternatives to SM solutions. You can also think about moving the role to another member of the team.


    Interaction with the company


    Symptom : Scrum master does not share agile values. This culture is not close to him, he himself adheres to other views. This happens if the SM appointed a person, and not he himself showed a desire to fulfill this role.
    What is bad : If a person does not believe in the culture of agile, does not share values, but he is SM, then most likely he pursues very selfish goals, and is unlikely to be able to benefit the team, product, company in these conditions.
    How to treat: We are looking for / educating / teaching SM, who understands and shares the values ​​of agile, and realized scrum: what is being done and what is it for. We assign him the task of running scrum, giving the command, PO, product. It is important to understand the challenges that scrum faces in an organization. It is necessary to immediately determine how we will understand that scrum works, how we will evaluate it, with the help of which metrics.


    Symptom : SM does not organize the exchange of experience between teams. Does not translate the success of the team to the level of the company. Does not provide transparency of the results and processes of his team for the entire organization.
    What is bad : the team exists within the company, it has a high degree of autonomy, but is nevertheless closely connected with the company. If a team is closed on itself, then it may break away from the realities of the company, it may become unnecessary or irrelevant, there may be unjustified expectations in both directions, etc.
    How we treat : It all depends on the level of agile in the company and the tasks facing the team. In general, this is a very large range of options, but consider the simplified cases:

    • Pilot team at a company that thinks about scrum applications : This is a real challenge for SM. His team is under the watchful eye of the whole company. How to proceed:
      1. Finding out ( possibly developing together with the initiators of the changes ) what task does scrum have in the company? What is the "pilot" running for? What hypothesis is tested? How will the result be assessed? Agree on the duration of the experiment and the decision point about the fate of scrum in the company.
      2. Carry this information to the team. Develop visualization of indicators that the company is going to follow. Regularly update visual indicators.
      3. To work as openly as possible. To enable employees of the company to observe new processes for the company, but not to the detriment of the team. Regularly inform on the progress of the entire company.
      4. By the deadline, prepare data on the results obtained during the experiment (the work of the pilot team ). Conduct an extensive retrospective on the decision of the fate of scrum in the company.
    • One of the teams in the company, where some of the employees work on scrum, and some do not : Most likely the company is in the process of transition. And SM should help the entire company transition to scrum. What can be done in this case:
      • Maintain transparency regarding the processes and results of the team, disseminate this information within the company ( open sprint review, newsletters, etc. ).
      • To organize the SM league, where to “pollinate” each other with fresh ideas and practices. Share experiences and support each other.
      • Together with other SM fight organizational dysfunctions .
      • Take part in the work of non-scrum employees, train them with scrum, suggest changes in their processes ( if a change can lead to improvement ).

    • The team in the company is fully working on Scrum and using various scrum scaling methods: LeSS , SAFe , Nexus , etc. : Here on SM shoulders comes the issue of command synchronization. I have no real experience in such companies, so I refrain from offers. But it would be very interesting to read about your experience - write in the comments.

    Conclusion


    Let me briefly remind you once again ( see the conclusion of the first part ) what to do with the information received:

    1. choose the most relevant symptom for yourself;
    2. discuss with the team its negative impact, as a starting point for the reasoning, take my theses;
    3. team come up with ways to remove the symptom;
    4. do what you come up with;
    5. analyze the results;
    6. Repeat from the first item.

    In three articles I managed to describe the most obvious symptoms of roles in scrum. In this case, the description of the roles in the scrum guide takes 3 of 19 pages. The scrum guide says “what” to do, but leaves it to the discretion of the “how-to” commands, because it depends a lot on the situation. It seems to me that it is important to share your experiences and practices of how you do it. I want to believe that the material turned out to be useful and you adopted the “medical” cards described in this series of articles.

    Thank you so much for the illustrations, Sai Kin !

    Tags:

    Also popular now: