We talk about value a lot in agile. The whole point of agile is often given as "the ability to deliver value quickly". Lean looks at value streams and flows of value. But when we say value, what do we really mean? What is value? The dictionary tells us that value is "the regard that something is held to deserve; the importance, worth, or usefulness of something."

So value describes something that is important to someone. But who? When we ask ourselves this question, we usually come up with and answer of - "the customer". This isn't a wrong answer, customer value has to be our of our key drivers. Make the customer happy by giving them what they want. That's the key to business success. But note that I said "one of our key drivers", not "our key driver". There are other "someones" out there who are also important, and often get forgotten. What about the organisation itself? Its employees?

We have all seen the press releases come out. The CTO of some big organisation proudly announces that with this new agility thing they are now able to release to market every three months instead of yearly. Great news isn't it? Great endorsement of agile techniques, isn't it? Have you ever worked in one of those organisations? What is it like working in the delivery teams for one of those organisations? Is it, as the press release seems to indicate, some sort of IT workers' paradise where features flow easily into production and there are smiles and profits for all?

Or does it feel like an endless treadmill where releasing every three months just means jumping through all the hoops you had to jump through for the yearly releases but now instead of doing it once a year you are doing it all the time? Where the nightmare month you used to have once a year to push the release kicking and screaming out the door is now your normal workload? Chances are, it's not the first one. Feeling burned out? Are we achieving our results by throwing away one of our key principles - the principle of sustainable pace?

How do things get funded in the organisation you work for? If you work for most organisations, a business case will be prepared and submitted to management for approval. The conversation around approval will invariably be based around cost and benefit - how much will this cost and how much will this make? This leads to some pretty well known problems. I have written about these problems before (The Problem with Projects and Outcome Based Funding) and they are pretty well known. Ask anyone involved in funding approvals and they will tell you that the process is pretty bad and things need to be done to improve it.

Organisations have tried many things - fast track funding for small initiatives, streamlined approvals processes, delegated approvals, all sorts of things, but the process remains inflexible, flawed and generally broken. I think this comes not from a flawed process but from a flawed starting assumption - that cost vs benefit is the correct way to allocate money. I think we are asking entirely the wrong question. No amount of tweaking the process will help if the process is answering the wrong question. So what is the right question? I think we should stop asking "how much will it cost" and start asking "how much should we invest".

Leadership is crucial to a large scale agile transformation. You can go so far bottom up but to achieve any sort of real scale you need to get some leaders involved. A lot of what I do day to day is get leaders involved and engaged in the transformation process. When talking to leaders, this question inevitably comes up - "What is the single most important thing I can do as a leader to make this work?" For quite some time, my standard answer has been "Set a good example."

Have we ever seen this situation - the boss has just announced a fantastic new agile change program and that he or she is right behind it. "Agile is the most important thing the organisation can be doing" they say. But over the next few weeks it becomes clear that they aren't turning up to the business scrum, are too busy to make the sprint review, can't afford the time to attend backlog refinement. Then other people's attendance starts to drift off. "Too busy" becomes the standard excuse for missing something. The agile transformation falters, struggles on for a while, then vanishes without a trace.

Last time we looked at how to transform large organisations by building capability internally rather than buying capability externally. There are a lot of benefits to this approach. It's faster. It's cheaper. It's more effective. But it does fundamentally change the way an organisation sees its agile transformation program.

Most of the time, a traditional coach-led transformation program is set up to minimise the disruption to staff. Apart from some training and a new way of working (and maybe a slight blurring of strict job titles), the organisation sees its staff doing pretty much exactly the same thing they were doing before the change. Developers develop, testers test, they just do it in a new, agile way. With an internally-led transformation, this is not the case. A significant number of staff will be involved in this program for a long time. This will impact their day jobs. So the first rule of internally-led transformations is - give people time.

If you work for a large organisation and you want to transform the way you work to be more agile, what's the first thing you do? Chances are it's hiring a coach or two. That's not a bad way to start. Experienced people to guide the transformation make things much easier. But what do you do once the first pilot is done, you have proven that it works and demand is growing? More and more people are wanting agility. Your current coaches can't handle the load. What do you do?

What most organisations do is here some more coaches. And some more coaches, and more coaches and more as demand continues to grow. Now, as an agile coach, this has kept me in work for many years so I may be shooting myself in the foot a little when I say that this is a really lousy way to do an agile transformation. Yes, that's right. You heard it. An agile coach says that hiring a bunch of agile coaches is not a good way to transform an organisation. Let's look at why and then look at how we can do things better.

Often in large organisations we have to deal with groups with names like "legal" or "compliance" or to use an example from my days in the healthcare software industry "patient safety". To a project manager, the function of these groups seems to be to throw up obstacles and prevent getting things done. These groups tend to appear out of the woodwork near the end of a project, inspect everything that has been produced, identify a bunch of problems and then block release until they are all fixed. The problem of course is that at the end of a project, everything has already been built so changing things is hard and expensive. There is also a very good chance that the money is starting to run out so these changes would push the project well over budget. Throw in a rapidly approaching release date and a team already stressed with defects and last minute changes, and it's no wonder project managers view these groups with dread.

Of course, these teams are not just a bureaucratic hurdle to be jumped. They do an important job. The organisation could be in serious trouble if they release anything that is illegal or is not in line with whatever regulations they are under. Groups like legal and compliance have the skills and knowledge to make sure that doesn't happen. In the healthcare company I worked for, patient safety was responsible for exactly that - the safety of the patients whose treatment was administered through the software we wrote. They were trained medical professionals, with years of hospital experience, who assessed what we produced and made sure that in the stressful, overworked environment of a typical hospital, that the software could be used without the risk of accidentally administering the wrong drug or the wrong dose or operating on the wrong leg (or even wrong patient) or anything like that. That's a pretty important thing to do. We knew how valuable it was. We still hated dealing with them though. Product managers would jump through hoops to get their product classified "non-therapeutic" so they could avoid a safety review. The downside of course is that there was no safety review. If only there was a way that we could get the value that these groups provide without all the downsides.

As an agile coach I am always pushing for cultural change. That's what agile is really - it's not a delivery mechanism, it's a fundamental change in the culture of an organisation. What do we mean by organisational culture? There are many definitions but the one that I like is that culture is a shared understanding of values. It's the understanding everyone has of what the organisation thinks is important. Culture drives behaviour - people will seek to maximise what is considered important in the culture and will behave in ways that do that.

The problem of course is that, as anyone will tell you, cultural change is hard. CEOs are tasked with changing culture and spend years failing to do it. People say that the only way to change culture is to change all the people. Or that cultural change only happens when a generation of employees retire. I don't agree. Cultural change is really easy. You just need to let people know what the organisation values. "Hang on", I hear you say, "Just wait a minute. Organisations have been putting out statements for years about what they want in their new culture. People can often quote chapter and verse from the CEO's latest values statement. Millions are spent on flashy communications. And nothing changes."