Definitely this. The distinction between stories and tasks is an important one. Don't confuse them.

There's some truth to this. Shorter optimized iterations with no good learning opportunities lead to busy work.

A few points to take with a pinch of salt, especially regarding the proposed solutions. Still it makes a very good point that most transformation failures toward agile organizations are due to lack of trust and the swapping of one bureaucracy for another.

To take with a pinch of salt since it has a couple of biases (most notably it focuses a lot on satisfaction) and the sample size is a bit small. A few interesting insights nonetheless. In particular it hints at autonomy, transparency, technical skills and vision as being the most important factors for satisfaction and success within teams. The applied project management method? Not so important it seems if the other factors are satisfied.

Looks like a nice way to automate the creation of changelogs.

Definitely true. This is why I refrain from using the term nowadays... this allows to focus on the principles instead. Takes more time to explain but allow for slow and steady change management. Indeed it's not perceived as an all or nothing situation anymore.

Good approach for tackling it indeed. The crux of the issue is really measuring the tech debt since it's still a fuzzy concept and we have no good metrics for it.

An interesting interpretation of what was behind the "move fast and break things" motto which is nowadays blindly followed by some. A bit of a long piece but does the job and propose a more complete view and an alternative approach.

Interesting set of advices for better communication and more sustainable production of software.

Very good piece. Explains why postmortems are important. It also explains how to prepare your organization to conduct them and how to do them properly. This is important since a lot of pressure will happen in case of a failure.

Indeed, going for scrutiny on made up numbers probably won't get us nowhere. Tweaking them won't help either. It's the shared goals which matter most.

Lots of food for thought in here. I really appreciate how Kent Beck's thinking keeps evolving. This Explore, Expand, Extract curve is indeed a good way to frame things. It is a good base to know what to put in place or not.

Interesting set of follow up questions during a retrospective.

Nice little article about Conway's Law. Shows nicely all the ramifications it has.

Wording matters, and framing things differently can free teams from the Scrum limiting views. This is required to find a path towards improvements.

Very interesting! This is really old wisdom which should be more widespread. A few words of caution in there for everyone, me included.

Good piece on how to reduce uncertainty before something is built and ready to be in front of users. It starts with prototyping but goes all the way to feature flags and deployment

Nothing really new but well written. This highlights fairly well the importance of decomposing projects, having at least the broad strokes of the architecture laid down and how automated tests help drive the progress. It's nice to see it all put together.

A good reminder that there is life outside of Scrum... I especially like the framing of Scrum as training wheels. When you learned biking you outgrew the training wheels, didn't you?

It's a bit a "yet another article" about estimates. Still there are a few good points in there, they're harder to apply than it sounds though.