Similar to the song by Orelsan that repeats, "Vous n'avez pas les bases! Vous n'avez pas les bases!" (You don't have the basics! You don't have the basics!), I sometimes also have the impression (without wanting to seem disrespectful) that certain agile transformation initiatives miss some common-sense rules. Here's an overview of six absurdities observed (with all due benevolence) in some organizations that have nevertheless declared their intention to become "agile". If you encounter some of these, don't panic; it's a great opportunity to progress!
Absurdity 1: Creating an organizational silo dedicated to transformation or agility
Why is it absurd? The primary foundation of agility is collaboration. It was established by the pioneers of this movement to combat the phenomenon of organizational silos, still prevalent today. The problem with silos? Each has its own objectives and priorities without coherence with others, inevitably generating conflicts among individuals who nonetheless share the same logo on their paychecks. Curiously, the first thing almost systematically implemented in an agile transformation is a team responsible for leading this transformation, sometimes called an "agile center." Organizing its roadmap individually, its goals are often completely disconnected from those of the rest of the company!
You can detect this phenomenon through some classic symptoms: the transformation team refuses to help certain teams that request assistance because they are not "prioritized" and simultaneously imposes its intervention on others who have not asked for it and are satisfied with their functioning. In such cases, the agile center likely falls into the trap of "vanity metrics" - indicators like the number of teams assisted or the number of people trained - without caring to observe real changes in behavior, let alone real benefits for the company.
How to get out of it? At a minimum, change advocates can try to integrate into existing silos rather than creating new ones. Working with the leaders of each entity can help identify their priorities regarding agility, define achievable initial objectives, and provide them with the means to get support, particularly from agile coaches, for these objectives. To go further, it may be interesting to federate management transversally at each hierarchical level and assign them the mission of regularly working to improve collaboration between their teams.
Absurdity 2: Creating "feature factories"
Why is it absurd? Genuine virtuous and respectful cooperation between business and IT directors is a total fantasy for many large companies. However, this relationship's quality should be the first thing any agile transformation addresses, as agility's purpose is primarily to create better products. Paradoxically, perhaps contaminated by a certain fatalism or trapped by sponsorship generally coming from IT, some agile transformations only aim for efficiency. Thus, agility is confined to a simple method for optimizing delivery. The consequences can go as far as widening the business-IT gap because teams, inundated with messages urging them to go faster and proclaim their autonomy, become extremely arrogant! This is where the concept of "feature factory" appears in all its perversity: teams lose sight of the company's purpose and find satisfaction only in producing more and faster. Customer satisfaction, business value, or user feedback are then far away, lost in a forgotten manifesto, at best.
"There is nothing so useless as doing efficiently that which should not be done at all." - Peter Drucker
How to get out of it? Common sense reminded by agility is that each novelty or change must fit precisely into a more global logic that meets the company's, its teams', and, above all, its customers' needs. To achieve this, it is necessary to take the time to co-build, share, and explain the adopted vision and the value brought by the company's products or services. It is also important to identify the main recipients of this value (customers, users) and involve all employees so that they feel proud to contribute to the agile development and evolution of the company, with the conviction that it will better serve its customers. This defined, shared, and global notion of progress, beyond the DSI's borders, should then appear as one of the main transformation indicators, to avoid losing direction.
Absurdity 3: Adopting agility without believing in it or endorsing it
Why is it absurd? Before being a set of methods implemented by experts, agility is above all a culture imbued with strong and tangible values. However, many agile transformations forget this dimension and do not seek to obtain adherence to these values before deploying practices. Successfully carrying out an agile transformation requires significant introspective work upstream to affirm the deep convictions motivating change and share them with all employees. The company and each contributor must know why they embark on this process, why they need it, and why they truly believe in the benefits of agility.
If you haven't found this common thread yet, you know what you have to do! This is what will allow you to successfully lead your transformation and make it efficient without getting lost along the way.
How to get out of it? A possible first step is to identify the most influential sponsor and help them co-build, communicate, and share an inspiring vision of the transformation itself. You can especially bring out deep convictions through questions like, "Why do we really need to change? What could the ideal company we want to build look like? What will make employees and customers notice that the company has become agile?" To obtain the adherence of as many employees as possible to the transformation's vision, it is possible to use tools like the "Vision Of New Generation".
Absurdity 4: Applying agile jargon to old practices without adopting real changes
Why is it absurd? Agility, true to its name, uses specific vocabulary with new terms. However, using this vocabulary is not evidence of having become agile and should even be one of the final stages of the transformation. In practice, labeling certain employees as "Product Owner" or "Scrum Master" while asking them to continue working as functional or technical project managers makes no sense. Similarly, designating a team as a "Scrum team" that does not have the characteristics associated with it (restricted, multidisciplinary, autonomous team) would be like calling a brewery a "gastronomic restaurant" just because servers in tuxedos were added. New designations must be earned and carry meaning through a profound change in practices.
How to get out of it? It should start with training for both managers and operational teams much earlier and preferably together to involve cross-functional departments (HR, management, quality, procurement) from the beginning and create a co-construction dynamic. It is then important to tell the teams implementing Agility that they have the right to make mistakes to create a culture of experimentation. The temptation to secretly return to one's comfort zone will then be much weaker. To align with the ever-changing reality of the company, whether agile or not, it is also necessary to allow for regular reviews of job descriptions, processes, and staffing logic.
Absurdity 5: Having a "Chief Transformation Officer" or a "Chief Agility Officer"
Why is it absurd? I have seen agile transformation teams influenced by a despotic leader who falsely believes to have understood everything about agility. Moreover, this leader often defends an attitude completely out of line with agility. It is often this leader who will implement the previous absurdities (especially the phenomenon of new silos), convinced of holding the truth. From the start, the very principle of an absolute expert deciding what the transformation team (whose existence is already questionable) should do and how it should do it is heresy. It is essential to establish and protect a logic of co-construction and self-organization with leaders who distribute decision-making power rather than monopolizing it.
How to get out of it? "Eat your own dog food!" as the Americans say. If you advocate the values of agility, start by applying them to yourself. For example, the transformation sponsor could try entrusting the reins to someone with the right mindset and a deep understanding of agility. If that's not possible, personal coaching from an agile coach, preferably very senior, can be proposed to help evolve their convictions and posture. The goal is to achieve a solid qualification and training for employees who will know how to implement and subsequently transmit the agile culture.
Absurdity 6: Devoting days or even entire weeks to preparing reports or committees
Why is it absurd? Also encountered very regularly, this phenomenon has no place in an agile context. Indeed, Agility encourages important operating metrics to be integrated into the teams' daily operations, eliminating the need to specifically generate reports. Yet, it is very common to expend insane energy to shape and specifically convey information to leaders who will ultimately decide nothing. By definition, important indicators should be produced and used by teams before being used for display or to legitimize anything. This is where true transparency comes into play.
How to get out of it? Review your previous reports and ask yourself how you could make the important information it contains be naturally produced and used by the relevant teams. Also, ask yourself how teams manage without it! You may deduce that the information is not so important, or conversely, that teams do not have this information (or not as clearly), which may explain certain dysfunctions...
Rediscovering the agile spirit means keeping it "simple, basic."
The common thread among all these absurdities is the natural tendency of companies (especially Western ones) to want to complicate things that are actually very simple: creating new teams when it would be sufficient to help existing ones work together, producing more when slowing down would add more value to what is done, insisting on controlling everything when conveying meaning would naturally make things happen. Agility invites us to simplicity. It is its foundation and is explicitly stated in its principles. A truly "agile" transformation must, therefore, make it a motto to simplify things within the company. Unfortunately, this is probably the greatest challenge of these transformations: positioning themselves against a voracious culture where the eagerness to do "more" tends to overshadow the wisdom of doing "better."
