Indeed I wish we'd see less fixation on burndown and velocity. There are superior alternatives and what matters if the full flow of work.
A bit long for what it's saying. And yet it's a good reminder, don't focus on why... Ask the question as many times as necessary to get to the point where you can find a solution which prevents issues to reappear.
Cryptic title to be honest. But this is a good explanation of why any "agile transformation" better start close to the code and in particular with automated tests. If you can crack that nut (and it take time), the rest will follow naturally.
I agree with this very much. The only productivity metric in the end is the end-user satisfaction.
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.