I’ve been working with agile transformations and agile working methods for several years now. And never have I met any other business trend that has grown so fast. It has gone from a somewhat "geeky" methodology for IT that was met with great skepticism and resistance in other parts of the organization, to "yesterdays news" where today it’s considered as a business risk if you have not yet started your transformation. Everything should be agile. Everyone should be agile.

But what’s does “agile” really mean?

Well, there are many different definitions and just as many people who is determined there is only one definition. When I, a few weeks ago, sat in a roundtable discussion on an event focusing on agility, I got a direct question: “what’s your definition of agile?”. I had to take a minute or two to think about it, since there are so many things I relate to that word. It’s about mandated cross functional teams, it’s about focus and prioritizations, it’s about breaking down big initiatives to smaller pieces of value to be delivered with speed and so on… But all of that is actually only the means to the greater purpose. So after some time for consideration I managed to deliver a slightly unstructured response that "it basically is about being able and willing to change according to new customer needs, changes in the market, etc.". That question and the discussions that followed made me start to think and gave me the conclusion that this is my definition:

Agile is the ability to see and understand the customer's needs and based on that choose to and dare to change focus, change how resources are used (people and money) and change priorities or activities. So there are two things: 1) to see and understand changing needs and 2) to have the ability to act on the new knowledge.

But this has to happen at all levels of the company. What is well described in many methodologies is this ability at the team level. The team need to be very close to the customer, get direct customer feedback, test and learn, prototype, create MVPs that provide more knowledge, etc. Then also the mandate needs to be there, to be able to act quickly - to not have to wait for decision forums, steering groups or priority boards. Based on the knowledge of the customer's preferences, the team change their activities and priorities to optimize the customer value.

But the same thing must work also at higher levels in the company if you should earn the right to say that the company is agile. At the management level, you must also have the ability to quickly see changes in customer needs and market, identify trends and acknowledge trends in results, etc., but at an aggregated level. As top management, you need to have an agile mindset where you are open for and actually welcome these changes and new insights. At this level, it is not about having a mandate to act - since that is often already there - but here it is about having the courage to change course. And on top of that you need to have structures and processes in the company that not only makes it possible but are optimized for rapid changes. Budgeting and planning processes, strategy development and organizational structure also need to be designed for agile operations.

If the budget is set annually and every deviation from the planned budget allocation needs to be explained and defended in each monthly business review, well then it is obvious that you will avoid making changes. If the annual business planning sets detailed activity plans down to team level, that is then followed up monthly with remarks on every deviation, you will most likely stay away from changing direction and replace planned activities. Just the word "deviation" sends bad vibrations to most of us. Something negative that you should avoid as far as possible. But in our new agile world, it’s the opposite - something to praise. Every “deviation” is a sign that you have learned something new and acted on the new knowledge. It's something we should celebrate. Instead of explaining and defending each deviation in the business review, we should instead ask for explanations when there are no deviations. Or what do you say?

Jenny Lagergren

Agile Transformation consultant

Recoordinate