Interesting exploration on the difficulties to switch a team to XP. I'm not fully aligned with some of the fine details pointed there... That said there is a core truth that "XP is about social change" so if you mandate it as a managerial decision it can't be XP anymore.

A good reminder of what agile is about from the product management perspective. If you can regularly demo your work you ensure a feeling of progress.

Good explanation on how the agile movement scaled down about design over time in its literature. It's probably its biggest failure. The good thing is that the pendulum is starting to swing in the other direction a bit (that's probably why Beck is now working on a book series on software design).

He is spot on again. The scope is what will allow to create flexibility in a fixed price project. This is what leads to the necessity to work incrementally.

Very nice interview. This is an interesting reflection on the past 20+ years of Agile Software Development.

A bit long and a couple of mistakes when pointing out the flaws of story points. Still, it's definitely a worthwhile read. Quite a lot of the criticism of story points is warranted and the proposed approach based on queue theory is welcome. This is stuff you can find in Kanban like approaches and mature XP.

Good reminder that teams are made out of people. It's good to look at the daily standups less as a technical management tool and more as a need to get into the work.

Interesting musings indeed. That's lesser heard opinions about the manifesto and its origins. Good food for thought.

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

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.

Good summary of all the "fake agile" practice one can see. Without enough trust it's not possible to put in place an agile organization.

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.

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.

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.

There will always be some design and some testing. The intensity of both activities needs to be properly managed over time though.

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.