Our mission at LinearB: 

Asynchronous Development for Hybrid Remote Dev Teams

One small step for your team. 

One giant leap for the software development community.  

What is Asynchronous Development?

Asynchronous Development (Async Dev) is an approach to building software that helps dev teams deliver maximum value to their business and customers by allowing them to work the way they want – asynchronously. Async Dev builds on important movements like Agile and DevOps and offers a new ideas to help hybrid remote dev teams, working together in different locations at different times, perform their best.  

Group 1138

Why do we need Async Dev?

Consider this brief history of industry-changing software development trends

AGILE

Replaced long waterfall cycles with early validation and rapid improvement. 

Many organizations focused more on rules and less on cultural changes. 

DEVOPS

Aligned dev and IT teams and emphasized not just on how we build but how we deliver. 

Some teams have not implemented CI/CD due to lack of skills or business interest.

WORK-FROM-HOME

Work-from-home shook the world in 2020, seemingly giving dev teams new flexibility. 

After a few months, meetings & distractions have crept back into the WFH reality.  

2001

2014

2020

"We choose to go to the moon..."

At LinearB, all of our energy and the future of our company is invested in helping the software development community make Async Dev a reality. Why? Because hybrid remote is not going away. Because the 2020s are destined to be the decade of developer empowerment. “Not because it will be easy, but because it will be hard… because that challenge is one we are willing to accept, one we are unwilling to postpone, and one we intend to win.” 

The 5 core tenets of Async Dev

1

Dev teams are the heart of the business

The best companies in the world evolved from developers highly aligned with market needs that could unleash the raw business potential of building great software. 

From the Agile Manifesto: “Business people and developers must work together …” 

This statement was right for the time and started a bridge between developers and business stakeholders. But we believe sometimes the most important business decisions are hiding inside lines of code. Therefore ‘development’ and ‘business’ cannot be disjointed sets. Companies that want to innovate and create truly great customer experiences empower developers to make decisions on behalf of the business. They give context, not instructions, to dev teams. In return, dev teams should provide radical transparency to their business stakeholders and educate them on how to understand and measure dev teams and projects. 

2

Async is the default method of communication

To empower dev teams, we must embrace the way they work best. Devs need sustained periods of deep focus to create. Meetings, live status updates and other synchronous forms of communication disrupt the building process and hurt the company. 

From the Agile Manifesto: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” 

We acknowledge the advantages face-to-face conversations have, both online and and in-person. Especially for activities like brainstorming and planning. But, for hybrid remote dev teams, face-to-face is no longer the most effective method of communication. 

Companies that want the most from their devs should embrace async comms. Communicating through async conversations reduces interruptions and context switching and dramatically increases dev productivity and innovation. In return, dev teams should provide constant, real-time status updates to their business stakeholders so they can plan and provide feedback on the process. 

3

Git is the central element of your development process​

Whether you use GitHub, GitLab, Bitbucket, Azure DevOps or other Git provider, most of the stages of the development cycle either start or involve your Git system. How you choose to configure, deploy and utilize it has a great impact on your development process. 

Because Git was built with open source in mind, most of the phases (coding, review, merge) do not require mandatory synchronous communication and can be executed in different places and different times. 

Git is code-first and designed for devs so most dev teams avoid exposing their Git system to non-technical business stakeholders. This is a mistake. The most up-to-date status and the most detail about dev team progress resides in your Git system. While it does not make sense for the business to login to Git directly, understanding the terminology and general flow of Git will eliminate the need for constant translation between engineering and execs and allow business stakeholders to be better partners to the dev team. 

4

Project Management tools are for planning, not updates

Project tools like Jira and Clubhouse are great for planning and prioritization. But when planning ends and building begins, project tools don’t have enough understanding of Git systems and code to help dev teams with their day-to-day work, ceremonies and decision making. 

During an iteration, dev teams constantly balance and rebalance customer needs, scope changes, time constraints and technical blockers and  important decisions are being made every hour. Project tools slow down the process. Firstly, they don’t provide enough visibility to the real-time details within Git to be useful for decision making. Which leads to the second problem which is they encourage meetings and follow-up conversations. “In progress” is rarely enough information so dev leads and PMs are forced to interrupt devs for more information. 

Developers have Git. PMs have project management tools. Dev leaders, who blend technical and business together to help the team deliver, need their own tools and dashboards that are designed for constant changes happening in the development process. 

5

Continuous improvement is a daily practice​

The best dev teams approach their internal processes just like their products – start lean, get feedback, iterate often. 

From the Agile manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Most teams have equated the “reflection” process with a retro meeting which means learning and improvement is limited to once every few weeks. Identifying opportunities to get better and implementing process improvement does not require meetings. But it does require data. Which leads to another problem. Data about internal efficiency and quality is typically hard to get and controlled by gatekeepers. 

To make continuous improvement a daily practice, teams should make team-based metrics about efficiency and quality available to everyone on-demand and embrace async discussions about how to get better. 

Is Async Dev right for your team?

Join us and cut status meetings and developer interruptions by 60% 

Our mission at LinearB: 

Asynchronous Development for Hybrid Remote Dev Teams

One small step for your team. 

One giant leap for the software development community.  

What is Asynchronous Development?

Asynchronous Development (Async Dev) is an approach to building software that helps dev teams deliver maximum value to their business and customers by allowing them to work the way they want – asynchronously. Async Dev builds on important movements like Agile and DevOps and offers a new ideas to help hybrid remote dev teams, working together in different locations at different times, perform their best.  

Group 1138

Why do we need Async Dev?

Consider this brief history of industry-changing software development trends

AGILE

Replaced long waterfall cycles with early validation and rapid improvement. 

Many organizations focused more on rules and less on cultural changes. 

DEVOPS

Aligned dev and IT teams and emphasized not just on how we build but how we deliver. 

Some teams have not implemented CI/CD due to lack of skills or business interest.

WORK-FROM-HOME

Work-from-home shook the world in 2020, seemingly giving dev teams new flexibility. 

After a few months, meetings & distractions have crept back into the WFH reality.  

2001

2014

2020

"We choose to go to the moon..."

At LinearB, all of our energy and the future of our company is invested in helping the software development community make Async Dev a reality. Why? Because hybrid remote is not going away. Because the 2020s are destined to be the decade of developer empowerment. “Not because it will be easy, but because it will be hard… because that challenge is one we are willing to accept, one we are unwilling to postpone, and one we intend to win.” 

The 5 core tenets of Async Dev

1

Dev teams are the heart of the business

The best companies in the world evolved from developers highly aligned with market needs that could unleash the raw business potential of building great software. 

From the Agile Manifesto: “Business people and developers must work together …” 

This statement was right for the time and started a bridge between developers and business stakeholders. But we believe sometimes the most important business decisions are hiding inside lines of code. Therefore ‘development’ and ‘business’ cannot be disjointed sets. Companies that want to innovate and create truly great customer experiences empower developers to make decisions on behalf of the business. They give context, not instructions, to dev teams. In return, dev teams should provide radical transparency to their business stakeholders and educate them on how to understand and measure dev teams and projects. 

2

Async is the default method of communication

To empower dev teams, we must embrace the way they work best. Devs need sustained periods of deep focus to create. Meetings, live status updates and other synchronous forms of communication disrupt the building process and hurt the company. 

From the Agile Manifesto: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” 

We acknowledge the advantages face-to-face conversations have, both online and and in-person. Especially for activities like brainstorming and planning. But, for hybrid remote dev teams, face-to-face is no longer the most effective method of communication. 

Companies that want the most from their devs should embrace async comms. Communicating through async conversations reduces interruptions and context switching and dramatically increases dev productivity and innovation. In return, dev teams should provide constant, real-time status updates to their business stakeholders so they can plan and provide feedback on the process. 

3

Git is the central element of your development process​

Whether you use GitHub, GitLab, Bitbucket, Azure DevOps or other Git provider, most of the stages of the development cycle either start or involve your Git system. How you choose to configure, deploy and utilize it has a great impact on your development process. 

Because Git was built with open source in mind, most of the phases (coding, review, merge) do not require mandatory synchronous communication and can be executed in different places and different times. 

Git is code-first and designed for devs so most dev teams avoid exposing their Git system to non-technical business stakeholders. This is a mistake. The most up-to-date status and the most detail about dev team progress resides in your Git system. While it does not make sense for the business to login to Git directly, understanding the terminology and general flow of Git will eliminate the need for constant translation between engineering and execs and allow business stakeholders to be better partners to the dev team. 

4

Project Management tools are for planning, not updates updates

Project tools like Jira and Clubhouse are great for planning and prioritization. But when planning ends and building begins, project tools don’t have enough understanding of Git systems and code to help dev teams with their day-to-day work, ceremonies and decision making. 

During an iteration, dev teams constantly balance and rebalance customer needs, scope changes, time constraints and technical blockers and  important decisions are being made every hour. Project tools slow down the process. Firstly, they don’t provide enough visibility to the real-time details within Git to be useful for decision making. Which leads to the second problem which is they encourage meetings and follow-up conversations. “In progress” is rarely enough information so dev leads and PMs are forced to interrupt devs for more information. 

Developers have Git. PMs have project management tools. Dev leaders, who blend technical and business together to help the team deliver, need their own tools and dashboards that are designed for constant changes happening in the development process. 

5

Continuous improvement is a daily practice​

The best dev teams approach their internal processes just like their products – start lean, get feedback, iterate often. 

From the Agile manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Most teams have equated the “reflection” process with a retro meeting which means learning and improvement is limited to once every few weeks. Identifying opportunities to get better and implementing process improvement does not require meetings. But it does require data. Which leads to another problem. Data about internal efficiency and quality is typically hard to get and controlled by gatekeepers. 

To make continuous improvement a daily practice, teams should make team-based metrics about efficiency and quality available to everyone on-demand and embrace async discussions about how to get better. 

Is Async Dev right for your team?

Join us and cut status meetings and developer interruptions by 60% 

Enter your email and we’ll send you a link to start your free account.