Cultural Roadblocks to Implementing Agile

If you had asked me a couple of years ago what type of people didn't like Agile software methodologies, I would have said "people who never tried it and managers with too much focus on the wrong success metrics". If you had told me that there were people who didn't like Agile because they didn't truly understand it, but tried (and failed) to deliver software using Waterfall methodologies altered just enough to look like Agile, I wouldn't have been surprised. But it pains me to admit that I rather naïvely believed that people simply needed to be shown the benefits of using Agile to design, develop, and deliver software in order to become believers. Now I know better. While I still believe that Agile is a superior methodology to delivering software if you care about the right things, here are some (interrelated) cultural problems that can be significant roadblocks to finishing a successful Agile software project.

Unwillingness to change staffing

Central to Agile's core principles is responding to change well. This is important because software needs change quickly and often. In some cases, this can occur because business needs can change on a dime, e.g. a new competitor enters the market. In many cases, change occurs because people working with new software improve their understanding of the underlying need. Whatever the reason, though, software makers need to be able to change quickly.

Because such change is expected, it is impossible to set firm budgets, timelines, or scope for an Agile software project. But it's largely a project manager's job to track and maintain timelines, budget, and scope for projects. Sticking a traditional project manager on an Agile software project is at best a waste of the project manager's time. At worst, though, his/her presence and influence can undermine the newfound agility of the software team.

Unwillingness to embrace uncertainty

As I said earlier, change is expected within the course of completing an Agile software project. Agile teams are built to adapt to these changes by handling the most important issues as they arise and dealing with the rest later. However, some business leaders want to have a plan for every possibility. Spending time to plan for a situation that will never happen is a waste of time and resources under the best of circumstances. But when taken too far, this can lead to "analysis paralysis" and kill the progress of a software team.

Lack of leadership

When ever-shifting priorities are built into your process and mindset, it is easy to get distracted with items of relatively little importance to the organization. Leaders with a strong sense of true business priorities who can persuade others what the right path is will keep the software product moving in the right direction. Weak leadership will allow individuals with a personal agenda to hijack the effort of a software team. Or just as bad, multiple people can try to take the product in multiple disparate directions, creating confusion and frustration in the team while leading to an unfocused product.

Lack of personal responsibility

If you had shown all the items on this list to me five years ago, this one would have surprised me the most. After all, who doesn't want to do a little extra work in order to do much less work in the long run? Agile requires constant communication between the software team and the business leadership, but it also requires business leadership to make decisions and make their teams ready for the coming changes. But not all leaders are willing to do so, unfortunately. There are two attitudes that I've seen from these people:

• People who believe that software is the job of the "techies", so they don't wish to make any decisions regarding the software
• People who avoid getting deeply involved so they don't have to take blame if the project fails, but try to stay superficially involved so they can claim a portion of any successes

Regardless of the reason, to depend on these people who won't take responsibility for the success of their area will almost certainly derail your Agile effort.

Inability to see the big picture

When you are constantly reprioritizing your queue, you need to have a grasp of the big picture, both in terms of current state and ideal future state, to know what features/fixes should be worked on first. When you don't see the big picture, everything seems like a high priority. And to quote a former co-worker of mine, "when everything is a high priority, nothing is a high priority". In such environments, it becomes nearly impossible to know when anything will get done. This will cause people to first lose faith that their items will get done, then to lose faith in both the project and process as a whole.

Extreme change aversion

Few people like change. But there are some people for which change is something that causes extreme anxiety. You can tell who these people are fairly easily in meetings - at the mere suggestion that they might have to rethink what they do their eyes get wide, they literally brace themselves in their chair, etc. When the mere suggestion of a single change can cause this level of anxiety, the thought of constant change can lead to mental shutdown.

Conclusion

Change is hard under the best of circumstances. Changing to Agile is no exception. When you're not dealing with the best of circumstances, it's vitally important to identify that as early as possible to make appropriate adjustments. If you have a team that's smart, is willing to take charge, and is willing to change, then you'll likely have a relatively smooth transition to Agile. If not, then you'll need to take additional steps to prepare your leadership team and the rest of the company for the change.