Forcing functions are constraints that nudge people towards desirable behaviours. In this article, I discuss five forcing functions to promote effective meetings.

Advocates of in-person work often say they need to get their teams together for brainstorming sessions. This is a waste of time. The effectiveness of brainstorming is a corporate myth.

Agile inceptions are a workshop oriented process to help you get your project on the road. Remember Mr Miyagi? It’s all about ‘balance’ in communication. Given the time-boxed nature of inceptions, mixing synchronous and asynchronous communication is an effective approach. In today’s post, I want to tell you how this balance can be a mighty good thing for your project.

In a world of work that’s changed rapidly in the two years of the pandemic, I feel we need to ask the “Why” more than ever before. This is a new normal and as we switch between work patterns, such as forced-remote, remote-first, all-remote and hybrid, some practices will have to die. Others may have to change.

In this post, I want to explore two sprint ceremonies with a “Why” lens. I’ll also share a few ways you can buy back time for your team by taking lightweight, more async-friendly approaches to manage iterative development.

If working remotely is more productive, what’s face-to-face (F2F) good for anymore? In today’s post, I want to explore that question in some depth. I have strong opinions; so don’t get all bent out of shape when you read this.

When you’re in a remote setup, think of your retro not as a meeting, but as a process. That process has two parts - asynchronous and synchronous. How much you do asynchronously is totally up to you and how adept you feel with working this way. This post will tell you how to run effective retros distributed team, with a solid sprinkling of asynchronous methods.

After reading a lot of long form advice about asynchronous agile, some of you may look for a ‘gimme’. The Cambridge dictionary defines a ‘gimme’ as “something that is extremely easy to do”. So this post is about three things that are relatively easy to do on a software development team that’s trying to be more asynchronous. Consider these as little plays that you can try independently. Sounds good? Let’s get started.

Distributed standups are painful, period. With modern tools there are better ways of getting the value you’d expect from such a meeting. As an individual, you’ll get back a few minutes of your life every day. The bigger benefit? You can share updates continuously, and at your own pace. From a team perspective, you’ll be able to create an audit trail of communication and, of course, plough back the time savings into deep work.

It’s clear that we need fewer meetings. This is step one to being asynchronous, and I’d argue that it’s the most important step to take if you want to be a productive, remote-first organisation. In this post, I’ll outline the ConveRel quadrants for you to figure out which meetings you need and which ones you can get rid of.