VRT: The team and development process behind the new 'deredactie.be' app
VRT recently released their brand new ‘deredactie.be’ app. A news application that inherits the style and concept of the existing mobile site and the experience of a mobile app, basically resulting in much faster news-updates and videos. As a member of the native mobile behind this application I would like to give you a quick look into the team’s composition, our daily habits of scrum and the way we get software to our audience.
The mobile team
Our native team is part of the Digital Production Center(DPC) within VRT, a center that works closely with several brand managers to deliver new digital products.
At the moment of developing ‘deredactie.be’ we worked with 2 Android and 2 iOS developers. But at this very moment we consist out of 3 developers for each platform to create new products even faster and to make some space for maintaining our existing apps. As a member of these developers I can safely say that we have a crush on test driven development. Each and every line of code has to be tested, this is not carved in stone but it is just a habit we created over the years. One of the good things about bringing Android and iOS developers together is the way they challenge each other in code and UI difficulties. None of our issues survive a heated discussion.
To enhance our software quality we have a dedicated tester, who surprises me every time we deliver a feature. This guy surely knows where to look for possible bugs and since a few weeks we are investing in fully automated tests using Appium to increase our software quality even more.
The look and feel of our applications are very important to us, this is where our designer comes in. He is (unfortunately) not fully assigned to our team. But we can rely on him during our sprints. He ensures users don’t have to look at system-standard components.
The last member of our team is our very own product owner, who gets us out of the difficult desisions and looks for a proper planning in collaboration with VRT’s brand manangers which takes us to the next step, the development process.
Development process
Working together to create software calls for Scrum, an agile methodology that has proven itself several times. We and all other teams at the Digital Production Center of VRT work agile-based. So lets take a look at how we implement it.
Scrum
On earlier projects at other clients I’ve always missed that ‘we’-attitude. At VRT ‘we’ is the team, and ‘we’ help one another to ensure a successful sprint. This way of working has always been my preference.
Our sprints last two weeks, beginning with a retrospective to talk about the good and bad of the previous sprint and ending with a demo to all stakeholders. After we commit to our sprint-planning we start developing new features and clean up some technical debt. Each day we take just a little time to groom, which means to look at upcoming features, describe acceptance criteria and make an estimate on the level of complexity. These small meetings are the key for us to shorten the sprint-planning and avoid confusion among team members. Our last meeting is the well-known daily stand-up to quickly inform everyone of what’s going on. It takes place at 11:30 when we are all gathered around our scrum-board.
If you are familiar with scrum or are using it in your own team, you might see some differences in the way of performing it. Always remember that there is no ‘correct’ way of implementing scrum, as it is highly dependent on the team’s needs.
Continuous delivery
Now that we talked about the scrum part let’s take a look at how the team manages releases. Our goal is to get features on production environment as soon as our testers approve. Here our continuous delivery system jumps in.
Together with a feature based deployment concept a tester is able to pick a feature -> run fully automated tests -> deploy it to a testing environment -> test it -> and promote it to production environment. All of this with a single push of a button. We can even promote iOS and Android builds right to the Google Developer Console and iTunes Connect for Alpha/Beta testing. This way users will be getting their hands on our newly released features in no time.
Several releases usually take place during the sprint and we might even do multiple releases a day for our mobile sites. For our native apps we aim for several alpha releases during and one beta release between sprints.
For those interested in the technical details: we use Jenkins as a CI tool and Shenzhen & Google Play Publisher plugin to distribute our app builds. It’s no rocket science to set this up and I can highly recommend this setup to every mobile development team.
Now that I have informed you about the team, our daily developing habits and our releases system, let me end by saying that I’m very proud to be part of such a great development team and I’m looking forward to show Belgium even more of what this team has to offer!
Thank you for having us, VRT!