This has been documented for a long while. Of course, it's been followed by an unhealthy fascination for the "Toyota way". This kind of cargo cult of course lead you nowhere to doing things properly. And yet, now that the dust settled, there are good lessons to learn from Toyota management back then.

Estimates are is always the weak spot in project management in my opinion. Story points are generally confusing and there are better ways.

The definition of ready can be a big help avoiding too many questions about stories as they are implemented. They should be clear before hand.

This is a very good resource on the different ways to split user stories.

Martin Fowler obviously wrote a lot on the topic. This is a nice guide pointing to some of the most interesting resources on his blog around the agil topic.

Nice list of ideas for stories estimations. I applied some of that with nice success.

When teams grow the usual standup/daily meeting format doesn't work anymore. What's proposed here is a nice alternative.

A good justification of why you want to slice your stories finely. It definitely helps steering the project and reduces chances of bottlenecks.

Interesting method to split stories which are proving difficult to split.

Was it all going to end up as a management fad? I'd say yes. It's not to say the values and principles in the manifesto are useless... but if something gets successful you'd better have guardrails on how it'll be warped. It didn't happen here.

For technical tasks, the user stories common structure (the "Connextra format") is not adequate. We can indeed take inspiration from other long forgotten agile approaches for alternatives. I particularly like this one, and it works for user stories as well in my opinion.

Interesting history outlook on where Lean Software Development is coming from. The focus on flow efficiency rather than resource efficiency is definitely key.

Or why focusing on the practices will likely lead to cargo cult and you might never reach the real benefits. Don't mimic other organisations, think about the underlying philosophy.

There's a balance to strike on quality. Too much or too little and you won't be able to progress towards the user needs.

A good reminder than the supposedly seminal paper about waterfall process was likely identifying it as an anti-pattern.

You can also have experiments on your organisation. This is actually a good thing and probably should be done when something keeps popping up as a problem.

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.