Smooth introduction of scram by the developers themselves (resolving contradictions, setting up a team, avoiding conflicts)

In a repressive management model, a leader will, as a rule, select employees either more stupid than himself, or those whom he can “hypnotize” or blackmail in one way or another. Here they are looking for "dogs" that are easy to control and easy to poison. The idiotic instructions coming down from above will be proxied down without any changes and those who can proxy them below survive, the rest burst.
Is everything so bad with team leadership? To impose scram formally, when no one understands his need, and it is not really felt, or to introduce its elements gradually, so that the team will feel its effectiveness.

Conflicts of interest is a common situation in work teams and not only in programmers. And often there is no right and guilty, there is a clash of experience and visions. How to unleash the potential of all employees and get synergy when 1 + 1 = 11, not 2.

Inspired after the football World Cup. The history of the withdrawal of scrum. All events are fictional, all coincidences are random. Generalized and greatly simplified situation.

So, the team is formed, analyst, fronder, fullstek-bekender. Do not scrum. The team is formed with a fairly competent and diversified and experienced team leader who has broad powers. The management of the company delegates full authority to it.

For the sake of analogy, let's imagine that the project is a football league. the whole team with a file, that is, a failed or permanently protracted project. Success is considered a quality-made and on time delivered product, that is, the top position of the team in the championship based on the results of all games. Games are sprints. Sprint - an iteration in the scram, during which the growth of software is created. Hard fixed in time, like a match in football. Review of the first match (sprint), the situation is quite real.

Getting started on the project (First half, everything goes well, goal scored 1 - 0)

So the whistle, and quite individually experienced players, but not played together, do their work very well. The analyst sets the tasks, the front-endender makes the application on the backend. At first, everything is going well, the layout, the architecture of the project, pages are quickly created, the customer quickly gets results, the team receives feedback from him. Everyone is happy.

The backend is developed separately, the architecture is built, the database is laid, approximate methods are thrown.

Nonclientoriented backend (Dangerous moment, goal, transfers do not go well into the middle zone, 1 - 1)

Analyst showing very good individual qualities, passes the task to the team, the screen and description.


The front-tender, receives the pass, imposes the form, writes the client code, passes the pass to the fulstek-bekender. And he expects something like:

GET / some / method


Fullstek bekender (team captain, he is a team lead) accepted the pass and gives:


As a rule, full steaks have shallow knowledge in areas (just because they are physically unable to reach deep ), but see the whole project as a whole. They are good on small projects where they do everything themselves and are not effective in team development.

There was a pause and bewilderment, when asked why so, silence and ignore, the team leader knows what he is doing. With repeated such transmissions and follow-up questions, why so. Answer: "Trust me, I know what I'm doing, you don't have a vision of the system as a whole." For now draw 1-1. And nothing can be done here, neither the front-end, nor the leadership.

Weak teamwork (Dangerous moment, goal, 2-1 fakap leads)

Fronttender thinks and strains. What you need to throw on the screen? Asks again, but the interaction is not glued. Tim-leader-fullstek-bekender is nervous, pouring answers. "Think!" “It's easier for me to do it myself”, “Kick-Ass”. The game does not stick, the team misses the second goal.

Strengthening by team development (Time is not in favor of the team, 2-1 score is the same)

Frontender little by little guessing about the parameters, learned to predict the direction of the pass, but still there was a marriage in the game. Frontender badly perceives everything aurally, and asks for team development tools (Redmine, Jira, Trello). The guide goes to the meeting. Began to set tasks, such as:

Greeting -> ??? (which field to take from the data)
Parameter1-> ??? (which field to take from the data)
Parameter2 -> ??? (which field to take from the data)

For clarity, the data is cleaned directly from the backend and in an understandable way prokibyvayutsya in html. The game has stabilized, but time is running out, the former account is in favor of the fakap.

Injury, code refactoring, (The team plays, but misses a goal 3-2)

The frontend is injured and leaves the field for some time (planned vacation), at this time the backendant gets into the front code, spends time refactoring it, and heroically unravels the data from the backend directly into html. Quick goal, great! But in response, it receives bugs from the analyst and outstanding tasks for the current sprint. Yes ... the team quickly got a return goal. Becker enters a list of top scorers. Fronttender quickly recovered and again in the game. But since the passes do not go, and the lead leader himself copes, the front is not yet very involved. The final whistle, the match is over. 3-2 team lost, but the next games ahead (sprints).

Sprint Retrospective (Analysis of the first game, fender on the bench)

In the scramble to identify problems in the early stages and flexible self-adjustment of the team, there are retrospectives of sprints that are held by the scrum master (team coach), but since he is not in the club. Fronttender initiates it. Gathers all participants, and explains the fallacy of the refusal of the game in the pass, because one moment can not improve the team's game throughout the championship (the end of the project), and asks all members of the team to speak. In response, the captain of the team - timlid - full-stack, offers to transfer the front-end to another project, since the players' opinions do not care about anyone. The team is silent - the club management too. The transfer has been delayed, the fender is hanging on the bench.

How to act the leadership of the club? Tim leader or scrum master? Open discussions, voicing opinions or sole orders of the team lead. In fact, there is no right answer. To clarify the situation, you need to enter the tester and look at the game in a few more sprints. It all depends on the size of the project.

Epilogue (time passed):

Many thanks for the comments!

What is our life? The game ...
Good evening, in the intellectual club. What? Where? When? The only place where each viewer can earn money with his own mind ...

So, silence in the hall.

Dear experts (scrum). Once again I pay attention that in the article at the very beginning it was clearly emphasized that what the team was doing was not scrum, but only an attempt to print it on the scrambler.
Scrum like poker, he has very simple, but very strict rules. But at the same time, poker and scrum are very difficult games.

Now, attention is the correct answer.

In the process of work, a very simple and basic rule of scram was violated. There are few roles in the scram and they are clearly spelled out. There is no role called timlid. The task of the scrum master is to clearly monitor the implementation of this rule. And stop any attempts to break it. The result, the chaos from the backend went to the front and the project zapakapilsya.

Scrum is a flexible software development framework. The framework is based on an empirical method (based on experience) and is designed to develop high value products in a confusing environment.

Round. 1: 0 - in favor of the viewers. Connoisseurs go on a musical pause ... And prepare for the next round.

Also popular now: