The Buddha said that nothing exists on its own and everything changes. His students called these the two core truths of all existence i.e. emptiness and impermanence. 2500 years later, despite the aid of countless wise men and women explaining these apparently simple concepts, millions of us are still trying to make sense of them.

In my first article in this series, I posited that the only problem Agile has is that it’s too concise. Since it’s not a prescriptive methodology, but a collection of values and principles, people feel lost when it comes to “becoming agile”. We lose countless hours interpreting the Agile values and principles, and countless more wondering about how and where to get started.

There is no switch to flip

I’ll be a good Agilist and tell you right away that there is no silver bullet to becoming Agile. Like learning any new skill, you have to put in a fair amount of effort, before you can practice the skill naturally.

We all know the driving license analogy. What starts with an intention to drive, has to be backed by some theoretical and practical lessons (perhaps also with a minor incident or two), and a fair amount of effort which finally culminates in an official qualification. When you do get your driving license, you don’t immediately become an expert driver. Expertise, even just the dissipation of the fear of driving can take quite some time to disappear — and only comes about AFTER you actually start driving.

So when it comes to Agile, the values and principles require a lot of practice, trial and error and re-enforcement before they become second nature. That’s when we could claim to be Agile.

But this assumes that you set your mind to it, got started, and kept going until you reached your goals. In real life though, transformation goes in stages, circles, and spirals.

Just think about any personal transformation. We go through stages of awareness, intention to change, initial effort, followed by concentrated regular effort, growing pains, the first fruits of change, enjoying the transformational process, integrating the changes, and eventually we reach a new status quo.

And in all these stages, there can be partial or total setbacks thanks to changing environment, one-off external or internal events, mother nature (e.g. Covid-19), self-sabotage, or overwhelm from increasing complexity.

All of this is true for an Agile transformation as well, since an Agile transformation is a people transformation first and foremost.

So it’s not just me, my intention to change, and my efforts?

Going back to what the Buddha said: “nothing exists on its own” or in other words, everything exists within (and with) a context. And so do people. People influence the system around them, but more often than not people conform to the system within which they operate..

In fact, sometimes people are already ready and willing to change, but the system around them might be keeping them stuck… There is another aspect of human psychology that has a huge influence on our behavior: relationships. Relationships change people.

I believe that an Agile transformation is first and foremost a transformation of people, and the system within which they operate. Organizations are nothing but groups of people who work with each other based on certain implicit or explicit agreements. These agreements color the experience and relationships of the people working together.

So if you want to make it easier for people to change, change the system, and facilitate better relationships.

We seem to miss this perspective in technology companies. Why?

Did you know that 74% of drivers worldwide believe that they are above-average drivers? I believe we have the same problem in the tech industry, but perhaps amplified to 90% or so.

In the tech industry, we seem to believe that we are so smart that no complex idea should be hard to understand and implement for us. Despite incredible amounts of evidence to the contrary, we continue to treat each other as perfect machines who, if they were fed the right instructions, would execute them flawlessly. For proof, just discuss social issues, politics, or Agile with a random group of programmers.

Even though I don’t personally believe it, I do think that we technologists, as a group, have bought into the idea of being emotionally unintelligent geeks who can do magic with machines. Along the way, we just started to model our workplace relationships just the same way as we did with our machines. Input, processing, output, bugs, frustrations and fixes. Except we forget the fact that people don’t work that way.

How does this connect back to agility and Agile transformations?

We have a huge blindspot when it comes to our personal and collective shortcomings and our very own complex human nature. And it shows in the countless failed transformations; in the companies and products that fail despite having big names and tons of money backing them, and in the projects that rarely get delivered on time or achieve the projected ROI (if someone’s keeping the score at all).

But instead of reflecting upon and acknowledging the difficult nature of the task, we continue to think that it’s just a matter of getting the instructions right (and if only people followed them to the letter).

I truly believe that our bad mental model i.e. expecting people to execute like machines is at fault here. And we do it all the time, especially to each other at work. We look at Scrum/Kanban/XP and do something vaguely resembling it, pat ourselves on the back, and continue laughing at the fools across the table who just don’t seem to get it.

And when it doesn’t quite work, we buy the next agile methodology, or the next training, and hope that the certificates will magically make everything work.

I have been in countless conversations where people argue incessantly about the definition of agile, PO vs PM, how the customers in their industry just don’t get it, and what actually constitutes good software engineering practices.

And almost all of these conversations (a) talk about other people and (b) use incredibly harsh language. It seems as if we have lost our capability to reflect upon ourselves, and when we do reflect, our aggressive language doesn’t invite constructive dialogue.

We have a kindness problem in the tech industry. And the Agile community has not been immune to it either. Our problem in the Agile community could be captured in “great ideas in terrible packaging, and annoyingly presented”.

Just observe the language we often use when talking about Agile adoption. Have you ever heard something like: “Those QA people, they’re not agile! Or those stupid project managers, they don’t get it! Management doesn’t care about engineering! Our customers are too old school…”?

No wonder all “those other people” stop listening. Words rarely change people for the better, relationships do. And our language is often destructive rather than constructive; while we little to no effort goes into really understanding the “other” side.

I pray that even when we know we are right, we find it in ourselves to have some empathy for our colleagues, and that our attempts to convince others to change are born from good intention and infused with kindness, not contempt.

Transformation goes way deeper than words

Like all learning processes, the first thing you realize is that you don’t know much.

As you become better at your transformation efforts and become more aware; you start seeing your weak spots. Most people give up at this point and end up back at square one or worse. If you find yourself continuing despite these growing pains, rest assured, there’ll be more to come.

Just before we manage to fully transform, we feel the worst anxieties, and heavy emotions, as we face the fact that who we were and what we previously believed must be left behind, perhaps even along with some friends and relationships.

Transformation essentially means that we become someone new, more distinct from the person we once were. We change or adopt different attitudes, habits, and beliefs. And we learn to let go of the image we had of ourselves in order to embrace the uncertain future of this ‘new’ self.

No wonder it’s not easy or straightforward, even when you fully believe in the necessity to transform. You will inevitably find yourself procrastinating, slowing down, reverting back to old habits, self-sabotaging, finding excuses to abort the whole process, questioning your own motivation or ability to carry this through. Because it hits at the core of who you are.

So you need a lot of motivation, effort, persistence, self-leadership, and self-management, and a whole lot of support along the way.

If the Agile Manifesto was all about better ways to build viable software with people and their interactions at its core, then an Agile transformation is nothing more than a shift in how people collaborate.

And collaboration is a matter of how people relate to each other, more than just their defined roles in an organisational process.

So how do we do this crazy complex thing called Agile transformation?

Can you imagine a team — that does upfront planning, down to the days, has customers chasing them down every day, driven by contract negotiations and overrun by project managers who believe that engineers aren’t capable of understanding business and are just good for “execution teams”? — Now imagine this team changing from that to a beautiful cross-functional full-stack Product Developers’ team, just because they said they would.

Can you honestly expect these engineers to suddenly become great partners in software development despite years of learning to follow orders? I have seen engineers continue to wait for permission even after management agreed with them and allowed them to re-form into scrum teams. Usually the management then starts wondering when these engineers will take ownership.

We expect people to change, and sometimes we try to change them. And we never reflect. That’s not how this thing works.

You have to change the system, and coach the people.

Repeat after me: “Change the System, Coach the People”.

How do you change the system?

Focus on information, identity, incentives, infrastructure, communities, open communication, relationships, belonging, teamwork, achieving together and failing together in a safe environment. Change the system to allow for more open, honest, timely feedback loops. Use technology to your advantage, and make sure that the system fosters collaboration and co-creation, rather than isolating people.

Transformation is hard and we’re all too human, with habits and patterns of behavior reenforced through our belief systems and life experiences. We are slow to change, even in the face of clear knowledge and desire for it. So coach the people. Don’t try to change them, coach them.

An invitation to kindness

I want to close with a wish, and an invitation, to reflect upon and share our emotions and feelings more. To notice, and really see our colleagues, as they are: human beings with lives, pressures, and joys both inside and outside of work. Work with them, negotiate with them, and treat them with the same attention we would grant someone we were responsible to care for.

I hope you will see that any transformation will transpire naturally and joyfully if we went through it as an adventure together, rather than work that someone else needs to perform.

If you’re still waiting for the formula to do an Agile transformation, I highly recommend watching this talk about how not to do an agile transformation by Anton Zotin. Hopefully, you’ll get a few pointers on how to avoid some of the pitfalls.