What does agile look like in practice?

Question

Agile

There are several questions about what agile looks like in practice (let's take scrum for clarity). While I understand theoretically, according to books, I would like to ask those who have practical experience - how some (perhaps seeming) problems and contradictions are solved.
one). What is meant by team cross-functionality. "By the book" is required so that each employee can take and complete any task. But it's really not clear how. Here is a real team, for example, a frontender, a backender, a database specialist and an admin. It is proposed to give the admin a javascript code, and to the front to tune the base? So everything will fall apart in a week. I met a clarification that in fact it is necessary to ensure that the team as a whole can complete any task on the project, and let the specialists inside be narrow. But this, of course, imposes serious restrictions on the selection of tasks from the backlog and on the use of statistics.
2). planning poker. The situation - two participants call (and argue) radically different terms. In "traditional" management, this is solved as follows: Signor Vasya says "We'll do it in 6 days", junior Petya says "Enough for 2 days". Petya argues, after which Vasya either listens to him and corrects the assessment, or says "I'm older [UPD: I mean by position], we do as I said." This concludes the discussion with some result. In planning poker, it is proposed to discuss until they agree on some kind of joint assessment. And if they do not agree in two hours, what to do? To say that the task is "incomprehensible" and not to take it to the sprint? Then it turns out that junior Petya blocked an important feature. In all negotiation techniques, there is a plan in case a compromise cannot be reached.
3). Stress Testing. This is such a special type of testing that can take, for example, several days and, as a result, a significant redesign of the architecture may be required. At the same time, when developers implement specific user stories, they do not think about performance, but in general, performance requirements should be imposed on the system. Where is the place for load testing in scrum?
4). Pair programming. Has anyone ever seen this used regularly, and not in the format of "joon looking over the signor's shoulder"? If you saw - tell the name of the company, very interesting.
5). Who (what person) is responsible for the fakap / failures of deadlines and tede. The answer "the whole team" (= no one) is unlikely to please a customer from the real world.
6) Who makes decisions about firing and hiring employees?
It is clear that each of these questions can be answered "Accept the soul of the Agile Manifesto and find the answers in yourself", however, I would like to know how this is solved in practice. I understand that the topic is somewhat holivar, but I would like to avoid answers like "You don't understand agile, go to the janitors" or "All the answers are in Google / such and such a book." The questions are understandable, not for the sake of trolling, but for the sake of knowledge.

Answer 1

1. Well, you yourself write: "Development Teams are cross-functional, with all of the skills as a team necessary to create a Product Increment."
Development Team, as a team, etc.
This means that the team must be correctly selected for the project. The team should be cross-functional, not everyone on it. If you recruited 5 seasoned backend workers, then you don’t need to blame them later that they screwed up with the frontend.
2. Firstly, if the developers argue for 2 hours, or "humiliate" one another, then you have enough problems other than Scrum processes.
3. The same situation as with refactoring. How do you explain that part of the project needs to be rewritten? Those. you have been sculpting some kind of guano all the time, but now you realize? If you are already working on Scrum, then the product owner should be well versed in this. In development, there are always enough tasks that do not provide the visible functionality that they so much want to see on the demo, but such tasks must be included in sprints. + if you have high workloads, then it is necessary to discuss this in advance during planning and add this work either to the story or create a new one in the backlog for the future.
4. In practice, it's more of a brainstorming session. You just sit down with a colleague and think/write.
5. In fact, the whole team is responsible. If the failure was due to the fact that the wrong estimate was set, then everyone played Planning poker or its alternative together. If someone sawed the task for the entire sprint, and then said before the demo that they didn’t have time, then it’s their fault and the Scrum Master, who didn’t follow through, perhaps hung up too big a task. If the customer asked for a too big task in the sprint, and no one objected to it - sszb, again to blame.
6. Project/delivery manager.

Answer 2

A small note on point 2 - scrum involves assessing not the timing , but the complexity of the task (in parrots, i.e. SP). The strategy for resolving conflicting scores can be as follows - the average score for all cards, rounded up. Or fashion. The maximum and minimum marks are explained by the participants who submitted them, taking into account the explanations, the team can vote again. The deadline for completing the task varies from the performer, from his personal speed (velocity, SP / sprint).

Answer 3

You have mixed business and software development together. Hence the misunderstanding.
1. "frontender, backender, database specialist and admin" The admin is definitely only indirectly involved in product development. "base specialist" is a very narrow specialization, do you need one for the project, can you fully load him with work for the duration of the project? Therefore, Agile proposes to use a different type of workers, a broader profile. Although with Agile it is possible that both the frontender and backender are evenly loaded.
2. Your example is rather a psychological problem in the team. Signor - with low self-esteem, compensating for it on subordinates. Agile - means, as you wrote, "so that each employee can take on and complete any task", which means that there will be no Signor in the team,
3. In the requirements for the User Story, you need to write the requirements for the load, and the architecture should be built from this load.
4. Again, the work of programmers of the same level is implied.
5. Nobody canceled the business owner. Agile means "Retrospective" and for future sprints the failures of the current one should be taken into account, but if the team fails constantly, then you need to look from outside the team what the problems are inside. And the owner of the business is responsible to the customer and nothing else.
6. Business owner

Answer 4

In practice, agile looks like this: after planning, developers politely escort the business out the door and start writing code. They need it solely so that the business does not throw up new ingenious extra-urgent Wishlist, otherwise any developer, with the exception of very beginners, can organize themselves.
Business thinks that it needs agile for control, but in fact it is needed for - understanding that you can't get everything at once and already yesterday - setting priorities, it's still impossible to feed the cats.

Answer 5

Agile is very similar to communism. IMHO, both ideas are extremely utopian, do not take into account evolutionary psychology, ethology and a bunch of other aspects. Software development management includes a wild number of variables that cannot be realistically taken into account. And customers often do not understand what they are getting into. We'll see where it all leads.

Answer 6

As smart people say, agile is institutionalized mess. Unfortunately, this is how it looks (in our realities, because everyone does it wrong and thoughtlessly), with experience and years, sane people understand this very well. Agile, this is when "Huyak-huyak, and in production", normal methodologies are different :)

Answer 7

1) In practice, this means a) It is desirable to select people for the team who are more versatile, who own different technologies and without ambitions like "I am a programmer, I will not test." b) If you don’t have to choose and you got narrow specialists and at the same time the team is permanent, then develop it, expanding their competencies. It's long, but worth it. c) If specialists are narrow and given for a short time, then do without cross-functionality. This is not a dogma, like everything else in Scrum.
2) 2 people cannot participate in planning poker. The whole team is involved. In addition, in practice, the junior usually does not argue with the senior, but listens to him. Sprint planning is limited in time. (max 8 hours for large and complex sprints) The Scrum Master must ensure that the discussion is constructive and not stalled. If someone rests his horn on the ground, cannot convince others and does not listen to their arguments - this is not team behavior. And the team is the foundation of agile. He needs to be educated. If this is regular, the question arises whether he really belongs in this team.
3) All necessary types of testing must be carried out within the framework of the sprint. It is advisable to use Continuous Integration and tests, including load tests regularly. Developers, when implementing user stories, should think about performance, as well as about many other things. Of course, performance requirements should be voiced by him.
4) This is not Scrum, but one of the Extreme Programming practices. Used at SiberLogic. In cases where it was critically important, despite the costs, to quickly and efficiently cut down the task in hours.
5) Communication with the customer in Scrum is usually carried out by the product. He also answers to him. The team is responsible to the product. In practice, in some companies, a PM who is outside the Scrum team answers the customer.
6) The same people are responsible for hiring and firing as without Scrum. It could be a director or HR. Sometimes PMs do this. However, a Scrum team can push a person out if they don't fit in. If heart-to-heart talks do not help, then the person is transferred to another team or to another company :)
Scrum is not implemented according to the books. If you have any more questions, please write to me.