Introduction
There is a virtuous circle that many think is key for any organization to achieve success:
I want to focus on autonomy and its relation with alignment.
I
do not know any single smart person that do not like autonomy.
Definitely I want it and most of the managers and developers I have
worked with too. There is no doubt that we achieve the best results for
ourselves and the organization we are involved with with great doses of
autonomy.
Autonomy
though, as usual, requires high levels of coordination in order to be
sustainable over time. It requires mechanisms of check and balance
against a plan. Take a look at Scrum, for instance. It proposes to do
checks and balances against the backlog every 2 to 6 weeks aprox., at
the beginning/end of every sprint And it forces also to stablish a daily
check and balance against the micro plan every day. That is a lot but
it is the price to pay for getting autonomy.
And this is because the success of a group completely depends on the alignment of its members. Our tendency of "taking our own way" (entropy) is so high that organizations need people and many processes just to make sure everybody fight hard against it.
Definition and a little bit of history
I think it was 2004 when I started my relation with Fotón S.I. crew. Fotón is an open source company from Gran Canaria, founded in 1998, lead by Mike Vazquez and, back then, also by Gonzalo Aller.
Working with Fotón SI had a huge impact on the way I perceive management. It worked as a catalyst. I learned with them in a few months what takes ages for others.
Fotón was formed by a group of very talented and young hackers. The decision processes were very participative and transparent. Let me put you one single example: the basic accounting of the company was open to every employee, including salaries.
In their peak times they were around 20 people but it was strange to see more than 5/6 in the office. Most fotonians worked from home most of the time. They were based in Gran Canaria and my little company was in Tenerife. It was a distributed environment.
Going back to Foton, a key variable that balanced autonomy and alignment in that distributed environment was THE DIARY, a simple concept but very effective.
Most people right now are probably thinking about that little notebook that needed a key to be opened where some boys or girls write their thoughts at early ages. Obviously that idea has little to do with what I am talking about. The term bitácora, a short way in Spanish to refer to the ship's log, is closer to what I am talking about.
A bitácora is a log chronologically organized, written by the ship's captain, kept in a wel define place where the most relevant events related with the ship, the crew and the journey where described. It had two main goals:
- Analysis.
- Report.
By writing on regular basis what happened in the ship, captains were creating a tool that allowed them to learn from past experiences. It was a very precious treasure, so preious that needed to be destroyed in case the ship got into the wrong hands. It was way more than the Black box of a plane. It captures the most important knowledge. If the captain got sick, for instance, or died in combat, his replacement used the bitácora to analyse the past history. Many of you are familiar with this concept since it is popular among scientists, archaeologists, etc.
The bitácora worked also as a reporting tool. After a few months sailing, it was impossible for any captain or officer to remember details about the trip if they were not written in real time. Providing a report about the trip was impossible without the bitácora. One interesting point was that, once written, no entry could be modified. If the captain made a mistake, he needed to create a new entry correcting the mistake, like in a check-book.
Fotón was a pret-a-porter development company organized per project. Each project had its own diary/bitácora. Following its culture, everybody had +xrw permissions in every bitácora. Agreed labels were used for different purposes: identify each user, assign relevance a specific entry through colours, etc. This idea was implemented in a hacked Twiki, integrated with Request Tracker and a mail service for notifications. A very smart, geeky, simple and efficient implementation for the time. Like all the wikies back then, UX was not the main feature but for console lovers.....that was no issue.
So Fotón extended the concept of the bitácora to a new level, going from an individual oriented tool to a group one, that is, they took a collaborative approach with a great result.
I still remember the day they explained and showed it to me. I was amazed, excited and cautious about its scalability. I was already used to write regularly what I was doing so the main hurdle did not applied to me: I had the habit. The collaborative approach was new to me though, together with the implementation.
How come something so simple has such a high impact? What makes reading what others do, think or feel so valuable? What is the relation of writing what you do and being efficient as a team? What a diary has to do with alignment? And here is the question that most people that face this tool/process for the first time ask: isn't it the diary a tool to control me?
Let me start with the last one. The bitácora is a tool to control yourself. If you think you do not need to regularly check and balance your actions against your plans, your colleagues expectations and your company goals is simply because you are not senior enough, period. The diary is just a way to achieve that, like the stand up meetings or the burn down chart.
You decide what kind of information you should include in the bitácora. Here is the main rule. Knowing that is open to those you work with, add what you think is :
- Relevant to you.
- Relevant to your peers.
- Relevant to those you interact with like, managers, other teams, customers, etc.
Do not add information that only one person should know about or that you would not say in a team meeting. Simply use your common sense. For instance, if I am frustrated about something.... I add it in the diary if I want to share it.
Fotón used to open the diary about a specific project to customers and third parties involved on it and it worked beautifully. Of course once in a while somebody wrote something inappropriate, but the benefits of these diaries were so high that assuming the damage was out of question. It became an outstanding engagement tool, as good as the best sprint planning meeting.
Very soon I experienced myself the benefits of getting the habit of writing regularly in those project diaries I was involved with, reading what others wrote and interacting with them through the diary. I got a sense of control of my day to day work and, even better, of what everybody else was doing. Control in a good way. Sync meetings were reduced, asking for weekly reports made no sense,... we were a more efficient, coordinated... better aligned organization, even in our distributed environment, despite working in several projects at the same time, with different customers, third party companies or different working schedule.
Conclusion
In many ways Fotón diaries laid upon two ideas that today are very popular: semantic and social (in a twitter way). I believe that the diary is a key complement to agile methodologies, specially in distributed environments.
In my next article I will describe in detail the concept and what the perfect implementation should look like, based on my experience since I have used it widely since then.
