[case] Iteration on time or half-team?

    Friends, well, since the first case received its 15 minutes of attention of the pros, we will continue.

    Four years ago we held in Moscow the third seminar from our series of seminars of that time. To diversify the program, we decided to devote a couple of hours to parsing the participants' cases. Since there were about 40 participants, it’s clear that you won’t understand all the cases here. Therefore, special democracy was imposed: collecting cases, voting, counting the results by an authoritative commission represented by us with slavapankratov .

    As a result, the following situation got into the top of the most interesting cases. The case is real, taken from the real experience of our students:

    Case "Dismissing half the team"

    Disclaimer from a colleague slavapankratov . We draw your attention to the fact that after that the real situation that is used to design the case is handled by the trainer (depersonalized, overgrown with formal introductory notes, enhanced by facts without which its solution would not have been possible), it may acquire a “plastic taste”: that is, it may seem somewhat artificial and invented. The analysis of a problem situation in itself always carries a certain percentage of distortions of reality, and a case, as a model of a time period of the real world, may seem artificial and far-fetched. We suggest that you consider this situation as a training simulator, and the situation itself as a sparring partner, which, unlike a punching bag, can fight back but at the same time it is not his task to knock out the trainee.

    Why did we make this introduction.

    Any trainer, if he is conducting the training, and not just giving a piece of lecture or retelling a memorized seminar, is faced with the student’s resistance. As soon as a student’s real experience falls into a situation of critical evaluation by a coach or a group, a person is inclined to defend him. There is no way to fix anything in the past, but to admit that you used to be wrong earlier, even if it was a long time ago and, it would seem, no longer important, we do not like. In other words, if in a learning situation a student recognizes himself and sees that he previously could not behave in the most logical or effective way in such a situation, a defense arises: “Some case, obviously, wrong” or “What can they know with with your case about real life? !! ”or (the most favorite for trainers)“ You specially slipped me a curved case to mock it. ” Why is your favorite? This is a good marker of triggered reflection, internal discussion in the student’s head. And reflection is the first step in learning.

    So if in the process of reasoning over the decision of this case you get similar defensive reactions or just a desire to look around the guilty ones (in the case itself, in the comments of other participants or in the words of the authors of this analysis), you should not keep it in yourself: the reflection has simply gone. Perhaps we have prompted you to the idea that earlier in your experience you might not behave correctly. Congratulations, you’ve joined the case, and the learning process has started.



    There is a project team: programmers, testers, analysts and a project manager, for which we suggest you play in this case. That is, you will need to design a model of the project manager's behavior for a sustainable solution to the situation.

    The project team is developing a large IT system that is delivered to the customer by monthly iterations. That is, before the beginning of each month, the team selects and evaluates the amount of work that it can deliver to the customer. The work includes analysis of the requirements for iteration, development or revision of the system code, testing a new version of the system, its deployment and configuration at the customer’s stand. The team spends the first day or two of each month analyzing and evaluating requirements that can be developed and tested within 1 calendar month. Work with the customer has been going on for about a year, at the moment, taking into account public holidays and vacation seasons, 10 versions of the product have been delivered to the customer.

    The customer does not just accept the intermediate version of the system and waits for the next one, but uses the supplied software to automate a significant portion of business processes. On the customer’s infrastructure, the system contains real data. If errors or delays occur during the delivery, deployment, or operation of a new version of the system, the work of a large part of the customer’s company loses working time of approximately 300-400 users.

    Despite the well-established procedure for assessing the volume of iteration, the project team in 4 iterations out of 10 disrupted the delivery of a new version of the product (from 1 to 4-5 business days). The reasons for the failure each time are different: the problem with the deployment and updating of software on the customer’s infrastructure; critical errors that result in corrections and re-delivery; changes in the composition of the requirements being implemented and underestimation of the terms for the implementation of the changes. It was not possible to identify any one systemic problem in retrospect after the “problematic” deliveries. The consequences of missing deadlines for the customer’s business are also different each time: the problem is the simple division of the customer, and not just the fact that the delivery date is delayed.

    The last 2 disruptions in delivery dates occurred in a row in two months one by one. The failure to launch the new version for 3 days led to the downtime of all 400 employees of the customer’s unit for a period of 3 days. The angry customer in an ultimatum form demanded that your company management take measures to restore order in the project.

    The technical director of the company in which the project team works, called the main character of the case and informed him of the following management decision:

    If the next iteration, at the beginning of which the project is now located, is broken by the deadlines, then in order to discipline and set an example precedent for the other 15 project teams of the company (in total, your company has more than 1,000 employees), half of the employees will be dismissed from your team, and The project will be reformatted according to the composition of people and the timing of future deliveries.

    The decision is voiced as final. The technical director, possibly under pressure in negotiations with the customer’s representative, promised to implement this decision in case of delivery deadlines and can’t cancel it.

    Put yourself in the place of the project team manager, to whom such a management decision has been conveyed by his superiors, and try to answer a few questions:


    1. To speak or not to tell the team about management decision?

    2.1 Speaking, what exactly and with what words to say the team or its individual members?

    2.2 If you do not tell the team, what will be your further actions? Will you work? Will not be? How will you lead the project further? What consequences can your chosen model of behavior lead to?

    Additional data

    The team works smoothly. There are no obvious outsiders or stars in the team. Previous problems were not systemic. Earlier, you already announced to the team that a deadline could affect the future of the project: in your company’s practice, you have been depressing employees and dismissing both managers and engineers. But the breakdowns were repeated. There are always explanations. The situation has not changed, and now the customer decided to put pressure on the company whose services he uses.

    Take a break. Think calmly for as long as you need. Write down your decision and clearly record your decision: to speak or not to tell the team about dismissal in case of failure of the iteration terms? If you decide to “hint” to the team about the consequences - write down the formulations and think about how they can be perceived by the team. You have already voiced these comments before. Will people work differently after your words this time?


    Before offering you our solution, let us once again recall that we are in the framework of a training model that cannot take into account all the factors that will affect the stability of the solution. In real life, a solution can turn out to be much simpler or not feasible at all.

    Usually the "spherical manager in a vacuum" is the servant of three masters:

    1. Business - interests of the customer, company, management
    2. Team Interests
    3. Own authority (informal and formal) and reputation

    All these things are tightly interconnected. If the decision will do well for the business, but the team will die, fulfilling it, then what will happen to the reputation of the manager? In the eyes of the business, everything can be fine, but in the eyes of the team ... And our market is sooo small, after 5 years of work in all companies there are friends.

    If the decision is good for the team, but the interests of the business are not taken into account, then what will happen to the reputation of the manager?

    Real life example. Not so long ago we talked with a participant in our annual program , who, among real prospects, considered moving to another company with his team. Regardless of the situation, this is a very unstable step. Because the owners of another company can do this in order to get a team, but will they want to continue working with a manager who withdraws teams from the companies? The big question is ...

    Let's get back to our case. When designing a solution, we try to take into account the most obvious factors that affect the stability of the solution and can lead to loss of control over the situation. That is, an unstable solution, a solution in which the team manager will not be able to influence the situation, it will get out of his control and go into a phase that the manager did not want to allow.

    In simpler words: having driven a car before a turn, the driver sees that the curve is covered with ice and decides what to do to get the car out of the turn. An unstable solution will be that leads the machine to a ditch. If the driver enters the car into a controlled skid and beautifully takes the car out of the corner, the solution is considered to be working, but applicable in a limited space - the driver is professional, ready to act in a similar situation and repeatedly did it. “Lucky” as a variant of the decision is considered as an accident.

    In terms of the case, the decision to fly to the customer and by means of blackmail or threats to convince him to cancel the decision and influence the technical director is accepted as risky. “And we have a wonderful relationship with him and have a thump together” - an amendment by which you change the conditions of the case and solve it in your reality, and not in the conditions of our training simulator.

    At the same time, we, for our part, can accidentally change the reality of the case with our own solution or made assumptions. Rules for both you and us. Both we and you have the right to say that the decision makes a change in the initial conditions of the case.


    We will give some very unstable, in our opinion, solutions that most often sound from students in trainings and our online programs. Analyzing these answers, we, at the same time, give examples of what we call a “non-sustainable solution”.

    Let's go through the first fork of the decision tree.

    Option number 1. The team is not told about the consequences.

    The arguments are different: in order not to panic, so that no one falls off on his own (as soon as he finds out about the impending threat), so that there is no split in the team (who will be fired?), So that no one goes instead of working on their tasks to look for another job and so on.

    From the point of view of systems theory, the manager assumes the risk of the decision “We don’t speak”, leaves the team without information and hopes (you can’t get another word) that “Everything will somehow resolve.” And hope is not the most stable management plan ...

    More often total not taken into account when designing solutions for this case?

    Quite often it is not considered that information about the threat of dismissal will become known to the team in the middle of the iteration. At the same time, in fact, in the real world, the model of which we are still considering, the information goes around the company in the most unexpected ways in addition to the official ones: “You’ll only get anyone ... but they’ll cut you soon, look for yourself a job” (as an option, people worked or studied earlier together), “I heard that you will soon have cuts, maybe come to our project? Just the vacancy has opened ”(a case of internal competition for resources between managers of one company),“ These from Project A were completely awesome with such delays! I’ll fire half if they try to soak it again! ”(Angry tech director secretly to someone from trusted managers or just near the ears of strangers: secretaries, HR,

    We work in companies that are a plate of vermicelli, where connections between people exist regardless of the staffing and verbal communication (aka gossip) is practically impossible to manage).

    What will the manager do in a situation where he does not tell the team about a possible dismissal, and the information leaks into the team? Say you didn’t know? Say he hid in order not to sow panic? People cannot live in conditions of uncertainty. And the realization that the manager due to lack of awareness or (even worse!) Deliberately hid information about the common fate from the team is very likely to break the trust of the team manager. It will be very, very difficult for the manager to complete the project and work further in such a situation.

    This is not a change in the conditions of the case: we are not saying that we will definitely find out. We test the decision “Don't tell the team” for stability. Sustainability is determined by the ability to answer the question “What should I do if?” And be able to continue implementing the solution in the event of a similar risk.

    Option number 2. Tell the team: “If we can’t do it, half will be dispersed.”

    What are the risks of this option? In the series “Interns” there was a wonderful series when Dr. Bykov tells 4 interns: “At the end of the day I will fire one of you. I have not decided yet whom. Yeah, here! I’ll sack it, it’ll hurt most of all! ”

    What happens next? Further, people by all means try to be in the group of those whom the punishing right hand does not touch. Non-working games come into working reality: setups, a conscious decision not to share information with other colleagues, etc.

    Will the iteration be completed on time under such conditions? Unlikely. People are not thinking about that. how to pass something on time. but about not being in half of the losers. Energy is not directed there.

    Option number 3. Is he there?

    Wait, you say. You can’t not speak. You can’t talk either. How is that? Where is the solution? ..

    As a result of an hour-long discussion with 40 managers, we then came to the following option, which so far seems to us the most sustainable:

    Step No. 1. At a general meeting with the team, describe the situation. And to inform that if we don’t pass the iteration. then everyone will be fired. And me. as a manager in the first place.

    Comment: not “half the team,” but all. In order not to give birth to “games” in a team. If someone somewhere hears that half the team will seem to be fired, the manager can always object: but according to my data, at least I’ll definitely leave.

    At the same time, the very threat of dismissal can affect different people in different ways. Someone can start looking for work right away, which increases the risk of a person leaving in the middle of the iteration. Therefore, you need:

    Step number 2. Immediately at the general meeting, literally say the following: “I understand that this information can be perceived differently. If you decide for yourself to leave before the end of the iteration - a big request to inform me about this in the next 2-3 days. After our meeting, I would like to meet with each of you one on one to understand what you think about this. ”

    Step number 3necessary to instill confidence in doubters. At the end of the general meeting, say: “Friends, in order to minimize the risk of our failure to miss the deadlines, I suggest aiming 5 days earlier. Just to be safe. Moreover, every day we will all get together and see the big picture of how we are going - whether we are in time or not in time. ”

    Step number 4. Meet 1: 1 with each team member. And if someone was about to leave, then report it in a couple of days to everyone, and once again get together and decide how we can cope without leaving.

    If the team succeeds in delivering the release, if it doesn’t, the life will show. But from the point of view of three components:
    • Business
    • Command
    • Authority and trust

    This solution seems to be the most sustainable of all options. You can say: wait, so the manager what, you need to be able to lie? A lie for good? May be. At least the manager does not know exactly what will happen if the project is not delivered on time. And IMHO it’s sometimes better to thicken the colors and play it safe, especially since there is always the opportunity to say that you did not have a clear certainty that half would be fired.

    Well, then, behind our shoulders there was a second case. We will be glad to hear your opinion - both positive and constructive.

    And we, along with the launch of the closed case club "System People", will continue to publish difficult situations on Habré.

    Also popular now: