Organisations often adopt agile as a way to challenge their status quo. However, if agile is only seen as a process or method to manage the agility of your teams without first changing the way you think, it’s not going to work.

Often organisations aren’t happy with the rate of delivery on certain projects. They have no transparency and realise very late in the process that they are behind schedule. When they can’t keep up with the demand, someone else always seems to deliver faster. That’s when things need to change, and they turn to agile for the answer.

Since agile teams deliver faster, they continuously improve, sprint after sprint. The teams’ velocity increases iteration after iteration, so the thinking goes that – if they can be measured by velocity – they can be managed when ‘slacking’.

This goes on for a while, but when the teams’ velocity starts to slip, someone else inevitably decides what the velocity should be. From that point teams start getting measured on stats, but without first understanding individual teams’ stories this can quite quickly instil fear. Fear kills innovation, which drives the wrong behaviour. Instead of being open and transparent, teams start telling management what they want to hear, hiding behind reality.

Managers need to change the way they think, which in turn will change the way they act. This is the key to agility: it’s a different way of thinking.

A stored procedure, SQL query or class does not overnight become easier when you decide to adopt an agile framework. Lines of code aren’t shorter than before; instead teams find ways to work smarter to deliver business value faster.

They become self-organising, guided by good leaders. Good leaders understand that when teams become more self-organising, they (as managers) might lose some of their ‘powers’. That’s a positive; they instead empower their teams to make decisions, building trust within the group.

Good leaders understand that they need to allow their teams to make mistakes, because they understand the importance of learning. For instance, if a team makes a mistake with a deployment to production instead of creating another SOP (standard operating procedure) or more governance, they will find a way together to make deployments easier. Instead of only deploying twice a year, they encourage their teams to deploy more often.

Daniel Ek, the CEO of Spotify, has a saying: Good leaders think like this: if we aren't failing then we're not innovating. We aim to make mistakes faster than anyone else.”

I recently had a conversation with a test analyst. She reported a bug in her company’s daily scrum. The developers said it is a new story, but she was adamant it was a bug. So she asked me how they should manage it, since she’s obliged to report on all the bugs.

Bug-story-bug-story… what does it matter? Set the priority and get it done. Often developers have some sort of KPI attached to the amount of bugs they code, and testers are rated on the amount of bugs they find. In both cases their increases or bonuses are connected to these stats. Yet we are blind to the behaviour this drives in our teams. No wonder they clash so regularly.

Let’s think differently. We’ll call it a ‘learning opportunity’ or a ‘cool story’. It might be a team’s first time building a specific feature and they are still learning. Other more senior teams may have built something similar hundreds of times before. So rather than managing the team with the bug stats report, why not think: they had several learning opportunities. Good leaders will also give open and honest feedback, not allowing teams to make the same mistake over and over.

Leaders understand that creativity lies in the midst of chaos. It is okay to have chaos every now and then. But in this chaotic state they allow their teams to manage themselves and won’t interfere or try to fix the situation unless asked.

They also understand that they don’t always know everything, knowing how and when to submit to a fellow team member.

I will never forget my early Scrum Master days, when I experienced leadership that changed my whole career. The CTO of the company I worked for asked me to investigate why a team best known for delivery suddenly stopped delivering. I did the investigation and took the results back to him, explaining what happened. He then asked for recommendations and my opinion on how to fix the problem. I gave him my opinion; he looked at me, said “go do it,” and walked away.

He trusted me, valued my opinion, and without second thought allowed me to experiment. He did not expect any solution the next day or even the next week, as long as we managed the challenges. Under his leadership, I had many opportunities to ‘experiment’ with teams, taking good teams and making them great.

Leaders don’t always have the opportunity to pick who will follow them. In organisations – unlike politics and sport – the followers don’t have the opportunity to appoint the leader; they either emerge or get appointed by management.

Why not allow your teams to pick their leader for a specific situation? Be the commander on the battlefield that allows his soldiers to call an airstrike. Magic happens when we take agility to the next level, by thinking differently from the norm.