Treatment of "mechanical" Scrum. Part 2. Team

    In the first part, we looked at the alarming symptoms and possible ways to “treat” the Product Owner in a “mechanical” scrum. We continue the analysis of the roles and the next in line - the team.
    Everyone knows the mantra, that the team should be self-organized and cross-functional, it looks like the easiest part of the scrum: we take people with the right competencies, tell them: “you are a team,” and fly! But in fact, everything is somewhat more complicated.


    image

    Self-organization


    Symptom : There is an explicit hierarchy (directory submission) outside, or worse, within the team. Those. in fact, a product developer may come up with a task that is not directly related to the team’s activities. Or, inside the team, people are not free to choose a job to achieve the goal of the sprint, but receive tasks from the “manager”.
    What is bad :

    Any boundaries - limit @ CEP
    When a person is clamped down by a job description, hierarchy of subordination, etc., this prevents him from revealing. The power of the scrum team in the opportunities that people face. There is a task, take courage and answer for its implementation. The person must decide for himself what he will do to achieve the goal of the sprint. If he is told what to do, then this is not self-organization and no scrum.
    How to treat : For people in a team, all job descriptions and hierarchies are canceled, the structure tends to be flat. All who are in the team are product developers (the scrum guide does not allow other roles). There is only situational leadership, and people themselves decide how they can work comfortably to be effective. Of course, there are general rules of the game in the company, the team does not violate them in any way ( although it can influence change at the company level ), but it is responsible for all internal things. If there are serious obstacles to the abolition of restrictions for developers, then it is worth escalating the issue to those who have decided to introduce scrum and agile transformation. You can try to run a flat structure, like an experiment on several sprints, and then hold an extensive retrospective, where all interested parties discuss the results of the experiment.

    Symptom : People, in addition to teamwork, must perform other functional duties in the company. For example: 50% of the time performs the tasks of the team, 50% of the tasks of the department (development, testing, etc.).
    What is bad : One of the values ​​in scrum is focus. The team focuses on the goal of the sprint and moves towards it. If, in addition to teamwork, a person has to do something else, then the focus is lost. As a result, the result will be worse. It is difficult to maintain team spirit in such conditions.
    How to treatA: It is necessary to ensure that people entering the team work ONLY in this team. To do this, it is worth understanding the nature of the work, the team that fell on the developers from the outside, and find ways to do it without breaking the scrum. Surely this work is necessary for the company, so depending on the specifics of the work, you can:

    • or put the work in the backlog team, and then it will be done on a single workflow.
    • or transfer it to other employees outside the team. For example: not the whole company works on scrum, and you need to do some regular work at a specific time, then such work is no longer suitable for scrum employees.
    • or a special team can be created and a product selected that will bring together all the works of this type.
    • or if this is a unique function that is done by one person for several teams due to the lack of specialists. Then you should take a person out of all the teams and build another process for him that does not break the rest of the scrum ( for example, the priority task queue ) until specialists in these scrum teams are found.

    Cross functionality


    Symptom : People within the team perform only certain work, there is a clear specialization. Worse when it is still covered by official duties, regulations and other bureaucracy. The absence (vacation, sick leave, etc.) of one team member reduces the functionality of the team. Hi, bus factor .
    What's bad: If a team depends on the competencies of one of its members, this is a team that is unstable to changes. It is difficult to build communication with it, because you need to understand its current functionality and remember the risks associated with this level of fault tolerance. The narrow specialization of the developers greatly complicates the organizational work for the team: when planning, you need to think a lot about who will be doing what and what; not every task needs to be given the proportions of the team’s competencies, therefore it is difficult to assemble a balanced sprint In such a scheme, a “bottleneck” necessarily occurs, reducing the overall speed of the team.
    What to do : It is necessary to promote and maintain t-shapedskills. In order for the team to remain flexible, it is important that a specific function or knowledge is not concentrated in one person. It is necessary to stimulate and encourage continuous development. It is important to ensure that the team improves, looking for ways to improve processes. As t-shaped development options: conducting internal seminars where team members share knowledge with each other; adopt a rule for performing a non-core task, each sprint by each team member; pair work on tasks, etc. You can artificially stimulate a team by “turning off” its members for a while: holidays, seminars, trainings, business trips, etc.


    Symptom : In the value chain, the team is responsible (influences) only for a small part of it, and as a result, the team cannot release increments on its own.
    What is bad : If a team has little effect on the delivery of an increment ( product release ), then the scrum also loses its essence: releases occur with a delay, feedback occurs with an even greater delay. In general, there is no rhythm, and therefore speed. No speed - no flexibility. Such a team does not feel its involvement, it is just a functional cog in a large machine. The functionality of the team should be enough to close most of the value chain, otherwise the team will simply not deliver the value, but simply process one type of “stock” into another and pass it on.
    We illustrate this with an example from the web. Where simplified creation of a new feature includes the following steps:

    • development of UI / UX prototype
    • design development
    • creating a RESTful API
    • SPA creation
    • writing integration autotests
    • assembly and pouring on the combat environment

    Different competencies are required for this work. An example of unsuccessful division into teams: select team A from UI / UX, designers and frontend development, they prepare their increment in the form of SPA; but they depend on when the backend prepares the API for the new functionality to work; waiting for QA to check everything integration and write tests; and then they are still waiting for DevOps to roll everything out for a fight. Such a team is difficult to be responsible for the release and delivery of value, it just cuts the “stock” - SPA.
    How to treat: We determine what competencies the team lacks to deliver the increment. We empower the team with these competencies by training existing team members, or adding new players to the team. Because to find / teach people is not the easiest and fastest task, it is possible to establish communication with neighboring teams / departments, explaining to them the values ​​of scrum and agreeing with them about special rules / rules of interaction in which they will not break the scrum of your team. It is worth highlighting the process of expanding the functionality of the team: after the first retrospective and determining the missing competencies, you can print them out and place them in front of the team. When a team copes with a lack of competence ( learned; a new team member; set up effective communication with another team, etc.), then we hang the solution on top of the previously missing competence. Over time, the team should strive to expand its functionality in order to fully cover the value chain.

    Team and product


    Symptom : There is a team, but there is no product. No PO, no backlog. People just do tasks that come from different directions.
    What is bad : This is not a scrum. When a product is not assigned to a team, the team is unlikely to “burn” with work. When there is a global goal ( vision / strategy / roadmap of product development ), then you want to go to it. You do the work, get feedback, reflex and take the next step. Without a sense of involvement, you risk being in a routine: you don’t really need feedback, the team becomes just a tool for processing TK into functionality.
    How to treat: The team must have its own product with backlog and PO, which can ignite the team with the product and carry it along - that’s the essence. You need to understand why you need a scrum? Understand where the team comes from the task? Understand whether there is a “product” among this stream? Choose among the "customers" of the team one and make it the owner of the product , giving it the sole right to be responsible for the backlog. It may be necessary to divide the team into a scrum team working with one PO ( this could be a “pilot” scrum team ) and a second team, as long as it works the same way with the other “customers”. Providing maximum transparency of the processes and results that occur in the new scrum team, you can lay the foundation for the further spread of scrum and agile in the organization.


    Symptom : The team has no influence on the product component: it does not decide “how to do it?”, The team simply says “what to do?”, I.e. TK comes to the input, and the team is considered as a functional unit.
    What's bad: This is a very dangerous option if the company really proclaims the values ​​of agile and scrum. This usually means that all employees are great professionals who can solve any tasks that are not afraid to make decisions and take responsibility. But if they do not allow to make product decisions, then the whole creative freedom of the team usually spreads from the product to technology. Since the team is not allowed to decide how to make the user's life easier, the world is better, and the product is more useful; then the team begins to develop a code base, try new technologies / tools / frameworks, etc. There is a conflict of interest between the PO and the team, the team begins to sell “refactorings”, “optimization”, “silver bullets” in the form of a new stack, etc. And first of all, the user and the product suffer from it.the team has not made a decision before ). This is fraught with the fact that either we kill the initiative of the team, or we come to a situation where the team is more interested in technology than the product.
    How to treat : you need to identify the cause of distrust of the team or its indecision: why the team is not looking for solutions, and works only with detailed technical tasks? Finding the cause, you can gradually eliminate it. For example:

    • The team lacks competence or experience. : Someone is working on solutions and writing TK, you can either add this person to the team, or allow him to work on some tasks with the team, thereby transferring some of his skills and experience to the team. So gradually, the team will learn and get used to solve food problems.
    • The management has a fear that the team is mistaken. : This is the cornerstone fear of the transition to agile, but without overcoming it, you will not be able to acquire all the power of the scrum team. The team will surely make a mistake, because everyone makes mistakes. But error is the source of experience and skill. More useful when the team makes a mistake, because she decided so, and not because of the wrong external TK. Scrum is a rhythm: they quickly made a decision to test a hypothesis; received feedback; realized that they went wrong; threw the decision. The cost of the error is dramatically reduced ( sprint spent, not quarter / year / your release period ), which allows you to step over the fear of error.


    Symptom : Team members do not have free access to team artifacts. For example, not everyone sees the sprint or general backlog, or there are difficulties with the possibility of updating its state.
    What is bad : Scrum is based on transparency, artifacts help to increase transparency. If the team members have difficulty working with these artifacts, then there is no transparency in the teamwork of the team members themselves, and for other stakeholders the situation will be even worse: it is not clear who is doing what and why. It is not clear where the team is on the way to the goal.
    How to treat : It is necessary to define the formats of scrum artifacts and make them ( you can devote to this retrospective), and then place so that the team was comfortable working with them. Well, if you manage to create a separate space for the team, the conditions under which the team will work side by side (shoulder to shoulder) at the same time. This will reduce the overhead of communication. And in a common space it is easy to visualize everything ( flipcharts, stickers, markers are the favorite tools of agile ), the main thing is that it is convenient, relaxed for the team. Artifacts should help, and not interfere with the work of the team, not bureaucratize it. Verbal interaction is good for command. If there are difficulties with organizing the local work of the team ( for example, distributed or remote), you need to create the effect of command and unity. For example, video presence channels, interactive scrum boards are immediately visible to each team member, etc.


    Conclusion


    In the next part, we’ll continue to look at the roles of scrum, and finally get to the scrum master. Let me briefly remind you what to do with the symptoms:

    1. Select symptoms applicable to your situation.
    2. From them choose the sharpest.
    3. Realize this pain.
    4. You come up with a solution with the team ( you can take cases from the article as a starting point ).
    5. Implement your decision.
    6. Go to step 1.

    Thanks for reading, I would like to see the “symptoms” that you know in the comments.

    Thank you Sai Kin for the illustrations.


    The next part about the Scrum Wizard

    Tags:

    Also popular now: