stevefenton

I'd start with small batches. Quite a lot of the benefits come out of just doing fewer things between each release.

It's fair to say that culture eats everything else alive. It's also the hardest thing to change. I've worked in a few places where we felt helpless to impact the culture and creating a culture-bubble (i.e. to the extent of the technical teams, but no further) didn't help impact business outcomes, even where it made our lives a better. Maybe that was enough to make the culture-bubble worthwhile.

Accelerate: The science of Lean Software and DevOps

Nicole Forsgren, PhD, Jez Humble, Gene Kim

IT Revolution

ISBN 978-1-942788-33-1

You may like Platform Engineering even more as there's a lot of crossover with what you mention. A key difference from your list is that you enable teams to build and run their own applications, so they remain responsible throughout. You would provide a simpler way for them to do it, so they could self-serve.

Companies who need every engineer to "Do Everything™" are doing it wrong. A team may need to cover a lot of ground, but by putting together folks who have different skills. It's a management skill to assemble a team with diverse experience, rather than only hiring individuals who are "a team on their own".

I don't think you should feel excluded from "Software Engineering" just because you don't have a passion for managing containers. We need people who can write great code in the world, too!

Yes, there is that! ;)

DevOps part one was just "developers and operations working more closely together". It only really required the managers to update the goals of the two specilizations to remove the conflict (developers are rewarded for delivering more, operations are rewarded for stability).

Once the research picked up, they started building out a broader picture of what a DevOps organization did and whether those things made them more successful (better at delivering software, more reliable, more profitable, etc).

The Phoenix Project / The Unicorn Project explain the concept by telling a story - they kind of tell the same story, but from different perspectives. There's also Investments Unlimited which takes an even broader view by adding governance, risk, and compliance (but in a way that aligns to DevOps).

In 2023, DevOps is best described by the DORA research (The State of DevOps Report) as it covers technical, cultural, and product concerns that all amplify each other.

Rather than a maturity model, DORA use metrics and a capability model. The idea is you use the metrics to decide on which capabilities to focus on. This tailoring to your context is the great thing about it - it's what you mention when you talk about determining the capabilities per-org... that's why you'd choose a capability model, not a maturity model. Maturity models seek to standardize the practices globally, rather than leaving room for customization.

I guess... we're pretty much in agreement - except perhaps over the definition of the two types of model :)

Cynefin is a great model - I must admit I've been insterested in it for a long time (I think Liz Keogh brought it to my attention) - but I've not applied it practically. Anyone got ideas for using it IRL?