I wonder what the whole series will give. Anyway I very much agree with this first post. Too often projects have a single product manager and that's a problem.

Interesting move on the Scrum definitions to move from roles to accountabilities. The article does a good job explaining it but then falls back into talking about roles somehow. Regarding the tech leads indeed they can work in Scrum teams. Scrum don't talk about them simply because Scrum don't talk about technical skills.

Unfortunately and as far as I can tell we're still not there. I'm trying to do my part in how I push for those topics when working with teams and organizations. So many things to help with on the practice level and making developer teams function properly.

We can cast doubt on the "Spotify Model" (not really a model anyway...) all we want. Still, I think the whole "guild" idea in there was spot on. This article gives a feel of how it can be setup and the benefits it can bring.

What's behind the notion? Some historical musing about self-organizing teams and the design they produce.

A few interesting ideas for having retrospective at a larger scale than the single team.

I think the Open Agile Adoption ideas have been unfortunately unnoticed. It's thus hard to tell if it would have been fairly efficient. What's sure though is that the widespread mandate approach used during the past decade does a disservice to teams.

This is indeed one of the core questions on you "agile" project management. If the feedback loops are very long, you're in for trouble.

I think this is still one of the best distilled explanation of product ownership. It's also interesting for the other parties on an agile project.

Those principles are old now, but they really captured the zeitgeist of the time.

There's often confusion as to where the management responsibilities are in agile teams. This little rambling does a good job pointing it out and giving an idea of how management happens inside and around teams.

A good reminder that there's a lot of things going on in something as mundane as a stand up meeting. It needs to be organized properly for the needs of the teams.

The question is always valid. I like this particular answer.

Looks like another certification circus is about to begin...

It's likely the best explanation of the YAGNI acronym I know. Explains quite well when it applies or not.

Don't just blindly apply dailies. Make sure they really solve a problem in your team.

You have to be willing to experiment and adjust in order to truly be agile. Otherwise you indeed just do dailies and call yourself agile.

Neat tools to keep retrospective fresh. If people settle too much in habits they quickly become dull.

Nice check list, there's more to project life than churning out tickets.

So, you derailed and the joy is long gone in your team. This second part shows a possible way forward. Although it's probably not widely applicable (YMMV), the proposed end goal is what matters... If you stop fussing over labels but focus on what matters you're likely on the right track.