
Scrum implemented, agile - forgot
Recently, I was lucky enough to start working with one relatively rather big company (~ 100 people), where, as the employer put it, “individually, all are good specialists, but it doesn’t work together.” Well, I think I’m just specializing in creating teams, give, I think, help as much as I can. We talked at an interview on a common understanding of the company's goals, on the conditions under which successful joint work is possible, on maximizing the use of employees' competencies and on involvement in a common business. It would seem that the thoughts with the employer agree, but I keep my eyes open - I know about the negative reputation of the company among potential job seekers in the city. Well, the more interesting the task will be!

The company has already tried to implement scrum, in the beginning it worked, but then something went wrong and it came to naught. As a result, we returned to a hierarchy like this: the head of the direction, the deputy head, the leaders of the testing, development and analytic groups with manual distribution of tasks and the narrow responsibility of each employee.
The first thing, of course, was to diagnose why scrum actually didn’t work. I chose two diagnostic methods: survey and research through a slight change.
The survey showed the division of people into unequal groups:
The essence of the study is to poke and look at the reaction.

Mostly a minor improvement in everyday life came under attack: a kitchen, a beginner’s starter kit, mugs with corporate symbols, headphones, vitamins, an office. These changes were justified by the leadership of the need to work on a corporate culture: to increase the reputation of the company in the city and to increase the loyalty of employees by taking care. "Poking" was deliberately flaunted in order to provoke a more intense reaction of both the leadership and ordinary participants.
In the process of introducing minor changes, I came across interesting facts:
In the course of my research, I realized that the problems of the unit where I was brought in are not at all in the unit, but in the whole company - in accounting, in the business unit, in senior management, in ordinary employees. The problem is simply evenly distributed throughout the company. Then I realized that you need to dig towards such an ubiquitous substance as corporate culture. I tried to formalize the manifestation of corporate culture and its essence as advised by Edgar Shane. I tried to describe the artifacts (external manifestations) of the corporate culture, the declared values and get to the bottom of the basic ideas of the company participants. Because this was my first analysis of corporate culture, please treat its results condescendingly.
Artifacts:
Proclaimed values:
Basic views:
The image below illustrates my attitude to scrum implementation in the context described above.

Recently I came across a selection of various manifestos related to software development. Then, having looked at all of them, I established myself that the basis of any agile framework is the maximum use of the competencies of each employee. Here we need to make a small digression so that we all equally imagine agile. Agile is not only a way to manage tasks and requirements, and its essence is not in iterations. Its essence is the continuous adaptation of everything to everything: requirements, communications, tools, processes, etc. - not for nothing somewhere near the term “agile” is the term “self-organizing team”. So, continuous adaptation can be achieved only in special conditions, with special relationships in the team:
Agile is possible only in conditions where every person is important. If this is not the case, then even applying all the scrum practices, you will get only a task management tool, but it will not be agile. Agile does not imply any particular static structure or frozen processes, no, by no means. If suddenly you are happy to discover that you have invented the ideal processes and structure of the company - in less than five years you should go to a landfill. Naturally, we are only talking about software development; in factories, the relevance of processes is lost much more slowly (this assumption). Agile is the state of a group in which it is constantly changing in order to adapt to constantly changing conditions. The state of agile is to understand that as soon as you stop developing and stop experimenting,
And now back to the company under study. As soon as you were refused twice without a clear, in your opinion, explanation of the reasons, as soon as you were raised a couple of times, as soon as you were left alone with your working problems and did not help in a critical situation - there’s no more talk about agile is coming. After all, you will no longer openly talk about problems (because the problem is the people who ask you about the problems), you will not take the initiative (you have already tried, but were at least ignored), you will not help your colleague (he’s didn’t help you), and there is no longer any talk about any development of the company or an individual team. Alas - you already smell bad and in places covered with cadaverous spots.
So ... when using scrum, don't forget about agile!

Collection of information
The company has already tried to implement scrum, in the beginning it worked, but then something went wrong and it came to naught. As a result, we returned to a hierarchy like this: the head of the direction, the deputy head, the leaders of the testing, development and analytic groups with manual distribution of tasks and the narrow responsibility of each employee.
The first thing, of course, was to diagnose why scrum actually didn’t work. I chose two diagnostic methods: survey and research through a slight change.
The survey showed the division of people into unequal groups:
- A small part of the employees was pressed by a strong negative precipitate. They expressed an extreme degree of negativity with respect to leadership and to each other.
- About a third simply did not believe the leadership and that something could be changed. During their work in the company, they have already experienced a couple of rummages and have not seen from the management measures that would help to avoid rummage in the future.
- A third did not see problems, I was surprised when I said that they are sitting in the same office, with people who see GREAT problems.
- And the rest are students. They did not know what is good and what is bad, and therefore simply worked somehow.
- There were also a couple of people who were quite positive about work, actively and enthusiastically fulfilled their duties.
Research through a minor change
The essence of the study is to poke and look at the reaction.

Mostly a minor improvement in everyday life came under attack: a kitchen, a beginner’s starter kit, mugs with corporate symbols, headphones, vitamins, an office. These changes were justified by the leadership of the need to work on a corporate culture: to increase the reputation of the company in the city and to increase the loyalty of employees by taking care. "Poking" was deliberately flaunted in order to provoke a more intense reaction of both the leadership and ordinary participants.
In the process of introducing minor changes, I came across interesting facts:
- The inertia of specific officials - even after reaching an agreement on their own, few did something, everyone had to actively pedal.
- Some officials reacted to the changes being introduced openly negatively - although during a face-to-face conversation, they either nodded or simply were silent.
- Some minor changes like vitamins should have been personally claimed by Himself.
- Some rank-and-file employees took my initiatives positively, some acutely negatively.
- Some ordinary people and not only employees informed me that they offered the same thing as I did, but were at least ignored.
Preliminary findings
In the course of my research, I realized that the problems of the unit where I was brought in are not at all in the unit, but in the whole company - in accounting, in the business unit, in senior management, in ordinary employees. The problem is simply evenly distributed throughout the company. Then I realized that you need to dig towards such an ubiquitous substance as corporate culture. I tried to formalize the manifestation of corporate culture and its essence as advised by Edgar Shane. I tried to describe the artifacts (external manifestations) of the corporate culture, the declared values and get to the bottom of the basic ideas of the company participants. Because this was my first analysis of corporate culture, please treat its results condescendingly.
Artifacts:
- We tried it, it does not work - a frequent response to suggestions and initiatives.
- Some rules for working with jira and git for all departments.
- Personal participation in the coordination of vitamins and headphones of Himself.
- Prohibition of the dissemination of negative information.
- There is no free post information.
- Lack of mutual assistance.
- Lack of initiative from employees with rare exceptions.
- Tough work schedule.
- Overloaded managers.
Proclaimed values:
- The most important thing is the client.
- Subordination.
- Regulations.
- Standardization.
Basic views:
- The person is easy to replace.
- People do not want to work of their own free will.
- Life does not affect production.
- The strength of the organization lies in its regulations.
- Only managers make decisions.
- The staff is incompetent.
Was there a scrum?
The image below illustrates my attitude to scrum implementation in the context described above.

Recently I came across a selection of various manifestos related to software development. Then, having looked at all of them, I established myself that the basis of any agile framework is the maximum use of the competencies of each employee. Here we need to make a small digression so that we all equally imagine agile. Agile is not only a way to manage tasks and requirements, and its essence is not in iterations. Its essence is the continuous adaptation of everything to everything: requirements, communications, tools, processes, etc. - not for nothing somewhere near the term “agile” is the term “self-organizing team”. So, continuous adaptation can be achieved only in special conditions, with special relationships in the team:
- Initiatives are important and welcome.
- The problems of an individual are the problems of the whole team.
- Experiments are strongly supported.
- Mistakes are inevitable. Moreover, they are useful because with their help, the team gains experience. We quickly make mistakes, we quickly learn, we improve quickly.
- The professional goals of each person are known and taken into account.
- Trust is at the heart of team relationships.
- Free expression of opinion.
- Psychological safety (according to google, this is the main factor in the success of projects and teams).
Agile is possible only in conditions where every person is important. If this is not the case, then even applying all the scrum practices, you will get only a task management tool, but it will not be agile. Agile does not imply any particular static structure or frozen processes, no, by no means. If suddenly you are happy to discover that you have invented the ideal processes and structure of the company - in less than five years you should go to a landfill. Naturally, we are only talking about software development; in factories, the relevance of processes is lost much more slowly (this assumption). Agile is the state of a group in which it is constantly changing in order to adapt to constantly changing conditions. The state of agile is to understand that as soon as you stop developing and stop experimenting,
And now back to the company under study. As soon as you were refused twice without a clear, in your opinion, explanation of the reasons, as soon as you were raised a couple of times, as soon as you were left alone with your working problems and did not help in a critical situation - there’s no more talk about agile is coming. After all, you will no longer openly talk about problems (because the problem is the people who ask you about the problems), you will not take the initiative (you have already tried, but were at least ignored), you will not help your colleague (he’s didn’t help you), and there is no longer any talk about any development of the company or an individual team. Alas - you already smell bad and in places covered with cadaverous spots.
So ... when using scrum, don't forget about agile!