Own the problem, not the solution
I saw a few interesting bands a few months ago at The Kilowatt in San Francisco. The first was a local band and the second (Poppy Jean Crawford, check it out) was on tour with the headliner (Blood Red Shoes). Each of the first two bands played mostly original songs, and each played a cover. They couldn’t have been more different.
The lead singer of the first band knew all the words, the intonations, and the inflections of the song they were covering and sang them. The lead singer of the second band made the cover her own. It was her version of the song, customized to her style, her personality, and her capabilities.
In case you’ve never heard it, the story of “cargo culting” goes that the Pacific islanders after World War 2 tried to bring all the Allied cargo planes back to the island by creating replicas of the air traffic control towers, etc. Obviously it did not work. Sometimes I have clients who take a monolith, with sticky sessions and an Oracle database and run it in Kubernetes. Why? Because Kubernetes came from Google? As the saying goes: you’re not Google.
Kubernetes solves a lot of problems, Kubernetes shaped problems. Running an application that requires local state in a pod is not a Kubernetes shaped problem. When solving problems in engineering organizations, it’s not enough to look at what others have done. It’s not enough to copy the intonations and inflections. You have to make it your own.
Kubernetes is great, but it’s also 1000 more knobs to turn and introduces more complexity, and complexity is not free. Agile is great, but one of the benefits of being agile is being able to get fast feedback. If your organization is not also working on releasing more than 4 times a year, then you will have big bang releases and no agile benefits.
What problem was Kubernetes trying to solve? How did the solution address the problem? What problem was Agile trying to solve? How did the solution address the problem? It’s only by examining these questions can an organization make the solution their own.
I have a lot of clients who ask which solution they should buy and I always ask: What problem are you trying to solve? If the answer is always Kubernetes, that’s a solution looking for a problem. Problems need to be solved at a customized system level. Architecture matters, technology doesn’t.
Find a solution that works for your particular situation.
I had a client with an engineering manager who didn’t really know how to be a product owner for a Scrum team. After a few months, he understood what everyone was working on, he understood what was being asked of the team from outside, he understood the strategic initiatives that were on the horizon for the business. He didn’t worry about what the Agile Alliance said to do, he made the solution his own, and he excelled.
Now that’s a hit song.