It’s all in the planning: Here’s how an African Bitcoin startup is using Trello

Legend has it that in 1962, the then US President, Jack Kennedy visited NASA and he met a cleaner who was carrying a broom. The President walked to the cleaner, introduced himself and then asked the cleaner what he was doing. “Well Mr. President,” the cleaner responded, “My job is to help put a man on the moon”.

I’m leading a team of 6 Developers, who are collaborating across different 5 time zones (you should try that some time) and my two biggest challenges are:

1. Firstly, to make sure that everyone always remembers that all the work they are doing is to help put a man on the moon (like the cleaner, everybody should know the importance of their contribution);
2. Secondly, to make sure that, of the 100 tasks every developer has on their job list, they have chosen the best one.  Our moon is a world where it’s super easy for anyone (and this includes your grandmother) to buy and/or sell Bitcoin.

Of course every startup is different, so in this article, I will like to share with this community what has worked for us. I would really love to hear in the comments below what has worked (or not) for your organisation/project.

We use Trello in the following 13 Ways:

1. We’re probably going to fail. So we want to fail in 2 weeks (or less)

This is an idea we borrowed from the SCRUM Methodology and using the SCRUM terminology, the other way we can put this is to say that: “our sprint is two weeks long”. In SCRUM, a sprint is the length of time it should take to build out a feature that is complete and ready to ship – a meaningful deliverable.

We’re working in an early stage startup, and building something for our customers and our starting belief is that our assumptions of what your customer wants or what’s going to work are almost always going to be wrong.

I think that the “build it and they will come” approach product development is in many cases the wrong way to do it (unless you’re Apple). I find a better approach to be to look at everything you do as an experiment and every experiment building upon the results and the lessons learnt in the last.

And although you think your experiment is going to work, you still have to test it with real customers (because no battle plan ever survives first contact with the enemy). Now, if it takes you a year to test your first experiment, and you fail (because most of your experiments are going to fail anyway), then it’s going to be very hard to recover from that failure.

It makes it an expensive experiment and if it fails, it’s therefore a very expensive way to fail. If we had deep pockets and unlimited resources we could maybe take longer to fail but being a small startup with limited resources, we can only build a flea market rather than attempt to build a cathedral.

For us, if a task takes more than two weeks then it’s still too complicated. If it’s too complicated then it can be simplified by further breaking it down.

One of the reasons why my last startup failed is because we spent a lot of time building everything we thought our customer wanted in our system without getting out of the building and testing our assumptions with real customers. When our one big experiment failed (because no battle plan survives the first contact with the enemy) we couldn’t afford to run another experiment.

At BitFinance, we can still afford to have every developer do an experiment that runs for two weeks. And if that fails, we try to figure out why and how we can do better. If it succeeds (& my next blog post is on how we measure success so watch this space) we move on to the next experiment.

As a rule of thumb:

Fail fast, fail cheap and fail while leaning towards success by learning from your failures

Also, putting a 2-week deadline on our goals (time binding) makes them SMARTer.

2. Every card is a task/goal

The same way you don’t have a meeting that’s now in your calendar, we don’t do a task unless it’s in Trello

 

3.  Trello cards are created from Github issues

Everything starts as a Github issue and we do it for reference purposes. When you’re  a developer and you pick a task on Trello you can be able to follow from Github the discussions that were had before decisions were made, see what commits were pushed to the code repository are associated with that issue and get all the information you need to be able to figure stuff out on your own.

 

4. We’ve now also started putting issue numbers it tiles for ‘easy reference’ purposes

5. We often use checklists to keep track of progress.

Because sometimes a sprint can be further broken down into much smaller tasks. And because team members who are waiting in expectation want to know where you are in the process and/or how best they can help.

6. We use stories in Card Descriptions (whenever we can)

A story is a description of how the product/feature will work, but it’s written from the user’s perspective. We use stories not just to get in the head/shoes of the person we’re building the feature for but also to remind ourselves why we do what we do (hint: it’s for the customer).

This is another thing we adopted from the SCRUM methodology.

7. We use labels to put cards into categories

Because, let’s face it: some categories are generally more important than others, for example, we generally fix bugs before we deal optimisation issues.

Categorising Cards makes it easy to sort/view them by that category.

8. We use Lists to keep track of what’s being worked on and what’s complete

Most simple projects will just have 3 lists: Not started, Started, Complete, but bigger and more complex projects projects will have more lists.

9. Notifications in Slack

The Trello feature I’m excited about the most is Slack integration so I get updates in real time on my phone or my computer.

10. One, and only one project manager

We’re still a small team and right now our exchange is one project. But this is a more scalable approach because as our team grows we going to have to break up our exchange into smaller projects – each with their own project manager

11. One man, one card

Because we only need one person responsible for a particular task. Not two. Adam Lashinsky explains this idea better than I can.

12. Use comments to update other team members

When we have something to share about the progress we have made with a particular task, we write a comment on the card. Like so:

Some cool features that we’re not using now but would love to tryout one day include:

Calendar – maybe we’ll start using this one day for our social media editorial calendar or for scheduling standup meetings. We’ll see.

Emailing cards to the Trello Board – Right now I can’t think of a situation where I would need to use this but I still think it’s a pretty cool feature.

BTW, we’re hiring so if you’re a Rails developer and working with Bitcoin and these technologies are something that excites you, then I’d encourage you to consider joining our team. We have both part-time and full-time positions so you don’t necessarily have to leave your job to start working with us.

I have been writing code long before Trello came along and back in those days, collaborating on a project was a more painful experience that required more work and more meetings than it does today. Humanity has come a long way. Tools like Trello have made the world a better place.