At Blossom, we care a lot about workflows and how people interact in order to get a certain task done. We strive to understand what processes are in place at different companies to make Blossom easier to use for everybody involved in a project.This series is intended to show you how different companies approach the software development process and what matters to them.
The development workflow of Die Socialisten
For this first part of the series, I talked to Johannes Nagl from “Die Socialisten“, who are behind Swat.io and Walls.io. Johannes is a very invested CTO who made the transition from agency developer to managing a product team. He isn’t afraid of big changes and while he keeps a high-level overview, he’s still down in the trenches doing development every day!
Johannes, tell us who you are and what you do!
Hi, my name is Johannes and I’m CTO of “Die Socialisten”, a Vienna-based Social Software development agency. We used to be a very classic agency, but in the last couple of months we have evolved to a “modern” SAAS-startup. Although our field of activity is still the same (Social Media, Facebook, Twitter, …), our internal development paradigms changed totally. I’m in web-dev for almost 16 years now and it was never more exciting to create web apps than today.
Can you tell us a little bit about “Die Socialisten” and swat.io/walls.io?
“Die Socialisten” is a relatively small software agency in Vienna, Austria. We’re Austria’s only Facebook Marketing Partner and very well known for our deep knowledge about Facebook and the Social Media scene in general. A couple of years ago, we decided to start more complex software products for partners of us. The feedback was so positive and the market potential so big that we decided to standardize these products over time and jump even more on the SAAS-train to focus on these products. While Swat.io is a Social Media Management tool for teams, where you can manage your published content and your community for all major social media networks, Walls.io is more of a social media aggregator for displaying live-activity for a specific hashtag. Both products share the social media aspect but have different target audiences. Swat.io is used in many companies over years, while Walls.io is often a one-time-shot for events.
Establishing these workflows is really important and every time we did something wrong we reflected on our workflows and introduced something new.
How is the company and your team structured?
Our company consists of ~12 employees, mostly dev related. We have no big hierarchies or management overhead, almost all of our team mates (including our CEO) are directly involved in improving our products. The dev-teams for Swat.io and Walls.io are decoupled but share sales, customer success and product managers. In our working environment speed is everything – using multiple external APIs is always a bit tricky and changes to these APIs happen very often, so we try to push changes on a frequent basis (multiple releases per day). To be able to deploy often, we have to reduce the size of each work package to a minimum. For Swat.io, we end up with ~50 issues/bugs/features a week the development team has to take care. This is why we use Kanban since the beginning for both projects. In a weekly kick-off, the development team tries to prioritize our Kanban board, so every team mate is able to pick new tasks on his own.
Could you go into a little more detail on what changed when you moved from agency to SaaS provider?
Almost everything changed for us. We used to build one-time-shot marketing apps with a campaign run-time of 4-8 weeks. Although quality of these apps was one of our USPs, we had to change our mindsets completely after moving to the SaaS business. We do not make any projects any more, we do products. So every code we write should have a half-life of many years now. Code Quality, Coding Guidelines, Code Reviews, Pair Programming. This is all happening now on a daily basis. Establishing these workflows is really important and every time we did something wrong we reflected on our workflows and introduced something new.
How do requirements come to your team and how do they progress through your company for one product like Swat.io?
Well, there are three different areas of origins. First, our most important channel for new requirements: Our customers. We really love to get feedback from them and try to solve their needs (not always the same as their ideas ?). Most of the time these requirements are easy to implement, so we try to fulfill these very fast. Second, there is our very own roadmap, where we define where we would like to head to. Michael, our CEO and product manager of Swat.io comes up with quite some challenging tasks all the time. We try to keep our roadmap agile and limited to a maximum of 3 months. Although we know there are tasks in the mid- and long-term, we also know that it does not make sense for us to plan longer than 3 months. Our market is too fast and changes happen very often. That brings me to the third source of requirements: External sources like social network apis. If Facebook introduces a new API, or there’s a new hip social network introducing an API, we need to catch up with this very fast. And of course, there are a ton of API bugs we encounter every week, so our weekly sprints are often disturbed with small bugs. Hey, nobody ever said, it would be easy to talk to ~15 apis concurrently ?.
Our approach is very agile so we test some tools and if we like them: boom, they make it very fast to master/production. If we find something better, then we switch tools quickly.
What tools help you deliver your product and why?
GitHub is currently our one stop shop for all information regarding development tasks and roadmap. We store every Kanban todo as a GitHub issue. GitHub is good for storing and referencing these tasks from the code base, but it’s really bad in visualizing these issues. So we use Waffle.io on top to visualize the tasks in a Kanban-style board. As mentioned earlier, code reviews help a lot to deliver the product in a much more stable condition. As external bug tracking / issue management tool, Intercom helps us a lot! We installed the widget almost 2,5 years ago and since then our customers love us for our quick replies to any questions. Intercom is really great in getting almost any information you need (which user, which browser, on which site does a user asks something). For visual bugs we’re currently investigating the additional use of UserSnap, where you can annotate screenshots directly within your site.
Are there any tools missing from your setup?
In the last 3 years we tried to improve Swat.io and invested a lot in our tool chain. Now we’re having quite a good foundation, where we can add new things on top. One area where we aren’t there yet is automating testing. We use PHPUnit & Codeship for basic testing, but need to implement way more automated tests in the backend as well in the frontend. Our approach is very agile so we test some tools and if we like them: boom, they make it very fast to master/production. If we find something better, then we switch tools quickly. Almost everyone in our team loves Facebook’s mantra: Move fast and break things!
Do you think your current setup of GitHub, Waffle.io and Intercom is a good one? Is there something missing from the picture?
It’s definitely an improvement to our old workflows. Currently, the GitHub centered workflow is quite good for dev-related topics and cards. But what is good for developers, is often bad for others. So, especially for our Product Managers, it’s hard to filter “user related stories”. There is a lot of noise with all the technical refactorings, library upgrades and so on, so a “high level overview” about features/bugs can get very challenging.
But what is good for developers, is often bad for others. So, especially for our Product Managers, it’s hard to filter “user related stories”.
How did your development workflow evolve over time?
As said before, we were agency devs. We needed to learn more suitable approaches for SaaS tools. I’m really proud about our achievements in the last couple of years. When talking to other devs, I always receive a very good feedback. Pushing continuously small changes, doing Kanban, removing unused features, have coding guidelines in place, having a fully standardized dev-environment (Vagrant) which can be installed in less than an hour, having time and CEO-commitment for big refactorings and fulfilling all external communicated timelines is rare. But it’s the necessary foundation for “moving fast & compete in the market”.
The “Die Socialisten” team while on their corporate retreat at Lake Balaton
What are your plans to evolve your development workflow in the future, if any?
Well, there are a few challenges we face at the moment. The last years were driven by scaling our PHP backend. We’re not done yet (or never will be), but now face more problems in our UI. We try to switch to a more SPA architecture, more (internal) API-based communication. So we definitely adapt our development workflow to be JS(ON) first ?. This is quite a challenge for our devs because we are all more or less backend devs. I’m really looking forward to this next paradigm shift for us.
Thanks! Anything missing you want to point out or something?
Yes, definitely! Thanks for having me. It’s already a tradition for me to point readers to Arnold Schwarzenegger’s 6 Rules to Success – they are simply amazing: Trust yourself, Break the rules, Don’t be afraid to fail, Don’t listen to the Naysayers, Work your butt off, Give something back!
Thanks again to Johannes for taking the time to do this interview. There are some awesome insights into their development workflow, especially for small, agile teams. I love the approach of doing Kanban and not focusing too much on planning every detail for a long time but instead keep an overview over the next month and only be detailed about the very next steps.