The process many organizations today use to deliver software is called Scrum. We think it’s a bad fit for our clients and us. Let me explain why and what we do instead.

Scrum was created to solve some problems that big corporations have with their software projects. It replaced long phases of “coding to specs” with shorter iterations of “coding to tickets,” hoping to deliver software faster.

Predictably, the ideas look better on paper than in practice.

In this series, I will argue with the key tenets of Scrum and offer an alternative to:

  • backlogs
  • sprints
  • team ceremonies
  • roles and responsibilities

To be clear, I am not arguing that Scrum is bad for everyone. As the de-facto standard for corporate software development nowadays, it still is an improvement over its predecessor.

For startups and smaller teams of high achievers, not so much.

Today, let’s look at backlogs and what we can do to replace them.

No to backlogs, yes to living documents

A backlog is a list of features described as “user stories” in Scrum parlance.

It replaced long specification documents. To be sure, we have issues with those, too. But how do you elaborate and contextualize your ideas if all you’ve got is a one-dimensional bucket list?

Backlogs are terrible for organizing ideas. There’s no way to see how they are connected, from which desired outcomes they are derived, or if the client cares about any particular item.

What’s the alternative? A living document. A document that’s high-level enough so that we can use it for steering the project and detailed enough so that the team can derive its daily work from it.

It’s neither a specification written up-front nor is it documentation written after the fact, both of which become obsolete before the software ships.

It must spell out the desired business outcomes and a broad description of how the team plans to achieve them. It might contain prototypes, Figma designs, and whatever additional artifacts are appropriate to communicate the vision.

The document can only be living when used continuously and updated as the work evolves. That can only be true if it’s central to the process.

How do you make it so? By aligning incentives for everyone involved.

First, make the document alive from the perspective of the client. Capture the outcomes of your discussions in the document itself so that the client will always see their vision for the future there.

As long as this is true, the team will also trust the document as the primary repository of ideas, similar to how they trust Github with their code.

The team can derive smaller chunks of work into, for example, Github issues. The client rarely cares about those directly, but you can link them back to a planning table in your document, if you have one, to increase visibility into the project’s progress.

That’s all there is to it.

You can use all kinds of collaboration software for this. We like to use Notion. It feels like it was made for this purpose.

Summary

Backlogs are an over-reaction to long specification documents and are lacking in many important aspects. Documents are much better at organizing information but instead of writing them ahead of time, planning to capture all important decisions up front, make them a living repository of ideas and decisions as the project runs its course.

In the next installment, we'll look at iterative development and how to replace two-week "sprints" with iterations that deliver more meaningful outcomes to the client.

photo credit: Mari Helin