Day to Day work in the SI dev team

Most applicants want to know how we work day to day, so here’s a quick overview. Nothing unexpected really, but if you’re considering to apply at SI, this is for you! 🙂

Dev Meeting

We meet once a week, and discuss what we did the past week, and what will happen the coming week. We usually only talk about the larger picture tasks, as bugfixing gets slotted in on day-to-day basis. We’re agile in that we can change plans midweek if we really must. But it doesn’t happen often. We’re agile in that we never plan more than one large feature ahead – once a large feature is done and a developer is looking for new tasks, we never pick from a long roadmap, but we pick whatever looks most reasonable at that point in time (based on the critera outlined before).


We’re not doing Scrum. We don’t hate it, but we feel it’s a model that’s great for large teams that have to meet deadlines, and be able to predict so. We don’t have deadlines, our goal is building the right things efficiently. Scrum would be overkill for that. We’re a bit Kanban in that we try to not bite off too much at a time – no person is working on two major projects in parallel for instance. But we’re not religious about Kanban either. Many things we do resemble more XP: Test stuff, refactor stuff, be agile, be lean, but don’t be dogmatic about things.

We use JIRA for longer term bugtracking, and Trello for day to day work planning. We just love the “item list” feature in trello.

We use Freshdesk for support, and most bugs or problems that our customers report are fixed on the spot – only if something can’t be fixed in a day or two, we translate a support ticket into a JIRA ticket. Most of the time, we simply fix the code and move on, resolving the support case and not creating jira nor Trello Tickets at all.

We have a pretty neat change log on our website – but it only lists major customer-facing improvements, so a lot is happening behind the scenes. We’re happy to show you our git repo if you want to learn more about our dev speed.

Pair Programming?

We sometimes work in small teams on larger features, and pairing is totally fine, but most of the time we work on our own, while being able to ask for help at any time.


We all sit in the same room, and we all go to lunch together, so we know what’s happening around us and who to ask when a problem occurs. Also, we have our weekly dev meeting (even there most people already know what the others are talking about). So we don’t do standups yet, they’d be a bit of a waste of time at our current setting. But we might start conducting standups once we reach 7 or 8 full-time developers and when it becomes too hard to remember what everyone is working on. Even then we’ll not be religious about standups: Maybe we’ll have two standup meetings on Wednesday and Friday (in addition to our Tuesday dev meeting)

Continuous Deployment?

We deploy frequently: 4-5 times per week onto production would be an average number, but it can happen 10 times on one day as well in case we simply have many parallel features being worked on. We don’t do continuous deployment (as in: each commit triggers a deployment) but it’s one of our longer term goals.


Oh yes. We test. Most of our tests are in the backend, loads and loads of integration tests, and some “pure” unit tests too. We’ve got heaps of integration and unit tests for the new Angular work too, and we have some end-to-end tests, especially to test larger workflows around authorisation and authentication via web and REST API. Our CI server (Team City) runs our tests in stages, so we get very quick feedback if some commit was broken.


We use feature branches for really large things, but most of our work happens on master. We use feature switches to enable certain new features to specific customers or groups of customers. We often have “secret” pages, especially if we rewrite a feature: Then the old version remains as is, while the new version (for instance a rewrite in AngularJS) gets deployed already, but nobody except for us knows about it.


We’ve conducted two hackathons so far: One during our October 2013 US trip in New York, and one more recently in summer 2014. The main reason we didn’t have so many hackathons yet is that our team was just so small that pairing options were very limited, and time was a bit limited. Now that our team is growing, we’re aiming for one hackathon day per quarter.


Want to know more?

We’re happy to share more information here, simply send us a mail if you think something was missing!