BusyFlow integrates cloud applications into one dashboard, helping teams collaborate and work together more efficiently. The company works with numerous APIs, codes in Python and has just launched their Android app. We are talking with their CEO Jaro Satkevic on their development process – and how they adjusted it to make developers happier.
Tell us about yourself. What does your company do and what is your role?
I am the CEO and co-founder of BusyFlow. Busy Flow is app that integrates different productivity and collaboration tools, like Dropbox, Trello, BaseCamp, Google Drive and other tools into one workspace where people can see the changes, act on them and collaborate together. I am a co-founder and I manage the developer team.
Are you a developer yourself?
Yes, I am. But at the moment most of the time I am doing other activities in our start-up.
Can you tell us how big is your team? How many people and how is it organised?
At the moment we have four people. We also have two more people related to our company – a designer and an iOS developer – who help us when needed. So actually it is me and three other developers in our team.
Can you tell us about your development process? How does it typically work?
Our development process is “chaotic agile”. In my previous company we used to use Scrum with all its techniques. But we have now switched to a more chaotic process – because it is more creative. We use a few extreme programming techniques, like test-driven development. Also our client is available all of the time – it is me!
We also do weekly stand-ups. We usually do the planning on Mondays and try not to change the plan during that week. However, we do not have stand-up meetings every day, because we are a small team and talk all the time, so each of us knows what the others are doing. We also use BusyFlow to track everything – the changes made in GitHub and the tasks in Pivotal Tracker. So I feel that we do not need the daily stand-ups. We also use continuous deployment and sometimes we are deploying five or six times a day.
That’s a lot!
Actually, we are almost ready to deploy automatically. We do not have a testing server at all, so we actually push code, our Jenkins system runs all the tests, and then pushes some emails if something is wrong. And if it is OK, then we are ready to deploy.
So you do not have any testers?
We are the testers ourselves. Also, when we develop a new feature, we make it available for a certain group of people. So it is live on our system, but not everyone can see it. I think it is somewhat similar to Facebook, which delivers a feature to some groups of people. Once they test it, then it is delivered to everyone.
Sounds good. Do you have any challenges in this type of development process?
Yes, it could be more effective if you were to use Scrum techniques – but then the people are less happy.
When you work at a fast pace with daily deadlines, you can work like that for half a year, not more. We have been working on our start-up for more than one and half a year, and after some time working 10-12 hours a day under severe deadlines, you will get tired.
At the moment, we are more flexible. In this morning’s stand-ups, we did not commit to coding certain features – we just agreed on the general direction this week. There is a list of features that we would like to implement and the developers decide themselves which features they wish to implement first. They may even decide to do something else and that is OK with us. That is probably not good for me as a manager because I am not always up-to-date with what they are doing, but the developers are happier.
Do you plan to do any changes in the future? Or are you satisfied with the way it works right now?
If we have a bigger team, we will need some more structured process, just to manage everything. At this stage, we do not need it.
Do you have any advice for other start-ups or other CTOs on managing their process?
We love the possibility to deploy a couple of times a day. For example, when you get feedback from a user that a certain feature is not working and fix it in a few hours, users are really happy. This approach also makes us use a system where every feature is set up so that it can be coded in a few days. In this way, we are able to get user feedback first, instead of working on a big, month-long upgrade just to realise that the users do not actually need it.
Thank you very much!
