One cannot “implement” one of these frameworks if one does not have a deep understanding of them, and of how teams need to interact today. Indeed, if you have that understanding, then you don’t need the frameworks!!!
What makes things go wrong is when decision-makers issue edicts without having the required understanding. The edict “use SAFe” is such an edict. So is “use Scrum”. Unless the person issuing the edict has worked with development teams for years, in an Agile/DevOps context, and plans to involve themself in how the framework gets implemented. Otherwise, the edict is just interference: it is like issuing an army an order to use a certain strategy in the battlefield, and not being there when they try it, and not having ever used the strategy oneself.
Also, frameworks are a bad approach period. What works better is identifying target practices. Practices such as “Make automation integration tests a pre-requisite for approving any pull request.”
One thing I would like to call attention to is a line from the Air Force slide: “Teams shouldn’t have to coordinate if they use a Service Mesh/Domain Driven Design/Microservices model.” OMG. That is so, so, so utterly untrue.
Let me provide an example of what Google does: Whenever a programmer at Google makes a code commit, the tooling automatically kicks off a tool that automatically identifies all potential dependencies among all of its products, deploys all those potentially dependent products, and runs massive end-to-end integration tests on them all. If those integration tests pass, then — and only then — is the change actually committed.
Sure, if you have that kind of automated tooling, then you don’t have to coordinate as much. But not everyone can afford to create Google’s tooling and run automated tests as thoroughly and often as Google does. Coordination — whether it occurs through automation or through collaboration — is essential for building distributed systems. An API change to a microservice almost always entails changes to other services and clients as well.
The idea that if one tests a microserivice’s API, one is safe to deploy is completely wrong. APIs don’t fully specify behavior: they don’t specify temporal behavior, and that’s important because microservice based products are real time systems; and an API might specify message field types, but it cannot specify the semantics of those fields. Here is a LinkedIn article I wrote about this very topic.
It all comes down to people not knowing what they are doing. The people who issue the framework edicts don’t know what they are doing. The people who write memos like the one pictured in the article don’t know what they are doing. There is not enough deep knowledge and experience to go around. It is like the blind leading the blind.
