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.
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 not directly related to the team’s activities. Or, inside the team, people are not free in the choice of work 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 the job description, hierarchy of subordination, etc., this prevents him from revealing. The power of the scrum team in the possibilities 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 or 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 in no way violates them (
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 question to those who have decided to introduce scrum and agile transformation. You can try to run a flat structure, as 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 treat : We need to ensure that the people included in the team, worked 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 of the 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 it 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 is bad : If a team depends on the competencies of one of its members, it is a team that is not resistant to change. 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 the specified proportions of the team’s competencies, therefore it is difficult to assemble a balanced sprint; In such a scheme, a “narrow neck” necessarily occurs, reducing the overall speed of the team.
What to do : You need to promote and maintain t-shaped skills. 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 the team has little effect on the delivery of the increment ( product release ), then the scrum also loses its essence: the releases occur with a delay, the 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 simply will 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 : Determine what competencies the team lacks to deliver the increment. We endow the team with these competencies by training existing team members, or adding new players to the team. Since 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 member of the team; set up effective communication with another team, etc. ), we hang the solution over the previously missing competence. Over time, the team should strive to extend its functionality 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 coming from different angles.
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 : A team must have its own product with a backlog and PO, which can ignite a team with a product and carry it along - this is 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 the other “customers” work the same way. 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 is 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 them 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 the 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. In the process of transition from directive management models to agile, there is a danger of getting stuck in the understanding of the team as a functional unit (the team had 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: a quick decision was made 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 date ), 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 determine the formats of scrum artifacts and make them ( you can devote to this retrospective ), and then place them so that the team will be 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 ), then you need to create the effect of command and unity as much as possible. 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:
- Select symptoms applicable to your situation.
- From them choose the sharpest.
- Realize this pain.
- You come up with a solution with the team ( you can take cases from the article as a starting point ).
- Implement your decision.
- 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 Scrum Wizard