Do you believe in agility?
In a remarkable post here on the t2informatik blog, author André Claaßen has now written a few important things about agility. And he is right in many things.
The Agile Manifesto as a scripture of faith
What we are now experiencing in many places is the elevation of agility to a kind of religion whose sacred scripture is the agile manifesto. This is partly due to the fact that many of the points mentioned in the manifesto have characteristics that developers find very accommodating, such as the (interpreted) renunciation of (unloved) documentation and architecture, or the focus on software. Other points are often left out at their own discretion. The similarities with religious writings are striking. One takes parts and quotations from them, which are then used as justification for one’s own actions, in the name of agility. We are agile. End of the discussion.
The consequences of grassroots movement
In most companies, agility is implemented bottom-up as a grassroots movement. From bottom to top. With a generous renunciation of the top while losing the consideration of organisational elements. While the rest of the company is rooted in conventional concepts, small, agile islands of (supposed) bliss are formed. As a result, a not inconsiderable effort is actually invested in synchronising the two worlds. We do allow the teams some self-organisation, but not too much, so that we as an organisation don’t fly out of the curve altogether. Meanwhile, the rest of the organisation continues to turn in the old world. Dr. Andreas Zeuch has written a nice article about this here in the t2informatik blog.
To sell agility within the company and further up the ladder, the good old “we’ll get better-faster-cheaper” argument applies, fully aware that these things are not necessarily the strengths of agile working. But it is the argument that works best at the top. Which in turn raises expectations that cannot be met. Which brings us to the topic of faith. And the old, familiar conflicts that arise from faith and the misunderstandings that come with it. History is full of them, as is well known.
Agility has several aspects
Religions are not essentially about scriptures, just as agility is not about documenting (aka manifesting) rules. It is about values. It is about mindset. It’s about doing the right thing and leaving the wrong thing. It is not about calling the child agility and then following manual/faith scripture. It’s about implementing certain functioning values and mechanisms in the right place and adapting them so that you can get the most out of them. Not about sticking to precepts.
We know that daily synchronisation meetings have a positive effect on team collaboration. We know that regular retrospectives help us to learn from mistakes. We know that focusing on concentrated, short cycles leads to fast and good results and short reaction time to changes. We know many things that have a positive effect and why they do so. Not all are written in manifestos.
It’ s about best practices. These always have an effect and a causality as to why they work. That is why they are best practices.
What it is not about is sticking to wordings. Just because it’s called agile doesn’t mean that it’s agile. And just because it contains agile elements, it is not necessarily agile. And anyway, what is agile?
The debates on the wording
To rely on branded wordings is at best faith, but it leads us nowhere. Every company, every organisation needs its own way, its own measures, regardless of what the child may be called. Scrum does not work for every setup. In the regulatory environment, for example, it is very difficult to adhere to the basic rules given by Scrum. This is due to the nature of regulations that require security and stability. Scrum, on the other hand, shows its strengths in dynamic environments – dynamic requirements, fast customer feedback, etc. As a methodology, Scrum in turn possesses possibilities which, as Best Practice, can have a lot of positive effects. As a result, organisations adopt some of these possibilities. Quasi a bit of Scrum. The discussions whether this is still called agile or Scrum are still ongoing. But for what?
Debates about wording don’t help. Much more purposeful is the discussion of precisely those best practices that have proven themselves in the company and which then work in conjunction with the organisation. Interfaces, responsibilities, mindset, culture. These are the important topics. In the end, we have to deliver a product that makes relatively little difference whether we call the process of its production agile or not.
Doing the right thing
From the last 25 years of development, there is a wealth of measures that have proven themselves in a wide variety of organisations. A catalogue, from which one can and should help oneself informally.
Each measure includes the question of how it could fit into one’s own organisation, what goal I want to achieve with it and what I have to change in order to do so. Such measures exist on a wide variety of topics: leadership, quality, planning, implementation, interaction with stakeholders, etc. But be careful: throwing puzzle pieces into a bag and shaking them hoping that a picture would come out does not work. You should already know what you are doing.
By decoupling wordings from real implementations, we free ourselves from dogmas and focus on the essential. It’s about doing the right thing and leaving the wrong thing. What works in our organisational environment, in our socio-economic system, and what does not. Also under consideration of a cost-benefit calculation.
Many aspects and elements certainly come from the agile world, but other parts do not. Questioning and correcting the setup in the organisation on a regular basis ultimately leads away from faith and towards knowledge. That is the point. And everyone can grow from it: teams, companies, employees, stakeholders.
Note:
Oliver Fels has published another article in the t2informatik Blog:
Work agile or be agile
