3 Reasons Your Engineers Don’t like Agile Development and 3 Tips to Fix It

If you are planning to adopt Agile Development practices, chances are, you will encounter resistance from a variety of sources within your organization. This should be expected, since we as human beings generally don’t like change, because change disrupts equilibrium and introduces risk to our sense of security and safety. However, if you want to remain competitive and adaptive to change, you must have buy-in from your organization, especially on the ground level – your engineering staff – in order to succeed.

If you are an experienced Agilist, you may assume your engineering staff will like Agile because it is common sense. Why would they NOT want autonomy? Why would they want to keep being told what to do? Why would they NOT appreciate the opportunity to get feedback early and often? These are some questions that you may ask yourself as you encounter resistance to change.

The truth is, engineers do not always like what Agile Development means to them because it changes how they work. It forces them to do things that are uncomfortable for a variety of reasons. Here are a few issues that you will likely encounter, as well as a few tips that may help you address them.

Reason #1 – Too much freedom

We often assume that every engineer desires freedom to tackle a problem and implement a solution that they want, instead of being told exactly how to do it. While this may be true in many cases, you may be surprised to find that many engineers are not used to working in this way. In my experience, some engineers prefer to be told how to implement a feature because they are unsure of themselves, or do not have the experience or courage to take a risk and suggest a new solution.

Tip to address – If we give people an opportunity to think for themselves, it would be beneficial to provide them with the necessary support and guidance to ensure they can succeed. This may take the form of pair-work (i.e. assigning a more senior team member to help out).

Reason #2 – Too much transparency

Agile Development relies on the entire team to hold each other accountable and have the confidence (and psychology safety) to bring up issues as early as possible. We assume that engineers will ask for help when they need it, instead of spinning their wheel for days trying to solve a problem that someone else on the team may have already solved previously. However, this is simply not always the case. From my experience, technical people take a lot of pride in themselves and their work, and admitting that they can’t solve a problem is often very difficult because it could be perceived as being incompetent. Agile shines a bit bright spotlight on people who may not be used to that level of scrutiny, which could be counterproductive.

Tip to address – Building psychological safety is key to being transparent. If the team is new to this way of working, try to take focus away from individuals and shape the work so that collaborative ownership is encouraged. Instead of allowing individual team members to work on their own tasks, experiment with pair-work to cultivate a sense of collective accountability.

Reason #3 – Progress is difficult to gauge

Traditional projects usually have rigid schedules, milestones, and detailed assignments that provide a forecast of how work will be executed. More often than not, this schedule usually becomes a fictional prediction that turns out to be incorrect, but it can still offer some focus to the team doing the work. In Agile Development, you may not have such a schedule to provide the bigger picture, which means that the team could lose sight of the end goal. Engineers tend to appreciate and gravitate towards concrete outcomes, so they may feel lost within an Agile project.

Tip to address – To help the team stay connected to the end objectives, you may create and share a release burndown or release plan that is built with collaboration from the team. This tool could enhance the visibility into longer-term goals.

To sum up, your engineering staff must learn to be effective and perform at their expected levels in order for Agile Development to work. You must get them on your side if you wish to do work in a new way. Change is hard for anyone who wants to do meaningful work, so you will need to have patience, and as usual, seek help from experienced experts where needed!