Framework Names Don’t Have to Have Baggage

Ask anyone who works in product development how they feel about “Agile” or “Scrum” or “OKRs” or just about any other framework and you’re likely to hear a mixed bag of complaints, praises and comments of indifference. Everyone has an opinion on these ubiquitous frameworks and they bring that baggage with them to their subsequent positions. How they were implemented at each organization adds to the organizational reaction when they reach a new adoptee.

Baggage Hampers Adoption

How people feel about Agile or OKRs directly impacts the success of a new implementation. If the opinion is high, odds are the implementation will succeed. If folks don’t have good experiences with these frameworks they won’t adopt as easily or, at times, actively work to ensure they don’t get adopted. The mere perception that a new way of working has no value or has failed multiple times starts an organizational change at a deficit. Not only does the transformation team have to drive the new change forward, they have to erase the perception deficit.?

Rename the Framework To Erase the Baggage

In The Startup Way, author Eric Ries talks about bringing Lean Startup to GE. One of the first things the organization did was rename the program to Fastworks. At the time Lean Startup was at the height of its popularity and while it had many advocates, it also had its detractors. Had GE leadership announced they were implementing Lean Startup across the organization, many teams and departments would have pushed back based on their experience with the framework (i.e., the baggage).

By changing the name to Fastworks, GE could introduce a seemingly new idea. This idea had no baggage associated with it because no one had ever heard of it. It was an internal invention, unique to the company. The transformation agents had an enormous task ahead of them to be sure; however, one thing they didn’t need to do was figure out how to change the minds of detractors. They didn’t exist.?

Changing the names of these frameworks doesn’t mean we don’t use them. To the contrary, we can use any part of the framework we feel makes the most sense in our context. What it also enables us to do is to mix and match parts of frameworks that may not have been tried out together. No one can claim that a thing we added to the framework “isn’t Fastworks” or whatever name we choose, because we are literally inventing it on the spot.