As a leader, you’re responsible for much more than the mechanics of work. Depending on the size of your company you’re a custodian of culture, or the one who defines it, or someone in between. In today’s post, I want to share with you how you can foster a culture that supports async agile.

With the right systems and the right people in community management and curation roles, you can brew the perfect storm of “organised serendipity”. I daresay, that this can often work better than the proverbial water cooler meeting.

In this post, we’ll discuss how you can enhance your knowledge ecosystem by building on your existing collaboration stack. I’ll also go over how to create the right team of people to govern, curate and nurture that platform.

The approach of creating stocks of well structured, organisational knowledge has its limitations. In this post, I argue that you should invest in solutions that create flows and streams of knowledge while stocks move to a supporting act.

Remote work would have renewed your organisation’s interest in knowledge management. Considering one can’t walk up to co-workers for a quick clarification, could we instead ask the system for an answer? In an asynchronous, remote-first culture, a solid knowledge strategy can be a productivity power up.

In this article and a few subsequent ones, I want to share my thoughts about creating a knowledge ecosystem that keeps pace with your people’s know-how.

As a manager or a leader in any tech firm today, I imagine you have a DEI agenda. Your people’s ability to work asynchronously can be a powerful tool to not just further that agenda, but also to differentiate you as a progressive leader.

In today’s post, I want to share a few notes about diversity and a few more about inclusion. I expect these perspectives will help you shape your organisation’s culture and eventual competitive advantage, starting of course with the people you influence.

Remote and async first work is all set to be the standard way of working in the next decade. There’s still a window of opportunity for firms to be the early majority. Those that miss this window will lag the innovation curve in designing the workplace of the future. A misunderstanding of “hybrid” work can set organisations back in this journey. This is also counterproductive to async agile.

In today’s post I want to unpack the term “hybrid work” for you and I want to explain why misunderstanding this term is dangerous.

When I speak to managers and leaders about asynchronous work, I receive a variety of responses. If they’re remote work naysayers, then there’s an obvious scepticism. Then there are the remote work believers who listen carefully. There are some who can immediately think of ways this “asynchronous work thing” would work for them and their teams. Many leaders, however, see the value for their people, or maybe “other people”, but claim it won’t work for them.

If you’re one of those leaders or managers, allow me to unpack asynchronous work for you. Who knows, you may find an idea or two to enrich your own work life.

No biggie here. We’ve spent some time diving into the details of asynchronous work in the context of agile practices. Now it’s time to explore the kind of management and leadership that supports and asynchronous-first culture. I expect the next few posts may not be in perfect sequence, so think of this post as an explanation for the unpredictability.

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.

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.

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.

Earlier in this series, I mentioned your team will need a handbook. We’ve also discussed the audit trails you should create while in the flow of your work. If you look hard, you’ll notice that the goal still isn’t to create “comprehensive documentation”. The idea is to create enough “sensible documentation” that helps make communication effective. In this post, I want to zoom into a very specific section. This relates to developer documentation.

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.

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?

Chat is an essential part of your toolset. The trouble is in the “instant” of “instant messaging”. To be “instant”, you need to monitor chat all day. Not only does that build interruptions into your way of working, it can be mentally exhausting to keep up with all the channels your team and company have created. So in today’s post I want to share a few ways you and your team can use this set of communication tools effectively and support a more productive, async-first way of working.

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.

Aside from introducing async practices and plays on your team, you need to vote with your behaviour for an asynchronous work culture. Otherwise it’ll all feel like lip service. So in today’s post I have five ideas for you to implement as an individual, so you can broadcast how committed you are to an asynchronous way of working. Each of these is easy as they get. You can get started today itself!