Organizations are living organisms – people inside are connected by an established culture and they all move the organization together. Trying to influence this established culture is a difficult undertaking. In the last couple of years, I have been working in organizations, each being at different level of becoming agile and adopting Agile mindset:

• such, implementing successfully Agile mindset & practices;
• such, being successful in being agile until another culture interferes;
• such, using waterfall model and believing the world is almost static and changes slowly.

In this post I have collected some patterns I have seen (both from my own experience and from others) that cause troubles to organization trying to become agile. I don’t claim this is an exhaustive list, but rather want to share what I have seen most often happen in such organizations. Here I assume the management has bought the idea of implementing Agile practices and work in that direction, because if there is no support, all initiatives would die early. You are very welcome to share your experience in the comments below; I will be happy to see that.

You try to plan everything upfront

One of the reasons why the Agile movement became popular, is the need of living as an organization in a dynamic world, where things change at a high pace daily. By using small iterations, organizations can move slowly ahead, get back and rethink things, and react to new trends when they arise. Making big plans upfront ties organizations and what usually happens is they spend time on things that become irrelevant later, because of the moving trends and behaviors. This doesn’t mean organization shouldn’t have a vision for the following couple of years, though, but they should be ready to adjust their plans constantly as they progress in the time.

You prefer writing e-mails than talking to each other directly

Research shows that talking verbally is more efficient than in a written form. Using your voice and your body language enriches the context of the conversation and allows both parties to understand each other better. I know it may be tiring to stand up from your desk and go to your colleague, but the effort is worth on the long run. E-mails are fine when you have already talked in person.

You write documentation for the sake of documentation

Writing documentation ensures your project has history. Like in school, when you read history, you get an (even bare) idea why things have ended up the way you see them today. What I usually see is two extremes: organizations writing too little documentation and others writing too much. The problem with documentation is it gets out of date the moment you stop writing it. Your project tends to evolve faster than you have time to go back and make sure all documents reflect the most recent state. It is important to find a golden mean for your organization. Be prepared to challenge everyone who asks you for tons of documents without providing a reasonable argument.

You do not deploy often to a production environment

While the other points are general, this one is mainly related to IT organization. The purpose of software is to be used by its end-users. When developers put effort in developing systems, they want to push the result of their work to the end-users as fast as possible. In reality this push is delayed by other processes – testing and QA, legal inspections, internal and external policies, etc. The problem is that developers are always busy and they continue working on other tasks. At some point you get a big package to deploy to your production environment. Statistically seen there is a bigger chance for an error when deploying a bigger package, than a smaller one. I become personally worried every time a big package has to be deployed, in spite of the automated pipeline we have implemented. Furthermore, if an error occurs after the deployment, chances are it will take you longer time to find the cause and fix it.

You do not seek input from your end-users

You do work, because it gives value to someone. But if you don’t seek feedback from your end-users, you will never deliver decent value to them. I have seen organizations being so focused on implementing and delivering their list of features, that they forget about asking their end-users: “Do you find any value in this?” This usually happens, because such organizations have upfront defined big lists of things to do and they don’t spend enough time to look at what they have produced and to make it better. One of the Agile practices is using small iterations to help you look back and assess your product: “Can we make it better?”