I’m a big fan of dividing and conquering. After all, isn’t that what asynchronous collaboration is all about? But dividing and conquering without a cohesive vision is mere reductionism. Ingredients are nothing without a recipe. A recipe is nothing without a vision. The whole is more than the sum of its parts.

When teams and managers forget about the values and sentiments driving the agile movement, practices become convenient fig leaves to cover up the “inanities of corporate life.” I've observed four such fig leaves most often.

One-on-one meetings are a great way for managers to connect and manage their remote team members. Here’s a guide to run these meetings effectively.

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

The agile movement was about freeing developers from the baggage of Dilbertesque corporations. But in the 2020s, “doing agile” often comes at the cost of agility. Teams and companies sacrifice common-sense at the altar of a hustle culture, that looks agile, but is far from the spirit of the movement.

The “whiteboard effect” refers to a deep work phenomenon that occurs when two or more people problem solve together in spells of intense focus. The presence of this effect doesn’t mean, however, that we must always be in whiteboard mode.

The sooner a new team can norm, the sooner it delivers value to its stakeholders. This article provides a recipe for leaders of distributed teams to accelerate team norming.

There are different approaches to estimation and planning depending on the outcomes you’re looking for and the context you’re operating in. Making synchronous workshops efficient is part of this. Many activities can be asynchronous as well. You also need to consider if estimates are necessary in your context. I cover all these topics and more, in this post.

Onboarding is one of the first areas where you’ll see payoff for the effort you spend in writing things up. In this post, let’s explore a few mindset shifts and a few tips and tricks you can use to bring people aboard your team. As you read on, you’ll notice how your handbook and your developer documentation are among the key ingredients to brew the perfect onboarding storm.

As team size increases, communication becomes more complex. Small teams will eventually bring in new people. Such is life. Team size aside, you’ll find that complex decisions lend themselves better to the written word. Moreover, there are limits to what people can remember, so it makes sense to commit things to writing. If we’re designing continuously, we’re also communicating about it all the time. In today’s post, I want to share three asynchronous techniques to communicate about design.

Sometimes we give a free pass to any activity that seems collaborative. Before you know it, you’ve built half a dozen gate checks to deliver a single user story. Each of those “collaborative” gate-checks doesn’t just create interruptions and context switches. It also leaves an attention residue - your mind continues to think about the interruption even when you’ve switched to the task on hand. In this article we examine the ad-hoc “huddle” through a series of questions, so we can find out how much we really need them.

Like the pebble trail in the story of Hansel and Gretel, our projects need audit trails for us to keep track of changes, communicate on a daily basis, and to onboard and align people. We discuss the five most important trails in this article. In the context of distributed teams these represent communication and documentation in the flow of work.

To me, async agile is non-binary. The value of being more async is also in making the truly valuable synchronous activities more productive and fun. Pair programming is amongst the most frequent synchronous activities that agile teams, especially those that follow extreme programming (XP), practice. How do we weave this into a remote-native way of work?

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.

In today’s post, we’ll dive into the agile sprint - a time-box of approximately two weeks, when development teams work on a set of user stories they’ve prioritised to deliver. We’ll examine two synchronous collaboration practices - story kick-offs and dev-box tests or desk checks and how we can adapt them to a remote-native; async-first way of working.

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.