Category: How we work

There has been much discussion at bitcraze on where to put informations, forum or website. The website is more pretty and more accessible but it can only be updated by us. The wiki can be updated by anyone but it is less accessible and tend to contains much more details. We now solved this debate!

I’m happy to announce that in the spirit of open source and collaborative work, we have published the source code and content for our website on github. It is now possible for anyone to contribute to the website through pull requests on github, so if you want to add, updated or remove something, please go ahead! The code contains all static content, while the blog is still handled by a WordPress instance that lives elsewhere.

github_bitcraze_website

We have tried to make it as easy as possible to work with the code, start a server and see your changes in a browser – check out the “quick start” in the readme.md for details. Most of the content is still in html, but we are aiming at converting as much as possible to markdown over time. We hope that it will make it more accessible and super easy for everyone to work with the site.

Happy updating! And please tell us what you think about this new website.

 

We have a dashboard (aka radiator) based on dashing in the office.

office2

The purpose of the dashboard is to drive the team focus and encourage us to work on the most important tasks at hand. For instance, we realized that we have been really bad at merging pull requests from the community (sorry about that!), and we wanted to improve. Our solution has been to add a widget to the dashboard that shows all pending pull requests, and now we have been handling pull requests much faster. Success! The visibility of data changed the behavior of the team.

Another problem that has emerged in the new office, is that the 3D printer is now in the basement. We used to have it in the office so monitoring the progress was easy, but now it is two flights of stairs away. We use a Raspberry Pi with the awesome OctoPrint as print server (through the OctoPi image) and since it supports integrated video, we installed a webcam over the printer and viola! Now we can see the progress in OctoPrint.

octoprint

Why not add it to the dashboard? Due to how our network is organised, the dashboard pulls in the data from the printer on client side as opposed to server side, but problem solved. The code is on github.

dashboard

46 minutes left on the 3D-print. No pull requests to handle!

We are experimenting with pomodoro inspired techniques (http://pomodorotechnique.com/) in the team. What we do is that we are doing team pomodoros where we work focused for 25 minutes, without communicating. During the work periods we record all questions and so on that we need to ask, and after the period we communicate and resolve all issues that came up. We don’t do pomodoros all the time, but only when we feel that it is useful. Some days we might do a lot of them and other days none.

What we find interesting is that it has turned out that the important feature is not about NOT communicating during the work periods, but that the communication becomes more focused when we do communicate.

We have added a countdown timer widget to our dashboard to make it really easy to start by anyone.

pomodoro2 pomodoro
The timer is also handy for all sort of time-boxed activities in the team.

The code for the widget is available at https://gist.github.com/krichardsson/a2c8ad556caa643f822c

There are a lot of things we need to keep track of in Bitcraze, such as customer support, production, book keeping, planing for the future, improving how we work, our servers, forum, the community, source code, new hardware, just to mention a few areas. There has been an informal distribution of these areas between the persons in the company, but it has not been very clear who is responsible. This has led to that we all worry about everything but we still miss to catch some issues. So we have two bad properties: not as good performance as we would like to have and negative feelings. So what to do?

We have decided to set up role contracts. Our version of role contracts is simply to appoint one person to each area that we feel needs continuous attention. The person that is responsible for an area is expected to keep track of what happens to that area, think about how we should improve or change, and notify us (the rest of the team) when we need to take some sort of action. That person is not expected to execute or implement, but make sure that we get it done as a team.

We will update the role contracts at regular intervalls, every month as a start, to make sure we are working with stuff we passionate about and so that we have a dynamic team.

For a background on the “How we work” category, see Self organizing

Next on the agenda was to talk about feedback. Feedback is the oil that keeps the team happy and enable individuals to gain insights about them selfs. Important stuff!

We talked about the self and some techniques/models that can be used to understand our selfs and others (e. g. Johari Window). We discussed how we react when we receive feedback, and what we can do to increase the possibilities that we really listen to and understand the feedback that is given to us. These insights also help us to give feedback to other persons.

The last part of this was a “recipe” of how to compose feedback for someone. Try to include the following

  • Observation of a behaviour
  • How that makes you feel
  • Your needs that created the feeling
  • Your wished of alternative behaviour

Some slides are available at Prezi

Finally we practiced by giving everyone else feedback one-on-one. We will continue to give each other feedback over the coming weeks on a regular basis – practice makes perfect.

We have decided to use Travis for continuous integration builds of our open source repositories. Travis is automatically building the code on all branches and pull requests, which gives all developers that wants to contribute to the project, the possibility to see that their code passes the build. The current status of the latest build on the main branch, is visible through the icon in the readme in github, or on the Bitcraze page at travis.

travis-ci

The projects we have added so far to travis are written in C or python. The C projects for instance, must be compiled with special compilers for the processors used in the crazyflie which adds some extra complexity. We have created a docker image (bitcraze/builder) with the tools needed, to make life easier for developers. If you use the image when developing, there is no need to install tools locally, and the same image is used in travis builds, so you know you will get the same results as the CI-server. This also removes the problem of tools with different versions (and results) in the development- and build environment.

To use the image you can for instance type

docker run --rm -v ${PWD}:/module bitcraze/builder make

Event though it is awesome to be able to create a well known build environment through a docker container, we feel that too much typing is needed to execute a simple make.  To solve that problem we are looking at the possibility of creating a toolbelt that will handle that for you. More information on that later on, for now developers will have to find their own solutions through scripting, aliasing or other means.

Obviously you need Docker to use this image. If you have not tried it out yet, take a look at www.docker.com.

We are aiming for automated testing of our code, and even though we have a lot of work to do, we have taken the first baby step. For the moment, firmware projects are simply compiled and linked to ensure that the code is coherent. Projects that support both crazyflie 1 and 2 are built in both flavours to avoid problems for developers that might only use one of the platforms.  The python client project is only checked for PEP8 compliance, but we are looking at how to unit test. Any input from the community is welcome!

Happy hacking!

For a background on the “How we work” category, see Self organizing

We have done a session in the company on group development. We based our discussions on the IMGD model by Susan Wheelan (https://en.wikipedia.org/wiki/Group_development#Wheelan.E2.80.99s_Integrated_Model_of_Group_Development).

We wanted to understand more about the structures and forces in the team, what to expect and gain a better understanding of our everyday experiences.

According to the IMGD model a team evolves through a number of phases as it achieve maturity when it works together. The phases are

  1. Dependency and Inclusion
  2. Counterdependency and Fight
  3. Trust / Structure
  4. Work / Productivity
  5. Final (if there is a distinct final point)

We had some good discussions that we think will help us in the future.

This is the first post in the new category “How we work”. The intention is to write about how we work and evolve our company, as opposed to most of our other posts that are about the cool stuff we build.

First we need to take a look at the the history. Bitcraze was started by Arnaud, Marcus and Tobias in 2011 when they created the first Crazyflie. They all had day time jobs at the time and were working on the project on their spare time. Forming the company and taking the step to work full time with Bitcraze was the logical continuation of the success of the first Crazyflie.

They are all passionate about technology, innovation and creating cool things, but the possibility of working with interesting stuff was not the only reason to leave the safety of employment, an important driver to form the company was that none of them really felt comfortable in the companies were they were employed. They all have worked in multiple companies where they had more or less the same bad experiences and they wanted something else, something better. To understand the problem, take a look at Dilbert about shipping and managers :-)

During the years there have been interns in the company from time to time. One of founders donned the role of the “boss” to manage the intern and tell him what to do and to make sure the expected result was achieved. The problem was that they did not felt very comfortable with this, after all they were becoming the type of boss they disliked in their previous jobs, they were moving in the direction they had been running away from.

What to do? The three of them had equal relationships, no one was managing anyone else, so maybe one solution was to not employ any more people and continue the way it was? No, more people can do more fun stuff and they wanted to expand. During this spring Kristoffer started to hangout on Minc (the incubator where we are located) and we stared to talked about this problem. We talked about values, drivers, what we want to get out of work and life. Kristoffer has a similar background with similar experiences from the companies he has worked at and they all realised they were looking for the same thing.

I (Kristoffer) became the first employee in Bitcraze, in June, and we have taken an important step in building the company we want want to work in. We don’t really know where we will end up, but know that it is a continuous journey and that we will change over time.

There is a book full of inspiration and clever insights that everyone, interested in this type of problems, should read,  it is called “Reinventing organizations” and is written by Frederic Laloux, read it!

We have taken one super-important decision that will be the basis for all future work:

No one in the company can decide what someone else should do

Yes, that’s right, no one is the boss and no one is a manger – we are self organising. We’re in this together and will evolve together.