Unfortunately and as far as I can tell we're still not there. I'm trying to do my part in how I push for those topics when working with teams and organizations. So many things to help with on the practice level and making developer teams function properly.

What's behind the notion? Some historical musing about self-organizing teams and the design they produce.

It's likely the best explanation of the YAGNI acronym I know. Explains quite well when it applies or not.

Nice and short explanation on the design rules Kent Beck had in mind when devising XP. It still generally applies in my opinion.

This looks like a really fun workshop. Been wanting to run one for a long time now. Somehow I never had the chance.

Or why I really hate the whole certification business. Especially for process and practice's related topics, this pushes the multiplication of brands and churches to sustain them. The right approach is almost always a blend of different influences and flavours.

They're so misused that it's better to let them go. Indeed, we can go as far as wondering if estimating stories instead of slicing them is a good idea at all. Doesn't mean all estimates disappear of course, but at the single story resolution? You likely better invest time in slicing them better.

What is the "Whole Team" practice from XP? Well, it's fairly simple in the end... it's about collaboration really. Needs to be reminded often though.

This is funny how this article written a long while ago now is still relevant... These are all good reasons for reading Kent Beck's book about XP.

Looks like a good set of tips of get more DDD practices in place without the badly understood vocabulary which usually comes with it.

A look back at XP practices with some interesting insights. This doubles as a good XP primer as well.

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.

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.

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.

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".

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.

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

I definitely agree with this. Managing complexity is our trade.

Interesting musing on the skills required, why it's actually hard to apply them... clearly it's because you never find a real place to learn them so that ends up being on the job.