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:
- 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);
- 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.
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 the 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 limited 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 from your failures
Also, putting a 2 week deadline on our goals (time binding) makes themSMARTer.
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 have 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 sometimes use checklists to keep track of progress. Many times in fact
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 whats 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. Weekly standup meetings
11. 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 scalale approach because as our team grows we going to have to break up our exchange into smaller projects — each with their own project manager
12. One man, one card
13. One centimetre wide, but one metre deep
14. 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:
15. Some cool features we’re not using now but would love to tryout one day
- 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.
- Cathedral — http://news.bbc.co.uk/2/hi/africa/7396539.stm
- Mike Tyson Quote — http://www.slideshare.net/InnosightConsulting/scott-anthony-the-future-of-innovation
- Cathedral — http://news.bbc.co.uk/2/hi/africa/7396539.stm
- Flea market — http://www.zimsentinel.com/?p=1262
- Premature optimisation –https://www.reddit.com/r/ProgrammerHumor/comments/2ndm0b/and_what_do_we_say_to_premature_optimization/