In every project, there is always a communication gap between developers and managers. Be it small or huge, there always is. And if you add community into the mix, the gap will inevitably grow.

There seemed to be some level of confusion and false expectations before we officially came out with the Summer release, mainly in the general Telegram chat. I’ll try to describe how we develop things in Winding Tree, what are our core principles and how you can follow our progress and hopefully understand what is currently going on.

We are really trying our best to keep everyone informed.

Open

Winding Tree development is done in the open. Almost everything we do is immediately released to the public via GitHub, some of our discussions are held in public mailing group and even our planning is done publicly. The code has permissive licenses. We are not afraid and everyone’s feedback is welcome.

But none of these are optimal communication channels to bridge the aforementioned gap. Some of the information might not even make any sense to general public. That’s why we started to do quarterly updates in a more human-readable form (even transcribed into blog posts). But it seems that we need to publish this kind of information more often. And we are working on it.

We truly try to be as open as possible, but sometimes we cannot. It might be because something is confidential (like agreements with our partners), but usually, it’s just because we simply don’t know yet. And that leads us to the next point:

Agile

This is probably the most used word in project management during the last few years. It even has its own manifesto. But how does it translate to an open source project developed by a team distributed all over the world? Not easily.

We have tried to do Scrum-like sprints, and we have tried to hold bi-weekly demos, we have tried to do short-term planning and estimation. But it never really worked. People are travelling, working on multiple projects or just working at a different pace. We are also doing a lot of research and other work that is hard to estimate and does not really fit into any methodology.

But our experience with agile software development has always been good. We know that a short feedback loop and the ability to swiftly change direction can save a lot of time and money. So we tried to translate at least some principles into our environment. We are:

Always working on well-defined, contained, isolated pieces of work. And reasonably small, when possible.

Immediately releasing everything that is finished to a live environment.

Improving everything in many iterations.

Automating everything we can.

Focused on present problems and not looking too far ahead in great detail.

So even if we are not announcing something fancy on our communication channels, we are still releasing new things to the public all the time. And we consider the things that are released, done.

Well, they are of course not done forever. Our intention is to collect feedback as early as possible and improve the resulting product as we go along. You might say, “But it does not make sense to publish data about hotels if I cannot book them.” And you are probably right.

But it’s very valuable for us to validate our approach as soon as possible and make even the smaller bits public. Even if we can only show a few hotels on a map, that’s success for us. And not only because we have set up a ton of things behind the scenes; access to on-chain and off-chain data, deployment procedures, documentation. It’s just pure joy to see something running not from your own computer.

We of course know that at some point we will have to solve Booking and Payment. But we just don’t know the details yet, so we cannot communicate them. We are already experimenting with multiple possibilities, but we will dig into a future-proof solution only once it’s the current problem we are solving.

Why Summer release then?

Because we don’t hold a traditional release cycle (either time-based or feature-based), but release everything immediately, we needed something tangible, a medium-term goal we could focus on. So we sat down one June afternoon, draw some ideas on a whiteboard, sorted them and then had a long discussion on what we can really achieve during the summer. Which resulted in this card in Trello.

What is actually great on this is, that we delivered exactly what we agreed on. We did not over-promise and we are on time. That’s an amazing and not that common of a feat. Good job, team!