Money Talks: A Tale of Two Change Programs

Like many in the Agile community — or what sometimes gets called the Agile industrial complex — I am all for piecemeal adoption, small-scale before large scale, getting good at doing stuff then expand it out... — what else would you expect from Mr. Diseconomies of Scale?

The "start small" and grow might even be regarded as the canonical approach to Agile implementation. But from time to time I run across something that makes me wonder...

Four or five years back I got involved with an Agile transformation program at a large financial institution, not a bank, more of a mass market asset manager. I was attached to a small team trying to make the whole company Agile.

The coaches viewed themselves as a guerrilla movement, changing the organization from within. They had some success; there was a bunch of stuff the Agile teams and the coaches were doing wrong, but that is another story. This was a licensed insurrection.

As is often the case, this team found it lacked the ability to ask the big questions and get people outside the team (often the higher ups) to engage or change themselves. The organization wanted Agile down in the engine room — at the code face — but they didn't want to rethink how they set requirements and approached projects. The whole organization was chronically project-driven, obsessed with long-term planning and offshore development. Economies of scale thinking ran riot.

Because the Agile change was at the team level, the Product Owners lacked authority to make real decisions — like not delivering functionality. Yes, the organization wanted to "be Agile," but the management cadre didn't see any need to change their own behavior.

One day I met two men who ran the company's "Software Process Group." They were guardians of the formal process and "working practices." My immediate reaction was that they wanted to kill Agile and stick with ISO-9000, PRINCE2, CMMI, and certified approaches. They scared me. But actually, they were very clued up. They got Agile. They saw it was better than the current process.

These two had no role in the Agile transformation; their role was to ensure the company kept its CMMI level-two certification. This was really important to the company because this allowed the company to do business. They told me a story...

During the previous 20 years, the company had grown large, very large, by buying up competitors and companies in related markets. These companies had been thrown together and costs stripped out. One day the financial regulator came to the company and said:

"We have been examining your IT functions. They are not fit for purpose. If you don't fix it within 12 months we are going to withdraw your license to do business."

Shit hitting the fan doesn't come much bigger than this.

The company went to IBM and said, "Help! Fix it — we'll pay anything."

IBM flooded the company with people. IBM imposed a process — a traditional CMMI-compliant process. IBM changed the company, not just the programmers but everything. The company did as IBM told them.

And don't imagine it was cheap. I bet that the change and IBM fees were on the agenda at every board meeting during that period. The men I had met were the remnants of that programm, they worked for the company, not IBM, and their job was to ensure the company maintained accreditation and the financial regulator wouldn't have cause to come back.

Now contrast this with the piecemeal, small-scale, bottom-up change that us Agile folk are so fond of. Time and time again we get stuck: "The business won't change," "We can't get access to the senior people," "Existing processes and expectations are unassailable," "Projects are killing us," and so on.

I'm sure IBM faced many of those same problems but they had one big advantage: they were expensive.

OK, they had a second: the loss of license would destroy the client company. But when threatened, people often respond by sticking with what they know, so maybe it was a double-edged sword.

Because IBM was expensive, they had access to anyone they wanted access to. Because they were expensive they had authority. And if someone didn't want to make the changes IBM, suggested then IBM could simply ask the next person up.

Once again, money is information: by spending lots of money with IBM, the company was signaling it really wanted these changes to happen.

Agile changers may not like big change; they may point to the inherent risks, they may point that use of authority conflicts with self-organization, they may understand that diseconomies of scale rule and they may point to a bunch of other risks.

But they should also note one clear advantage: a big expensive change programm brings authority all of its own.