Definitely this, as projects scale, keeping an eye on dependencies between teams is key to efficient allocation. This will happen by trying to eliminate said dependencies, reallocating between teams.

It will fluctuate with time so it needs to be kept in check. Indeed, some things are commodities so can be decided upfront, but the rest of the functional envelope will change over time. Also make sure you drive the project by risks to have early feedback where it matters most.

This is one of those workshops I like to do with teams from time to time. Didn't do it for a while. I wish this resource was on a safer space than google docs.

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

This is indeed two sides of the same coin. A good reminder that you need to pick the right approach depending on the context.

Interesting point of view. I'm not sure I fully agree with the classification but it gives something to mull over. For sure the less reliable your estimates the more padding is needed to have some predictability.

Rituals are definitely important... if you understand why you're going though them. If you just "go through the moves" they're failing.

Or why estimates need to happen in one way or another.

Good summary of the different possible options around remote work.

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.

Or why the term "user" in "user stories" need to be seen very liberally.

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.

Short and to the point. It needs repeating from time to time for some reason.

Indeed, Kanban is massively misunderstood. This is unfortunate, this article does a good job explaining what this is about.

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.