Hello World!
Recently, I got the opportunity to listen to someone, that proposed to "Demystify Agile"... and I feel it's a cool idea... now I'm writing about it...
So let's go!
...how can we demystify Agile? mmmm
Ok, I think first we need to define what is something "mystic". In this context I would assume that it refers to "pseudoscience". Or also what in the streets is called:
Pseudoscience: Agile Smoke
In the market, it is easy to find a lot of "consultants" selling "smoke" about agility. And when someone is selling something, it's only because some others are buying it.
During the last 10 years, the market was flooded with "fake agilists". Some of them are selling "agile" without having the "agile mindset", or just selling the word as a "buzzword". Some of them were selling a "cosmetic agility", what is to "look like agile", let's say "using post-its everywhere", having a lot of "team meetings", showing that we have a "relaxed working space"... etc...
Suddenly, almost everyone wanted to be "agile", but very few knew "why".
And the common answer to the "why" question, used to be: "everyone is doing that".
But there is two types of pseudoscience: the one that "looks like a clown", and the one that "looks serious".
The problem with this situation is, that we should not follow our assumptions, that an authentic agility should looks "serious"... because we can fall into two possible mistakes:
- We think someone is "agile", because it looks formal and serious.
- We think someone is "pseudoscience", because it looks like a clown (for us)
The difference between "science" and "pseudoscience" is not the aspect or esthetics... the difference relies in the functionality.
The difference, we may agree, between science and pseudoscience, is that pseudoscience is not functional.
Agile is a process to improve product delivery.
No.
Its not...
... first it is not a "process", it is a "cultural phenomenon", and the purpose is not to produce more unnecessary gadgets to people we never met.
This perspective tries to use "agile" as a "management tool", to solve the "management problem": how to organize resources to fulfill contracts on time and budget.
Agile is not just another "management tool", its far beyond that, it's much more than that.
But this simplistic and mechanic perspective could be functional for starters. When you are starting with an "Agile Transformation", the easiest way to do so, is to transform processes, paint the walls and move the chairs... it's ok to start there and also good to know that it's not the limit.
Well... if Agile is not cosmetic, it's not simple processes, it's not a management tool... then,
- how can we "demystify agile"?
Let's suppose that to "demystify" something is to "understand" it. I think is much more easier to understand the phenomenon, if we take a look on it's context, instead of trying to explain it... and also to have a look into it's components.
Let's try, if we can demystify agility together... if you have any question or suggestion, please write me an email...
Context: Where comes Agile from?
The Software crisis. During the 80's and 90's, there was a "pandemic failure" in software industry... the traditional waterfall methods were failing with full effectivity. The old hierarchical command and control strategy was not effective to drive software projects. The world was looking for a solution, until 17 gurus met in Utah and in one weekend they found the "Manifesto for Agile Software Development".
The world was changing and the software products became more and more complex... and the cryptonite that defeated classical management was that: complexity.
If this was relevant on the 80's, imagine how relevant agility is today. It became Urgent.
In order to deal with complexity, it's a better strategy to have "flexible plans", "open collaboration channels", "self-organized and self-managed teams" and to establish a "learn-friendly environment".
In 25 years, we evolve from the mechanical typewriter to the IPhone... but organizations are not so well and fast on changing and adapting...
Let's take a look into those components:
Components: agility pieces
- flexible plans
- We abandon the waterfall practices by implementing iterative-evolutive methods
- open collaboration channels
- the opposite of collaboration is competition.
- self-organized and self-managed teams
- we cannot deal with complexity by micro-managing human beings.
- learn-friendly environment
- psychological safety and Dignity, are required components for an agile organization.
If we review the mechanic definition to consider agility as a way to "improve delivery", we can see, that in the "heart of agile", we are addressing two areas, of four of them.
You can be improving processes, reaching efficiency and moving faster (what is always interesting and welcome) but it doesn't means necessarily that you are sustainable, that your organization is evolving into its best version, or you will be ready to adapt to the next crisis.
Agile is about adaptability, not velocity.
When those gurus where searching a name for this new strategy, the "best name" for it was "adaptive", but it was not possible, 'cause of registered trademarks, then finally the chosen name was "agile".
I think it's not casual, that the organizations that finds more difficulties to transform to agility, are those old-fashioned, conservative and traditional ones... but it's not a matter of "processes", not only... its a matter of culture.
- why cultural change is not optional?
Because culture defines your behavior, your communication, collaboration and inter-dependencies... culture is the believes system that drives you... and also even defines how open are you to change and adapt... there is cultures more closed to adapt and others more open to change.
- Learn
- Evolve
- Collaborate
- Change
That's why the market talks about "agile transformations", and not about "agile implementations", because a transformation is an important reframing of your own mindset.
Ok, now sounds like pseudoscience? Let me explain why not...
How can we avoid to fall into pseudoscience?
Pseudoscience trends to reaffirm a "rationalized explanation" about the world we habit. But without testing, without experimentation.
Usually arguments are like:
- because of yes
- because I'm the boss
- why not?
- we always did that way, and it works
So, I think the easiest way to avoid falling into the pseudoscience trap, is to embrace experimentation, validation and tests.
You can start to implement frameworks, processes and methods, it's a good start, but it's just the beginning.
Later you can learn and develop a "team-working" culture. Learning to collaborate from the experience itself.
The most popular, common, simple and effective tool for cultural change: education.
Establish internal and external trainings, and exchange between professionals and teams. Learn from every source you can... Open spaces for learning groups, for example.
It's not a rocket science. It's just school science... But it is science.
What's next?
Keep it rolling! And remember: it's not complicated. And if it's becoming complicated, review your strategy, experiment, learn, adapt and enjoy changing.
I hope you like this attempt to "demystify agile culture".
Let me know if something is missing or hard to understand in this post and help me to help you...
Happy Change!
Daniel
