A bit too high on the "positive caricature scale" to my taste. That said there's a kernel of truth there, focusing on the developer experience will lead to improved impact.

You can also have experiments on your organisation. This is actually a good thing and probably should be done when something keeps popping up as a problem.

We can cast doubt on the "Spotify Model" (not really a model anyway...) all we want. Still, I think the whole "guild" idea in there was spot on. This article gives a feel of how it can be setup and the benefits it can bring.

Very interesting maturity model about proper communication in a remote work setup. I think it definitely makes sense and doesn't feel too difficult to evaluate.

A very long read but contains lots of insights. Goes from two very famous security related failure, to highlighting how a test first approach could have helped. It then finishes with a long section on how to foster a testing culture in an organisation.

Interesting stuff, very rich I think I'll have to get back to it. This gives good clues and ideas of metrics to look at when evaluating teams output. Some of the findings confirm hunches which is welcome. It also shows that measuring productivity keeps being a messy business, there are so many factors influencing it in some way.

I'm a bit on the fence regarding this article. That being said there's something I like about it: it's not always purely about money. It's also a good reminder that if the reward is in monetary form it's almost impossible to not somehow alter team dynamics with it.

I think the Open Agile Adoption ideas have been unfortunately unnoticed. It's thus hard to tell if it would have been fairly efficient. What's sure though is that the widespread mandate approach used during the past decade does a disservice to teams.

Good opinion piece, I wholeheartedly agree with the author on the topic. Like it or not, politics happen in organizations. Ignoring this fact is an enabler for bad decision making.

I'm not fully aligned with all of this article. That said, it's an interesting way to frame the topic of how we're having to make tradeoffs all the time.

An old series of posts which highlights quite well why GitFlow can be a problem and that you likely want something simpler. Since I still find GitFlow often recommended as a knee-jerk reaction, this is a good article to have in hand.

A good reminder that long hours are not a sign of success with your project... on the contrary.

A good reminder that there's a lot of things going on in something as mundane as a stand up meeting. It needs to be organized properly for the needs of the teams.

This is still a good framework to think about what motivate developers in a team. Not everyone is the same.

Don't just blindly apply dailies. Make sure they really solve a problem in your team.

Interesting article about expert generalists (also called "paint drip people" by Kent Beck). This is definitely a skill to foster in teams. The article is long enough that I'm not in agreement with everything in it. That being said there's a lot of food for thought here.

Both approaches have their pros and cons of course. Whatever you pick, it has to start with a care for quality shared within the team.

If your team is solely in "pushing tickets out" mode, there's indeed a problem. Teams needs more agency and care for the output to actually strive long term.

I like this article. Indeed, focus on building organisations and teams where it's easy to do the right thing bit hard to fail. This is much better than obsessing over mythical 10x engineers.

Interesting trick. Good way to frame decision making when needed.