In the midst of corporate organizations and the various levels of dysfunction that we encounter as coach-trainers, during training or interventions, there is a subject that is increasingly present in many organizations.
This powerful common denominator is central to the statistical panel I consider here. This panel is made up of various participants crossed over more than ten years of training at Smartview.
This is what we call " emergency mode ". We will then see how agility can help to free oneself from the tyranny of the emergency mode.
What is the "emergency mode"?
This is an emergency mode of operation, not justified by an objective emergency. It has become a nominal mode.
To be absolutely clear, let's first define what an emergency is.
An objective emergency is both unpredictable and important. A heart attack and a big business opportunity have three characteristics in common. That is, a sudden and/or random triggering event, the objective need for a quick action/decision, and important, even critical stakes.
However, it is increasingly common to see the management of daily business treated as if it were a real emergency. In addition to a possible reduction in processing time, this "emergency mode" will lead to stress, disorganization, and less control over quality. This hypothetical immediate time saving may cost future slowdowns.
Let's look for a moment at the emergency specialists, for example the firemen or the resuscitators. They are experienced in good emergency management and have organizational methods adapted to this particular context.
Let's imagine a dividing line between the emergency professions and the other professions. It is interesting to note that the "emergency mode" actually takes the worst of both worlds:
- The emergency, caught in the world of the real emergency (but without the organizational resources adapted to manage it);
- Non-emergency organizational modes.
How does the emergency mode work?
In companies, this "emergency mode" is manifested by the observation of operational staff that they "don't have time to deal with all the issues", or "don't have time to deal with them properly".
Factually, this can be translated on several levels. Typically, we will find :
- In terms of process: excessive wait times for processing, and a lot of "stored" work, which is on hold;
- In terms of results: "misses" or poor quality, customer dissatisfaction, and eventually loss of customers or penalties;
- And on the social level: de-motivated, even exhausted staff, with more turnover (or work accidents, sick leave, etc.).
Beyond these symptoms, the accumulation of problems will eventually be so great that the situation seems completely inextricable.
In the end, it seems that there is no solution to these malfunctions that feed each other. In another article, we will see an illustration of this emergency mode at a software publisher. The corollary exists outside of software development with organizational debt.
Is there a simple remedy to the emergency mode?
Faced with this muddle of problems, one might be tempted to think not. But the solution is easy to find, and if the organization has the courage, it is accessible and feasible.
The causes of the emergency mode result in fact from a simple mechanism. It is theexistence of a significant and stable gap between the level of resources and the level of workload.
The remedy can only be in two areas.
The most obvious solution is toincrease the level of resources. However, this axis of solution should rather be sought in a second time. That is to say, once the other corrective axis has been explored, if it proves to be the only way to regain efficient functioning.
The other solution is to reduce the workload. This is generally difficult or impossible for operational staff as it is.
At the level of operational teams, the only potential room for maneuver is that of significant process improvements. Depending on the context, there will be more or less room for improvement.
If there are no significant gains to be expected from process improvements, how can the operations team reduce its own load?
The only way to reduce a load is... to reduce it. This requires accepting to give up: for example, to give up launching as many projects as one would like in a given period.
This renunciation implies a managerial decision, resulting from trade-offs between the organization's strategic issues.
Let's bet that if the organization encounters this kind of problem, it is precisely because of its difficulty to decide and to give up. This is where agility brings useful resources to unblock this situation.
The first level of action is the strategic level. This prioritization will be done using tools typical of agile projects. These tools help clarify the vision, sharpen and facilitate the high-level prioritization.
Let's take the example of strategic story mapping and prioritization tools. For example, they allow you to visualize the hierarchies between different products and their respective time horizons.
These clarification tools at the management level of the organization are also effective operational communication tools. They are extremely effective. They are visual and reduced to a minimum: they show the essential, and the link with the vision and strategic priorities.
Thus, the strategic story mapping allows to give a clear and realistic direction to the rest of the organization.
The organization will then define these strategic priorities. The person in charge of a product (a Product Owner in a Scrum context) will carry out his own product story mapping.
Since a story map is a visual representation, the waterfall process between these different planning levels (here, the portfolio and product levels) is extremely efficient.
Story mapping gives a clear direction and facilitates arbitration. It helps to get out of the emergency mode because the organization stops working in permanent overload. It gives the means to focus on the most important objectives to create value.
This simplification and focus will bring efficiency.
Other agile tools
Other agile tools will be useful for the same reasons, such as tools based on feedback or the user-centered approach.
These tools can only be fully effective with a full understanding of the values of agility.
This agile culture is based on courage within the organization. Courage (1) refers to the ability of the various components of the organization to allow the status quo to be challenged. It allows for salutary changes of course and to learn from the past and the present.
It is then a matter of developing the organization's capacity to accept errors in order to overcome them, to authorize reversibility, to develop a culture of radical questioning of value creation.
These tools are useful, if not indispensable, to fight against the natural entropy of organizations. But also to make the most of resources. They are powerful vectors of a corporate culture that enables innovation.
Thus, an "emergency mode" type of operation does not result from emergency situations. It results from a lack of clarification of priorities and efficient choice mechanisms. The emergency mode will never solve the problem of overload. It will create new problems that will "indebt" the organization to the point of reducing its margin of action.
At a certain point, it becomes difficult to understand how the organization got there. The so-called emergencies of the moment are blamed. In fact, it is the failure of key processes in the organization that is the primary cause. It is true that these pseudo-emergencies have generated new dysfunctions. They have created debt (technical, organizational). Everything is so muddled that causal analyses tend to resemble the chicken or the egg question.
At this point, a flurry of false good ideas should follow in order to improve the situation. Usually, they create new problems or confusion. The best example is a cost-killing approach. This may be useful in some contexts, but will be harmful in this type of context.
As long as the solutions are simple, it is not impossible that the organization will eventually find the courage to solve the real sources of the problems, to find the courage to change some of the underlying flawed processes, and to find the path back to value creation (2).
(2) What looks like a fairy tale exists in real life! We regularly meet clients that we accompany in this transition.
Need help to remedy this?
If the situations described here sound familiar, it is not by chance. They are situations that we encounter quite commonly with our clients.
The Product Manager course that we will be delivering this year in partnership with Montpellier Business School is precisely for this reason. The objective is to help understand and correct some of these problems, through the implementation of a real product strategy, equipped and supported by well-trained Product Managers. This program is registered with the National Register of Professional Certifications (RNCP) and is therefore eligible for use with your Professional Training Account (CPF).
We will be hosting a webinar on Tuesday, March 8 to discuss this topic and answer your questions.