How to release agility in your company

It didn’t go down well.

Well, it wouldn’t have gone down well with you either, if you’d spent over ￡20 million pounds to “Go Agile” and somebody (me) had just told you you’d wasted much of it.

To be fair, she knew she’d wasted it. It’s why I was asked to come and do a talk.

After three years and little change in behaviours, it didn’t need a guest speaker from the North of England to point out the obvious. But point it out I did. With confidence.

I can’t help it. It's in my nature.

She was angry. I could see it in her face.

But for the first time in the last three years someone had pointed out a potential new road to travel, rather than merely throwing more external consultants at the problem or pointing out problems with no solutions.

It wasn’t that the existing agile consultants weren’t very good - some of them were excellent, but they were working in a system, culture and leadership vortex that meant they would never succeed. Instead of tough conversations by management, the company’s management team were throwing coaches at the problem instead. After all, it’s easier to blame coaching, than it is to hold your "management" hand up and own the problem.

And so this little story brings me nicely to the core premise of Releasing Agility - the main set of steps we use with clients who want to embrace agility, and a model that you may or may not resonate with.

I do hope it’s helpful for you as you embrace agility, take what is useful, discard that which is not. After all - other ways of working may also work.

Am I really working in agile?

I’ve worked in the “agile” world for too many years and have always been perpetually amused and despondent by the belief by so many people, that agile is somehow a silver bullet solution to problems they don't yet fully understand.

It's driven by a belief that there is some magical moment when you become “agile”, and suddenly all your business, communication and team problems go away. That somehow a framework off-the-shelf will solve your specific, niche, localised problems.

I’ve stayed clear of all of that, and instead have always focused on the idea of constantly, relentlessly and never-endingly Releasing Agility by improving communication, over-coming problems and fixing management behaviours.

I’ve learned that the more agility you release (as in getting smoother and quicker at delivering business results), the more interesting problems you uncover. The more you solve these new problems, the more agility you release. And it’s never ending. Companies always have more problems than they can solve. They also have more agility they can release.

Release - set free from confinement (it’s already there in your business)

Agility - moving quickly and smoothly towards your goals

I stumbled on why I’d made agile work a few years back - and none of it seemed to resonate with much I’d heard in the community or industry chatter. In fact, the more I dug deep on what I’d seen work time and again, the more I even wondered if I was even in the agile industry at all.

To be fair though I put myself through pain to get to this point.

It took me about 6 months of constant thinking; the kind of thinking that ages you, stresses you, tires you and makes you anti-social. The kind of thinking that leads you down many paths, some of which lead nowhere, some that provide golden insights, some of which bring pain and all of which teach you something.

The kind of thinking that makes you realise you know less than you thought, but ultimately, the kind of thinking that rips away the superficial layers of buzzwords, and gets to the root of why something works. The kind of thinking that lands on something far simpler than you originally may have expected.

You see, I’d moved from an agile tech team (described as Frighteningly Agile) to Human Resources (described as Evil) and was determined to Release Agility within the team, only I was failing. Failing for a number of reasons, not surprisingly, none of them were tech related.

In the world of tech it’s easy to hide behind agile tech speech and processes like Continuous Delivery, DevOps, user stories mapping etc. It's also easy to blame those things too. But when you try to do the same approach in a team like HR you need to peel back the layers to uncover the essence of why agile works - what sits below these techniques, processes and methodologies.

And after 6 months of brain melting thinking I’d deconstructed everything we’d ever done in the tech world at a level below technology. I’d drawn out a process, made it simple, re-written it 100000 times and ultimately condensed it down to something simple to digest. Despite its simplicity to understand though, it masks hard work, difficult work and complex work.

I showed it to friends, peers and colleagues and they all agreed, despite my awful drawing, it was a thing of beauty. And for those that know me, yes, it did have a picture of a dog on a skateboard on it.

So, I started to implement the ideas within in the HR team, with interesting results. We started to release agility. We started to move really quickly towards our business results. We shipped initiative after initiatives and made great progress on many big gnarly HR problems.

There were still problems, but we were overcoming them.

We were Releasing Agility.

"Release - set free from confinement". Let’s be honest, most organisations have high levels of agility at some point (in fact, most companies start out with extreme levels of agility), the problem is they just add layers of confusion, complexity, red tape and drama on top of what should be simple stuff.

"Agility - moving quickly and smoothly towards your goals". Let’s be honest here, it’s rare to find people in the business world who truly know what their business results and goals are - at a level that can be turned in to action.

And so I started to test and try the approach and it worked. It also worked in other industries and teams I tried it in. It worked in my own Consulting Business - and it worked for clients too.

By making it clear where we were going (with measures), identifying key obstacles (all businesses have more problems than can be solved, so we must identify the important ones), aligning the right people with the right skills, focusing on behaviours and habits, and then learning what works or didn't - we started to Release Agility in HR - and all without a single mention of an agile framework.

Eventually we got to the point where our HR team was described as "effective and less evil" - a compliment I think.

Shooting the breeze

After spending ￡20 million on agile coaches and consulting, the CIO I was shooting the breeze with, saw that her organisation was no closer to agility. Things weren’t changing. They were not getting to their business results smoothly or quickly. So I sat down with her and explained where I think her problems may have been.

Point 1 - Stop taking frameworks off the shelf

She had done the classic mistake of going to the agile-framework-shelf and pulling from it a standard large scale framework.

She had then tried to fit this on top of the business and, as expected, it didn't fit. They tried to make it fit. Some bits did. Some didn't. Most of the activity in the business though was people simply going through the motions. Large Scale Planning was happening, but the plans were immediately wrong, people didn't trust them and frankly, most people saw these two days of planning as two days out of the office.

Off the shelf frameworks are created by somebody to solve a problem.

So you need to be certain that you have the same problem, otherwise, why would you expect it to solve it? They often create more problems than they solve.

I suggested she take the time to study her real problems - and then find an off-the-shelf framework to solve those problems. It's a "trick activity" though - nothing from the shelf will solve your specific business problems. Some may come close, most will be miles away. And the sad reality is, so many companies are adopting frameworks without ever understanding what their real problems are.

If we don't understand our real problems, how can we ever solve them?

Point 2 - Agile is NOT an end goal

Upon further chats and discussions with her there was a belief that agile was an end goal. She was looking for a solution to a problem(s), and lots of consultants had provided her with empty promises that agile would solve them all. Every single implementation had failed to deliver. The consultancy companies were very good, as were the current coaches she had brought in, but so too were the last lot.

Alarm bells should be ringing if you put good people in to replace good people, and they get the same results.

There's a strong belief in many companies that I work with, that they need to be "agile".

Some of them even have agile/agility as a value or business goal. But when pressed on how they will measure the success of this, I often get blank faces.

Some people often tell me that it's my objective to define when the business are agile.

No thanks. I can't do that. I can help companies move to their business results more smoothly and quickly - and I can measure progress against that - but I can't magic a moment when we reach that point of being "agile".

Agile is a delivery approach and series of behaviours to help companies achieve business results. It is not an end goal.

I haven't seen a single, reliable, trustworthy way of measuring agility. I prefer to rely on existing business result measures such as revenue, customer satisfaction, time to deliver, cost to acquire etc - and behaviours - but we'll come to that.

I've seen lots of companies measuring agility using maturity models. But they make my eyes water and my heart sink.

Why would you want to compare yourself to a standard that somebody, somewhere else created? This is not agility. This is not moving quickly and smoothly towards YOUR business results. This is merely comparing yourself to a standard and adjusting yourself to become more standardised. Your business is not standard - it's exceptional...right?

I asked how the CIO was measuring agility and she showed me the maturity model that a consultancy had created.

My heart sinks when I see this stuff.

Simple activities and basic rituals codified in to spider diagrams and three charts. Supposedly a way of measuring agility. No data about delivering business value or behaviours or improvements - how can you standardise and codify this stuff - it's different for every company? They'd scored highly on many elements (stand ups, user stories etc), but they were not achieving their business results. I suggested she bin it.

Point 3 - Agile is NOT a Silver Bullet

It's easy, as a Leader or Manager under pressure to improve delivery, to put your faith in giant consulting companies and people selling solutions to your problems. It's particularly easy to put your faith in these people when you don't truly understand your real problems. It's easy to sell solutions to "perceived" problems. Off the shelf framework anyone?

But agile is not a silver bullet solution to all problems.

As we drank coffee and I talked to the CIO about her strategy, it became clear that the company still didn't have a real handle on what the real problems were - not fully. So, it's no wonder they were no closer to their business results and value flowing out of the door to their customers. If they didn't truly understand their real problems, how could they know when they were solved?

Agile had been sold as a Silver Bullet solution, but again, to what problems?

As we chatted it became clear that the company culture was one of avoiding conflict, of avoiding difficult conversations, of sweeping the real problems under the rug. Agility will never be released without leaning in to problems and overcoming them.

Point 4 - Agility is a management problem

Agility belongs to management. The CIO didn't believe it either, but when I asked her questions about why things weren't moving along I think she saw where I was going with this.

A manager's job is to achieve business results, and agile is all about getting those business results smoothly and quickly.

So it makes sense that agility belongs to management.

Yet many managers are doing the exact opposite of releasing agility. I hope you're working in a company with good management, but I don't see it often. Releasing Agility requires that:

1. Managers spend their time managing (system, process, incentives, structure, flow of information), not being individual contributors still delivering tasks. After all, when push comes to shove, which work will the manager do? The tasks that are measured, monitored and directly contributing to the product or service? Or the harder, more nebulous task of supporting people, fixing systemic issues and providing clarity and direction?
2. Managers spend a lot of their time fixing the systemic problems that are stopping people from adding value to customers.
3. Managers ensure collaboration, co-operation and co-ordination are in place to achieve business results.
4. Managers are nudging behaviours, encouraging and supporting people, dealing with low performance.
5. Managers are aligned and working with other managers to flow work across boundaries smoothly and with few hand-overs.
6. Managers are hiring the right people and maintaining high standards.
7. Managers are thinking about succession planning and mitigating "single points of failure".
8. Managers are leaning into problems and dealing with them.
9. Managers are fixing communication breakdowns.
10. Managers are studying, learning and getting better.

It's hard being a manager. The CIO knew she had weak managers who avoided hard conversations and dealing with the real systemic problems.

Many managers are simply not doing their jobs properly, for a number of reasons, but they need to be - to release agility.

Point 5 - You likely have what you need. You just need to release it.

As we wandered the offices of the company we were chatting about Point 4 above - that agility is a management problem. So I moved on to chat about her business.

I asked the CIO what problems people were coming to her with. The usual suspects:

1. Too many levels of decision making.
2. Too many governance boards making everything so slow.
3. Too many suppliers and third parties with contracts that don't align to agility.
4. Too much process. Process that doesn't even work.
5. Lack of alignment around projects.
6. Lack of ownership of deliveries.
7. Too many old ways of working. "It's just what we do here".
8. Too many managers not co-operating.
9. Competing goals.
10. Lack of direction.
11. Frustrated staff.
12. Yada yada yada.

You don't need to spend lots of money and bring in lots of outside help to achieve agility. You need to release it.

You likely already have people who care a lot about the business and the brand. You have good ways of working that are hidden from the sunlight by weeds, poor process and the lack of autonomy. You likely have the skills in place already - they just need to be surfaced and supported.

Managers seem to spend a lot of time managing people and process into tiny boxes. Boxes that contain red tape, bureaucracy and hand-overs. This stops agility. The role of leaders and managers is to uncover it.

You could see the CIO's eyes light up. She knew she already had what it took - now she needed to go and unleash it.

Sometimes you do need outside help, but only after your managers are doing what they should be doing; supporting people, unblocking people, fixing systemic issues and guiding people in the right direction. That's a managers job - if they're not doing it - they're not managing. Unleash it. Release it. Free it from confinement - and the best people to do this are the people in your business, supported by managers.

Point 6 - Agility is all about communication

When you break down the many rituals and ceremonies in many agile methodologies you uncover the real reason they exist - as opportunities for communication. For people to talk to each other.

So if you work out how communication flows, or doesn't, in your organisation, you have levers to pull to aid the releasing of agility.

It's rare to find an organisation that teaches effective communication. Not just how to run meetings, or how to put a powerpoint together, but solid, foundational, scientific knowledge of communication. From interpersonal communication, to non-verbal (a Super Power), to using the right medium for the message. I often joke that 99% of business problems are communication problems - I'm likely not far from the truth.

As I talked to the CIO about this, she knew that the ceremonies they were doing (stand-ups, retrospectives etc) were not addressing the real problems.

They'd scored highly on the maturity model they were using, but she realised these opportunities for communication were not achieving the purpose; people were not communicating, merely talking.

When you study communication you need to understand a few things:

1. How does information flow?
2. Who has access to information and why?
3. Who is not communicating?
4. Who needs to know information but is not getting it?
5. Why is communication not working?
6. What silos exist? And why?
7. Does everyone know the painted picture or True North? If not, why not?
8. Are people being listened to?
9. Are problems being surfaced?

The more you study how communication happens in your organisation, the more insights you have in to how to overcome problems and release agility. And if the ceremonies from agile methodologies help you achieve that understand, then happy days. But we all know you don't need these ceremonies to get people talking to each other.

Remember; agility is about communication. Not over-communication of poor communication, but people getting the right information to enable them to do their jobs - co-operation, co-ordination, collaboration, communication.

Point 7 - Agility is about behaviours

Underneath every single way of working are people doing things. People behaving in certain ways. The culture of your organisation is nothing more than group habit - what people do every day.

If you want to shift the culture, you shift behaviours.

Behaviours are what people do, what they say, how they say it, their non-verbal communication and their work output - hat tip to manager tools.

There are plenty of different culture out there, so you need to be sure about the one you're trying to build. When I spoke to the CIO it was clear she wanted a kind, fast paced and open culture. One where problems are surfaced and fixed, where people are respected and feel welcome, where work is getting shipped. She knew she didn't have that and was promised that agile would fix that.

It might do, but not unless we boil agility down to behaviours. Without a shift in behaviours then nothing will change. We can focus on process, tooling, delays, metrics and plenty of other elements, but if the behaviours of the people in the business don't change, then they will not shift the needle.

High performing organisations, have high performing people, exhibiting (day in and day out) high performing behaviours.

Managers need to set the behavioural standard, hire for the standard, communicate the standard, give feedback about the standards, maintain the standard and nudge the standard further.

The CIO knew that low performers were shifted from team to team, nobody ever got fired. There were no hard conversations about behaviours. Managers were doing what they wanted. There was no "high standard" to describe. I left her with a behaviour matrix. She immediately put it in to action.

Point 8 - Paint a picture

The Cultivated Management Releasing Agility 5 step process begins here. It seems odd to start at point 8, but the previous 7 points vary depending on the company - plus it's important to fix the management tier and the perceptions about agility before we actually start releasing it.

Step 1 requires that the business knows what it is trying to achieve.

Step1 requires leadership and management to have done research and analysis and know what value the company is offering, typically from the customer's perspective.

There are measures around this purpose and a compelling vision or painted picture of what the future looks like.

A True North, a guiding light, a painted picture, a vision - call it what you want - but it’s a clear, simple and easy to understand description of where people are going.

It is supported by data, evidence and measures.

The CIO had this vision. In fact, it was so compelling I almost asked her if I could join the team. It was a blisteringly compelling future. I could see why people were flocking to join the organisation.

Her team knew the vision. They knew what they were trying to achieve.

So I proposed the problems wasn’t here for the CIO. She had something else at play.

So we moved to Step 2. Seemed like a logical next step.

Point 9 - Overcome problems with a proper strategy

Step 2 of the Cultivated Management Releasing Agility approach is all about defining a strategy

Step 2 is all about looking at the bright future and then asking :

"If this bright future is so compelling, why are we not there yet? What's stopping us?"

When you identify the future state, and the current state, and then the obstacles that stand in your way - you can then add an action plan. This action plan is a strategy.

The strategy explains clearly and with evidence, what the obstacles and problems are that stand between where the company is now and this bright future.

It is an outline of the current problems and obstacles combined with a clear plan of action (prioritised) about how to move forward. It may be through, around, over, under the obstacles, whatever. But a strategy without a realistic look at the current world is just a wish.

Usually, I see lots of goals and mission statements, usually misaligned to the real problems in the organisation. These goals are usually too fluffy, unachievable, too demanding or unrealistic. Leaders talk of being aggressive, never quitting and destroying the competition. This is not strategy, this is personality type infecting the business.

After all, you’re in business to offer the customer something they currently do not get, not to beat the competition.

And so a strategy outlines the future, the current reality and the plan to move ahead. And this should be easy to understand, it should be prioritised, evidence based and well communicated to all. Everyone in the business should know what role they play in the journey. Alas, it’s usually missing.

And for the CIO, well, she had nuggets of this, but not the whole. Most of the strategy was fluffy wishes based on opinion rather than evidence. But the skeleton was there - it just needed some flesh.

She had some work to do here.

But she made a salient point and it helped to re-enforce why Step 1 and Step 2 are the building blocks. She mentioned that people were solving lots of problems and she was rewarding people for this. I asked her “Does your organisation have more problems than you can realistically ever tackle?” And of course her answer was “Yes”.

And so I explained that almost every business has more problems than the people or time to solve them.

So you must know where you are going and which problems are stopping you from achieving this future - and then you must overcome only those problems - and ignore those that are not preventing you moving on the journey.

It is a way of focusing attention and energy on the right problems, not just the easy ones. Human nature tends to draw us to problems that can be easily solved. Easy solutions often cause the problems of tomorrow - and often don’t address the root cause of today's problems. But that’s some heavy thinking for another day.

And so we mused about some ways to build the strategy before we moved on the Step 3.

Point 10 - Is this the team to get it done?

Now here’s where it gets interesting for most leaders and managers.

And remember, at this point we’ve not covered a single agile framework, approach, methodology yet. No need to - because until we fix the direction and deal with problems it doesn't make sense to roll out an agile methodology.

And so we moved to the most important engine of success in any company. The people.

Step 3 of the Cultivated Management Releasing Agility approach is all about having the right people to do the job.

If you could achieve your goals and dreams and business success without other people then you would. But bringing in people helps to amplify the abilities, productivity and achievements of all within the business. It allows a magnitude more work to be done.

Yet, so few managers and leaders know how to work with people - this is hyper-worrying.

And so I asked the CIO outright “Looking around your senior leadership and management team, could you honestly put your hand on your heart and say “This is the team to get it done?"”

She paused for a few minutes. Her eyes darted around the open plan office, and she started to fidget. I’d struck a chord, like I always do when I ask this question.

“It’s complicated” she said.

“Why?” I responded.

“Politics” she said.

“I understand, but is this the team to get it done?” I asked.

“Absolutely not” she said.

And there we had it. Sure, there were some gaps in strategy, but high performing people can overcome gaps in strategy and help to fill them in. But when you have a leadership and management team that is not the team to get it done, you have some work to do.

After speaking with the CIO, she encouraged me to speak to her direct reports, and ask them if they too had the teams to get it done. And the response was varied, but mostly centred around the words “No” and “Hell No”.

Yet not a single manager was doing anything about performance. Instead they were throwing coaches at a management problem. Why?

They didn't know how to fix low performance. They held on to a belief that you can’t remove anyone from the business. They believed they had no time to work with people - they were all too busy doing tasks. They had no training. They couldn't have hard conversations about performance and delivery. They weren't very good at communicating.

You should be able to look at your immediate team and say “this is the team to get it done”. If you can’t - you have some work to do.

That could be performance plans, feedback, removal or, as is usually the case, a simple and clear explanation of what is expected of people. I often find that most people have never received any feedback about low performance - they’ve never been told - and once they are communicated to - they immediately make changes for the better.

A managers job is to set the behaviour bar high, exhibit these behaviours themselves and hold people accountable to these high standards. Ideally it starts with leaders and managers.

This CIO had a real problem at almost every level within her team. This is a problem that affects many companies.

She also told me that the Agile Consultants had advised her to remove the management hierarchy - make it flat. But in most organisations the hierarchy has many benefits and the maturity levels of behaviours can be so low that the hierarchy is needed. I like hierarchy. It doesn't need to be deep, but there is nothing wrong with hierarchy.

It's the people in the hierarchy that are the problem.

I chin-wagged with some of the agile coaches and they had been spending 3 months trying to convince a team to move to an agile set of behaviours, but the team had all refused to do it. The refused to do it! Yep, you read that right. Refused to do it. They refused to do what they had been asked to do.

A reasonable request for a new way of working had been refused. It had been pushed away, ignored. They had chosen to do what they wanted to do, not what the business had asked them to do. And the business had responded by bringing in some agile coaches to try and “coach” them to do what was asked of them.

This is a management problem.

The more we chatted around this, the more it was clear where the money had been spent - on highly skilled agile specialists trying to fix management problems. And these coaches were good - but even the best coaches in the business can't overcome management incompetence.

And so we moved to Step 4. Again, a logical move.

Point 11 - Habits, behaviours and discipline to get stuff done

Step 4 of the Cultivated Management Releasing Agility approach is all about the habits and behaviours of agile.

It’s where the majority of consultants spend their time. It can be a complete waste of everyone's time trying to nudge behaviours and bring in agile approaches if you don’t have the right people, solving the right problems and heading in the right direction. And yet, most companies are spending millions here.

When you have steps 1,2 and 3 coaches are wonderful and accelerate learning. Without the first three in alignment, or being worked on, coaching can be frustrating, demoralising and wasteful.

The Agile Mindset is something the CIO kept talking about. It's what everyone kept talking about.

But when I asked what this meant and how she knew whether people had the mindset or not, she always came back to behaviours.

“Well they do X”. Or “they say Y”.

Behaviours. Not mindset.

The only way I’ve ever seen agility being released is by people exhibiting a series of behaviours that allow smooth and rapid delivery of value to customers. Behaviours that are honest, respectful and based around a need to constantly improve. Behaviours that are customer focused, based on good communication and are geared towards overcoming problems.

It's why I always focus on behaviours.

Behaviours can be observed, studied, communicated, nudged, discussed and given feedback about.

I have no idea what someone is thinking, but I do know how they behave. And their behaviours are usually a result of the system they are working in - exactly why we focus on Steps 1, 2 and 3 first.

In step 4 it’s plainly obvious to start with Leadership and Management behaviours - they set the tone for the rest of the organisation. However, that’s too simplistic - most Leaders and Managers think they are already awesome. It takes a self-reflecting leader/manager to appreciate that the chaos, confusion and behaviours in their teams are a result of their own behaviours, actions and communication.

And so we start with anyone who wants to get better. It’s easier and quicker to start at the top, but it’s still effective to work anywhere. You don’t have to fix your managers behaviours to work on your own. It’s childish to pass your own personal responsibility for behaving well on to others. Own it.

The culture of the organisation is nothing more than group habit, it’s what people do every day. So when working with behaviours it’s always important to take in to account the culture of the organisation and not go against the kind of culture the leaders want to build. Whether I agree with various ways of working or not, I am always aware that some people like to work in some environments over others. Some people like hyper-aggressive, go-go-go environments where achieving results is prized over treating people well. I don't. I've found ways to get both. People are all different and will be attracted to different cultures.

The CIO was in agreement - the behaviours were toxic, aggressive and confusing in her organisation. Not what she wanted. She was leading from the front and setting high standards for others - but her managers were not - and she wasn't holding them to account. Plenty of work to do.

It's also important to ensure your process for delivery works - and if it does, keep following the process. If it doesn't - fix it - then follow it.

There are too many companies with good processes that nobody follows. I worked with a manager once who was trying to improve the existing documented process for deciding on the next pieces of work. A kind of triage and decision making process - demand management so to speak.

I asked him what was wrong with the current process.

"Nobody follows it" was his response.

"Why?" was my next question.

"Because people don't like process and there are no consequences for not following it" came the reply.

"So, do we know for sure the current process is wrong?" was my next question.

"No" came the response.

"And is there a risk that we create a new process and still nobody follows it?" was my logical next question.

"Absolutely" was the response.

There are people all over the world solving the wrong problems. Agility is about following light-weight processes that work. And when they don't work, fixing them.

We will never know if something works or not, if people do whatever they want.

It's not cool, glamorous or exciting to follow a process that works - but business is about doing what works - not experimenting constantly and doing what you want. We learn more when people follow the process and we learn what does not work.

The CIO acknowledged that she was as guilty as anyone when it came to skipping process. And she knew it always resulted in delays or people distracted from their typical tasks to deal with spurious requests - but it was all too easy to do.

We must hold people to account, learn, improve, fix and study.

And so we moved to Step 5 to close out our little ramble.

Point 12 - Learn your way through it

Step 5 of the Cultivated Management Releasing Agility approach is simply about learning and getting better.

It’s about testing ideas carefully and only when needed, failing, learning from mistakes, deep diving on problems, using data to inform decisions and ensuring everyone in the work place is getting better.

How you do this is varied, culturally specific and must be geared around overcoming the problems your organisation have. After all, there is little point in training everyone in a technology your company don’t use, or a process that has no place in your business. Trust me, I see this time and time again. Companies with big budgets to spend, training people in ways of working that are not relevant, just to tick a box to say they train people.

Training and learning should be about improving the capabilities and behaviours of the business.

And how do you measure that things are getting better? Your business results will improve along with your team’s behaviours and ability to deliver them. Behaviours will change. Capability will increase and improve and be appropriate for the changing nature of challenges, obstacles and problems you now face.

As we chewed the fat on this, the CIO was excited about what the future held. She had ideas and insights and plans.

And remember - mistakes are an opportunity to make yourself and the business better, but only if you understand what happened and make changes off the back of it.

Point 13 - Don't spend lots of money

You don't need to spend lots of money on Agile specialists and Management consultants. Steps 1, 2, 3 and 5 are the day-to-day jobs of your managers. Step 4 is where you may touch on agile rituals and routines and need agile support, but only if they're solving the problems your business has.

If you already have managers, you have people who SHOULD be working to release agility, set it free, listen to their staff, set high standards for behaviour and work on systemic issues. If they're not doing that - what are they actually doing?

You likely have what you need. And if you don't have the right managers and people in the right places - what are you doing about it?

It's my strong belief that agile is a management issue.

If your managers aren't spending their time releasing agility, then you'll never achieve it by spending lots of money on consultants, coaches and specialists in agile process. Only do that once you know where you're going, you have a strategy to overcome your problems and you have (or need) the right people, with the right behaviours. And these are all activities your managers should be working on.

Avoid off the shelf solutions unless you have the same problems they were designed to solve. Avoid maturity models unless they measure the maturity of behaviours and key results that matter to YOUR business. And spend time making sure you have talented people working on their strengths and with clarity towards a Painted Picture.

That’s not agile

If you embrace the Releasing Agility approach, some people will say you're not doing agile:

1. Being very clear about where you are going
2. Honestly identifying your real problems
3. Building the right team to get it done
4. Focusing on behaviours first over frameworks
5. Learning how to make the business better

They'll say it's not agile because it doesn’t look like X diagram, or doesn't implement Y book, or Z framework.

That’s nice for them - don’t worry about this. You’re too busy releasing more agility by overcoming YOUR real business problems.

Ignore the haters and naysayers. By focusing on solving business problems and achieving business results, you'll keep the business alive. And if a framework or methodology helps you with that - use it! If it doesn't - don't do it. That's real agility.

Nothing ruins the ability to release agility more than being compared to a different company who have different goals, problems, people, culture and learnings. Nothing makes you more standard than using a standard maturity assessment. Nothing makes you less exceptional than not doing exceptional things.

Agility is about achieving business results. It is a journey that never really ends. And it will look like what you need it to. Don’t let the compare and despair mentality affect what you’re doing.

Use what is useful. Discard what isn't.

To sum it up

It’s really important to know which direction you are heading in. Talented leaders and managers are clear about the purpose, measures and business results. It makes it much easier for others to align around it.

It’s then important to identify the very obstacles and problems standing between where you are and this bright future. Once you identify these you can put in place a plan to overcome them - this is a strategy - a set of guiding principles to reach the destination.

It’s important to have the right people in the right place, at the right time to deliver on this. Is this the team to get it done?

You can then start to develop the behaviours that help you achieve this vision whilst remembering your principles and values. After all, it’s entirely possible to get business results through threats.

And then you can learn. Ask questions, make safe mistakes, learn how to be better. Follow process to understand what works and what does not.

And all of this helps you release agility in your organisation. And if you have the same problems as an off-the-shelf framework can solve - then use one of those. If not, then use what is useful from each one and apply it to solving your real problems. And I’ll give you a clue - the real problems are likely to be behaviour based - and the best way to address these, is by modelling the right behaviours at all levels in your organisation - especially so at the top.

And when you break this model down, its essentially management.

Managers hold the keys to releasing agility.