Treatment of "mechanical" Scrum. Part 2. The team

In first part we examined the alarming symptoms and possible ways of "treating" the Product Owner in a "mechanical" scrum. We continue the parsing of the roles and the next one on the queue is the team.
 
Still know the mantra that the team must be self-organized and cross-functional, it looks like the simplest part of the scrum: we take people with the necessary competencies, say to them: "you are a team," and flew! But in reality everything is somewhat more complicated.
 
Treatment of "mechanical" Scrum. Part 2. The team
 
bus factor . [/i]
 
Than bad : If the team depends on the competencies of one of its members, this is an unstable team. Build communication with it is difficult, because. you need to understand its current functionality and remember the risks associated with this level of fault tolerance. The narrow specialization of developers greatly complicates the organizational work for the team: when planning, you need to think a lot about who will do what and what; not every task needs the specified proportions of the team's competencies, therefore, it is difficult to collect a balanced sprint; in such a scheme there is necessarily a "narrow neck", which reduces the overall speed of the team.
 
What to do : We need to promote and support t-shaped skills. For the team to remain flexible, it is important that a particular function or knowledge is not concentrated in one person. It is necessary to stimulate and encourage constant development. It is important to ensure that the team is improving, looking for ways to improve processes. As options for t-shaped development: conducting internal seminars, where team members share knowledge with each other; accept the rule of performing a non-core task each sprint by each team member; pair work on tasks, etc. You can artificially stimulate the team, "turning off" its members for a while: holidays, seminars, trainings, business trips, etc.
 
 
Symptom : In the chain of value creation, the team responds (exerts influence) only for a small part of it, and as a consequence, the team can not release the increment itself.
 
Than bad : If a team has little effect on the delivery of the increment ( release product), then the scrum is also losing its essence: releases occur with a delay, feedback occurs with even greater delay. In general, there is no rhythm, and hence speed. No speed - no flexibility. Such a team does not feel its ownership, it's just a functional screw in a big machine. The functionality of the team should be enough to close the greater part of the value creation chain, otherwise the team will simply not deliver value, but simply one type of "procurement" will be processed into another and transferred further.
 
Let's illustrate this with an example from the web. Where it is simplified to create a new feature includes the following stages:
 
 
development of UI /UX prototype
 
development of design
 
creation of RESTful API
 
the creation of SPA
 
writing integration tests
 
assembling and pouring into the combat environment
 
 
Different competencies are required for these works. Example of unsuccessful division into commands: allocate command A from UI /UX, designers and frontend development, they prepare their increment in the form of SPA; but they depend on when backend prepare the API for the new functionality; wait for QA to test everything integrally and write tests; and then still expect DevOps, so they rolled everything into battle. Such a team A it is difficult to answer for the release and delivery of value, it just saws the "harvesting" - SPA.
 
How to treat : We determine what competencies the team lacks in order to deliver the increment. We empower these competencies by training existing members of the team, or by adding new players to the team. Because find /teach people - is not the most simple and fast, it is possible to establish communication with neighboring teams /departments, explaining to them the value of scrum, and agreeing with them about special regulations /rules of interaction in which they will not break your scrum team. It's worth highlighting the process of expanding the functionality of the team: after the first retrospective and identifying the missing competencies, you can print them out and place them before the team. When the team cope with the lack of competence (. learned, a new member of the team, set up effective communication with the other team, and so ), The top of the previously lacking competence hang solution. Over time, the team should strive to expand its functionality to fully cover the value chain.
 
 

Team and product


 
Symptom : The team is there, but there is no product. No PO, no backlog. It's just that people do tasks coming from different directions.
 
Than bad : This is not a scum. When the team is not fixed product, the team is unlikely to "burn" work. When there is a global goal ( [/u] ? vision /strategy /roadmap of product development [/i] ), Then you want to go to it. You do the work, get feedback, reflect and take the next step. Without a sense of involvement, you run the risk of being in a routine: you do not really need feedback, the team becomes simply a tool for processing TK in the functional.
 
How to treat : The team should have a product with a backlog and a PO that can light a team with a product and carry it along with it - that's the point. We need to understand why you need scrum? Understand where the team get the tasks? 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 is , giving him the sole right to be responsible for the backlog. You may have to divide the teams scrum team works with a PO ( It can be «Pilot» scrum team. ) And the second team, while working in the old way with the rest of "customers." Providing maximum transparency of the processes and results occurring in the new scrum team, you can lay the basis for further distribution of scrum and agile in the organization.
 
 
Symptom : The team has no influence on the product component: it does not decide, "how do?", The team is simply told "what to do?", I.e. TK comes into the input, and the team is treated as a functional unit.
 
Than bad : This is a very dangerous option, if the company really declares the values ​​of agile and scrum. Usually this means that all employees are great professionals, able to solve any problems that are not afraid to make decisions and take responsibility. But if you are not allowed to make grocery decisions, then all the creative freedom of the team is usually transferred from the product to the technology. Once 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 interests between PO and the team, the team begins to sell "refactoring", "optimization", "silver bullets" in the form of a new stack, etc. A suffer from this primarily the user and the product. In the process of transition from directive management models to agile, there is a danger of getting stuck in understanding the team as a functional unit ( , The team did not make the decision before.). This is fraught with the fact that either we kill the initiative of the team, or we will 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 to the team or its indecisiveness: why the team is not looking for a solution, but works only with a detailed technical task? Finding the reason, you can gradually eliminate it. For example:
 
 
The team lacks competencies or expertise. : Someone is working out solutions and writing TK, you can either add this person to the team, or allow him to work on some tasks together with the team, thereby transferring part of his skills and experience to the team. So gradually the team will learn and get used to solve food problems.
 
The leadership has a fear that the team will make a mistake. : This is a cornerstone of the transition to agile, but without overcoming it, you will not be able to acquire the full strength of the scrum team. The team is bound to make a mistake, because everyone is mistaken. But error is the source of experience and skill. It is more useful when the team makes a mistake, because it has decided so, and not because of an incorrect external TK. Scrum is a rhythm: quickly made a decision to test the hypothesis; received feedback; realized that they did not go there; threw out the solution. The cost of the error is dramatically reduced ( spent a sprint, not quarter /year /your release date is ), Which allows you to overstep the fear of error.
 
 
 
Symptom : Team members do not have free access to team artifacts. For example, not everyone sees a sprint or common backlog, or there are difficulties with the possibility of updating its state.
 
Than bad : Scrum is based on transparency, artifacts help 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 the remaining stakeholders, the situation will be even worse: it is not clear who does what and why. It is not clear where the team is on the way to the goal.
 
How to treat : You need to define the scrum artefact formats and make them ( [/u] ? you can dedicate this retrospective to [/i] ), And then place it so that the team can work with them comfortably. Great, if it turns out 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 the general space it's easy to visualize everything ( flipcharts, stickers, markers are your favorite agile tools ), The main thing is that it's convenient, non-stressing for the team. Artifacts should help, not hinder the work of the team, not bureaucratize it. Verbal interaction is good for teamwork. If there are difficulties with organizing the local work of the command ( [/u] ? for example, distributed or remote [/i] ), Then you need to create the maximum effect of a comaunity and unity. For example, the channels of video presence, interactive scrum boards in immediate visibility to each member of the team, etc.
 
 

Conclusion


 
In the next part, we will continue to consider the role of scrum, and finally get to the scrum master. Briefly recall , what do you do with the symptoms:
 
 
Select the symptoms that apply to your situation.
 
Of them, choose the most acute.
 
Realize this pain.
 
You come up with a solution ( , For a starting point, you can take cases from the article ).
 
Realize your decision.
 
Go to item 1.
 
 
Thanks for reading, I would like to see the "symptoms" you know in the comments.
 
 
Thanks Sai Kin for illustrations.
 
+ 0 -

Add comment