The word Agile has become so fashionable that the LinkedIn community cannot live without it anymore. Still, many job advertisements say that the company is looking for an agile tester and developer (if not currently looking for a ninja). It may sound posh and fashionable, but as long as we do not want to employ a circus troupe, agility shouldn’t be the main recruitment criterion. At least in my opinion.
When browsing the feed on LinkedIn, you get the impression that regardless of the organization – not being agile – means not keeping up. Even when the organization is a large iceberg that is effective in its navigation, it tries to give the impression of a little jumping bunny. We can observe daily glitches of: agile development teams and agile testers (quite accidentally filling reports in Excel and tools that can be dated C14), agile projects (with Test Managers and Project Managers), and overall environmental agility. And fruity Wednesdays.
We also observe a growing group of Agile Coaches and a multitude of online courses and webinars on this subject, which, like a fairy, can fly into the world of ancient projects, wave the wand, and from that day on, everyone will work efficiently, happily and deliver twice as much.
I’m afraid it can’t be that way.
Does this mean that truly agile organizations don’t exist?
Let me move to the familiar topic of software testing. Twelve years have passed since Lisa Crispin and Janet Gregory published the book Agile Testing. It is already a full-fledged teenager. Since its continuation – More Agile Testing – 6 years.
Are the conclusions from reading about agile processes taking place in organizations valid also in 2020? Today, an agile approach to software development is no longer a novelty, but rather a standard. At the same time, like every common issue, it has had its modifications and pathologies.
The understanding of Agile has changed and organizations have started to interpret it in a way that suits one another. Unfortunately, as my project experience shows, the term Agile has become a convenient replacement for the lack of complete or unambiguous customer-side requirements, lack of documentation in the project, or simply organizational clutter.
The phrase “we work in agile” repeated like a mantra during recruitment, often means “we do not know which way we are going, but we row with all our strength“.
On the other hand, agility is nothing more than a way to reduce the cost of change and uncertainty.
Like I usually do, I decided to raise this issue in a wider group by asking a question on Twitter:
So many different views popped up on the same issue. An interesting discussion resulted from the question, ended with a live debate with the organizers of Agile Testing Days, the conclusions of which I would like to present to you.
Agile – what does it mean?
Constant improvement and constant adaptation.
A Feedback culture.
A space for personal development.
Change and adaptation.
The most memorable, however, are two sentences – Agility has different shades – and Agile means no fear of failure. This is probably what agile work is at the heart of today. It is not only following the pattern of XP, Scrum, or Kanban, nor is it the famous “we work in Agile because we have Dailies“, nor is it a colorful board in Jira. Agility is a different way of thinking.
How was it before?
In the traditional design model, you have done your best from start to finish to achieve the goal flickering in the distance. It was far, lots of dots to combine, but all were going in the same direction. The problem arose when, after a few months of work, it turned out that the client meant something completely different, and your dedicated work was…. in short, not needed.
In such situations, there is usually a wave of mutual accusations in the project team: “You should have written the requirements better”, “You should have coded better”, “You should have tested differently” etc.
The whole team became frustrated.
How can it be?
In the agile model of work, you encounter such situations every day, but you are mentally ready for them, you can adapt them as something normal, and accept the change.
A bit like in this joke:
Two friends meet. One confesses to the other that he wets himself at night. A friend recommends him a great psychologist, a well-known specialist. After some time of therapy, colleagues meet again and the guy recommending psychological help asks:
- Have you been to a psychologist?
- I was.
- How are you now?
- Did you stop getting wet at night?
- No, but now I’m proud of it!
And that’s a bit like Agile. The point is not that after adopting a new way of working, it will magically change the project. On the contrary, not only the team, but most of all the client will learn to live with small failures and constant change. Sometimes expensive ones.
The agile approach to work can help both – the project teams and the clients – understand that no one can predict market needs. No matter how hard we try – often the planning effect differs significantly from the final product, and it is influenced not only by our willingness or the ability to work in a team but above all by the budget, software, or market limitations.
We have to accept it and learn to live with it. At the same time, agility does not have to apply only to the team, but also to the entire company and all its employees.
In the above context, is the sentence I heard in one organization true:
“We are an agile organization because we switched to remote work during the pandemic.”
Survival – This is not agility.
Agility comes from willingness, from trial and error, not from a panicked attempt to save what you can. Moreover, adapting new things to evolve, maintaining positive trends, learning from mistakes, and adapting, not blindly returning to “what was before” – this is what, in my opinion, agility is.
Besides, it takes time to implement a different organizational culture and way of working.
If a given organization, a given project team, decides to evolve from a traditional model to a lighter one, they need time. It is not to be expected that the Agile – Fairy will come and use a magic spell to heal all the problems that have plagued the project for months or years.
Is it then worth adapting the change?
In 9 out of 10 cases I will say yes.
However, it cannot be done by force, or just because it is fashionable. A different approach to software development, recruiting, or treating an employee should be the result of evolution and the real need of the company and not a trick.
How is your organization like? Do you work in Agile?