In my work as a self-employed agile trainer and coach, I have worked with numerous agile teams. Some used Scrum, some Kanban, some worked in a SAFe setting. These days the “Spotify model” (which to my knowledge they never fully applied themselves) is growing increasingly popular.

There is much fanaticism when it comes to agile methods and frameworks. I have even met people that got upset if others did not use the terminology “method” and “framework” correctly. But I have to ask: does it really matter? For the sake of simplicity, I will only use the word “method” in the rest of this article.

I have also come across quite a few zealots who would claim that the only real agile method was the one that happened to be their favorite. If the results when using the method were not as positive as expected, they would argue that this could only be because people were using the method incorrectly. Suggesting that there is not a “one-size-fits-all-method” was almost seen as a provocation.

But why this fanaticism, and why so emotional? At the end of the day, we are all striving to get more successful projects, less economic waste, and more efficiency in whatever way possible. I might add that this was what we were striving for too back in the days before “agile” entered the scene.

I find it counter-productive when people are more interested in the form rather than concrete results. I find it discouraging when people are fighting a “war of the methods” rather than accepting that there will always be prerequisites for making any method work.

This brings me back to the agile teams

One of the main prerequisites for making agile methods work as intended is having teams that understand what is expected from them, and what they need to do differently when they ‘go agile’.

And not only that – they also need to be motivated for making those changes. What would be their motivation for change if no one can explain why they should change and what is in it for them?

Agile teams will typically work with Scrum or Kanban, (some in combination with XP). But neither of them are intuitive or easy.

Scrum introduces new roles and responsibilities that introduce significant changes to the work processes. You need to let go of a lot of old habits, just as behaviors must change according to the Scrum values.

You might say that in Scrum the responsibilities held by the good old Project Manager are now split between the Scrum Master, the Product Owner, and the Development Team.

Even though Scrum does not fancy Project Managers, the tasks they used to do around planning, communication, stakeholder management, risk, and financial management, etc. will not disappear just because you work in a Scrum Team.

Looking at Kanban, you do not need to change your organization and introduce new roles and responsibilities, but you must for instance start to limit work in progress, and measure lead times. Kanban is data-driven, so if you don’t measure, you will not know what to improve.

Both methods require transparency to inspect and adapt and avoid guesswork. But I have found that it is not at all easy to convince people that they should be more transparent. Some find it almost intimidating, some believe that it is their management wanting to control them even more, some don’t think that it is anybody else’s business what they work with. And the list goes on.

To get successful agile teams you, therefore, need to overcome the resistance towards some of the built-in prerequisites for making agile methods work, such as transparency, and also make the teams embrace the values that are built into the method.

This is easy to say, but hard to do. Many habits have been formed over 5, 10, 20, or even more years. Such old habits are difficult to break, and it will not happen overnight. However, if you are not persistent they will not change at all.

“Nothing is easier than keep on doing what you always did. Changing requires conscious thinking and energy”

Continuous improvement is the path to higher agility

It is quite simple: If you do not see any evidence of continuous improvement, your teams are not agile. Continuous improvement is the path to higher agility, and fortunately, continuous improvement can be planned.

I have seen so many examples of teams that feel they are agile simply because they have introduced new titles, attend certain meetings, and work from a backlog.

Just like I have met teams that strongly believe they work with the Kanban method because they have made a task board, and meet in front of it every day.

Changing your organization or having stand-up meetings in front of a board will not make you more agile. It does create a bit of transparency, but no continuous improvement and thus no increased agility.

If faster value creation is important – and it usually is – the only way to achieve it is to improve your agile teams’ efficiency by facilitating an increased focus on continuous improvement. This could e.g. be to:

• Start measuring lead time, throughput, flow efficiency, etc., so decisions can be backed up by data
• Increase focus on blockers – how many, how long, why they occur, and what can be done to minimize the negative effects
• Increase focus on dependencies and bottlenecks. I.e. anything that disturbs the flow
• Stop multitasking, and thus minimize the cost of task switching
• Improve work and decision processes
• Improve collaboration both within the team and with stakeholders

Most of the above points have to do with behavior and habits. Some have to do with the way your company works, but any team interested in improving agility can decide to immediately start working actively with the improvement opportunities that they can control themselves.

Agile teams that plan continuous improvement tasks into their daily work are more successful than teams that don’t. It is not very difficult, but it is very powerful.

The key to higher agility is in the hand of the agile teams. Independent of which agile method they work with.