Last time, we talked about the problems with Scrum backlogs and Sprints and offered alternatives that work better for our clients and us.
Let's address the Scrum ceremonies. The problems we see here are downstream of the core issues we see with Scrum. Trying to fix them won't be as beneficial as replacing the whole framework with a process that's better suited to produce valuable outcomes for clients.
The ceremonies that we'll cover are:
- planning
- daily standups
- retrospectives
Planning
Planning work for the next two weeks (a typical length of a Scrum Sprint) necessitates smaller work increments.
The team picks up parts of bigger features, ordered by their declared business priority, and tries to fit as many into the sprint as it feels comfortable finishing.
Important context can get lost here. Since the team will only work on a subset of any given feature, thinking about future work is easy to postpone as the goal is to define what the team will do within the Sprint.
Many teams then "break down" the backlog items into so-called "sub-tasks," which are miniature work artifacts analogous to moving a single part on an assembly line.
Doing so gives the team a false impression that they did a full analysis of the feature, which they will only actually understand once they start developing it. It constrains individual creativity and creates the perfect environment for mediocre work to happen.
What to do instead: work in longer cycles to make room for concepts to form fully.
When planning, the result should be that the team fully understands the features and what outcomes they are designed to produce. That way, the team has a way better chance of shipping code that matters.
Standups
The "standups" are allegedly meant for team synchronization. More often than not, they are a reporting tool. And a bad one.
A team will develop its synchronization and collaboration rhythm. Whether in the office or remotely, developers now have tons of tools where meaningful conversations can happen.
That can be on Slack, on Github when reviewing pull requests, in Basecamp or Notion - whatever tooling you use, there's plenty of space for collaboration.
The daily standups add little value to the process. When used for reporting, they invite discussions that should be happening in other places or not at all.
Management should rarely happen on the individual task level. If it does, the process is very broken.
What to do instead: for sure, management needs to have controls in place. The best ones focus on the work product (code, designs, etc.), not on the process (unless it's broken).
Given today's modern approaches to development, such as continuous integration and deployment, stakeholders should have an easy way to check on the product as it's being born.
Have contributors report their progress asynchronously, e.g., in a Slack channel. Have a way for individuals to reach out when they are stuck. Otherwise, let the team develop its synchronization mechanism.
Retrospectives
The notion that a team should inspect and adapt its processes has merit. The question is, how frequently?
Two weeks is too often.
All you learn about your process within two weeks are tactical or one-time hiccups that you should fix immediately.
A genuine understanding of any fundamental flaws of your processes requires a more extended period. And you should continuously collect relevant performance metrics so that you can, once every couple of months, inspect and adapt the processes.
Doing so bi-weekly invites random navel-gazing and speculation since the team only focuses on the past two weeks. Process inspection should be strategic, focusing on the big picture. Scrum retrospectives don't; they are tactical and ultimately useless.
What to do instead: solve tactical issues as they happen, and meet as a team every couple of months to discuss the big picture. Inspect and adapt your processes once you have gathered sufficient intelligence and are thus equipped to make meaningful improvements.
Summary
This three-part series outlined the problems we see with the Scrum methodology and offered alternatives.
Since Scrum is used widely, anyone considering working with us deserves to know where we stand.
Our view is pragmatic, not philosophical. That's why there was no discussion about the motivations behind the Scrum method, its history, or the people behind it.
We are focused on delivering the best outcomes for our clients, and using Scrum would impede that.
We found a way that works for our clients and us. By sharing it, we hope that others can take inspiration from it. Summarizing its pillars:
- Write and maintain living documents instead of backlogs
- Make iterations long enough so that each is a major milestone for the product
- Manage the work product, not the activities, solve tactical issues immediately and gather once in a while to discuss strategy
They ensure that the team is aligned with the client's vision, ship visible features that make the vision more real with each iteration, and have the room and freedom to decide how they will accomplish it.
It is an idealized picture, yes. In real life, changes happen, and visions are refined or altered. We've [touched on this topic recently and will certainly tackle it again.
photo credit: Chino Rocha