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 opinion piece. Very often we see people mandating a "process". It's almost always the wrong way and how you end up with people following blindly "Scrum by the book" or "SAFe". The approach proposed here is smarter: give the business constraints, let people choose what works best for them, support them along this journey.

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

The interview is overall very interesting (I advise listening to it in full). It's nice to have such an historical perspective. At 15:00 there's a question which prompt a very important explanation of why the word "over" was chosen and repeated in the agile manifesto. Unfortunately it's been often misinterpreted...

This trend around critiquing code reviews on the argument of "trust" should be challenged indeed. This is just the wrong way to approach it.

Old article, still an interesting approach to making changes and looking for growth opportunities. There is value in trying not to frame everything as problems to solve.

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?

OK, not a perfect article, I think there are a couple of blind spots in the reasoning (I doubt all the estimates were as systematically bloated as presented here). Still, it's another interesting account of the problems created by the cargo cult agile. It indeed seems to resonate with the fact that the tech sector is very hype driven. A lot of useless work then ensues.

Excellent response to an article full of misconceptions about the Agile approaches. This turns in a good summary of cargo cult agile we see in the wild and the original intent. I especially like how it points out approaches to properly integrate UX as well.

Interesting to see the beginning of Kent Beck's thinking about scaling Extreme Programming. This was clearly missing. First by looking at dependencies which are definitely a problem which arises quickly at scale.

YAGNI is one of the easiest to misunderstood ideas behind eXtreme Programming. That's why I think it's a good thing it stays under active discussion. Often people understand it too literally which can create issues. That's why people talking about "PAGNI" (probably are gonna need it) are right. After all, people who also conceptualized YAGNI wrote back then: "This doesn't mean you should avoid building flexibility into your code".

Interesting first set of antipatterns... I clearly already encountered the "In the soup" and "Loudmouth" ones. This is like a long advertisement to the book of course but I think I'll try to get my hands on it.

This can indeed quickly become a problem. This slows down everything and can bring with ot a silent killer: context switching. It is avoidable though, there are good strategies to prevent WIP to go out of control.

OK, this is the best critique of the "Spotify Model" I've seen around. There's been plenty of unfair criticism thrown at this "model" (never aimed to be something you fully replicate though, hence the complaints I think). This one is properly balanced and doesn't just throw everything in the garbage bin, it takes the model bits by bits and try to highlight where the limits are. Very constructive.

Interesting points about agile and lean approaches. In my view they tend to complete each other, that said the diagnostic of Scrum as practiced in most places today is not Agile is very true. So beware about what you're doing, is it folklore? is it dogmatic? or do you really apply values and principles?

Interesting approach regarding estimates. Might especially make sense combined with kanban like project management.

A good set of skills to develop to bring technical changes to a project. It doesn't need to be overwhelming or a fight. If you doubt, if you have empathy and if you slice the proposals it can become doable and help the people around you.

Finally out of Google Docs it seems. Better version for sharing around. Still an interesting list of case studies and opinions around SAFe. I learned a few things, I didn't realize it's creation was so disconnected from the pre-existing agile community. It all seems to confirm my opinion that it's better to stay away from it though. The few organizations I know of which use it are clearly very much in a command and control mode. This is going backwards.

This feels odd to be hosted on a Google Doc, but this is an interesting list of case studies and opinions around SAFe. I learned a few things, I didn't realize it's creation was so disconnected from the pre-existing agile community. It all seems to confirm my opinion that it's better to stay away from it though. The few organizations I know of which use it are clearly very much in a command and control mode. This is going backwards.

Good point, this little wisdom from Kent Beck goes further than just code and refactoring.