Our brand of ‘agile’

We interrupt our regularly scheduled programming to bring you a rare insight into operations at our secret developer base, deep in the bowels of a nondescript office building in Nairobi, Kenya. Warning: this post may be techier than usual, but we hope still intelligible to our readers...

“Our dev team does SCRUM, with user-centric, test-driven development”. We’re proud of that statement, but also very aware of how unsubstantiated that claim can sound. We’ve all heard the stories of the tech companies with 6-month-long ‘iterations’ and 3000-page specification documents that nonetheless brand themselves Agile. These horror stories could push some to follow their agile approach of choice to the letter, for fear of being swept downstream into the dreaded waterfall, but at FrontlineSMS we feel we’ve adapted much of the industry’s best practices and most trusted tools to create a process that gives us confidence in our code, and the ability to create an ever-improving product for our users.

Building robust, reusable code as a team, in a predictable amount of time and to a dynamic and user-reactive roadmap is no trivial task. Our dev team is all located in our Nairobi office, which helps. As useful as distributed source control and cloud-based progress tracking are, there’s indisputable value in sitting next to the people you are collaborating with, asking when you’re stuck, and showing off your latest one-line gem of code. We make full use of this advantage by frequently pair programming, designing mockups on the whiteboard in the office and interrupting each other with our little technical challenges all the time, as well as more formal approaches like our daily standup meetings and face-to-face iteration planning meetings.

Any agile software development proponent would feel at home at the standup meetings. Referring to our task board, each team member updates the others on what they did the day before, and their plans for the day ahead. We update our burn-down chart to see if we’re on track to complete the work scheduled for the iteration, then after a quick coffee run, we get started on the coding tasks for the day.

The FrontlineSMS dev team is passionate about releasing quality code, and our tests help with that. We have unit, integration, functional, javascript, and database migration tests, and neat metrics giving us quantified code coverage ratings for our test suite. Our task board dictates that tests are written before the first line of functional code, however much you might be itching to try out that new Grails plugin or Javascript library. Of course, tests don’t guarantee perfect code, so we’re not hesitant about refactoring and rethinking our implementations, if it makes it more stable, extendible and useful to the end user. We peer review each others’ code when testing new functionality, and change code as soon as we come up with a better way of doing things.

This attitude is extended to our processes as well - we have tried, tested and documented approaches to coding, testing, building and releasing, but never hesitate to revise our approach. The columns on our task board reflect whatever we currently feel is the most productive way to classify each new piece of functionality’s journey from idea to release, but even they change from time to time as we iteratively improve our approach to work. You could say we’re agile about being agile.

Then there’s the tools - automation is almost an addiction. From little bash scripts to one-click building and uploading of new releases, we generally aim to automate anything we can envision ourselves doing more than once. Our Jenkins continuous integration server jobs are configured to run all our tests multiple times a day, and no feature gets merged into the main development branch until Jenkins gives the green light. We’ve got an awesome dev team dashboard that gently prods you if you forget to merge and delete a completed story’s git branch, or disable the dedicated Jenkins test job. Even when the dev team might be found upstairs at the iHub, procuring a Pete’s Coffee or sharpening our foosball skills, Batman, our in-house build server, is slaving away in the corner running functional tests to ensure everything works just right. Any ideas about how to make life easier for the devs is immediately thrown into JIRA (the task management platform we use) along with the tasks for the current iteration, because we believe in improving our processes as much as we believe in improving our product.

This evolving, iterative approach is part of what makes it great being a developer at FrontlineSMS. Skeptics may doubt our standup meeting ritual, and purists may scowl at our online task board, but we are proud of our approach and think it’s the best possible way to get the most out of our team, and put the best possible product behind those download links. And when we no longer think it’s the best approach, we’ll change it again.