Scrum implemented, agile - forgot
Recently, I was lucky enough to start working with one relatively rather large company (~ 100 people), where, as the employer put it, “individually, all are good specialists, and it’s impossible to work together”. Well, I think, I just specialize in creating teams, let me think, I will help as much as I can. We talked at an interview on the topic of a common understanding of the company's objectives, on the conditions under which successful joint work is possible, on maximizing the use of employee competences and engaging in a common cause. It would seem that the thoughts we have with the employer converge, but I keep my ear on my own - I know about the negative reputation of the company among potential applicants in the city. Well, the more interesting the task!
The company has already tried to implement scrum, in the beginning it earned, but then something went wrong and it disappeared. As a result, they returned to a hierarchy like the following: the head of the department, the leader’s ideas, the heads of testing, development and analytics teams with manual task distribution and the narrow responsibility of each employee.
First of all, of course, it was required to diagnose - why the scrum did not actually work. I chose two diagnostic methods: a survey and a study through a minor change.
')
The survey showed the separation of people into unequal groups:
The essence of the study is to poke and look at the reaction.
A minor improvement in the way of life came under attack: the kitchen, a starter's set for a beginner, mugs with corporate symbols, headphones, vitamins, office. These changes were justified by the need to work on the corporate culture: to raise the company's reputation in the city and increase employee loyalty with care. “Hobby” was intentionally shown off in order to provoke a more intense reaction from both the top leaders and the rank and file participants.
In the process of introducing minor changes faced with interesting facts:
In the course of research, I realized that the problems of the unit where I was brought are not at all in the department, but in the entire company entirely - in the accounting department, in the economic part, in the top management, in the ordinary employees. The problem is simply evenly distributed throughout the company. Then I realized that you need to dig in the direction of such an omnipresent substance as corporate culture. I tried to formalize the manifestation of the corporate culture and its essence, as Edgar Shane advised. 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's participants. Since This was my first analysis of corporate culture, please treat its results condescendingly.
Artifacts:
Declared values:
Basic views:
The image below illustrates my attitude to the implementation of scrum in the context described above.
Recently I came across a selection of various manifestos related to software development. Then, having looked at them all, I confirmed that the basis of any agile framework is the maximum use of the competencies of each employee. Here we must make a small digression, so that we all equally imagined agile. Agile is not only a way to manage tasks and requirements, and its essence is not in iterations. Its essence is in continuous adaptation of everything to everything: requirements, communications, tools, processes, etc. - the term “self-organizing team” is not somewhere near the term “agile”. So, continuous adaptation can be achieved only in special conditions, with special relations in the team:
Agile is possible only in conditions where each person is important. If this is not the case, then even applying all the practices of scrum, you will get just a task management tool, but this 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 the structure of the company - within five years it’s time for you to be in a landfill. Naturally, we are talking only about software development; in factories, the relevance of processes is lost much slower (this assumption). Agile is a group state in which it is constantly changing to adapt to constantly changing conditions. The state of agile is in the understanding that as soon as you stop developing and stop experimenting, you immediately begin to become irrelevant and the day is not far off when your company collapses.
Now back to the company under study. As soon as you were refused two times without an intelligible, in your opinion, explanation of the reasons, once you raised your voice a couple of times, as soon as you were left alone with your working problems and did not help in a critical situation, there is no talk of any agile is coming After all, you will no longer openly talk about problems (because the problem is people who ask you about problems), you will not take the initiative (you have already tried, but were at least ignored), you will not help your colleague (he did not help you), and the development of a company or a separate team is out of the question. Alas - you already smell bad and in some places were covered with dead spots.
So ... using scrum, don't forget about agile!
Collection of information
The company has already tried to implement scrum, in the beginning it earned, but then something went wrong and it disappeared. As a result, they returned to a hierarchy like the following: the head of the department, the leader’s ideas, the heads of testing, development and analytics teams with manual task distribution and the narrow responsibility of each employee.
First of all, of course, it was required to diagnose - why the scrum did not actually work. I chose two diagnostic methods: a survey and a study through a minor change.
')
The survey showed the separation of people into unequal groups:
- A small part of the staff was under heavy negative pressure. They expressed an extreme degree of negativity towards the leadership and towards each other.
- Approximately one third simply did not believe the leadership that something could be changed. During their time at the company, they had already experienced a couple of job seekers and hadn’t seen any measures from the management that would have helped to avoid future work.
- A third did not see any problems, was surprised when I said that they were 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 they just somehow worked.
- There were also a couple of people who were quite positive about their work, they were actively and passionately fulfilling their duties.
Research through a minor change
The essence of the study is to poke and look at the reaction.
A minor improvement in the way of life came under attack: the kitchen, a starter's set for a beginner, mugs with corporate symbols, headphones, vitamins, office. These changes were justified by the need to work on the corporate culture: to raise the company's reputation in the city and increase employee loyalty with care. “Hobby” was intentionally shown off in order to provoke a more intense reaction from both the top leaders and the rank and file participants.
In the process of introducing minor changes faced with interesting facts:
- The inertness of specific officials — even after an agreement was reached, of their own will, very few people did something; they all had to be actively pedaled.
- Some officials reacted to the changes being introduced frankly negatively - although they nodded or simply kept silent when talking face to face.
- Some minor changes, such as vitamins, he himself had to say.
- Some ordinary employees took my initiatives positively, some sharply negatively.
- Some ordinary and not only staff members told me that they were proposing the same thing as me, but were at least ignored.
Preliminary findings
In the course of research, I realized that the problems of the unit where I was brought are not at all in the department, but in the entire company entirely - in the accounting department, in the economic part, in the top management, in the ordinary employees. The problem is simply evenly distributed throughout the company. Then I realized that you need to dig in the direction of such an omnipresent substance as corporate culture. I tried to formalize the manifestation of the corporate culture and its essence, as Edgar Shane advised. 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's participants. Since 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 proposals and initiatives.
- Some rules for working with jira and git for all departments.
- Personal involvement in the coordination of vitamins and headphones of his own.
- Ban the spread of negative information.
- No free post information.
- Lack of mutual assistance.
- Lack of initiative from employees with rare exceptions.
- Hard work schedule.
- Congestion of managers.
Declared values:
- The most important thing is the client.
- Subordination.
- Regulations.
- Standardization.
Basic views:
- It is easy to replace a person.
- People do not want to work on their own.
- Life does not affect production.
- The strength of the organization lies in its regulations.
- Decisions are made only by managers.
- The staff are incompetent.
Was there a scrum?
The image below illustrates my attitude to the implementation of scrum in the context described above.
Recently I came across a selection of various manifestos related to software development. Then, having looked at them all, I confirmed that the basis of any agile framework is the maximum use of the competencies of each employee. Here we must make a small digression, so that we all equally imagined agile. Agile is not only a way to manage tasks and requirements, and its essence is not in iterations. Its essence is in continuous adaptation of everything to everything: requirements, communications, tools, processes, etc. - the term “self-organizing team” is not somewhere near the term “agile”. So, continuous adaptation can be achieved only in special conditions, with special relations in the team:
- Initiatives are important and welcome.
- The problems of the individual - 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, learn quickly, improve quickly.
- Each person’s professional goals are known and accounted for.
- Trust is at the heart of team relationships.
- Free expression of opinion.
- Psychological security (according to google is the main factor in the success of projects and teams).
Agile is possible only in conditions where each person is important. If this is not the case, then even applying all the practices of scrum, you will get just a task management tool, but this 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 the structure of the company - within five years it’s time for you to be in a landfill. Naturally, we are talking only about software development; in factories, the relevance of processes is lost much slower (this assumption). Agile is a group state in which it is constantly changing to adapt to constantly changing conditions. The state of agile is in the understanding that as soon as you stop developing and stop experimenting, you immediately begin to become irrelevant and the day is not far off when your company collapses.
Now back to the company under study. As soon as you were refused two times without an intelligible, in your opinion, explanation of the reasons, once you raised your voice a couple of times, as soon as you were left alone with your working problems and did not help in a critical situation, there is no talk of any agile is coming After all, you will no longer openly talk about problems (because the problem is people who ask you about problems), you will not take the initiative (you have already tried, but were at least ignored), you will not help your colleague (he did not help you), and the development of a company or a separate team is out of the question. Alas - you already smell bad and in some places were covered with dead spots.
So ... using scrum, don't forget about agile!
Source: https://habr.com/ru/post/344444/
All Articles