DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
What's in store for DevOps in 2023? Hear from the experts in our "DZone 2023 Preview: DevOps Edition" on Fri, Jan 27!
Save your seat
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Money Talks: A Tale of Two Change Programs

Money Talks: A Tale of Two Change Programs

Agile transformation frequently differs from other kinds in a very crucial but overlooked way: expense.

Allan Kelly user avatar by
Allan Kelly
CORE ·
Dec. 14, 18 · Opinion
Like (1)
Save
Tweet
Share
6.94K Views

Join the DZone community and get the full member experience.

Join For Free

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.

agile

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • A Brief Overview of the Spring Cloud Framework
  • API Design Patterns Review
  • How To Generate Code Coverage Report Using JaCoCo-Maven Plugin
  • How to Use MQTT in Java

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: