The Agile Lab handbook is the central repository for how we run the company.

Please make a merge request to suggest improvements or add clarifications. Please use issues to ask questions. For further details, please see the Handbook Usage page.

The public gitbook site of the handbook is available here

History of the handbook

This handbook started when Agile Lab was a company of 40 people in 2019 to make communication and information flowing efficient and easy. We were growing very fast and new people joining Agile Lab were not able to find information about processes and guidelines and also everyone had its own vision of these hidden processes. In addition in just one year became fully distributed in 5 branches and a remote first company.

The handbook was our way of ensuring that all of our company information was accessible to everyone regardless of when they became part of the team.

This handbook has been strongly inspired by other handbooks currently running in other companys like Gitlab, BaseCamp, TeamDigitale. Credits to them for such incredible amount of information they released open and we are looking forward to build a great handbook and company culture that one day will become an inspiration for someone else.

Why

The handbook has these benefits:

• Reading is much faster than listening
• Reading is async, you don't have to interrupt someone to collect such information
• Recruiting is easier if people can see what we stand for and how we operate
• On-boarding is easier if people can find all relevant information
• Discussing changes is easier if everyone is aligned to what the current process is
• Communicating change is easier if you can just point to the diff
• Everyone can contribute to it by proposing a merge request

Documenting in the handbook before taking an action may require more time initially because you have to think about where to make the change, integrate it with the existing content, and then possibly add to or refactor the handbook to have a proper foundation. But, it saves time in the long run, and this communication is essential to our ability to continue scaling and adapting our organization. This process is not unlike writing tests for your software. Only communicate a (proposed) change via a change to the handbook; don't use a presentation, email, chat message, or another medium to communicate the components of the change. These other forms of communication might be more convenient for the presenter, but they make it harder for the audience to understand the context and the implications for other potentially affected processes. Having a "handbook first" mentality ensures there is no duplication; the handbook is always up to date, and others are better able to contribute.