Are your rituals serving you?

We knowledge workers love rituals. We're always seeking ways to reduce friction, increase productivity, and increase visibility. There's Agile, XP, Kanban, Pair Programming, and now even Mob Programming. There's an entire industry within an industry devoted to teaching others how to apply these principles.

Some teams hold a daily standup. Most hold some form of an iteration planning meeting. And some apply points-based estimations during their planning meetings.

Both standups and estimation have value, depending on your team. If you have a dedicated project manager who scopes the next sprint's work, they might benefit from points-based estimations because they can measure how much progress to expect next. And if you work on a team building a high-touch customer-oriented product, you might benefit from a daily standup to keep your non-technical stakeholders in the loop.

But I've been on too many teams who did one or both of these rituals even though they didn't provide any tangible value. And in many cases, the maturity of modern network tools has rendered these rituals all but obsolete.

Are your daily standups redundant?

Before the likes of GitHub pull requests, it was difficult to, at a glance, see what your teammates were spending their time on. If they had a question, the daily standup served as a space for making inquiries without feeling like you were interrupting their day.

But now that GitHub pull requests enable a one-click view of ongoing efforts by your team and a vehicle through which questions can be asked and answered on our own time, the daily standup is a relic of a less connected past.

And even if you do commit to a daily standup, does it necessarily need to be a synchronous meeting where everyone is present at the same time? I've worked on a team with a #standup Slack channel. We each post our daily standup in the room. Everyone can read up on what the rest of the team is doing that day and whether they're blocked. And no one has to interrupt their workflow to do it.

Ask yourself: Do you get much or any value from your standup, or is it just another mindless ritual?

Are your estimations meaningless?

Stakeholders want to know how much their software is going to cost. This is a reality with which every software developer must contend. But another reality is that software estimation is a losing game.

We can try, to the best of our ability, to assess a software problem and estimate how long it will take to come up with a solution. Armed with an understanding of a fixed software problem, estimating the time to build a solution is actually relatively easy. But software problems are rarely understood correctly ahead of time, and are rarely ever fixed.

Most software problems are complex enough that they require further inquiry after beginning development. There might be a variable we didn't consider during estimation. We might have misunderstood the original problem and gotten that feedback from the customer halfway into development. When was the last time you developed a piece of software without asking for clarification from your customer in the midst of development?

And even if you're fortunate enough to understand a problem thoroughly enough to implement it to the customer's desires the first time, there's a good chance they'll change their mind about it in the middle of development. Maybe they think of a better way. Or maybe business conditions have changed and it makes more sense to do things differently. Whatever the reason, requirements change. And when requirements change, you can kiss your original estimate's accuracy goodbye.

Okay, then what do we do instead?

Estimation and daily standups attempt to solve a real problem: Making sure everyone involved in your project is held accountable and are aware of the changing conditions of your project.

If your team reports that they find value in these activities, then keep doing them.

But if you really consider the opportunity cost of continuing to live by these rituals, you might find their cost outweighs their benefit.

Does interrupting everyone's flow during ongoing high-value development work to hold a daily standup have a net benefit to your team's productivity and happiness? Or would the team be better informed by committing to reviewing open pull requests and tickets once per day on their own time?

Are your estimations providing your product owner with valuable insight into what progress they should expect in the coming months, or are your estimates so skewed from reality that they're meaningless?

Do you own your rituals, or do your rituals own you?