Your company wants to become agile. Most companies want that. So they hire some consultants, do a couple of re-orgs, call their line managers Scrum Masters, and so on. And then they declare success: Development is a little bit cheaper now. But many of those companies with "successful" agile transitions did not really become agile. They don't have real business agility or sustainable development or truly self-organized teams.
The ugly truth is: If your company is not already agile, it most likely will not become agile. Not within a reasonable period of time. Sure, you can do all the little rituals that Scrum mandates. You can even fully implement all the extra stuff that SAFe wants you to do. But this does not make you agile. This is not what I am talking about.
I am talking about true business agility. And many companies are struggling hard to achieve it. They are not even moving in the right direction. Even though they "sucessfully" implemented Scrum (or any other "agile" process).
Business agility is the "ability of a business system to rapidly respond to change by adapting its initial stable configuration"
The problem is: It does not matter that you successfully implemented Scrum or Kanban or SAFe in your development team. It does not matter that you do continuous integration or devops or noops. If your company is not able to move fast and change direction quickly, it is not agile.
The only thing that matters is its agility: how fast can the company change when the context changes. Agility is a property of the organization, not of a team. Improving agility usually includes using agile and lean practices at team level, but it’s not the full story.
And if your company is not already agile, don't wait for it to become agile in the near future. "Agile" is not a new trend. "eXtreme Programming eXplained" was published 16 years ago, as of this writing. So, if your software company is not agile yet, it is already 16 years late.
Sure, some companies can and will change. But for many companies, this will take a long time. Longer than one would reasonably wait. In this article series, I will list some reasons why many companies cannot easily become agile, even when they adopt agile practices (Spoiler: Change is hard. Most companies have processes and policies in place that prevent certain kinds of changes.). So, if you are waiting for your company to become truly agile, try to face the truth: It might never make it.
But does it matter?
Everyone is affected by Economic Darwinism. In the long run, only those will survive who meet the customer needs and demands best.
Yes, it matters. Because, as Uwe Friedrichsen explains in his conference talks about "The Next Generation of IT", economic darwinism affects every company.
Some companies already feel the heat, for others it might take years or even decades until there will be a dangerous competitor (think: regulated industries, government institutions, ...).
At some point, a company will come that meets the customers needs better and faster than all the others. You can only hope this is your company.
Here are some reasons why companies have a hard time becoming agile:
In order to be good at software development, you need an organization that's optimized for software development
If your company is organized in too many departments or if it has the wrong department / team structure, you will struggle to become agile. An organizational structure that is not optimized for software development will be slow because there are too many hand-offs and deadlocks/live locks in your organization.
I am talking about a demand / supply split, for example. Or separate Development / QA / Operations departments. Those are things that impede your efforts of becoming agile.
Annual Budgets are, by definition, not very agile. The same goes for fixed budgets for big projects. You lay out the basics of your companies finances for the next year - or longer. Changing direction quickly is not possible, especially late when the budget runs low. You'll often hear things like "We don't have money for that" - Even for necessary changes.
Bonus Systems are even worse - They encourage local optimization. People will work against each other to rescue their bonus. They won't do anything that could endanger their bonus - Even if this endangers the future of their company.
Top managers of most companies want their company to be able to react quickly. People at the bottom of the hierarchy - Developers, testers, ... - often want to be agile. But many efforts are killed by middle management.
Don't get me wrong - they don't want to be the problem. They are probably not doing this on purpose. But they are concerned about their jobs and their bonuses. Especially in companies that do not have a great failure culture.
Coming soon: Why you need a great failure culture and the right middle management to become agile.
Many companies have policies and procedures in place that completely kill the motivation of all people involved - Managers, developers, testers, operations engineers, ... . People are not allowed or able to do good work because policies, beaurocracy or a lack of funding prevents them. So they don't try anymore - They become demotivated. It is extremely hard to change those policies, because they have been in place for very long.
Sometimes nobody even sees those problems anymore - People develop blind spots. When there is a problem you cannot solve for a long time, you don't see it anymore. But motivation suffers. And without motivation, change is not possible.
Coming soon: You need motivated people that work towards a shared goal to implement change.
Why do many big / old organizations have so many management layers? Why do they have so many policies and processes in place? Why do they have all those departments, communication channels, escalation paths, and so on? Why did they become a bureaucracy?
Probably this didn't happen by accident. They became this way for a reason. Something bad happened, so they created a policy to prevent that in the future. They tried to save money by centralizing IT or Testing or Operations. And so on. For all the little details that build up the bureaucracy, there is a valid reason that can be found in the past of the company.
The problem here is that all those little details make up a system of policies and processes where it became hard for people to do their actual work. So you have to see if you can get rid of many of your processes and policies, even though they might make sense. And you have to make sure that you don't create processes and policies as a reaction one-time events - That you don't scar on the first cut.
Coming Soon: Why you need to relentlessly simplify your company, all the time.
I also have two case studies of companies that managed to stay agile or become agile. They are here to act as counter-examples to the claim "Your company will never be agile". I interviewed their top management and tried to summarize what they are doing right - from my point of view.
Smarter Ecommerce: A small, international company that has been agile from the get-go. They are sticking to their values, but contstantly changing their process. They practice continuous learning and improvement.
Read the case study: "Technical Excellence at Smarter Ecommerce"
So, your organization does not get all the topics mentioned above perfectly right. Is all hope lost? Will you never be agile?
I'm afraid it's not that clear-cut. Noone gets everything perfectly right - At least no company I know. But every area where you still have room for improvement is an impediment for your effort in becoming more agile. It is an impediment to delivering more value to your customers faster. It is an impediment to earning more money sooner.
Noone gets everything perfectly right - But successful organizations are constantly searching for areas where they can improve. And then they implement those improvements in a rigorous, sustainable, safe-to-fail way. Even if it means making big changes to their organizational structure or policies.
Want to get notified when I write the next article in this series? Subscribe to my newsletter (you should also see a popup below) and you'll get a mail with my next article.
My name is David Tanzer and I have been working as an independent software consultant since 2006. I help my clients to develop software right and to develop the right software by providing training, coaching and consultanting for teams and individuals.