Today we are talking to Campalyst – the social media analytics company behind the Google Analytics Twitter plugin. Campalyst team is based in Tartu, Estonia, and New York, US, and their CTO Juhan Aasaru shares a few insights into their development process.
Tell us about yourself. What does your company do?
I am a CTO and co-founder of Campalyst. Campalyst is a 1.5-year-old startup that helps brands to sell more via social media. Companies are spending huge amounts of money for campaigns in social media with little or no clue of how much it helps them earn more. We have build the software that measures the income from social media campaigns and provides the metrics to understand what works and what does not in terms of increasing ROI.
Before founding the startup I was working as a developer and private consultant in Estonia and Ireland.
Sounds good. Can you tell us about your development team? How are you organized?
Besides me – I count myself as developer – there are other 3 full-time developers and one part-time tester. Three of us are working in our development office in Tartu, Estonia. One developer and the tester work from home and occasionally pop into the office. We are a US company and the business office is in New York.
What is your development process? How often do you deploy to production?
Our development process is definitely agile. We are trying to iterate in small cycles of one week. The cycle starts on Thursday when new functionality is released and the new assignments are started. On Tuesday morning we have a meeting to review everyone’s progress. If someone sees that they will not finish their task by Wednesday evening, then we decrease the functionality, and still try to release it on time. For example, when we implemented a weekly newsletter with the key campaign metrics to our customers, the initial version had basically just one metric. Over time we then iterated and added more metrics.
What are the biggest challenges in the development process when it comes to project management?
The biggest challenge for us is communication, since our head office is in New York, US. So we have a seven-hour gap between the development and the business. We tried different things and software to solve this issue. We are currently using Skype calls and chats, email, as well as hangouts for regular updates between business and development. We have also recently started using Yammer.
The other challenge is spotting the small features that in the end turn out to be a massive waste of time. We need to spot these features early, and if we find out that these features take too long to implement, we can come back and review if they are worth implementing at all.
You said you are definitely agile, do you use any of the agile methodologies, like Scrum or stand-up meetings?
We are not using any strict agile methodologies, like Scrum. We are small and flexible and at this stage we are using bits and pieces from these theories, which we adjusted for our team and our situation to get a better fit. For example, we do have daily stand-up meetings, but they last longer than advised by Scrum. Since only developers participate in these meetings, it makes sense to have a longer duration without killing anyone else’s time.
After the stand-up meetings we have Google Docs document, which is updated after the meeting and then sent out to everyone in the company. And I have separate meetings with the business side, since they are sleeping in the US while we have the stand-up meetings.
OK. And can you comment what has improved after you adopted these methodologies?
At first we had specific software for developers for adding tasks, but it turned out that it was too difficult for planning and for the business to get a quick overview. Afterwards we tried Trello, which has a good visual component, but it had other problems of reflecting what we are doing, so having the Google Docs worked out best for us.
Finally, what advice would you give to other startups and CTOs?
The lean methodology is about eliminating waste, and this is what we found to be extremely useful. When you are in the analysis stage of designing a feature, you cannot always see all the things that are very time consuming and maybe only nice-to-have. So we allocate less time per developer than it takes to implement the task. If the developer hits the point of waste, they can just skip it and implement it in the next stage if needed, find another way – or not implement it at all.
Thank you very much!
