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.

This model is probably still a better one than certifications or very heavy processes. Far from perfect of course, but at least it gives a compass to teams to see if they're going in the right direction.

How to get started with putting in place an Agile approach in a team? Clearly structure helps in the beginning. One caveat of the article though: don't read this as having to respect a book to the letter forever, it's merely a starting point.

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

Interesting alternative retrospective format. The way of framing the questions might help get new ideas.

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.