It has become almost an adopted truth that so-called agile teams are more productive than non-agile teams. I write “so-called agile teams” because many of the teams I have worked with during the past 10-12 years as an agile coach, were in fact not very agile in the way they worked.

Most agile teams use Scrum, but in many cases in a very superficial way. Very often using Scrum only means that organizations have introduced new roles, artifacts, and events. They have Scrum Masters and Product Owners instead of Project Managers, and they work from a backlog instead of a requirements specification, and they hold a series of meetings because “Scrum says so”. (I know that I am simplifying things a bit, but I have seen this so often that it looks like a pattern).

However, changing organizations and giving people new roles will not result in agile improvements. On the contrary, it often causes anxiety, confusion, and uncertainty. Focusing mainly on the way people are organized will not facilitate increased productivity. Changing behaviors and habits will, but of course, that is not as easy as making organizational changes.

As a side-track, I came to think about the time where it became modern to change small offices for 1-4 people with big open-space offices, where sometimes hundreds of employees would sit almost glued to each other. The point was – at least from an academic point of view – that it would increase efficiency as it would be easier to exchange information and keep oneself up to date.

This dream did not come true, because the big open spaces made it impossible to concentrate on your work as there was a constant noise from people talking, walking, coughing, laughing, etc. The result was frustration, stress, and lower productivity.

I wonder if the same is not the case when it comes to agile methods and frameworks? They look deceivingly simple and sitting behind your desk it may seem compelling and easy enough to go agile. You “just” need to make a few changes, e.g., introduce a new set of roles and responsibilities and adjust your processes. But when you try to do it in practice it becomes obvious, that it is extremely difficult.

Agility is not a thing, and it does not happen automatically.

How to achieve evidence-based agility?

Understanding the way, the method or framework works is the easy part, but changing the more intangible parts such as work habits, behavior, values, and mindset not to mention accepting to be transparent is a different matter.

Unfortunately, these not so tangible elements are the real drivers of agile improvements, and they are often neglected. Therefore, teams and organizations end up doing mainly the mechanics which may make them feel agile, as they can see the obvious:

• We have a board
• We are having standup meetings every day
• We work from a backlog
• We have introduced all the roles indicated in the method/framework
• We hold all the meetings we are supposed to

So, we must be agile, mustn’t we?

But holding e.g. a set of prescribed meetings changes nothing until you focus on the quality of those meetings. They may facilitate a feeling of agility, but do not in themselves bring any evidence of it.

The evidence of increased agility will only be established when you start measuring. The metric that will give you the most accurate information about your efficiency and the progress achieved over time via continuous improvement initiatives is lead time. Lead times present you with the hard facts.

Below you see an example of what you should be focusing on when you measure lead times, namely the tail.

(Source: Kanban University, Kanban Maturity Model, Understanding Lead Time)

Knowing precisely where you stand in terms of lead times will indicate whether there is an urgent need for improvement. What you should be striving for is to optimize the way you work, so you over time will see your lead time distribution tail “move left ”towards an increasingly thinner tale.

Achieving such results will be clear evidence of success with changing the improvement drivers mentioned above: habits, behaviors, values, work processes, etc., many of which are “people things” that should be incorporated in the everyday work and be openly discussed.

People are different, but don’t let that stop you from finding common ground

People are different, they think differently about the same things, and each has their own perspective. That’s why it is necessary to agree on a common set of rules for the way your team should work and be explicit about what e.g. “quality” or “done” means.

It’s also necessary to discuss more sensitive topics such as: “do we have the right behavior?”, “do we incorporate agile values in the way we work?”, “do we work with openness and respect for each other and our customer?”, etc.

If those are the discussions you have at your meetings, then you have gone beyond the mere mechanics of just holding a meeting because the framework tells you to. You have started to talk about things that matter and will result in real change.

And if you measure the effects that behavioral changes, new habits etc. have on your lead time distributions, then you have achieved evidence-based improvements, and have moved from feelings and beliefs to facts.