Sprint planning is amongst the most time consuming activities for development teams. One could argue that the value you get is not proportional to the effort you put into these meetings. With some effort you can drop sprint planning meetings completely.

If all you want to share is a “yesterday, today, blockers” update, you don’t need a standup meeting.

A single line message that you send to 200 people isn’t a single line message anymore. It’s a 200-line message. Instead, “shrink the blast radius”.

Arguments on chat don’t help. Take a deep breath and slow things down.

One thread, one topic. And vice-versa.

Limit chat conversations only to those necessary to the discussion.

In the spirit of limiting messages, use emoji reactions where possible, instead of responding to a message.

It’s ok to write longer chat messages! Save everyone the extra notifications.

Imagine calling someone on the phone, going hello! then putting them on hold!

Estimates aren’t necessary on every project. In such cases, where can you shift your measurement focus?

If you have an established product, then you’re probably less concerned about big release plans. Instead, your priority will be to enhance your product regularly. For such situations, I’m a big fan of Ryan Singer’s “Shape up” approach.

Back in the day when agile still wasn’t a thing, wideband Delphi estimation involved anonymously filling out forms. You can do the same thing now, but more efficiently with online forms.

You don’t always need a long meeting to play the velocity game. It’s easy to run this using a simple survey.

Nigel Thurlow and Dave Slayton came up with this approach to estimate scope, at Toyota. You can use this to estimate size at the start of a project. You can also use this technique when you have to estimate a large amount of scope for an in-flight project.

Warp speed estimation is a way to quantify scope at the start of a project.

There’s an expression in Latin - festina lente. It means “make haste slowly”. We optimise for speed in software development. Deep work is often the casualty in this quest for speed. Slowing things down through writing has several benefits.

Advocate for a pair programming pattern where two developers act as each other’s accountability partners.

Create smaller decentralised pods inside the team to devolve responsibilities. Pods operate autonomously and make their own decisions.

To make remote pairing work, the tools involved play a big role. Make sue you have specialised tools that serve the purpose.

Take a break by going solo on simple coding activities that won’t benefit from the intense code review of pair programming.