Can agile management improve the employee experience?

Employee experience has a very operational component in the daily work that concerns the content of the work and the way it is done. Here we are in the concreteness, when the employee has “his hands in it”. But on a more macro level there is the way the work is organized.

For more and more people in the world, agile, applied not only to development professions but to all professions, is a possible path to a more efficient organization, a better customer satisfaction (internal or external…) and a way to contribute to an approach of operational excellence.

But does agile contribute to the employee experience as one can (rarely) read and if so, to what extent?

The “non agile” organization generates points of friction for the employee

Before looking at the subject from an agility perspective, let’s first look at the problems posed by a non-agile organization, from the employee’s point of view.Indeed, while nothing at this stage will say whether agility is an appropriate response or not, it is difficult to assess a remedy until the harm has been clearly identified.

Let’s start with the lack of adaptability resulting from organizational complication. When one chooses a trajectory, it is very difficult to change it along the way while it is well known that everything changes very quickly in the context of an initiative or a project. By accumulating small deviations, we can end up very far from the target after 6 months or a year. The need does not change, but as the context changes, so does the way of responding to it.

Then come the problems of compartmentalization and communication. The different stakeholders in a project speak little or badly to each other. Worse, communication and the relationship with the client (internal or external) are complicated or conflicting: there is the project team on one side and the client on the other and people forget that both are in the same boat.

We can also mention the lack of visibility and the famous tunnel effect. There is a project, an initiative, we know when it starts, we know roughly where we’re going (even if we risk missing the target) and we know roughly when we’ll get there. In practice, we accumulate delays, we move away from the target, deadlines are pushed back, and for a team member who only has a fragmented vision of the project, we quickly reach a point where we no longer know where we stand, we lose sight of the value and usefulness of our contribution to the project, and we no longer know if what we have done will be useful or even used. Result: frustration and disengagement.

A consequence of the previous point: the lack of pace. The more distant the deadlines are, the less sensitive the reality of the project is. The more we get lost. The more we can get caught up in another, more immediate and therefore perceived as urgent, subject and say to ourselves that we will have the time…and finally the deadlines arrive and we are in a hurry. From the employee’s point of view, having the impression that you’re doing relays and not running a marathon would give the impression that you always have a finish line in sight with precise objectives, which is not the case in reality.

Projects that become their own raison d’être. At the beginning you have a need, you launch a project. Then a bubble forms around the project that protects it from external interference (which can be beneficial except when the interference is only the name given to reality), people who do not participate in it forget about it, its clients sometimes even lose sight of it, and little by little the project becomes its own raison d’être, regardless of the need it has to address. We no longer know why we do things and then we feel the need to protect the project and its existence even more against any (even legitimate) questioning. Obviously, when you have consumed a few million dollars in 2 years and nothing has come out, there are necessarily people who can wonder if it is still useful, if there is no other way to do it, if we are going in the right direction. But even these healthy questionings from the point of view of the hygiene of the project do not have the right to exist.

Bringing the project to life and protecting its team become more important than bringing it to fruition. So much so that we even see projects that never come to an end, not because there is always room for evolution, but because seeing the end of them gives the impression of emptiness to those who participated in them, that they no longer imagine life outside and that they have been so cut off from reality that they are afraid to return to the real world.

If we relate this to the question of pace, visibility and the tunnel effect, we can see that not “delivering” functional things on a regular basis, even if they are only part of a whole, gradually takes the project out of the real world.

One also suffers from a multi-speed organization. The field advances at the speed of the customer, the market, with a horizon of a day or even a week. Then the higher you go up, the more you move on to weekly, monthly, quarterly horizons. What happens when you have to escalate a problem to get a decision, an authorization, a solution? Everything stops and the employee acts as a “buffer” or rather the big split between the client and the organization. Add to all this the organizational complication…

Let’s finish with a budget management that is not always optimal. “The bigger it is, the less questions it gets,”. We’re going to be here for a year and it’s going to cost 1 million…. whether it’s an internal project or for a client, it’s a reality that’s hardly palpable even if we’ve analyzed the budget estimate line by line and item by item. And there are so many unforeseen events, so many changes in the context that to predict on January 1st that we will need such resources in terms of quality and volume 10 months later is just a matter of reassuring ourselves.

On the employee’s side, the way things are done today is therefore not optimal. But what about the customer, whether he is, let’s remember, internal or external?

The “non agile” organization: the customer’s anguish

On the customer side it’s about the same because the same causes cause about the same effects but from a different reading angle of course. I’m not going to talk here about the external client in the context of a service, but about the internal client: the employee who knows that something is being prepared that will concern him or her and who is patiently waiting for it to happen.

So of course he’s not concerned about the budget issue but rest assured, someone is in his place. On the other hand he is concerned about the question of value for him! Is this really going to bring me anything? I am the first one concerned but I was not involved in the formalization of the need and the specifications…which was the case for me. And then since the time we launched the project my situation and my need have evolved…has this been taken into account. And then the famous: “we’re still going to spend crazy amounts of money on something that will be useless instead of giving budgets to more practical and useful things”.

He does not like the fact that the project team lives in its citadel and that it does not seem to want to listen to the stakeholders once the specifications have been drawn up (provided they have been involved in this phase). In the end it is no longer the project team but “the people in the project team”, “the others”, “the guys we don’t see”.

He is of course the first to suffer from the differences in pace between the different strata of the organization. There is nothing worse than having a supposedly responsible interlocutor in front of you and hearing himself answer “I don’t know”, “I’m going to ask”, “I’m waiting for an answer”.

In short, it’ s not better on the client side.

Is agile the answer?

This post is already long enough as it is and we will go into detail, point by point, later.

But let’s say that an approach that :

  • Is driven by the value for the end customer.
  • Breaks down the barriers between the different stakeholders and promotes communication between players.
  • Allows the roadmap and the final product to be continuously adapted to the changing context.
  • Is based on the regular delivery of functional increments.
  • Includes permanent feedback loops with the client as well as clear validation criteria for deliverables at each step.
  • Allows the team to not only talk about the project but also to regularly discuss its own internal functioning in order to improve it.
  • Allows resynchronization between all layers of the company as long as it is applied globally.

…has characteristics that can substantially improve the employee experience in its operational dimension.

But not everything is a project!

The limit of the approach is clear: agility applies to projects and not everything is a project in the company. Yes. But no.

Indeed there is the “day to day” with routine tasks that just serve, as I used to say, to “keep the machine running”.

But a large part of the daily work can be considered as a mini projects. Whenever there is a need to get things up and running to achieve a non-immediate goal. A recruitment, the organization of an internal event, the reorganization of the open space, a sale….

Part of the agile approach can also be used to give pace and organize the work of a small team but also individual work. If more and more people are using tools like Trello to prioritize and monitor the progress of their work, it is not without reason.

I also see a great interest in agility to steer transformation projects, change projects, substantive issues and more generally things that, as mentioned before, have difficulty finding their place in the face of the tyranny of the short term, so they have to happen in parallel with the daily work. The essential thing for these projects is to be anchored in daily life, to exist for those who participate in them as well as for those who are the object or the clients and, once again, to keep up the pace! To be a believer in this approach for a few years, I confirm that using it to avoid structuring subjects/tasks that occur in parallel to the daily work from being constantly pushed back, or poorly followed up, has undeniable benefits.

Image : agile management by Olivier Le Moal via Shutterstock

Bertrand DUPERRIN
Bertrand DUPERRINhttps://www.duperrin.com/english
Head of People and Business Delivery @Emakina / Former consulting director / Crossroads of people, business and technology / Speaker / Compulsive traveler
Head of People and Business Delivery @Emakina / Former consulting director / Crossroads of people, business and technology / Speaker / Compulsive traveler
1,756FansLike
11,559FollowersFollow
28SubscribersSubscribe

Recent posts