"Agile" is a really good name to unify all of the Manifesto principles. It carries all the weight of real-world imperfect practice on its strong shoulders of faith in the ideals and motivation. Like a torch of fire, it brings a feeling of the right direction on your path amidst the shadows of real business processes. And like all great idealistic ideas, it requires a key to open the door to practical realization. This key is freedom.

You couldn’t find two equal Agile processes utilized in two different development teams. The final approach is always personal and unique. Meanwhile, we could categorize all of them into two groups easily: effective, really productive approaches and non-working, imitating processes. But there is a single element which is repeated in a big number of inefficient cases… And it is lack of freedom.

Freedom is the enemy of fear and the best friend of an open mind. While ‘freedom’ is too abstract, psychological safety is more practical and specific to the real world. This article describes the importance of psychological safety really well. I totally agree with the author that it is the most crucial thing that Agile will never work without.

I saw different projects with a wide variety of Agile processes, but a lot of them failed for the same reason - not enough safety for personnel. Managers could struggle trying to understand why their great techniques don’t work, coming up with more and more options having the same result. But the key is usually in close proximity. The fact is that performers often know how to fix the processes even though they possibly don’t know all those “cool” management techniques. The team sees the workflow live from within and the only thing preventing them from telling management the truth is a lack of psychological safety to do this.

Sometimes it seems like the team is just not motivated, but as per my experience, it is often just a final stage of a long term absence of comfortable communication. Not by chance, “Individuals and interactions over processes and tools” precept sits at the first place in the list of Agile manifesto principles. It is much deeper than “we need to find qualified people and processes will work.” Moreover, experienced and highly qualified people are even more dependent on this principle as they have seen different projects, they know how things could and should work, they strive for the best. And through this, they quickly start to feel when processes are artificial and the communication base is low, when management uses psychological tricks to manipulate team members instead of creating a safe and honest environment.

The article I mentioned gives advice to a Manager or Leader on how to establish a solid foundation of safety for the team. But I’d like to share some thoughts from an ordinary team member's perspective, on how you could improve the situation from within without being a high-level decision-maker.

You could have more clear vision or realise whole the situation with processes better from your point of view having more frank relationship with your team members than your management. In this case it is your professional and moral duty to improve the situation.

Motivation

And the first big cornerstone for you could be motivation. It is really hard to do something when your actions are not supported. Your bosses could miss the big picture and aim only at visible business goals they can blindly reach with their hands.

In this scenario, you could find motivation in yourself and your nearest colleagues with whom you work every day. Striving for the ideal could be your engine, self-realization through making something meaningful and important despite resistance.

Also, you need to understand that insufficient processes are not only a company concern; they make your everyday life worse. First and foremost, your work experience is your responsibility. Stop complaining and start to improve step by step.

Your professionalism is significantly limited by bad psychological safety in your team; freedom in your daily work concerns you directly. Simplifying things, basically, your workflow as a Developer, for example, is to make a feature or fix a bug, find some more issues on your way, and process them to move forward more effectively. In a simplified version: do, find, handle, and iterate. Your professionalism is about ‘do’ and ‘find,’ but if ‘handling’ is not effective in your environment, your effectiveness with ‘do’ and ‘find’ also suffers. If you couldn’t or don’t want to tell a team or management about some part of code that limits your speed, you have to struggle with this code again and again, spending extra time and your nerves.

By the way, Agile was manifested by Developers, not by Managers. You definitely should be interested in it.

Explanation

When you have the motivation to make things better, it is time to take off your armor and break out of the shell to get some “agility.” And the first thing to try is to speak with management, telling them about the weak sides of your processes. Your goal is to make them understand what you as a team could gain from the improvement.

One approach is to describe how the business is impacted negatively by drawbacks. To make people listen, you need to demonstrate your professionalism in an accessible way. It's good if you could show some proof of concepts or show numbers. It could be a hard task, especially considering we talk about processes which could be rather abstract and hard to calculate or prove their efficiency. But it is worth the try.

Uniting with your nearest teammates also works well. It is a part of team play, and such synergy could influence your management more.

Action

Even a failed attempt to explain shouldn’t stop you from implementing improvements. Every little bit helps.

• Start to plan your assigned tickets better, divide your work into pieces more accurately, be more active in retros, or establish a self-retro if you don’t have these types of meetings in your team.
• Find ‘easy wins’ - general issues that you could eliminate quickly in the scope of your current task.
• Communicate more often, show and explain drawbacks, include these drawbacks' fixes into future tickets by yourself.
• Generally, take more responsibility and become an example to your teammates. Help them actively, encourage and thank them frequently. Suggest engaging activities related to Agile, like Agile games.
• Initiate discussions with management and do not be afraid to argue with them.

And a other bunch of actions you could easily find on the internet as the main goal of this post is to remind you about freedom as the most essential part of Agile and motivate you to achieve this Holy Grail.