From Zero to Hero: The Story of the Native App Development at ImmobilienScout24 I

It was spring 2011 when ImmobilienScout24 decided to undertake iOS software development in-house. There had already been an ImmobilienScout24 app since late 2009, which had been developed by an external service provider, but didn’t meet the demands for a modern design and simple navigation. At this time, many companies were realizing that the traditional web applications that had dominated the market for over two decades were now facing fierce competition and that the future would be small, smart devices in users’ pants pockets. The era of mobile applications had begun.

As a technology-based firm, ImmobilienScout24’s early “insourcing” of its mobile software development was a logical response to these changes. And rightly so: mobile traffic now accounts for over 60 percent of the real estate portal’s total traffic.

Team structure

The iOS development team had to be completely rebuilt for this task. The initial team set-up included two experienced Java Developers, who had attended an iOS development course, an experienced freelance iOS Developer and an intern. This arrangement was interesting in terms of the differences in expertise and experience. While the experienced Java Developers had an in-depth knowledge of real estate-oriented programming and software architecture, our iOS Expert was responsible for providing iOS development knowledge and had the clear task of sharing this expertise with the team. Our young intern was passionate about iOS and integrated the latest innovations into our everyday work. As we had chosen Scrum as the development process, the team also included a Product Owner — PO for short — and Scrum Master as well as the Developers. A Visual Designer, who was responsible for the visual design of the application, completed the team which was then highly motivated and ready to start. Its task was to rewrite ImmobilienScout24’s externally developed iPhone app from scratch.

The agile development process

The teams at ImmobilienScout24 have been working with agile software development methods since 2008. It was also clear to the new iOS team that agile working is the quickest way to achieve the best results. There’s lots of literature that clearly explains this technique, so there’s no need for a detailed explanation here. Basically, the agile approach involves breaking software products down into small increments so that they can be launched iteratively, i.e. step by step. In this way, ideas can be made available to users much faster, in order to obtain feedback and implement improvements.

Any bad decisions can quickly be identified and corrected. These benefits would not be available if software had to be planned, designed and implemented as an entire product.

At ImmobilienScout24, Scrum is the agile method of choice. However, it’s up to every team to decide whether to use a different method — such as Kanban — instead of Scrum. The young iOS team stayed with the Scrum method, with its sprints, two-week work cycles and regular Scrum meetings. Every morning, the daily stand-up took place, at which every team member reported both the status of their previous day’s work and decided which tasks should be processed that day. Implementation issues and obstacles (impediments) were also discussed in these meetings. In Scrum, grooming is the name of the meeting at which the team discusses and specifies the challenges and product ideas (user story). The aim of this meeting is to define the user story in such detail that the team can begin implementation in a subsequent sprint.

At the beginning of every sprint, sprint planning took place. In this meeting, the user stories with the highest priority were examined more closely. The technical implementation was discussed and every story split into smaller tasks. At the end of this meeting, the team decided which stories were to be processed in the new sprint. At the end of every sprint, two meetings were held — a sprint review and sprint retrospective. In the first meeting, the results of the sprint were presented. In the second, the team retrospectively discussed positive and negative events and developed suggested improvements for future sprints.

The “Minimum Viable Product”

The existing app to be improved included a number of features that people had been using for months. At that time, the app had already been downloaded 1.2 million times. Because the agile approach envisages that a software product should be gradually and iteratively improved, the functionality of the first version of our app initially had to focus on the essentials. After some discussion and evaluation, the so-called “Minimum Viable Product”, or MVP for short, was defined. The real estate search, for example, was therefore limited to the most important real estate features (apartments and houses). Functions such as “save viewing appointment” and “manage search history” were removed in the streamlined version.

Of course, restricted functionality wasn’t the only thing considered with the MVP. At the same time, an entirely new design and revised navigation were also integrated and the real estate search made easier and more intuitive. In addition, stability and speed were also to be increased with the new app.

This method of starting with a small product and continually improving it was very similar to the operation of a start-up. An entrepreneurial spirit therefore developed within the team. We were proud to show that a team can operate like a start-up, even when it’s part of a larger company that has long since relinquished its start-up status. The main advantage of this approach was that feature development was driven by users and the team and not in the form of management demands to the team.

Listening to users’ requirements

It took eight two-week sprints to program our first version. It was a very emotional moment for the team when the app was released to the App Store and everyone was anxious to see how users would respond to 16 weeks’ work.

In the beginning, opinions differed. While some users regretted the absence of the missing features, others admired the new design and clear presentation of content. We wanted to let our users decide what functions the app should include in future. In order to do this, we integrated several channels through which users could communicate their feedback and requirements:

App Store ratings: the App Store includes a rating function, where every user can give a review and leave a comment. In order to help our users with this process, a rating request was built into the app. Software regularly evaluates the App Store ratings.

Direct feedback: users were also able to give their feedback and requirements directly in the app. It was important that these reached the team of developers directly and without delay, so that they could be quickly evaluated.

Our user test lab: our test lab is an important way of identifying user requirements. This is a special room at ImmobilienScout24, where users are regularly invited to test and assess our latest product developments. Designers, concept creators and software developers are involved in these tests, in order to better understand how our users think and what changes or additional features they would like.

After the user requirements had been collected from all sources, they were evaluated and prioritized. The requirements with the highest priority ended up with backlog grooming, so that they could be directly implemented in the next sprint. As well as the usability of the app, stability and speed were also a major focus. A number of mechanisms were installed to continually monitor and improve these.