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.

Hear, hear! If you go through rituals without understanding the values and principles... It's not Agile anymore so stop pretending. Another certification isn't going to save you at this point.

If your team is solely in "pushing tickets out" mode, there's indeed a problem. Teams needs more agency and care for the output to actually strive long term.

The whole Scrum training and certification industry has a problem... and it's been going on for a long time.

A bit of a forgotten approach I think. A good way to quickly gauge projects, show the amount of work and spot the dependencies.