Trying it is not the same as adopting it. The cultural transformation of a company towards an Agile culture is not within the reach of every organization. Depending on your sector of activity, your clients or your competitors, agility may prove necessary to stand out, but it may also prove unsuitable.

Indeed, adopting an Agile methodology for a company is not only about learning new working practices. It is above all a cultural change, and a deep, counterintuitive and sometimes even painful organizational transformation that must be carried out.

Discover in this article how to adopt an Agile culture progressively, and what can motivate an organization towards such a cultural transformation.

Moving from an existing organizational culture to an Agile culture

If the whole difficulty is not sufficiently expressed in the title above, understand that an organizational change this deep cannot be done overnight.

Changing company culture takes time and effort, for understanding and for getting out of the habit of what has always been known and applied within an organization. But in 2022, adopting an Agile methodology is no longer a big leap into the unknown as it was in the early 2000s. Many companies testify to the benefits of having adopted an agile method, whether on the client side or the supplier side.

The time when one could only refer to the SCRUM method is over, since there are now nearly thirty of them!

A) Convincing management

The desire to transform an organization’s culture towards more agility is not necessarily ordered from the highest level of the hierarchy down to the lower levels.

Indeed, the demand for organizational transformation can be raised by several people within the same company, but also by several factors external to the company, and ultimately convince management to change its vision and organizational culture.

1- Agility motivated by internal factors

Whether it is tech resources, project managers, business analysts or even salespeople, the desire to move from an organization to an Agile method can arise from each of these sides, one after another or at the same time.

Examples:

• project teams and developer teams see their responsiveness reduced by the heaviness of processes,
• the different levels of hierarchy to consult to validate work slow down the resources mobilized on a project, a task or a mission,
• the repetition of previous failures due to the work organization in place reveals a flaw in a procedure to follow,
• salespeople see their sales arguments “swept aside” by their clients and prospects given their lack of agility, and a Time-to-market that is too long…

If these few signals were not enough, the warnings identified by the market might prove more impactful.

2- Agility motivated by external factors

It sometimes takes very little to take the agility turn, if one listens to one’s clients and their needs, one’s prospects and one’s market.

Examples:

• your clients who have become Agile are looking for Agile suppliers that best match their new working methods ,
• your competitors who have become agile are more competitive, more responsive, and closer to their clients than you,
• the Time to Market without agility is slower than that offered by your competitors,
• the client does not want to reduce their room for maneuver throughout the development of their project…

There are always elements that can tip the balance to the good or the bad side, and fashion effects that pass as fast as they arrived.

These are generally the types of realities that speak the most to any company leader, clients and the market. As the coherence between the service proposition and market expectations must be in phase, your arguments will gain consistency and enough resonance to be considered and reconsidered if necessary.

Once convinced by the benefits of an agile method for its organization, management will then have to set up an adoption and deployment strategy for its teams, and will have to, no pun intended, show agility.

It will also have to prepare a complete support method that is ideally participatory, so that each employee is convinced and then trained, and so that they gradually adopt a new work culture, a new organization, and new mechanisms.

These obstacles are normal reactions when they are perceived as hindrances to carrying out their work, and are often taken as a disqualification or a demotion.

Fortunately, an Agile method represents an opportunity for managers to change their stance. By allowing employees to work more flexibly and letting them decide for themselves, a virtuous circle will gradually set in between daily comfort and short-term objectives, between the manager’s trust and a common goal that the teams on board will understand by themselves, if they are convinced of it, a condition that depends on the example being set by their hierarchy.

It is by seeing the short-term benefits that managers will be able to gradually leave a mindset based on control, bringing instead more value to employees.

By supporting and training them permanently, by breaking down the barriers between departments, by including a personal development program or, more simply, by listening more, the change process will favor the adoption of every employee, managers included.

Managers have a key role in this organizational transformation since they will be the relay between leaders and employees. They are in direct contact with practice on one side, and theory on the other. Tasked with supporting and committing to this agile transformation, managers must therefore embody the change wanted by management, and demonstrate the values of agility to start the agile transformation process, but will also have to keep doing so in order to sustain it.

The change must however not come solely from management, since Agile teams include all the resources of an organization.

Care will therefore be needed not to rush them, and to set up a medium-term transformation, rather than something radical that would be badly perceived because of its suddenness and the size of the project. By adapting to the maturity of the teams, agility will bear its first fruits if it is experienced in a gentle and progressive way rather than in a strict and brutal way.

Cultural transformation, put in these terms, can be perceived as violent. Whether it is a change of tools, a change of methods, new software, a new organization, each individual is more or less tolerant of change, and accepts it with a varying delay as well. Nevertheless, what does not change is the human being, and their adaptation.

Cultural change can therefore be approached from this angle: by evoking the fundamental values of Agility, one can make them understand the real usefulness of adopting this agile method. Before having collective buy-in, a majority buy-in will in any case have to be won, itself gained by the addition of individual buy-ins.

Through this buy-in, we therefore understand that lifting the barriers leads to a change of behavior towards Agility. This acceptance of the idea of implementing the Agile method, and the personal understanding of its usefulness and its daily use will therefore lead to the employee’s willingness to be supported in a culture change.

In the absence of work on the culture itself and on behaviors, teams will tend to gradually return to a classic development model, the one that employees have always known. This tendency can be reversed thanks to the presence of agile ambassadors* and coaches* to support managers and then teams in their cultural transformation.

An Agile coach is a person from outside who will support managers in their cultural transformation so that they can become imbued with it themselves, and guarantors of the proper transmission of Agile values and practices.

An Agile ambassador is an internal person whose buy-in to the method is total, who can more easily pass on the codes of agility to colleagues with jargon closer to theirs, internal legitimacy, and possible closeness to others.

Depending on the size of the team, the Agile method defined, the seniority level of each developer and each person’s specializations, the cards will probably need to be reshuffled a little to adapt the methodology to the resources rather than the resources to the methodology.

It is, finally, quite common for the Scrum Master to be the Tech Lead of this team himself. Although in theory there is no designated leader in the team, it is very likely that there is a natural leader in the team. The difficulties that may resurface from this horizontality of tasks and responsibilities could ruffle the most experienced, and put pressure on the very latest junior recruit.

So, how to make them work together, in the same way, on the same subjects, with the same level of responsibility?

Here is a first gap between theory and practice, which requires small readjustments.

So that no one loses in responsibility, in skills, in time spent on production, it is still possible to assign a developer to what he does best, and/or to the mission with which he feels most comfortable.

Whereby two developers can take charge of the “testing” part, while two others are full “integration” and finally two others full “code”.

Otherwise, with an equal skill level, everyone can vary their tasks between code, testing and integration, and can grow in skills on actions they are not used to doing.

Each team has its particularity, each team its own adjustments, and each project its agility. So, strictly speaking, agility is like “finding your own method within the Agile method ”.

It is complex to apply an Agile method to the letter, at 100% of its definition.

E) Maintaining the gains, by involving each Agile member in a lasting way

Once everyone is on board and mostly convinced of the benefits of establishing an Agile method, the course will have to be maintained, and this constitutes the second part of the difficulty linked to the organizational transformation and cultural change of the company.

You probably know the adage “Chase away the natural, and it returns at a gallop”.

The natural is what the employee has always known as a way of working. It is not the same for everyone, since each has their background, professional experience, own convictions, and ability to adapt.

If moving forward towards the little-known takes a long time, going back to what we know can be very quick. It will therefore be a matter of keeping everyone under the same conditions, except that managers and the highest decision levels serve as an example, and cannot themselves take part in a backward step, in which case all the efforts put in place will be swept away in the blink of an eye, in a time that would make Usain Bolt pale.

Conclusion

Of course, adopting an Agile method is not suited to all sectors of activity, to all organizations, and sometimes even to all management styles. Adopting a methodology remains a choice that must be adapted to one’s activity.

For example, in construction, where one works in a classic methodology called the “V-cycle”, you will have:

1. Your budget (maximum)
2. The plans of your building
3. The schedule
4. The delivery

When you have built floors of your building, it will be too late to add two extra levels of underground parking.

Whereas for the delivery of software or a website for example, and with an Agile method, you can during its development add features that you did not think of including when making your mock-up.

All of this can even be included in your original budget, with or without replacing certain features, or by extending your budget and/or the delivery time of the finished product.