EXARING AG Distributed, Scalable Agility in the Development of waipu.tv

From Vision to Product

Even during the initial technical development steps, individual inovex experts supported EXARING in further defining and implementing their vision. These first steps comprised evaluating the fundamental concept, digitising the TV streams in real time, feeding these digitised streams into the fibre-optic ring and ultimately transmitting them via apps and Google Chromecast to televisions. Based on this fundamental concept, an initial prototype was developed. This was the “minimum viable product” (MVP), a product with a functional scope sufficient for initial testing. This principle of “lean” product development ensures that only as much effort is invested as is absolutely essential to gain useful user feedback. Companies can then use the response to their MVP to gauge whether or not there is a demand for their product and, if so, which additional features are required. At the same time, examples of personalised advertising were created in order to highlight starting points for later monetisation. This additional monetisation potential also makes EXARING AG an attractive innovation partner for television stations.

With the MVP on board, EXARING AG was ready to negotiate with investors and carry out the initial testing phase. The response of the test panel to the MVP was positive – so positive, in fact, that Freenet AG decided to jump in as an investor and strategic sales and distribution partner.

The next step involved creating an enhanced version of the product. This became the new MVP, containing sufficient features for “friendly user testing” with a closed alpha testing group. This round of tests was scheduled to begin in February 2016, meaning – as is not unusual for startups – that this phase of development was completed under a great deal of time pressure. inovex’s brief comprised the development of the frontend apps for iOS and Android (which, among other things, also process the Electronic Program Guide (EPG)) and of the backend systems – digital rights management (DRM), user account management, integration of a billing provider and marketing system, etc. The infrastructure of the ring and the management of the TV content are, however, handled by EXARING rather than by inovex.

The feedback from the “friendly users” was also positive, allowing the team to proceed with the third phase. During this phase, many of the “friendly users” remained on board, continuing to test the increasingly powerful system and providing feedback to the development team.

At the same cracking pace, the team headed for the next goal: the beta test with the closed beta testing group in May 2016. This expanded test group also remained as users in the system following the test and continued to provide valuable feedback for improving waipu.tv. Like the other test phases, the beta test was completed successfully, and waipu.tv was ready for launch.

By September 2016, waipu.tv was no longer the exclusive preserve of closed test groups. Instead, it was made available to the general public. As the product development team had been working consistently towards this date, the live launch was both exciting and nerve-racking – not, however, from a technical perspective, as the comprehensive testing and regular feedback had made the product technically stable, extremely high performing, and highly available.

In March 2017, a further milestone in waipu.tv’s product development was reached when, after thorough testing, numerous new features were presented to the public as part of a roadshow. After that, Amazon’s Fire TV was added (in addition to Chromecast) to bridge the gap between app and viewing device. Plans to add additional streaming devices are in the works.

Even today, new ideas are continually being tested. It has, for example, been proposed that A/B testing also be used in production (at feature level) and that every Sprint result be given to a beta group for testing. If required, crowd-testing providers could also be involved. These enable structured feedback from a larger audience to be collected very quickly. This setup ensures the continual delivery of new tested features – and thus, the long-term attractiveness of waipu.tv.

Agile Success Factors

Which success factors enabled such an innovative product to be created in such a short time by such a geographically distributed team? According to Scrum Master Lars Augstein (inovex), there are four factors which made a crucial difference:

In addition to the fundamental Agile success factors, four principles have proven themselves as best practices in day-to-day business:

1. Project communication: Consistent fulfilment of all the team meetings required by the Scrum process (daily Scrum meetings, Sprint Reviews/Retrospectives, Sprint Planning meetings) – entirely remotely, via video conferencing
2. Interpersonal communication: Persistent chat as a substitute for face-to-face meetings in conference or break rooms
3. One consolidated Backlog for all the tasks involved. This is very important for overarching stories.
4. Unified understanding of the Agile framework in order to define several important parameters:
   a. Definition of “ready for development”
   b. Definition of “done”
   c. Formatting of user stories

The waipu.tv team selected just a few outstanding digital tools to support their project development collaboration:

1. Jira as a central Scrum tool (Backlog, Sprints)
2. Google Hangouts, Meet, or Slack for video conferencing
3. GroupMap for Retrospectives
4. Slack for technical and content reconciliation/collaboration & socialising
5. Wiki and Confluence for documentation
6. Google Apps for Business for document collaboration
7. In-person team meetings, e.g. of iOS developers

During (or shortly before) the beta testing phase, the work stream became so complex that the development team was split into separate teams (including App, Backend and Integration), each of which had a separate product owner at EXARING. Scaling the project required a methodological solution, as the traditional Scrum concept assumes that there is only one Product Owner, one Scrum Master, and one Dev Team. As a general rule of thumb, Scrum should only be scaled when it is absolutely imperative, as doing so can get complicated and expensive. Within the Agile community, therefore, different approaches to designing successful scaling models are currently being discussed. As with all technologies and methods, there is no silver bullet which solves all the problems. Before the live launch, for example, the Scrum stream was interrupted and work continued according to Kanban principles. When it came to scaling the project, the team carefully examined ways in which the perfectly implemented Scrum setup for waipu.tv could best be enlarged. In the end, the entire product team decided against splitting up into smaller, more specialised teams. This decision was taken due to the fact that we consider communication and the integration of truly cross-functional stories across all platforms paramount, and we always adhere to the principle that any new feature for all platforms must be capable of being implemented in a single Sprint. Bearing this in mind, we constantly scrutinize each new challenge posed by a dynamically growing team, and have always found practical solutions to the problems. When creating the Backlog, we used the Nexus Framework as a basis. This gave us just one Product Backlog and one Sprint Backlog, and enabled us to visualise the dependencies with the goal of delivering an integrated increment. Another consistent principle which helped us master the scaling process was that of team autonomy. The team decided, for example, who was to be involved in which meetings. Although the Backlog Refinement phase, for example, requires regular meetings with predetermined agendas, the team worked on a case-by-case basis to decide who should attend each briefing.

Embodying agility in every aspect of the process prevented undue pressure on the team and enabled them to react flexibly to every issue that arose within the project period, which has been ongoing since October 2015. The dynamic events which occurred during the project period also included several happy ones, involving periods of maternity/paternity leave for several inovex employees. The extremely low system downtimes were another highlight which resulted from the Agile dev-ops setup. As all the teams are staffed cross-functionally with developers and operations experts (rather than having an external operations team to manage the day-to-day operation), the applications are so stable that they run reliably despite continuous releases. There has, therefore, been no need for emergency technicians to be on call to handle problems with live operations, as is the case with systems with chronic hiccups. The bottom line is that all participants live the simple, positive motto with which Benjamin Risom (Head of Product at waipu.tv) has always pushed the project forward: “Onward!”