Agile has been around for some thirty years now and there’s a good chance you’ve come across it in some way or another. There’s a good chance your organization has had a shot at applying it by using one of the many agile frameworks that have been developed.
In many cases it has become no more than a new way of working with little performance improvement to show for it. As a result, many organizations have tried and abandoned their shot at agility. So why even bother? Why should you bother with the agility of your organization when the benefits are either unclear or do not materialise? Is it just another fad that will pass in time…
You have probably seen it all come and go, and see some of it fail. Its failure might even have gone unnoticed to your organization.
To bother or not to bother, is that the question?
Asking yourself why you should bother about agile when the benefits don’t materialize, is like asking yourself why you should bother using a bicycle pump. You know why you’re using a bicycle pump. The benefits are obvious. And that is because you know it isn’t about the bicycle pump. You know that there’s something wrong with the tire. You don’t use the bicycle pump just because you’ve heard about how effective a tool it is. Using the pump is about riding your bicycle again.But what do you do when the pump doesn’t do the trick? You quickly conclude that there must be a reason the air keeps escaping. You probably won’t blame the pump for this. It’s blowing in the air allright. Instead, you end up fixing a leak in the inner tube of the tire. But what do you do when the same problem starts to recur over time? Will you blame the pump? Of Course not, because you know something must be causing the leaks right? As a result you might try changing your favorite route. ‘Cause hey, it might not be such a good idea to do laps around a glass recycling factory.
In the end we all know that it doesn’t make sense to expect the pump to have solved this problem. It is the cyclist that needs to solve it. The pump is nothing but a helpful tool.
It works the same with agile. It is not the quick solution to your problems. Agile has become a container term for concepts with very different meanings. There’s agile thinking, the agile values and principles for product development as stated in the Agile Manifesto, and agile sotware development practices. And last but not least agile as a set of frameworks that help to apply these values and principles in the practice of product development. Applying these concepts can help identify problems, and verify whether the solution was effective. However none of them fix problems by themselves. Applying any of these agile concepts effectively only makes transparent what needs to be fixed. But the fix needs to come from the people applying the concepts, not from the agile concepts itself.
Agile doesn’t solve your problems
So why do we expect agile to solve our problems or help us achieve our challenges just by applying it? To understand agile is to know that this is just silly. Agile doesn’t solve your problems, you do. Agile makes trouble transparent and requires you to understand this trouble and the context it arises in. This context consists of the structure, the processes, the behavior and capabilities of an organization and its people. Real understanding of this context is the key to lasting solutions, not the concept you’re applying.
Therefore you should not be bothered about agile because of the many fancy promising frameworks that make a claim to fame. You should be because in its essence it can challenge you to really understand your context. To bother about agile then becomes a question of whether you want to look at your organization in a way that makes you acknowledge its weaknesses and sore spots.
Take a step back to have look at your organization design
To answer the question whether organizations should bother about agile, or become agile, requires taking a step back to look at the organization. Identify its true purpose and the environment it operates in. This is important, because the design of an organization derives from its purpose and what it should optimize for. Organizations that produce a commodity service might want to optimize their design to achieve cost leadership. Organizations that develop innovative products in new markets will probably have to be designed in such a way that it is capable to adapt to continuously changing conditions.Organizations these days have to operate in an environment that is volatile, unpredictable, complex and ambiguous (VUCA). Organizations that embrace this VUCA world develop capabilities to deal with this, turning this challenge into their competitive advantage. To achieve these capabilities, such organizations have been designed in a way that they optimize for agility and become agile as a result.
At the beginning of the COVID-19 pandemic I worked for a Dutch government agency that was faced with an enormous challenge. The administration decided that businesses affected by the lockdown restrictions were to be compensated. The first policy to be effectuated was a compensation for patato and floriculture farmers. Due to the ability to quickly form cross functional teams consisting of developers, legal experts, domain experts, and process specialists, the organization dramatically reduced it’s time to market. The execution of such a policy would normally take months to be rolled out. Now it took only three weeks.
It is about the development of the right capabilities
When we look at agility from this perspective of competitiveness it becomes clear that this (whether one should bother or not) is not a question of which agile framework to apply, but a question of asking whether your organization is designed in a way that it is capable of developing the capabilities needed to gain this competitive advantage.
Agile organizations are adaptable. They have developed a capability that allows them to change focus and activities quickly at acceptable costs. Agile organizations also develop strong learning capabilities. They’ve learned to understand what causes problems and how to resolve them in a sustainable manner. Very much like the cyclist.
Try to be like the cyclist
Just as the cyclist needs to understand the cause of the recurring flat tires and have the flexibility to change the daily routine, an organization has to apply itself to develop similar capabilities. Only then can it prosper in a VUCA world. Don’t ask whether you should be bothered about agile, ask if you are blaming the pump or resolving the causes of all your flat tires.
In 2009, Jeroen first came into contact with agile working through Scrum. After a career as an analyst and project manager, he noticed the enormous contrast between the creation of agile organizations and the organization of classic software development. Jeroen has since been able to help many organizations and teams change to make this difference their own, and to organize for agility. In addition to being trained and experienced in Scrum, applying it on a large scale, and designing the organization that is needed for it, Jeroen is also a passionate facilitator of group processes. In facilitating workshops, multi-day off site sessions, and training, Jeroen derives enormous satisfaction from sharing his knowledge and the growth that people can experience together.