Agile Transitions and Employee Retention

A question from my mailbox this morning (paraphrased):

Our organization is transitioning to agile. I often hear that not everybody will suit an agile team. I’m concerned that some of the non-agile-minded will drop out. How do we keep everyone on board?

My correspondent had heard statistics and advice like “20% of the people in your organization will not make the transition. Be prepared for some turnover.” And he’s right to be concerned. Agile transitions are not easy. No significant change is ever easy.

Since this is a question I hear often, and since my response to my correspondent applies to any organization in transition, I decided to post my response here.

I offer four observations:

1. People sometimes surprise us.

The person who seemed complacent, satisfied to stay in their little comfort zone, resistant to taking ownership, may turn out to be a great collaborative team member when given half a chance. I’ve seen it happen. By contrast, the “top performer” who seems so pro-active and who everyone is desperate to retain may turn out to be toxic in the new organization because she prefers the mantle of hero to true collaboration.

2. Leaving isn’t the worst thing in the world.

One of my absolute worst screwups as a manager was to work too hard to “help” an employee that was not performing well.

He was on a performance improvement plan for months. Both of us were miserable about the situation. He’d been with the company for a while, and after many organizational changes ended up in my group. The organization had changed, and he wasn’t fitting in well in the new world order. No amount of training or coaching was helping.

When we finally mutually agreed that things weren’t working, he found another job at another company almost right away. The next time I ran into him at a conference he was brimming with happiness at his new success. His new organization loved him and he was thriving. His skills and temperament were a perfect fit there.

So while I thought I was being kind when I tried to give him every chance to succeed in my group, I was actually being cruel by prolonging his feeling of failure unnecessarily.

Similarly, at one of my clients, a QA Manager who had been resisting the transition to Agile ultimately left. Upper management was very, very nervous about what his departure would do to the QA group. But it turns out that everyone was better off.

Leaving isn’t the worst thing in the world, and sometimes it can be the best thing for all concerned.

3. Creating safety is more important than retaining individuals.

Transitioning to Agile inevitably results in increased visibility. That visibility can be incredibly scary, particularly in a political organization where people have historically practiced information hiding, and information hoarding, as a survival strategy.

Instead of trying to retain specific individuals, it’s more important that managers focus on making people feel safe. Much of creating safety is about not doing things: don’t use velocity as an assessment mechanism; don’t add pressure by blaming the team if they miss sprint targets; don’t foster a culture of competition within a team.

Even more important is what managers can actively do to promote safety: talk to individuals about their concerns; get whatever resources people say they need in order to be successful; reward collaboration over individual achievement.

4. Treat people well.

The people in the organization are humans, not fungible “resources.” They deserve support and compassion. As long as managers treat people as people consistently throughout the transition, it will all be OK, even if some people decide that the new organization isn’t a good fit for them.

13 thoughts on “Agile Transitions and Employee Retention

  1. “20% of the people in your organization will not make the transition. Be prepared for some turnover.” sounds more like promise of layoffs 🙂

  2. Nice article!

    Re #3: A few years ago I experienced a horrible example of safety being destroyed by a CEO firing a team member for a minor behavioural infraction that could have been handled as a simple reprimand. I was the organisation’s coach at the time and I considered terminating my contract. In retrospect should have.

  3. @George I think I understand what you are trying to say, in the examples I know that was when they did not think hard enough about what they wanted as result.

  4. I haven’t been asked this exactly as you were, but I have always suggested that if good, solid employees do not take to Agile ideas, there must be other development work of value for them to do. Now I usually work with large(r) organizations and they do not make a flash change to everything being suddenly done using an Agile approach. So there is always useful work for people who do not want to be a part of an Agile team.

    What seems to me to frustrate folks, in larger(r) organizations, is the way the transition is (or is not) handled. It may be the employees hopeful of what a real change could mean who may decide to leave or look elsewhere in the organization because the transition is half-hearted.

    I would be more concerned, as an organization, with this latter issue more than the loss of people who can’t/won’t accept trying the Agile approach.

  5. The company where I work switched to Agile methodology (SCRUM) from a more traditional waterfall methodology. The way the change was implemented seemed to have rubbed many employees in a bad way. Managers were basically demoted to just team members (two levels down for some). R&D was divided into feature teams (good in my opinion) but this was done without any consultation. This meant that people who were subject matters in particular areas are now on teams where they are novices – as you guessed there was a learning period for many (months). When someone asked a few hard questions in our SCRUM training management was quick to crack the whip and said individuals were fired for disrespect – as they went out the door their was a knowledge gap created. So it seems our management failed on points 3 and 4.

  6. Hi John,

    Transition stories like this just break my heart. Any significant transition is difficult enough without adding short-sighted fear-inducing management practices. My sympathies to you.

    I hope that your management is able to recognize the extent to which their policies are creating chaos. Unfortunately, my experience is that managers who think that it’s reasonable to fire someone for “disrespect” just for asking questions will also tend to blame the workers when they don’t see the promised benefits of Agile. Best of luck to you. It sounds like an incredibly difficult situation.

  7. Pingback: QuickLinks for December | (Agile) Testing

  8. “…reward collaboration instead of individual achievement…”

    I think it’s fair to say that this is a tall order in many environments unless there is complete, in-total “buy-in” from management about the Agile/Scrum/Kanban methods being used, and not abject cluelessness.

    Many environments (thinking of one in particular) practice so-called Management by Objective, which usually contains a significant “individual performance” component.

    It also seems that quantifying “how well one collaborates” is a challenge.

  9. Misquoted the original phrase which is “collaboration over individual achievement”, but even with this subtle difference … previous comments, still apply.

  10. I think one of the big challenges for sudden implementation of Agile is ‘Employee Retention’.
    Managers trying to implement it will be focused more on the bonus (for so called ‘improvement’) than understanding Employee Satisfaction.

  11. I found this article because I was wondering if there have been any studies done on what % of employees tend to quit due to an Agile transition. Is 20% really an accurate estimate? I wouldn’t be surprised if it was actually more than 20%, but that comes from very limited experience (only my current company, which is in the early stages of Agile transition).

    What some companies and many managers fail to grasp about Agile is, there’s no free lunch. You can’t get more quantity of products developed, faster release cycles, better quality, and less or the same workload for your employees. Something has to be sacrificed, and it’s not going to be quantity or speed. So what’s left? Quality, and the strain on employees’ personal lives.

    Given that some employees (myself included) are not overly inclined to sacrifice quality for speed, nor sacrifice their personal lives to participate in a never-ending stream of meetings (in addition to the extra actual work, the meetings…. god the meetings…), my assumption is that probably around half the company is currently considering whether it would be better for themselves personally to move on.

Leave a Reply

Your email address will not be published. Required fields are marked *