From Spotify to Scrum and DevOps
The agile community, as any community, has an strong tendency for standardisation or fixed patterns. The widely used and discussed combo Spotify model and SAFe is a great example in my opinion.
I believe that the gain for Spotify wasn’t the picture of their model but the journey they took in order to end up the way they found suited best. Are they even still using the same patterns? So the model has no value for us non-Spotify employees other than learning from their journey. The same applies for the the combo that has been implemented a lot lately: Scrum and DevOps. This combo should be regarded as an possible option. Not as an industry standard.
A Scrum DevOps organisation means in general that all operational and development engineers are being put in teams and all the work follows the Scrum flow.
DevOps
We really should call it Change and Run instead of DevOps. The words development and operations have a strong historical meaning in most companies. It is almost impossible to break with this and see the true meaning of DevOps:
DevOps teams have full ownership of both the changes as the stability of their products/services. There’s no interesting distinction between what is dev and what is ops other than a DevOps team does everything to deliver and maintain qualitative products and/or services themselves.
Foundation and innovation
Let’s say that we work at a company that has an existing set of products (some custom in-house build and some of the shelf) which almost all of our existing customers use. We are currently also experimenting with new products. These products are partly focussed on the existing customers but also on new market segments. We call the first foundation and the second innovation. Both teams are DevOps teams.
The teams that are focussed on innovation (example A) have a entirely different approach than the foundation teams that are about maintaining the current landscape (example B).
These different approaches all have different patterns, tooling and measurements. For each there are ways with the best suited patterns for each situation. We cannot just choose a framework and apply it to everything. That has nothing to do with flexibility. Some ways of working, tools or patterns are suited for both situations and some are not.
People
The people in the example teams can also be very different. That doesn’t make them good or bad engineers. It has to do with affinity a lot. Hylke Stapersma wrote a great article about this from another angle: Coaching commandos, infantry and police:
Not everyone likes new fancy frameworks or tools nor should everyone. Some developers are less interested in maintaining an older application than others. We should embrace this diversity. Different strokes for different folks.