The word “agile”has become somewhat of a controversial term in many groups. While many organizations and teams claim to be “agile”, in reality few are. This has caused the essence of agility to be diluted, not because it isn’t as valuable as it promises to be, but because it is misunderstood so easily.
Becoming agile is a journey. It’s not an on-off switch that you can simply turn on. It takes time, and it takes a lot of effort. And mostly, it takes opening yourself up to try and learn a lot of new things.
When I first came across the world of quality— which is at the heart of the Scrum process design as I’ll explain later — it literally took me the best of 2 years of learning and teaching it to others to fully understand the concept of quality and the underlying work of Deming (in which I’m still not an expert to this day). Little did I know how important this foundation would become later in my career. At that stage, the word Agile or Scrum didn’t exist mainstream yet.
Agile coaches then were known as Quality Managers.
When I came across the Theory of Constraints —a process to identify and support those things that stopyou from being productive — it again took years to master the principles (and I wouldn’t call myself a master at all).
Psychology, human behavior, change and habits are subjects I’ve actively been studying for more than 5 years and each day I realize exactly how little I know. It is, however, the most basic goal of agility to change human behavior and harmful patterns into healthy habits.
Coaching and the art of asking the right questions to guide a person towards an answer rather than telling it was one of the hardest skills I’ve had to develop, as it asks you to unlearn everything management has told you a good ‘manager’ should do for the past 100 years. It definitely doesn’t take a few days or even a few weeks or even months to develop and it takes a lot of actual practice, something I don’t think I’ve mastered yet.
Yet, people call themselves agile coacheswhen most are unable to pose any questions when dealing with teams, so used to giving instructions. Traditionally, the manager or specialist was the one who had the most experience and they saw their role as telling people how to do something. Asking doesn’t come natural to us.
Maybe I’m a slow learner, but even as a slow learner there is no comparison as to the depth a person can go into on a subject in years compared to a few days of isolated classroom training. It’s an ongoing learning journey to each day become a little bit better. It doesn’t stop. It evolves.
The first mistake most people (including me) make — sometimes out of laziness (as in in my case) or out of ignorance (in many more cases) is using the word to describe something vastly bigger than what the word actually means. The word “agile” has been changed from the intended adjective to describe howsoftware (and specifically software) is developed in the manifesto for agile software development, into a proper noun to refer to teams, organizations and even tools. As a result the meaning of the word has gotten lost in translation.
Where the intent of the manifesto was to serve as north star and compass to help teams develop software in ways that better responds to changing requirements and needs, it became an abstract term to describe anything you wished to perceive as ‘better’than other teams, organizations or processes. If you started using Slack after it was previously banned in your organization, suddenly this new felt mere snippet of freedom was considered a sign of organizational agility. If your team had a Scrum board (even if it was only on Jira or Trello) and used sticky notes, people deemed themselves as more ‘agile’than those mere mortals who didn’t. If they had a backlog and daily standups, they were considered super‘agile’in relation to those doomed to long sit-down meetings.
