Estimates are is always the weak spot in project management in my opinion. Story points are generally confusing and there are better ways.
This is a very good resource on the different ways to split user stories.
Indeed, people getting into lean processes tend to obsess over "eliminating waste". Sure there might be some waste to clean up but it's pretty much useless if you don't focus on the flow of work.
Where are acceptance tests coming from? They're generally the result of a conversation.
A good justification of why you want to slice your stories finely. It definitely helps steering the project and reduces chances of bottlenecks.
Indeed, having generalists in teams is definitely what you want. Having only specialists will reduce the project efficiency.
The other advantage of not relying only on specialists. You actually get teams better at solving problems due to the extra context and communication channels the generalists will bring.
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.
A good reminder than the supposedly seminal paper about waterfall process was likely identifying it as an anti-pattern.
Decades that our industry doesn't improve its track record. But there are real consequences for users. Some more ethics would be welcome in our profession.
Interesting approach I didn't know about. Definitely worth trying. I like how it seems to bake risk management in.
I'm a bit on the fence regarding this article. That being said there's something I like about it: it's not always purely about money. It's also a good reminder that if the reward is in monetary form it's almost impossible to not somehow alter team dynamics with it.
I wouldn't frame it as always superior (I'd argue the article falls a bit in this trap). Still this can sometimes be an alternative to driving everything purely on project mode. Some organizations would benefit from such a change of perspective other less so.
There are indeed way to deal with important but lower priority tasks. You want to tackle those to avoid your teams to slow down too dramatically.
Indeed, stress can't be completely eliminated... but at least build an environment where risky situations are reduced as much as possible. So that when stress or anxiety shows up you can take notice and react. Otherwise you'll be creating vicious circles.
Indeed many projects are started without such a charter and that creates issues.
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.
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.