Software development continuously reinvents itself. Practices, languages and frameworks all change at a fast pace.

This is less true, historically, for the development cycle itself. When it comes to how we work together, there hasn’t been much progress over classic frameworks like Scrum or Kanban, which are now 20+ years old.

In the past couple of years, though, something has changed.

The shift to remote shuffled the cards of how engineering teams work, suddenly turning it into a prime-time topic. Managers are questioning what makes their teams productive and they are more willing to experiment.

There is a feeling of reinvention and nothing is sacred anymore, which led many teams to reflect on their practices, like:

• Do we really need daily stand-ups?

• Are two weeks cycles long enough to deliver value?

• Should we work in cycles… at all?

This article tries to bridge the old with the new.

I will address common criticism of traditional agile practices, and discuss popular, sometimes wild, but always interesting, alternatives.

Finally, we will figure out how to converge all this advice into a process that fits your team.

We will cover:

• 🔄 The role of processes — why do we even bother?

• ⚖️ Criticism of Scrum — the good, the bad, and the ugly.

• 🚪 Alternatives to Scrum — classic, new, and wild ones.

• 🔨 How to create your process — mental models to make the right calls.

• 📚 Readings — case studies and resources to learn more.

As always, the article also includes contributions from people in the Refactoring private community.

Let’s dive in 👇